Designing a mobile app can seem simple when you are sketching it out on the whiteboard. But when you actually sit down in your developer environment and get cracking, turning your ideas into reality is not always so easy.

That's only the beginning, of course. What if you need to design your app for both the iPhone and Android? You will very quickly learn that you cannot just cut and paste your design from one platform to the other. Android and iOS frameworks share some basic principles, but when it comes to design, they are as different as ebony and ivory. 

For instance, the notification bars in iOS and Android may look similar, but they perform different functions on each platform. And did you know that the action bar interface icon for iPhone is 20x20 pixels, while Android's is 24x24 density-independent pixels? Do you know the difference between a pixel and a density-independent pixel?

Here’s a quick reminder, from StackOverflow: Density-independent Pixels - an abstract unit based on the physical density of the screen. These units are relative to a 160dpi screen, so one dp is one pixel on a 160dpi screen. The ratio of dp-to-pixel changes with the screen density, but not necessarily in direct proportion. Note: The compiler accepts both "dip" and "dp," though "dp" is more consistent with "sp."

Sometimes you just need an easy chart to remember these kinds of things. Mobile cloud-service provider Kinvey created a quick infographic going over the basics of iOS and Android design for easy reference when you are pulling out your hair trying to port your iPhone icons over to an Android app (or vice versa). Check it out below.

What are your biggest app design problems? Let us know in the comments.

As the world goes mobile, businesses around the world are rushing to build app they hope will take center stage on your smartphone home screen. Most are not worth the bother. This seems especially true for apps from non-tech companies, too many of which seem to be poorly designed attempts to create intrusive commercials.

But not every app from non-tech companies fit that description. It turns out that you don't have to be an Amazon or a Google to deliver a great app experience. 

Each of the six apps profiled below fully delivers on the company's core business - making me want to remain (or become) a customer. Beyond that, they are all surprisingly intuitive and helpful. The key characteristic they share? An overriding concern for the user: 

1. CVS Pharmacy: Primary Needs

The CVS app makes great use of multiple smartphone functions. You can easily find a nearby store, use digital coupons to save money, then collect points for additional savings - all within the app.

Scan your prescription's barcode with your smartphone camera to have your medications refilled. If you want a picture from your smartphone's camera printed out, that's easy, too.

The CVS app is simple to use and packed with helpful customer-facing features. If my parents used a smartphone, I would get them this app. The iPhone version of the app has 4.5 stars and nearly 16,000 reviews. 

[iPhone] [Android]

2. In-N-Out Burger: Loyal Following

Not being from California, I am at a loss to explain the cult-like popularity of this burger chain. But, the app is as as good as a Double-Double. Basic, well-made, and exactly what the user wants.

The In-N-Out app offers turn-by-turn navigation to the nearest In-N-Out outlet. Users can store their gift points in the app. For the faithful, the app includes a full menu (including the not-so-secret menu; Animal Style anyone?), downloadable content and the "history of..." In-N-Out. Well done.

[iPhone] [Android]

3. Chase: Personal Service

Perhaps nobody likes dealing with their bank. Though I think this app is great, with more than 71,000 reviews in iTunes alone, it scores only a 3.5 rating. Frankly, I wish my regular bank's app was this good. 

In fact, for what this app allows me to do, and for how easy it is to operate, it not only outdoes other bank apps, it's far more handy than many mainstream tech apps.With the Chase Mobile app, you can scan and deposit checks into your account. It's easy to set automated text alerts - such as for being notified via SMS when you have low balance. You can pay bills through the app, get a complete overview of all your Chase accounts, transfer money, review your transaction history, find a nearby ATM, click-to-call a Chase representative - all very easily, in my opinion.

[iPhone] [Android] 

4. MLB.com: Content-Rich

If you're not a baseball fan you may not care about the MLB's "At Bat" app. This is wrong.

At Bat app's ease of use, it's incredibly dense feature set, and its simple, well-crafted design offering various additional levels of content, all billed through the app, are a thing of beauty. App developers for all content-rich sites should study At Bat.

With this app, users get the latest scores, the latest news, can track their home team, and favorite players. Set notifications for team and players - and know instantly if your favorite pitcher is chasing a no-hitter, then tune-in.  

Want more than animated game graphics? For very reasonable fees, At Bat offers options to listen to any game (home and away feeds). Pay a bit more and you can watch nearly any game, live. Games are also archived and condensed for later viewing. 

At Bat is simple to use, understands its fan base - and their varying levels of fanaticism - and offers greater content depth for each level of user. I suggest every sports league in the world just copy MLB.com's At Bat app. 

[iPhone] [Android] 

5. Grainger: Servicing Core Customers

Grainger sells all manner of industrial supplies, power tools and equipment for builders and contractors. It's been in business since 1927 - but the company obviously understands the importance of technology to support its mission, as its app is great. 

Looking for a highly specific product among thousands of options? Type it or speak it into the search box. You can have the product shipped to you or a nearby store, and track its progress in real-time. You can even get product reviews from other contractors. 

Your shopping cart and data are synched across your computer and smartphone. That's important for contractors who may need to access Grainger from a job site or back at the office. Plus you click-to-call for help, tap for the nearest location,and share purchase/needs lists with co-workers. This app knows what the company's customers need and works hard to fulfill them.

[iPhone] [Android] 

6. Lululemon: A Sense Of Community

Lululemon sells clothes and accessories, primarily for yoga, primarily for women. Its app, Om Finder, is not a shopping app, however. Instead, it focuses on helping users find the nearest and/or best yoga studio, yoga teacher or yoga class. 

The Om Finder app is simple and purposeful. It's all about helping the customer be their best at the thing Lululemon's clothing is best suited for.Users can share tips about a facility or teacher, connect with others through the app and maintain a schedule of their yoga sessions.

Sure, it's not all altruism. Many people who practice yoga are likely to purchase (still more) clothing from Lululemon. This is a smart way for the company to support its business, help its customers and foster a sense of community, all with a single, simple app. Other businesses - not just retailers - should follow Lululemon's lead.

[iPhone only] 

Great Apps Are Everywhere

The shelf life of most apps is not long. The apps listed above, however, all make my life easier, better, happier or more productive - without annoying me, intruding upon my personal space or bombarding me with junk.  

While very different, all these apps offer important lessons in how companies of all types can use mobile applications to please customers, extend their mission and leverage the power of community.

Guest author Darrell Benatar is CEO of UserTesting.com.

It seems so obvious: you have a successful desktop app or website and users are asking for mobile access to it. So you rewrite your current product for mobile. You take out the Flash graphics, rearrange the interface elements, change the font sizes and you're done. 

This sort of “porting” approach rarely succeeds. Most desktop apps and websites are carefully balanced products that have been optimized for years to fit the conditions found on a computer: high-speed continuous network connections, large screen, powerful local processing, keyboard, and mouse.

Mobile has none of those features. What it does have are many features not found in most computers including location awareness and a touchscreen interface. Porting an existing product or site to mobile almost always produces an awkward hybrid that doesn't work as well as the desktop version. 

Two Traps When Porting To Mobile

1. Nothing Changes

Have you ever used a mobile-optimized website only to be dumped back onto a desktop-optimized website? That happens a lot. These old-style Web pages force the users to pinch and zoom constantly and require a lot of horizontal scrolling. Users are often intolerant of these half-mobile sites.

2.  Trying To Recreate Your Desktop User Experience

Failure to create a real mobile experience is the kiss of death, so by now, even the most stalwart desktop software companies have done at least some mobile development. Yet that exposes them to the next big temptation: trying to faithfully recreate your software for mobile. It's almost always a mistake.

Your users, of course, will tell you they want the full functionality of your website or app transferred to their mobile devices. In reality, though, mobile device can rarely handle the same features and controls without making things way too complicated. The absence of things like Flash and a pointing device like a mouse make it virtually impossible to replicate a traditional desktop experience in mobile.

Rethink For Mobile, Don’t Port

We've learned a lot from previous software evolutions. From DOS to Windows, and from Windows to the Web, our digital history is filled with companies that couldn't rethink their strategies for the new paradigm.

The lesson from these industry transitions is clear: Don't just reformat your app or website, rethink it. Mobile isn't just a different set of technologies; it's a different set of user behaviors and expectations. Desktop computers are generally used in long immersive sessions focused on productivity or entertainment. The user expects to dedicate some time to the session and is relatively tolerant of complexity and involved processes. 

In mobile, users expect immediate gratification. The user may have only a minute available so they need to get in, accomplish something and get out. That means the basic workflow of an app or website — its purpose and structure — needs to be redesigned with that foremost in mind.

In some cases, it’s best to break your product or site into several distinct apps or mobile sites. (Facebook has been done some of this with Messages and Camera.) In other cases, the right approach may be to focus on only one area of functionality and completely ignore other features of the computer version. Or you can choose a mixed approach, with one app or website that’s feature-rich and another app that's rifle-shot focused on a single important mobile feature.

5 Tips to Avoid The Mobile Trap

1. Understand what problems users have: Users often can't do this sort of thinking for themselves. Skilled product managers need to focus on understanding the users so thoroughly that they can think on their behalf.
2. Design for the mainstream 80% of mobile users: Don't design for the technophile. You'll add too many features and make your app and site too complex for anyone else.
3. Decide which user problems to tackle first — and dump the rest: In mobile, it's better to start with an app or that does a few things well, then gradually add more functionality. Evernote does this particularly well.
4. Functionality is key: Make sure the app or site works properly and is easy to navigate. Then make that design as beautiful as possible.
5. Test for engagement, not just usability: Use all the testing tools available to you to make sure that your users will actually engage with the product you release.

If this sounds like a lot of work, it is. Ideally, a company should set up a separate team to focus full-time on mobile issues. That is not always affordable. At minimum, you should have a mobile-focused product manager who spends full time rethinking what you need to do to succeed in mobile.

The transition to mobile is dangerous. By relying on traditional assumptions about what makes an app or website effective, companies leave themselves vulnerable to new competitors who design for mobile first. However, by rethinking — instead of merely porting — their mobile apps and sites, companies can avoid falling into mobile traps and gain a competitive advantage for years to come.

Yesterday, Facebook bought Parse, a San Francisco startup with a service designed to greatly simplify the process of creating mobile and Web apps. Today, Parse's rivals are doubtless celebrating because the (reportedly) $85 million acquisition effectively puts a big seal of approval on their techniques for automating some aspects of app development.

(See also: What Happens When Almost Anybody Can Build A Mobile Business App?)

In tech jargon, outfits like Parse are often called "backend as a service" (or, worse, BaaS) companies. But they could be better described as mobile cloud-service companies. They offer services designed to easily tie mobile apps into the cloud, providing a host of automatic "backend" functions such as data storage and connections to social networks. That allows developers to focus on the core elements that make their apps sing instead of doing a lot of complicated integration with cloud systems.

One of the companies paying closest attention to Facebook's move is Boston-based Kinvey, one of Parse’s biggest rivals and a startup eager to see this cloud-service market really hit the big time.

What This "Validation" Means

Over the space of a few months in 2011, three startups effectively created this app-service automation market. Parse, StackMob and Kinvey promised easy cloud integration to mobile developers, but lookalikes quickly surfaced. Cocoafish (acquired by Appcelerator, Tiggzi (now Appery.io), FeedHenry, Applicasa from the startup end, new services from the likes of Sencha (Sencha.io) andeven Apple (iCloud) joined the fray. IBM and SAP now also offer similar cloud solutions.

(See also: Parse Offers "Backend as a Service" to Mobile Developers)

Some critics wondered if the industry segment had become too crowded and if all the outside entrants would doom the three original backend-service providers. They were small, their business models were unproven and their stories (i.e., “we provide backends so you don’t have to") were quickly in danger of being drowned out by competition claiming the same thing. There was a time in 2012, before it raised its first venture funding, when Kinvey had serious doubts if it would make it.

A map of the BaaS ecosystem from Kinvey from February 2012

Then these companies, which initially had started as developer tools, started turning into actual businesses. StackMob and Kinvey found that big companies were really interested in their services. Parse started attracting brands like the NFL's Green Bay Packers, Hipmunk, Armani and the Food Network.

(See also: Bringing Enterprise Data To Your Mobile Workers)

It's no coincidence that Facebook named Parse, StackMob and Kinvey (along with the likes of PhoneGap and Sencha) as preferred technology partners last week. These are companies with useful skill sets. All three have done extensive work with Facebook in the past. 

Many in the tech community associate “validation” of a new technological or business approach with startup venture funding or outright acquisition. But the likes of Parse arguably found validation much earlier, with the arrival of big, high-profile customers. 

“Lots of people are saying [the Parse acquisition] ‘validates’ the space,” said Sravish Sridhar, CEO and co-founder of Kinvey. “I disagree. The space was validated when brands like J&J, Aetna GSN and Cadillac began trusting their data and apps to BaaS."

Sridhar has a point. But until Parse sold out, none of these startups had entered the "big money" realm of tens of millions in funding, revenue or acquisition. In that sense, the Facebook-Parse deal has definitely lifted the prospects of StackMob, Kinvey and the rest of their competitors.

Where Do These Startups Go From Here?

Parse reportedly had a long line of suitors. Facebook won the bidding, but Dropbox, Google and Yahoo also all apparently had interest, according to Wall Street Journal reporter Evelyn Rusli. A variety of other companies have also shown interest in the backend-service startups, including Salesforce (customer relationship management), Intel (chip manufacturing and developer tools) and classic enterprise service providers like IBM and SAP, which have acquired mobile enterprise application platforms (MEAPs) in the past. 

Dropbox had also bid for Parse-- didn't meet fb's offer though.. google & yahoo also expressed interest ---

— Evelyn Rusli (@EvelynRusli) April 25, 2013

When parsing what the Parse acquisition means to companies like Kinvey and StackMob last night, Kinvey’s head of marketing Joe Chernov turned to Sridhar and said, “Do you know of any other tech space that has so many different kinds of big companies wanting to acquire its vendors?"

It's a good question and one that should have the likes of Kinvey and StackMob hi-fiving, jumping in their seats and making plans for happy hour. 

Twitter will be the next company to watch. It recently bought Boston-based Crashlytics and Bluefin for a total a little less than $200 million. Twitter is beefing up on its own application ecosystem (see: Vine and Twitter Cards) and could very easily find a place for backend services in its app efforts.

As programming tools become increasingly accessible, it’s not the actual building of a mobile app that’s difficult. It’s the time it takes — and the risk nobody will ever use it. Studies estimates that 26% of mobile apps are used just once, and more than 60% never get downloaded at all.

We are well into the age of the disposable mobile app. Now, according to Raw Engineering, the makers of Built.io, we have the fast, easy to use app-development technology to match. 

Temporary, Disposable Apps

Today, many businesses create apps for a variety of occasions, including one-time events like conferences and product announcements. But for most businesses, building these apps is a process that can take several months. At Demo Mobile 2013, Raw Engineering CEO Neha Sampat showcased an app her team built in a week. 

“The life of an app used by enterprises is sometimes as short as a month,” said Sampat. “If it takes you three to four months to build an app you’re only going to use for a month leading up to an event or a conference or an announcement, there’s no [return on investment] there.” 

Leveraging Built.io, Sampat said, app development can be almost “plug and play.”

“We provide the back end, the building blocks, the basics of the app ready to go - and they can spend their time working on user experience and the app itself.”

Crowded Market For App Development Tools

Decluttering the back end of app development is a mission on everybody’s mind. Built.io joins a crowded market, including services like Parse (just acquired by Facebook), Kinvey and Cocoafish. But here’s what makes Built.io different, for better or for worse: anybody can use it.

(See also The Rise Of Mobile Cloud Services: BaaS Startups Grow Up.)

Creating new apps requires a developer’s assistance. But "once the app is built and available, [employees] can log into the [content management system] and upload additional photos, press releases, anything they need to do to update the app without running to their developer or IT department,” Sampat says. 

The easy-to-use, what-you-see-is-what-you-get visual design is intended to make app upkeep less of a headache for developers. But developers have also historically been gatekeepers. When everyone and everyone at a company can make updates to the company app, what’s to keep the company app from becoming a huge, cluttered mess?

Developers In Charge

To avoid that, Built.io keeps developers in charge. A Built.io feature lets them assign roles and privileges to specific users. For a conference app, for example, the developer might give the organizer permission to update event names and times, but not to alter the structure of an app. 

Built.io has the potential to make developing a company app so fast and so easy (the beta is free) that everybody in the office may want to create apps for every purpose they can think of. The question yet to be answered is whether non-developers will use their newfound powers for good - or end up helping to churn out useless apps on a weekly basis, adding to the existing glut of unwanted and unused mobile apps.

Photo and screenshot via Raw Engineering

This week has been full of news on wearable devices: First the report from The Wall Street Journal that Microsoft is fabricating a smart watch (whether it’s just a prototype or an actual product is not confirmed); then Google’s release of guidelines for developers building apps (known as “Glassware”) for Glass; followed by the news on Wednesday that Google will start shipping Glass units to participants in its Explorers program.

(See also Google Glassware: How Developers Can Build Apps For Google Glass.)

To put these stories in perspective, Glass is a much, much more important story than any smart watch story — whether that watch is made by Microsoft, Samsung or even Apple. Smart watches could enable new “glanceable” experiences that we haven’t had on other devices, enhanced by body-generated data, like the Basis smartwatch does today. But they won’t fundamentally disrupt social norms in the way that Glass will. At best, they’ll reinforce existing ecosystems for smartphones — i.e., iPhone buyers might buy an iWatch; an iWatch might displace some phone usage, but wouldn’t replace a phone altogether.

Google Glass Could Be The Next Big App Platform

Smart watches are incremental steps forward toward the smart body future, but Glass is a giant leap forward in shoes propelled by rocket fuel. There is a very real chance that consumers will reject Glass, consigning it to the geeky niche of Bluetooth earpiece headsets. But if Glass succeeds, it could be the next iPhone: the next great platform for app development — not just for professional software developers but for non-tech companies like media, banks, retailers, hospitals and every other entity that wants to engage its customers or employees digitally.

Three initiatives in particular stack the deck in favor of the Glass success scenario.

First, Google’s transparent approach to product development gives Google insight into how consumers envision using Glass, identify concerns early and adapt its product and marketing accordingly, all while building buzz among socially connected early adopters. (Key fact: 68% of Glass Explorers have 1,000 or more followers on Twitter.)

Second, the new Glass Collective seed fund from Google Ventures, Andreeson Horowitz and Kleiner Perkins ensures that Glass-related apps, accessories and other products get the investmeent they need to feed the Glass ecosystem — just as iPhone app startups got in 2008.

The third initiative — Google placing restrictions on app developers in support of the user experience — takes on the biggest barrier to Glass adoption.

Wearing Glass creates a new experience not just for the person wearing the device, but also for everyone near someone wearing the device. Initial curiosity could quickly fade to annoyance when talking to someone seemingly distracted by a display you can’t see.

(See also 5 Socially Unacceptable Things You're Going To Do With Google Glass.)

And then, of course, there’s the anger and frustration you feel when your likeness is photographed or videoed, autotagged and shared without your consent or control.

(See also Google Glass: Our Lives Are Not Reality TV.)

We already live this every day on Facebook; Glass just accelerates the phenomenon. The hardest challenge for Glass to overcome is not making the technology work or attracting developers, but establishing social norms around the device that draw people in rather than making them want to run for un-surveillanced cover.

Google Can Influence How People Use Glass

Google can’t control consumers’ manners — if you’re rude enough to text on your phone at the dinner table, you’ll be rude enough to read texts on Glass in front of other people. Your rudeness is not Google’s fault any more than it is the phone manufacturer’s fault. Still, Google, Glass Collective investors and app developers can influence the degree to which Glass supports, rather than distracts from, human goals (see Adam Gazzaley’s research at UCSF to understand what I mean).

Google is moving Glass in a positive direction, forbidding apps with advertising on Glass, forbidding apps to access sensors on the device and forbidding apps to track and share user data for advertising purposes - at least to start. The New York Times Bits Blog quotes Google advising app developers to “make sure apps do not send updates too frequently and to be sure to avoid doing anything consumers do not expect,” and get users’ explicit permission to do things on the user’s behalf.

This is a smart move on Google’s part. It not only supports consumers’ interests but also makes it more likely that using Glass — and being around someone using Glass — will be a positive experience: The less intrusive and distracting the experience of using Glass is, the more Glass wearers can focus attention on the people they’re with or the task they’re trying to accomplish.

(See also Is There Any Way To Jam Google Glass?)

We will all play a role in shaping how Glass fits into our lives and our culture. Consumers must take ultimate responsibility for how they use the device, but it’s encouraging to see Google playing its part.

Google Glass just got a little bit more real. If you were worried that Google’s augmented reality glasses were a pie-in-the-sky concept that might not ever become a real product, you can relax. That is not going to happen to Google Glass.

Google released the tech details to Glass this week - along with everything that developers need to know to build apps for the specs. Called “Glassware,” the Google Mirror API is designed to let developers create innovative, useful and fun apps for the forthcoming Glasses.

What can you build and how do you build it? Let’s break it down.

Java Or Python

Google recommends two programming languages for building apps for Glassware: Java and Python. For Java, developers will need Java 1.6 capability, Apache Maven for part of the build process and the App Engine SDK for Java. Apps can then be built in Eclipse, an integrated developer environment (IDE) for app building. Developers will need to create an OAuth verification and tie their Google account to their Glasses and allow access to Google’s Glassware API and access the SDKs. 

It is essentially the same for Python, except you do not need Maven or Eclipse. Developers use the App Engine SDK for Python to start. 

Add A Cat: User Interaction

Users of Google Glass interact with apps on a timeline. These items, or “cards” display information to users (like weather, business information, search results and so forth). Glassware is accessed from the cloud, not locally on the device, and developers call upon a RESTful endpoint to carry out actions such as creating new cards, updating cards, receiving input or subscribing to Glass push notifications.

Google uses the example of a cat to show off examples of the Mirror API. For instance, a user could automatically composite a picture they have taken with a random picture of a cat accessed through the API. Here is a work chart from Google on how a developer could "add a cat to that.”

Since the user is so fond of cute little kitties, she might decide to find the nearest pet store after adding a cat to her most recent picture. Glass can do that as well. Glass will fetch the user's location, run the search and “pin” a card to the user’s interface as they move around in search of a pet store. 

Timeline + Cards

This timeline + card interaction is the primary method of building apps and functionality for Glass and for users to interact with the hardware. Timeline cards can be text, images, HTML or video. Essentially, anything you can create on the Web can be created as a timeline card in Glass. 

If you add the capabilities of Glass to what we know of the timeline cards, we begin to get a clearer picture of exactly what can be done with Glassware. The primary hardware features of Glass will be location ability, photos with a 5-megapixel camera, videos shot in 720p, Wi-Fi, Bluetooth, 12GB of usable memory synced with Google cloud storage (16GB Flash memory total) and a full-day battery for “typical use.”

So a user could take a picture, search the contents of it, save the picture to a Google+ profile. If a user subscribes to a service, that service can send push notifications through Glassware tied to location. Examples could go on and on. Thoughtful and innovative developers will have a field day with Glass capabilities, extending what a smartphone can do to a device specifically designed for augmented reality. 

Glass can be tied to a smartphone through an app called MyGlass. To enable GPS or SMS, Glass will need to be tethered to a smartphone through MyGlass.

Guidelines For Glass

Google has four primary guidelines for developing for Glass:

1. Design for Glass: Do not design for another device, like a smartphone, and import to Glass. Because Glass is unique in how users interact with it, Google suggests that you developer directly for it.
2. Don’t get in the way: Apps should be for users, not for developers. Don’t be pushy with notifications and other information.
3. Timely: The goal is to provide users with up-to-date information with Glass. Make sure your app responds with correct information in a timely manner.
4. Avoid the unexpected: Imagine walking down the street and Glass sends you an unexpected notification. This can be annoying or even dangerous. Make sure the user has given explicit permission to be notified in Glass.

What Google Won’t Let You Do

Google does not want developers placing their own advertising in their Glassware. Part of this is likely because Google wants the user interaction to be free from clutter and pleasing to the user. Another reason may be that Google would rather be the one monetizing the data collected from Glass through its own apps and services - like Google Now. 

Google prohibits developers from gathering data of any kind for advertising purposes and will not allow developers to charge fees or collect payments for downloaded apps. Developers may not tie payment to virtual goods or upgraded functionality.

Essentially, Google has made it impossible for developers to make money from Glassware apps. No ads, no in-app payments or “freemium” functions will be allowed. This should help protect the user experience, but may slow developer participation past a certain point. Why would developers bother to create Glassware timelines and cards if they can't make any money from it?

Are you going to build apps for Google Glass? Let us know your plans in the comments. 

Do you like video games? More to the point, do you like developing games and making money? Then here's some great news: The gaming boom that's been underway for the past few years is still picking up steam.

And the good times should keep rolling for years— at least, that is, through 2018 or so. But by that point you'll have had plenty of time to establish yourself, or even to have made your pile and retired.

Why Games Are Hot

Everybody needs games. Like, everybody. Games to pass the time. Games to learn. Games to compete. Games to prove yourself. Millions of years of human evolution and games, in one shape or another, have been there every step of the way.

Now we have computers, ever evolving gadgets that allows to do many, many things. But, what have people done with computers since the advent of the personal computer in the early 1980s? That's right, they played games. In many ways, games define computing. And that's never been truer than it is now in the midst of the mobile revolution.

With a billion smartphones in the world and tablets reaching hundrends of millions of consumers, the opportunity for mobile developers to create successful and long lasting careers in gaming is now. It's a new renaissance for the game and an opportunity to build an industry that will last for decades.

The rise of the app ecosystem is directly correlated to that of mobile games. Millions upon millions of users have launched irate fowl at impertinent pigs, run from ghouls escaping a temple and built empires one block at a time. Mobile, social and connected games have been a huge boon to developers.

The total app ecosystem amounted a $2.2 billion worldwide market in the first quarter of 2013, according to research firm Canalys. That's up 11% from the same time in 2012. The revenue comes from paid apps, in-app purchases and subscription services; it doesn't take account the growing (and increasingly complicated) mobile advertising sector. Games produce the lion’s share of that revenue.

All Types Of Games, All Types Of People

Take a quick glance at the current top grossing apps in both the iOS App Store and Android’s Google Play. Of the top 30 apps on iOS, 23 of them are games. The rate is even higher on Android, where 28 of the top 30 are games. That’s a lot of games.

And there's no particular rhyme or reason as to the types of games that are pulling in the bucks. They run the gamut from console remakes like Final Fantasy, to new legends like Angry Birds, to slot machine replacements like Slotomania (currently No. 7 on Google Play's top grossing charts). These games cross gender, generational, ethnic and racial boundaries. So there's lots of running room if you're looking to get into gaming development.

Top grossing games, Google Play, April 2013

Mobile analytics and advertising firm Flurry breaks down the types of games that people play by gender and age demographic. The biggest cluster belongs to young adult males (aged 25-30), who play card-battle games, strategy, shooters, racing and action role-playing games. Younger women tend to play more brain/quiz games, management and simulation and match/bubble puzzle games (like Candy Crush, No. 1 grossing in both Android and iOS currently).

Older women play more social turn-based games (think Farmville), slots games or solitaire-style card games. "Runner" games (Monster Dash or Temple Run) and arcade-style games (Angry Birds) are more gender neutral.

A Stable Market

We are now in year 6 of the mobile revolution. As mentioned above, people around the globe were using more than a billion smartphones as of late 2012. Another billion are expected to come online over the next three years. After that, who knows? Developed countries have hit a saturation point — most U.S. and Western Europe consumers already own smartphones that they continue to upgrade when new versions come out. Emerging markets like India, China, Eastern Europe and the Middle East will drive much of the growth over the next five years.

Flurry estimates that 32% of smartphone user time is spent on games — and it's been that way for a while. As the mobile revolution matures, we now have historical usage data to look back upon and make definitive statements about which categories will remain strong and which were mere fads.

There's little reason to think that mobile gaming is in any type of “bubble.” Games investment bank Digi-Capital expects the entire gaming sector to produce $83 billion in revenue (excluding hardware) in 2016. Mobile is predicted to contribute more than 10% of that overall revenue, perhaps $10 billion to $15 billion. Gaming investments will continue to climb and mobile will be the largest category, with nearly mobile far and away the leader in capital investments.

If you're a game developer, there are many ways to not just make a living, but to make yourself quite wealthy. If you can crack the top charts on iOS or Android (or even BlackBerry or Windows Phone — even better, all four) then you can be looking at a substantial payday. If not, it's an even bet that if you have a good product you could pull down some substantial venture capital dollars or get snapped up by one of the larger game makers. 

Everybody in the world has the potential to have some type of computer in their pocket. You know what are going to be some of the first apps on those computers? Yup, games. Mobile game developers are facing a Golden Age. One that is not going to end any time soon.

Top image: Soul Caliber for the iPad

1. Hire A Good UI Architect – Now 

2. Hand Out A Free Download 

3. Offer A SaaS Option 

4. Get Out Of The Way 

Last week, Google unveiled Keep, a note-taking service similar to, but much more limited than, established apps like Evernote and Apple's Notes. But there's another service to which Google Keep bears an uncanny resemblance: Voice Actions, an Android feature Google launched more than two-and-a-half years ago, only to see it almost completely eclipsed by Apple's Siri.

It's no wonder, then, that Google Keep is essentially Voice Actions with a fresh coat of paint. Although Keep improves upon Voice Actions in a few ways, there's a great degree of overlap between the two. And, in some cases, Voice Actions is simply better.

As a note-taking and reminder app, Keep takes aim at both Evernote and Apple's Notes. But it's worth, er, noting, that each major smartphone platform now has its own dedicated note-taking app: Google Keep, Apple's Notes, and OneNote for Windows Phone. And, of course, there are a number of other competitors.

Google Keep's functionality really boils down to just three features: quick notes, checklists, and photos. Keep can also transcribe (and maintain recordings of) notes that you input via voice, which Android already does for SMS messages, Twitter tweets, Facebook posts, and a number of other apps within Android. Google Keep may have inspired multi-page reviews, but you should pick up the basics within minutes. 

How Voice Actions Beats Keep

With the right command words, however, Voice Actions can do many of the same things, albeit in a slightly different format. With Keep, you must open Keep, and then choose one of the four actions (or enter a Quick Note at the top). Choosing a Note allows you to select a title, enter the note, and save. With Voice Actions, just trigger the mic, say "Note to self," and the note. Android will transcribe it while you watch, pause for a split second for your review, and then announce, "Saving note" - which it then emails to your Gmail for later review.

Likewise, saying "Remind me to go the dentist at 3" with Voice Actions creates a Google Calendar event for 3 PM, identifying the location as "the dentist". That's miles ahead of Keep, which merely creates a note to that effect. 

Keep's one advantage seems to be the checklist, which creates a to-do list that you can check off as you accomplish it. Voice Actions has nothing comparable. (It could; imagine a list triggered by "to do": "To do: go to the store, buy milk, phone grandma.") What I'd like to see in Keep is a checklist that could be shared with someone else in real time, so that by the time I arrived at the store I knew exactly what my wife wanted me to buy.

Why Voice Actions Didn't Keep

Google has always struck as me as a for-profit university of sorts, with the broadest of mission statements: "Go forth and collect data, which you shall then sell ads against." Keep either seems be a recognition that Google's earlier efforts with Voice Actions failed to generate the attention they deserved - or, equally likely, that another of Google's product teams merely reinvented the wheel.

Call it what you will — the tyranny of the masses, entropy, or just a growing fascination with ephemera — the truth of the matter is that as more and more free and low-cost applications are hurled at consumers, there is less and less time to become familiar with The Next Big Thing before it, too, is superseded. Voice Actions is a solid, fundamental piece of Google tech, but it simply isn't as integral to the Android experience as say, Apple's Siri is to that of the iPhone.

If this is true, then perhaps Keep will incorporate other Google technologies which have been somewhat forgotten: image recognition (Google Goggles by another name), collaboration (Google Apps, anyone?), or shared location (Google Latitude). 

Stick around long enough in Silicon Valley, and someone will come up with a new twist on an old idea. Even, sometimes, within the same company.

Guest author Sanjay Poonen is head of SAP's mobile division.

Mobile devices have become the world's steady companions that we take anywhere and use everywhere. A recent forecast by McKinsey & Company estimates that by 2014, 1.7 billion mobile devices will be accessing the Internet - and a steady diet of online content. Widespread smartphone and tablet adoption is giving birth to a new ecosystem of mobile apps. Apple with its iTunes App Store is currently the gold-standard of the mobile experience, and it enables distribution to millions of users. In early 2013, Apple announced that users had downloaded an astounding 40 billion apps from its App Store, with almost half of that total logged in the last year.

The rollout of smart mobile apps yields numerous benefits not only to consumers but also for the enterprise. Mobile apps for business must offer the expected, Apple-easy download experience, but the enterprise requires quite a bit more for apps to be successful and risk-free. Many companies are struggling to manage the proliferation of mobile apps and connect to business content.

Here are seven critical areas for enterprises to address as apps multiply through the mobile enterprise ecosystem.

1. Not Point Products: Using An Enterprise Mobility Platform

The basic foundation of the mobile enterprise begins with deployment of the devices - employee and corporate-owned — along with a portfolio of productivity apps. The goal is simple: The user downloads an app and starts using it. All onboarding, app registration and bootstrapping is done by the enterprise mobility platform — the server strings, logon information or certificates are pushed to the user’s device automatically.

2. Configuration: Based On Roles And Responsibility

Deployment and configuration policies have to go hand-in-hand. Ultimately, enterprise workers want to be able to use any device and any app, accessing content without any roadblocks. Ideally, if an employee has an iPhone or Android phone provided to them, they will immediately have the secured content and correct business apps configured based on their roles and responsibilities (finance, HR, sales, etc.).

3. Deployment: Cloud vs. On Premise

Enterprises have a choice of where they get content and apps. They can come from the cloud, be stored on premise, or in some hybrid combination. This piece of the mobile equation doesn’t have a correct answer, but IT has to remain keenly aware where each component of mobile content resides and (most importantly) who has authorized access.

4. Beyond MDM: Managing Devices, Apps, Content And Things

IT must maintain control over how mobile devices access corporate information: At the very least, IT has to be able to turn off the device, content or app if the mobile hardware is lost or stolen. A key component of that is creating lockable configuration and security policies. Mobile Device Management (MDM) software helps IT centrally manage, secure and deploy mobile data, applications and devices, including tablets and phones. The journey continues beyond MDM to Mobile App Mgmt (MAM), Mobile Content Mgmt (MCM) and eventually takes you on the journey to securing not just devices but every machine in the Internet of Things.

5. Security: At Every Stage In The Lifecycle

A Symantec study calculated that the average annual cost of mobile breaches for an enterprise business was $429,000. Security has to be part of the fabric of mobile throughout the enterprise. It must be integrated into the initial mobile strategy - and into each subsequent stage in the mobile lifecycle. It must be nimble and designed for the post-PC era of mobile computing.

6. Interoperability: Take A Cross-Platform Approach

In a mobile enterprise, all devices, apps and cloud services need to recognize each other and be able to share content. As we deal with a combination of HTML-based mobile-Web apps and device-native apps, three key factors contribute to interoperability.

First is cross-platform support. Most enterprises will have to cater to Apple's iOS, Google's Android, Microsoft's Windows and BlackBerry.

The second factor is backend connectivity: While all mobile users will run Tripit, for example, against the same hosted backend, your enterprise apps needs to run against your company’s backend systems. For example, a customer relationship management (CRM) app needs to access your customers in your CRM system. A Leave Request app has to run against your own enterprise resource planning (ERP) system.

Third, enterprise apps must adhere to your company's information technology security standards. Employees will access your corporate data from the open Internet, and you need to safeguard your business data.

7. Mobile Apps: Buy And/Or Develop Your Own

Mobility starts with the app creator, which could be an individual developer, a customer who wants to develop an app, a partner or an internal development team. Many larger organizations will benefit by designing their own apps for mobile-enabled business processes. These mobile solutions can tap into different applications and workflow tools using dashboards to monitor everything from sales to the health of the entire business in real time.

Some apps may be developed and used internally to solve a specific task in the company. Others maybe standardized to be sold via the various app stores, both platform specific outlets such as the Apple App Store, Google Play, Windows Phone App Store or BlackBerry World.

Guest author Todd Anglin is EVP Cross Platform Tools & Services at Telerik.

For HTML5 developers and decision makers, the most important technologies right now are HTML, JavaScript, CSS, mobile platforms and devices and evolving HTML platforms (browsers and operating systems). But what does that mean in the real world? It means these 10 things in 2013:  

1. Rise Of HTML5 Mobile Platforms

HTML5 has played an increasingly important role building cross-platform apps for mobile devices. So far that has primarily been done using native “wrappers,” such as Cordova, which allow HTML and JavaScript to power apps on other native platforms (such as iOS and Android). This technique is called “hybrid” app development.

This year, though, a wave of emerging platforms will support HTML5 apps as a first-class citizen - no wrapper required! The biggest players will be Chrome OS, which is about to get much more attention from Google; Firefox OS, already scheduled to start shipping on low-end ZTE and TCL devices in Europe; Tizen, a new HTML-focused platform backed by many industry heavyweights, including Intel and Samsung; Ubuntu Phone, which brings the most popular flavor of Linux to phones, again with a HTML-centered ap strategy; BlackBerry 10, which puts HTML and JavaScript at the center of its next-gen app strategy; and Windows 8, which introduced a new HTML and JavaScript development model for it’s “Windows 8 style” apps.   One (or more) of these platforms is bound to succeed in 2013. My money is on Chrome OS and Tizen. With the backing of Google, a revamped developer and consumer push, and the broadest platform strategy (spans mobile and desktop), Chrome OS is very well positioned.

Tizen, meanwhile, enjoys broad industry backing from Intel, Samsung, NEC, Panasonic, Sprint, Huawei and Vodafone (among many others), and engineering stewardship in The Linux Foundation. It shows the most potential to challenge Android as the “more open” (read: more customizable) open source device platform, which should appeal to device makers.  

2. Made For Chrome(kit)

A growing number of sites are once again buildiing Web apps tested to work in only one browser. Like the “Made for Internet Explorer” badges of the 1990s, developers are now proudly advertising “Made for Chrome” in their apps. Not using Chrome? No guarantees.   This trend is likely to accelerate in 2013.   With a rapidly evolving, highlycapable browser platform that is available on virtually every major operating system (Windows, Mac, Linux, Android and kinda iOS), and a Webkit foundation that helps deliver a little extra compatibility with other non-Chrome browsers (like Safari and BlackBerry browser), developers are likely to conclude that the “good outweighs the bad” when it comes to building exclusively for Chrome.   In exchange for potentially alienating some users, developers building for Chrome can more aggressively leverage HTML5 APIs and save valuable development and testing time.  

3. IE10 Euphoria - And Pain

Internet Explorer 10 is widely regarded as a huge step forward for the venerable Microsoft browser. With more support than ever for Web standards, IE10 goes a long way to put Microsoft’s browser in the modern HTML5 conversation.   But as fast-updating browsers like Chrome and Firefox race forward through 2013, IE will once again be left looking old and slow. There is a glimmer of hope that Microsoft will evolve IE more quickly: The Microsoft-owned HTML5 Labs, launched originally in the IE9 days, is continuing to publish new “experimental” improvements for IE10 that make it an even more capable HTML5 browser. Baby steps, but still a good sign.  

4. The Death Of IE6, IE7 & IE8

While IE10 will be in the spotlight, the long death march for Microsoft’s older IE versions will continue. Only the most stubborn corporate environments (and China) still require IE6 support, and much of the world skipped IE7 anyway. If you haven't already stopped supporting IE6 and IE7, 2013 is definitely your year.   Dropping IE8 is a bit more of a stretch, but the pressure is on. Not only does IE10’s release make IE8 two versions old (often used as a “clean” support cut-off justification), but jQuery 2.0 will join Google Apps in cutting-off IE8 in 2013. By the end of the year, most developers will conclude IE8 is not worth their time.  

5. The Death Of Android 2.x

Until recently, it looked like we had another IE6 on our hands with Android 2.x (Eclair, Froyo and Gingerbread). According to Google’s own stats, as recently as mid-2012, these versions of Android (mostly 2.3.x) represented more than 90% of all Android devices in use, despite the fact that Google was already shipping Android 4+! Google was failing to keep its Android user base (and ecosystem) upgrading.   Fortunately, the 2012 holiday season seems to have broken the logjam. Usage of Android 4+ (Ice Cream Sandwich and Jelly Bean) surged to nearly 40% at the end of 2012. By the end of 2013, Android 2.x will likely account for less than 15% of the market, and Android developers will be able to shift focus to versions 4+.  

6. Responsive Design Goes Mainstream

So far, responsive design has remained on the fringes of Web development - something nice to do “if you have time."   That's about to change. With the lines between PCs and mobile devices increasingly blurred, developers will have no choice but to develop websites and apps that can dynamically adapt to an unpredictable array of screen sizes and resolutions.

(See also The New ReadWrite: Looking Good On Every Screen [Video].)

To ease the way, look for new techniques and defacto standards to also emerge, offering guidance for properly dealing with different device capabilities and form factors.  

7. Mobile Development Overtakes Desktop

It doesn’t take an expensive analyst to see the growth in phones and tablets while traditional PCs fade. Right now is the moment when developers will begin spending more time developing software for mobile devices than for traditional desktop PCs, extending from the consumer market to businesses of all sizes, for both internal and external audiences. If you’re not developing for devices in 2013, you’re either A) maintaining legacy software, or B) missing the boat.  

8. HTML On The Desktop

Just because mobile is on the rise, don’t start writing an obituary for desktop development. The traditional desktop form factor will remain critical for many information workers. But as the PC becomes one among many screens, developers will look for ways to write code that can be shared across the PC and mobile devices.   HTML and JavaScript are perfectly positioned to offer this capability, and platforms like Chrome Packaged Apps and Windows Store Style (WinJS) apps will make this possible. With both Microsoft and Google pushing HTML for desktop app development, developers will take notice and start embracing cross-platform desktop development with HTML and JavaScript.  

9. SPA Time

With the shift of desktop development and increasingly complex mobile apps to HTML and JavaScript, developers will recognize the need for new techniques to build maintainable cross-platform apps. The “Single Page Application” (or SPA) has been on the rise thanks to powerful frameworks like Backbone, Knockout and even Kendo UI. If “RIA” (Rich Internet Applications) was the buzzword in 2010, “SPA” will be the buzzword in 2013.   If you’re looking for the one new technology or concept to learn as an HTML and JavaScript developer in 2013, it's SPA architecture.  

10. HTML Gets Naked (Again)

Now that the W3C has “finalized” HTML5, public conversation and media coverage is going focus on what’s next for the Web standards platform. The W3C is already working on HTML 5.1, the next “snapshot” of the “living standards” work done within WHATWG, the Web Hypertext Application Technology Working Group. But as we move past the “HTML5” bubble, we’ll once again settle-in to talking about HTML, sans version numbers. After all, who wants to talk or write about “HTML5.1” or “HTML5.3”?   Whatever it’s called, the next wave of HTML platform improvements will shift focus beyond the lower-level core at the center of HTML5 (DOM elements, CSS styles, Simple JavaScript APIs like Geolocation) and instead characterize improvements that are important to more robust application development (like ShadowDOM, Web Components, CSS layouts, speech recognition and more).

The HTML conversation (and technology) will continue to evolve, even if the version numbers don’t come along for the ride.

Image courtesy of Shutterstock.

Guest author Anthony Smith is CEO of Insightly.

You may have read a lot of articles last year about why the so-called "freemium" model doesn’t work for most consumer-oriented companies. And it’s true that offering a base-level product for free to gain visibility and marketshare and then converting a subset of users to a paid, premium version is not a viable strategy for every business.

However, depending on the product you’re offering, the freemium model can work well for business-to-business (B2B) companies, and especially well for B2VSB (business-to-very-small-business) companies.

(See also Why Free Is Bad: Businesses Should Be Happy To Pay For Key Services)

Here are six questions to ask yourself if you are entertaining a freemium model for business customers:

1. How big is the target market? For a freemium model to work, you need to make sure your audience is extremely large, since typical conversion rates range from 3% to 10%. According to the Small Business Administration, in 2009 there were almost 28 million small businesses in the United States. (The SBA defines a small business as one with fewer than 500 employees). Let’s say your business captures 2% of all the small businesses as free accounts, and 3% of those convert to paying customers. That’s almost 17,000 paying customers. Based on your business model is that enough to sustain and grow a profitable business?

2. What is the value of a free customer? By offering your product for free, you run the risk of cementing that value in the minds of customers. The flip side of this is that when you’re trying to build a brand and a user base, the freemium model makes it easier to get exposure, a base of quality leads, the potential of high virality and a built-in sounding board for essential user feedback.

3. How does your product impact the daily lives of your users? Do your users recognize that your product makes their work life more productive, more efficient, more organized or more informed? If so, converting from a free version to a paid version will be a natural progression.

4. Does your product help grow your customer’s business? If your product offers some kind of analytics or metrics that can be used to measure an aspect of the health of the business (i.e., sales, efficiency, productivity savings or gains), then it’s easier to align your product with the growth of the company and easier for a small business to justify spending dollars on it.

5. What is the best conversion metric – transactions or users? Both models have pros and cons. In many cases, users like the transaction model because it’s often pay-as-you-go. However, sometimes a transaction model can be perceived as nickel-and-diming the user. A user license is another common conversion metric, and it may be easier for your customers to swallow as they try to justify the budget to convert from a free account to a paid one. If it makes sense, you can may be able to combine both models (i.e., offer X number of transactions per user license).

6. What is the difference between the free and paid versions of the product? Don’t cripple your free version to the point that it offers minimal value. Remember, your customer’s first interaction and impression will likely be with your free product, so make sure that your free offering is useful on its own terms and not just an obvious stepping stone to a higher-level paid version.

Freemium models should be based on your specific business realities. If the math of the freemium model looks like it will work for your business, your product and your audience, give it a try.

 Image courtesy of Shutterstock.

Savvy – and even not-so-savvy – mobile and online users know that most Question & Answer platforms aren't worth the time and effort it takes to scan them.

But the good folks at the Butler University Business Accelerator set out to learn exactly how bad they are, and which ones suck the least. 

The Butler University Q&A Intelligence Index aims to measure how accurately and quickly various mobile Q&A apps could provide quality answers to a variety of questions. The idea was to measure "the likelihood that a user could expect to receive a correct answer in a timely manner to any random query using natural language."

The contenders included Ask.com, Answers.com, ChaCha Google, Quora, Siri and Yahoo Answers, among others. Questions covered advice (“What if a girl doesn’t want to talk to you?”), objective (“What are the 10 most common names?”), and subjective (“Who would win in a fight, The Hulk or Superman?”).

The winner – or, if you ask me, the least terrible – was ChaCha, while the ultimate loser was Quora. Apple's Siri was second worst, while the oft-reviled Yahoo Answers came in a respectable fourth – which certainly makes me wonder about the strength of the competition.

Here are some highlights from the research:

ChaCha Rocks: “ChaCha delivered the highest-quality responses consistently across the largest group of categories and question types,” Trent Ritzenthaler, operating director of the Butler Business Accelerator, said in a statement.

Objective Questions: Ask.com did best on objective/temporal questions, such as “When does summer end?”

Tough Questions: Quora was best able to answer "difficult questions that require expert and extensive explanations," but answered only 24% of all questions and consistently failed to answer at all – and often presented matches that did not include a viable answer.

What Is Siri For? Siri accurately answered only 37.5 percent of the questions posed, but Siri’s biggest strengths are considered to be in local discovery and operating system commands, which were not highly represented in Butler’s study of more mainstream questions.

100% Google: Google’s response rate was 100%, but the first organic result was correct only about half the time.

Tetris was the original addictive puzzle game. Developed in 1984 by a Soviet programmer, the tile-based game eventually made its way to the 8-bit Nintendo in 1989 and a new era of gaming was born. If you were playing console or PC games in the early 1990s, Tetris was everywhere. You played it, your mom played it. Your dog watched you play it. 

Tetris may have also been the original popular mobile game. It was one of the first cartridges for Nintendo’s Game Boy and sold 33 million on the handheld gaming device. If ever there was a game custom-made to popularity in the Mobile Revolution, it is Tetris. 

Tetris Wins Over Xio Interactive's "Mino"

But Tetris, like many old time games (or popular new games), has run afoul of copycats and pirates. Do a quick search of the Apple App Store or Google Play and you will find similar titles like “Angry Block 3D Tilt” or “Retris.” One such copycat, Mino by a developer called Xio Interactive, was so egregious in its copying that The Tetris Company brought it to court for copyright infringement and trade dress rights in a New Jersey court in 2009.

Yesterday, Tetris announced that it has won its court case against Xio’s Mino in a summary judgment that was made in May 2012. 

“This is great news for budding designers and developers in the video game industry. Without this protection, our industry would not exist," said Henk Rogers, friend of original Tetris developer Alexey Pajitnov, in a release. 

You may look at the announcement and shrug. Great, you may say, Tetris won its court case against a copycat. Good for them. 

There is more to it than that.

Good For Developers In Battle Against Piracy

This is one of the first instances where a mobile game publisher has sued a copycat in a United States high court and won. The precedent set will be important for many developers – independent or large publishers – looking for legal solutions to pirated apps. The Tetris judgment could be a guide for how other courts handle copyright not just of mobile games, but many other types of copyright infringement concerning computer programs.

The broad concept of Tetris’s win is simple: it sued Xio for copyright and trade dress (a legal term that generally applies to “a product's physical appearance, including its size, shape, color, design, and texture”) and won. The underlying issues are more complex. We saw many of the same types of concepts crop up in the legal battle between Google and Oracle in the spring of 2012 concerning Google’s use of Java in Android. For instance, when is computer code copyright protected and when is using concepts within that code considered fair use? 

Ideas Not Protected, Expression Is

When it comes to copyright, ideas are generally not protected. Anybody can have an idea and we have seen time and again through history that several people have come up with the same idea independently of each other. What is protected is the express or implementation of those ideas. Hence, Oracle cannot quite claim copyright on Java in Android when Java is the idea but Android is the expression of the idea. In the Tetris case, similar concepts apply in that Mino copied seven different aspects of the implementation of the Tetris idea in such a way that it was an obvious copy of the original. 

Xio’s court argument was that it had only copied the rules and function of Tetris, which are not explicitly covered in The Tetris Company’s copyright. The court found otherwise. 

One caveat for developers and publishers looking to go after pirates: copyright is very difficult to prove. Only the most egregious suits will find ways to win and many smaller developers will not have the money for protracted legal battles. To see the complexity of Tetris’s argument, read the summary judgment provided by the court.  

Guest author Jonathan Stark is a mobile consultant, Web evangelist and an advisory board member at Mobiquity, a designer of customized mobile computing applications.

Until 2007, "computing" meant sitting down to use a PC with both hands. When smartphones came on the scene, we got used to computing with one hand while standing, walking - even running.

As great as they are, smartphones have a significant limitation: the touchscreen. You have to be able to look at the screen, and have at least one free hand to touch or type. If you're doing anything else - driving, cooking or changing a baby, for example - they're practically useless.

This limitation leaves us disconnected for big chunks of our day, which means that there is a demand for a screen-less mobile device. .

You Talkin' To Me?

How will we interact with these new devices? By talking to them. With Apple's Siri and Google Voice Actions and Voice Search, early versions of voice-controlled devices are already here. And more sophisticated versions are on the way. Yes, voice input is imperfect, but so was the touchscreen before Apple perfected it for the iPhone. 

But it's not just about voice commands. A truly voice-activated device would listen to you 24/7. A phrase like, "I wonder . . .?" or, "Who was . . ?" spurs it to action: with blinding speed it searches the Web or your personal database to find the answer - and whispers it in your ear.

Imagine that your mobile device is proactive. It reminds you to grab an umbrella on a rainy day, or lets you know that a friend is at a nearby cafe and would like company. It learns your habits, your likes and dislikes, and becomes acquainted with your friends and family.

For example, say you favor a certain route to work; your mobile will tell you when there's an accident or construction blocking your way and suggests an alternative. Your best friend's birthday is coming up: your mobile knows that you're both basketball fans. It checks your calendar and that of the home team and finds tickets for an upcoming game. 

Be Prepared

In this new world, designing a compelling mobile app just got a lot more interesting. Make a good smartphone app has never been easy. Now, remove the screen and try it again. Sounds impossible. But there are things developers can do to prepare for the next revolution.

1. Create Smart Content.You no longer know where your content will end up. Some devices support cascading style sheets (CSS), others don't; some render HTML, others won't. The screen-less mobile device is just on the horizon. This level of diversity requires that content be truly device-independent. Your content management system (CMS) should contain metadata describing the content, be free of display information (RTF, CSS, or HTML) and organized by what the content is (article, blog, or tweet, etc.) rather than its context (pages, screens and windows).

2. Build Open APIs. Content and services should be made available via Application Programming Interfaces. Think of these APIs as your core offering. Other departments in your organization, registered third-party developers and even consumers should have access them without requiring ongoing assistance. 

3. Start Small. Smart content and open APIs are both back-end considerations. Once it's time for you to build a front-end, start by designing and building for the most resource-constrained device that exists. It's much easier to scale up from a small mobile experience than it is to shoehorn a big design into a little package. 

When the smartphone market is disrupted by the next revolutionary mobile device, you're don't want to have to start over. The principles outlined above will prepare you in a way that is useful in today's mobile computing environment, and for the inevitable disruption to come.

Image courtesy of Shutterstock.

As part of it's splashy launch of BlackBerry 10, the company announced Wednesday that it has 70,000 apps in its BlackBerry World app store today, along with 1,000 premium apps from top publishers. 

Many BlackBerry Apps Not Native

Not so fast. These apps are not all hat they seem. In fact, a great portion of them are actually ported Android apps.

“40% are wrapped Android applications,” Martyn Mallick, VP of global alliances and business development at BlackBerry said to reporters. 

For instance, the Skype app on BlackBerry 10 is actually a port from the Skype app for Android. Skype has built native apps for iOS, Android and Windows Phone (Skype is owned by Microsoft) but it was easier for Skype to port its existing Android app before building specifically for BlackBerry. 

Android To BlackBerry 10 Port-o-Thons

BlackBerry (formerly Research In Motion) is relying on the port strategy in the short term to help developers get their apps onto the BlackBerry 10 platform fast. It encourages developers to build straight for BlackBerry 10 and the features that the operating system holds, but for now at least, it will basically take an app any way it can get it.

“The only way I can compare it is that it is a soft quality strategy,” said BlackBerry VP of developer relations Alec Saunders to ReadWrite. “If you compare what we do to what Apple does," they make developers conform to all of these iOS guidelines or theywill boot you out of the store. "We are like, 'You know what? If you have a code base, we want if to run on the platform.' '”

Saunders said that BlackBerry will offer developers who build specifically for BlackBerry “tangible marketing benefits,” which will be announced at a BlackBerry Jam Europe conference in Amsterdam next week. The suggestion seems to be that ported apps will not receive the same type of visibility or marketing from BlackBerry in its app store. 

“When I say tangible marketing benefits, you are going to do better in our store [with a native BlackBerry app] than if you built for Android,” Saunders said. “The porting strategy is there but increasingly we are going to be pushing people to build for BlackBerry to have the native parts of the BlackBerry experience because we think that experience is better.”

Saunders and the developer outreach team started doing “port-o-thons” in January to get developers “over the hump” in pushing out BlackBerry 10 apps ahead of today’s launch. One such port-a-thon brought nearly 15,000 apps to BlackBerry 10, while another added several thousand more. About 38,000 of the 70,000 apps in the new BlackBerry World app store are ports. As part of the port-a-thons, BlackBerry built a utility that can easily turn Android Apps into BlackBerry apps. 

A Sound Short-Term Strategy

In the short term, the port strategy should work for BlackBerry. Developers maynotice that an app is actually an Android app and not a BlackBerry app, but most consumers won't know the difference. As long as it works, right?

As the presence of the ported Skype app shows, this strategy is a decent way for BlackBerry to quickly get top-tier apps to its nascent platform. And if BlackBerry 10 sales start taking off, developers who built directly for the platform could benefit better than they would on iOS or Android - which is a reasonable incentive to follow up quick ports with true, native BlackBerry 10 apps.

Image of BlackBerry z10 by Dan Rowinski.

You have a brilliant software idea. Now you need to design a good-looking prototype. You look around. You search high and low. Chances are you will dig up a sum total of three usable tools.

That’s right, three.

Rapid Prototyping Is A Wasteland

Welcome to the largely ignored world of rapid prototyping.

If you design on the PC, you can choose from three tools:

1. Axure RP ($290)
2. Mockup Builder (free)
3. Serena Prototype Composer 3 (free/$300)

If you prototype on the Mac, your three choices are:

1. Axure RP
2. Balsamic Mockups ($79)
3. Sencha Architect ($400)

Balsamiq Mockups is a cross-platform rapid software prototyping tool that allows a UX designer to quickly create a mockup of software screens. This is a prototype I created for a next-generation CRM program. One major quibble: no ready-made icons for folders or documents.

If you develop mobile apps or websites, there are more choices, including Protoshare ($29/mo.), a Web-based (SaaS) software solution and Tiggzi ($40/mo.). If you like to design apps entirely on the iPad, there’s AppCooker ($40), AppSketcher (free), Blueprint Lite (free), Interface HD ($10), iMockups for iPad ($7) and Mockop (free), plus many others.

According to an educated guess, there are some 12 million programmers worldwide. That’s equal to the population of metropolitan Los Angeles.

Now imagine you are one of those 12 million LA inhabitants, and you have only three, maybe four, auto repair shops to choose from. What’s wrong with that picture? The size of the global information technology industry was estimated at $3.8 trillion in 2012, according to Gartner.

The same CRM mockup created in Azure RP, another cross-platform prototyping tool, that creates more buttoned-up designs. Tools that address various software design work styles are much needed.

Here’s a another cogent example. I searched the Home Depot site for cordless drills and found 348 search results. Try it yourself. And that’s for a global power tool market that will reach only $27 billion by 2015.

The Disconnect Opportunity

Notice a disconnect here? In a previous post, I wrote about the need to create 1,000 user-experience (UX) design studios in the U.S. alone. These studios would require a healthy infrastructure of innovative rapid prototyping and coding tools. Yet it's clear that when it comes to creating software, designers lack much choice.

What type of prototyping tools are needed? For one, they should be collaborative. I know this because I found a sparse factoid on the design activities of programmers that suggests that unlike the relatively solitary activity of coding and testing, designing interfaces requires much collaborative work.

Finding the above statistic buried in a Microsoft site full of articles about finding bugs was a worrisome sign all in itself. You would think that, given a $4 trillion information technology economy, there would be a lot more research about software-design habits.

Please plug this innovation gap, entrepreneurs and venture capitalists! We need a lot more help to make software work the way it was intended. And do contribute to my crowdsourced ideation engine and suggest more ideas on what type of software is needed to help create a next-generation software economy.

Lead image courtesy of Shutterstock.

Mobile browser Dolphin is by all accounts a quality third-party application for both iOS and Android. Dolphin was one of the first browsers to come out with gesture and voice controls, allows for excellent personalization and is reasonably fast. 

It is also fundamentally flawed. 

A lot has been written in the past few months about “mobile first.” The mobile-first approach is where you develop your product thinking of the smartphone or tablet user first and the Web second. This, by all means, is usually the proper way to do things in a world where most people access the Internet and a variety of important information from their smartphones wherever they go. If it does not look good or work well in mobile, people are not going to come back on any device. 

First vs. Mostly vs. Only

There is a distinct difference between mobile first and mobile only (or even mostly mobile). We have seen, with a couple notable exceptions, that mobile-only companies have trouble achieving extraordinary scale. Path, Foursquare and others have demonstrated this (with exceptions like Instagram proving the rule). They can make a tidy business if they learn how to monetize right, but tend to get stunted by the mostly mobile strategy. For an industry that often espouses open standards and ubiquity, it is surprising to see companies put themselves in a position to be in a fundamentally closed channel by limiting themselves to the mobile experience. 

Dolphin, and other mobile-only browsers like Skyfire and Boat Browser, have a fundamental problem. They are always going to be one of many choices and relegated to niche status on the devices they are installed on. Most people that use third-party browsers on their smartphones tend to have two or three installed and use different browsers for different purposes.  

Dolphin rationalizes its mobile-only position this way:

“In short, no, we do not need a desktop browser to compete with the big boys,” the company said in an email through its public relations firm LaunchSquad. “Roughly one in seven searches are happening on mobile. [39%] use the Internet on their smartphones while going to the bathroom, and [89%] of people who search on mobile have taken action within a day. Mobile is our wheelhouse, and we aren't going to extend ourselves by making a desktop product when we aren't ready to do so.”

When asked if Dolphin has plans to move into the desktop browser space, the company declined to comment. 

Mobile Searches Still A Minority

Applying reverse logic to Dolphin's statement, if one-in-seven searches come from a smartphone, would it not be prudent to have a product in the vertical where six-of-seven searches take place? After all, it is not like Dolphin has a monopoly on those one-in-seven searches on mobile. Hence, it is competing for only a fraction of a fraction of the market. 

In its latest update, Dolphin allows users to share content from the mobile browser with any other device that shares a Wi-Fi connection with the smartphone. While impressive, that is still not exactly a true cross-platform approach. 

One reason why people gravitate toward cross-platform browsers like Chrome on computer, iOS and Android is the ability to have a single sign-on with the ability to sync bookmarks, login credentials and browser histories between devices. Opera was one of the first browsers to deliver on this trend, but it remains on the fringe of the popular browser wars. Chrome has popularized the concept of a cross-platform browser profile and as such it reaps the benefits of the data generated for a single user on any device they may be using. 

No Such Thing As True Cross-Platform Browsers?

Not everyone agrees, of course. “Sharing bookmarks and possibly open tabs is nice, but it's not a defining feature that drives people to change their habits,” said appMobi’s CTO Sam Abadir. “The mobile versions of Opera, Chrome and Safari are all optimized for small screen/touch (as they should be) and this makes them pretty different from their big screen/mouse desktop brethren. Dolphin for example, has achieved decent traction without having any desktop presence.”

Maybe so. But the fact is that an app like Dolphin, with an extensive feature set, traction among mobile users and gaining popularity, is still leaving money on the table with its mobile-only approach. 

The last several years have seen an explosion in mobile applications. By the end of 2013, both Android’s Google Play and the Apple iOS App Store will be hosting a million apps - and we have only seen minor signs of slowing growth.

Where the heck are all these apps coming from? Thousands upon thousands of developers are working hard to pump out games, social networks, utility and productivity apps, news readers… if you can dream it, someone is building an app for it. 

So, how much time and effort is going into feeding this beast? Exactly how long does it take to build a quality native mobile app (not a mobile Web, HTML5 app)? Boston-based Backend-as-a-Service (BaaS) mobile-cloud-platform vendor Kinvey set out to answer just that question. 

More Than 4 Months!?

In a survey of 100 native mobile developers, Kinvey determined that creating a fully functional and polished app takes a team about 18 weeks from start to finish. That includes both front-end design and user interface as well as back-end integration like push notifications, user management and authentication, caching and sharing through social channels. 

I know what many app developers are thinking when they hear that: “18 weeks?! Who the hell are these turtle-slow developers?” On the other hand, enterprise developers are probably saying: “18 weeks?! We are only halfway through by that point.”

Given the sheer volume of apps published on a monthly basis (the App Store averaged 641 new apps a day from September 2012 to January 2013), taking 4.5 months for one app does seem like a long development cycle. But as many smartphone users already know, not all of those apps (probably not the vast majority of them) are any good.

Some apps are naturally easier to make than others, like reverse-engineered “copycat” apps or feature functions like Android wallpaper apps. For instance, it was rumored that it took Facebook engineers only a matter of days to clone Snapchat with its similar Poke app. 

Android vs. iOS: Which Takes Longer?

What if you are developing specifically for iOS or Android? Does one take longer than another? The answer used to be a definite Yes, Android took longer because of the fragmentation issues of developing an app for a wide variety of smartphones.

That is not quite as true as it used to be though. Google spent a good portion of 2012 updating and streamlining the Android Software Developers Kit (SDK) to better handle varying screen sizes, pixel densities and operating system versions. Many improvements came to Android app development processes with both the Ice Cream Sandwich and Jelly Bean releases. 

“Assuming equal skill level on the part of the developer, it shouldn't take longer to build an app on one platform or the other," said  Joe Chernov, VP of marketing on behalf of Kinvey’s engineering team. "In the fairly recent past, Android took longer because of the complexity of multiple device form factors. However Android's vastly improved developer tools and SDK has removed that complexity. Now a developer can use a designer tool to instantly see what the UI will look like on multiple devices. Yet while building the app might take the same amount of time on each platform, what does take longer is the approval process. For Android, approval takes hours (and there's a self-service option that removes approval entirely), while Apple can take weeks.”

The infographic below is the result of Kinvey’s developer survey, conducted in partnership with AYTM (Ask Your Target Market). The infographic itself was created by Visual.ly. Developers were asked 12 questions on how long it would take to perform a variety of functions such as integrating server-side data storage or design work. Respondents varied from different aspects of Web and mobile development, with 30 identifying themselves as mobile Web (but not native) developers, 27 as strictly native developers and 43 as enterprise-level developers. The 18-week-development-cycle conclusion was reached by adding up how long developers said it would take to perform certain actions. The data seems to show a standard deviation of about two weeks in either direction.

So, how long will it take you to develop your native mobile app, start to finish? Really, there is no easy answer to that question. Dave Bisceglia, founder and CEO of Boston-based iOS game development studio The Tap Lab sums it up nicely:

“The less exciting but entirely true answer is, ‘It depends,’ " Bisceglia said. “I've seen very talented teams crank out high-quality apps in just a few weeks. However, the demand for higher production quality in apps has certainly risen in recent years. Accordingly, app dev cycles have extended and we're seeing folks spend anywhere from 6 to 12 months on more complex projects.”

Note: Click the infographic to see the full-size version.

Top image courtesy of Shutterstock.