It is, after all, that access to the internet that determines who may end up using your web-based products.
Let's list those form-factors just to be on the same page:
Before we get into the details on each, let's agree on some terms to describe each:
* size will be variable as technology adjusts.
So now let's consider the strengths of each of these devices, in general.
Touch screen for easy navigation.
Primary communication device for voice/video, secondary for text.
Extremely usable on the go & traveling.
Touch screen for easy navigation.
Excellent consumption for reading / video / images.
Easy to travel with.
Excellent battery life.
Excellent content creation device using mouse/keyboard combination.
Good communication device using video & text forms.
Good amount of real estate.
Excellent consumption for video / images.
Maximum amount of real estate.
& their weaknesses? (in general)
Poor typing abilities, not content creation first, excepting photo-taking.
Voice-to-text still needs improvement.
Very little real estate for display.
Moderate battery life.
Not as easy to carry as mobile.
Content creation better than mobile, worse than desktop.
May or may not be portable.
Short battery life.
Little content creation ability.
How do we, as web product developers or application developers, handle these devices? There's a great deal to consider at each development facet. Before you write any user stories, you have to first understand what strengths the four form factors provide, what limitations they have, and how your product plugs into those strengths.
It's a tall order for any group, particularly smaller shops with just a handful of resources, but even for larger organizations where web development has purely been done for the desktop. Legacy web products can make these challenges greater. When these realizations occur, the conversations typically turn towards outsourcing the development or even hiring mobile specific developers.
Instead of jumping down that road, I think there's an easier, more organic way to ease your staff into design for many screens and many devices.
Don't focus completely on the big picture yet. Look at your web product and ask what parts of it would translate to the mobile form factor the easiest. Do you have basic data to display to a user? Is this data they may want to see while traveling or to be able to show in conversation? Do you have content creation functions that could benefit from the use of a mobile phone camera? Does your product try to facilitate communication between people? Would the ability to do this from a mobile device provide a benefit?
Don't get hung up on the how's yet. Leave implementation out of the picture and definitely avoid the application versus mobile web question out of it for now.
Now consider portable.
Does your product show graphs with detailed data points? Would a 7'' or 10'' tablet do a good job of letting users browse your site? Remember how nice pages of photos appear and how well video can be done on a portable device. Do you have large data sets of written data you need to display? Would the portable device's ability to better create typed data than a mobile device be beneficial to your users? Is there an instance where your users would need access to your products while walking around?
Now look at your web products.
Are there advantages and processes that are done better at the mobile and portable level that will improve user experience at the web level? Can you build a synergy between the different platforms? What upgrades can you do to the web product to facilitate the mobile and portable experience? What API do you have available from your websites to support mobile applications? Do you need to begin construction on one and what operations will it need to support?
Now look at the big screen.
Do you have content that would look great on a large screen? Big graphs? Images? Video? Don't consider too many content creation options with this form factor. Until the mouse and keyboard comes to the big screen, the desktop is going to be a better device for content creation.
A Product Path Emerges
Look at what you've put together so far. Is there a general product strategy starting to form out of this? What you're doing, after all, is what you've been doing for your desktop-optimized website. Now there's more variations to consider, but the question is essentially the same: how can I get the most out of my products using each device's strengths?
This general question needs to be asked for each facet of your product portfolio. You don't ask "do we do mobile?". You ask "which product(s) of ours translates the best to mobile?" You have to tailor the sauce your making for that device and audience. It's another facet, another layer, and it gets complicated, but it's necessary.
And yes, it takes time to figure out. It also takes quite a bit of time to implement.
Your products are in a world moving towards a four-legged stool. Mobile, Portable, Desktop, Big screen. You're going to need the non-fat, low-fat, normal, and creamy versions of your spaghetti sauce flavors.
For the techs on your team, this will become a passionate conversation. Some will eschew mobile web for native apps while others will prefer apps wrapping HTML5 like PhoneGap and others will want to use a multi-platform compiler like Appcelerator. These are all viable options depending upon your team's skill sets and the needs of the product you're building.
The simplest transition for any web developer is going to be to mobile web. It'll even let them start to really dig into all of those tools CSS3 and HTML5 provide since the majority of mobile and portable devices use advanced browsers. This also requires the fewest deployment headaches since there's no app store to wait for approvals nor do you have to worry about developer keys. Mobile Web also requires the least amount of research by your developers. The largest impact is getting your product developers/designers (whatever you call the people who turn a product idea into a product and user stories) to think small.
Just remember: mobile web requires connectivity to work optimally.
Writing native for devices is the most difficult to manage, train, and build experience on, especially if you want to build for more than one platform. While Java developers can swap to Android's Java environment pretty easily and C programmers can jump to iOS's Objective C pretty easily, the skill set to jump into both can be difficult to find. Should you find developers that can do both with out issue, you will now need to create a system that allows you to support both code bases at the same time. Code an update in the version of your app for Android and you will need to do the same for iOS.
Of course, if you out-source this, you won't have to worry about these challenges. But you may have to worry about the keys to apps and if you should ever decide to take those applications back into your team, you may not get the keys from the out-source provider. Be aware of the challenges with using the various market places, as well. iTunes and Android Market both have approval systems, although Android appears to require much less time.
Both have their advantages and with both you can build polished applications. If you're a web development shop like mine, then these are going to be the most attractive options available to you. Being able to utilize your current staff's skill set to build your Mobile and Portable applications is huge advantage!
Alright, so how do you put this together?
At this point, you should have an idea of what you want to create for each form factor. Flesh out those ideas and understand how you need them to operate. That, in combination with your team's skill sets, will lead you to deciding how to implement those ideas. I strongly recommend using a 3rd party platform. The simplification they bring to maintenance and construction is very hard to pass up. If you're building for one platform, like iOS, then this advantage is mitigated, but for most people I'm pretty sure you're going to consider at least iOS and Android.
Do some research and design sprints with your web developers while your product developers start to wrap their heads around designing for mobile, portable, web, and big screen. Get used to building in the emulators, transferring to device, and seeing the differences or similarities between platforms. Get your team's heads wrapped around the entire product chain from conception to execution.
Remember, you now have to consider your product on three or four different platforms. Your developers will need to integrate this thinking into their maintenance routines, development schedules, and skill sets. Product developers will need to start thinking about the advantages, sizes, and uses of multiple devices.
Ease your way in, start small, then expand as your skill sets improve.
Then you can start to implement your products across many screens on many devices.