Conceptualizing your ported application on the netbook platform

Skipping the conceptualization processWhat if you decided to simply port your application without consideration for platform differences? While this seems like the fastest route to completion, it is also the surest route to miss many opportunities for improvement in terms of usability and overall user experience. With an abundance of screen real estate, you have the ability to display multiple views concurrently (such as master/detail), split panes, and other techniques that make your application easier to use. Invest your time here in determining what this new and powerful platform means to your application before you write a line of code. As the old saying goes, “an ounce of prevention is worth a pound of cure.” Your time spent in this portion of your porting process will undoubtedly save many hours of work later on.

“What will my application be like on the netbook?”This is the question posed by iPhone* developers around the world as they begin porting to the Intel® Atom™ SDK. When porting an application from one platform to another, the first item we as developers tend to think about is the programming language. Let us set that aspect aside and have a look at the hardware differences and how they affect the overall user experience. While a direct port of your application’s features and user interface would be simple, a bit of due diligence up front may necessitate minor changes that will ensure what you end up with at the end of the porting process is what you had envisioned.

We want to draw a clear picture of what your application is going to look like, how it will behave, and how your customers will interact with it on a netbook. Let’s take a look at the primary aspects to consider as you create your future state.

User experience gap analysisThat sure sounds complicated, however we can break it into easily digestible parts. The goal is to expose differences in the user’s experience when using your application on the netbook platform and whether or not those differences need extra attention during the porting process. In order to create a vision for the future state of your application, we must analyze the current state and consider platform constraints. One simple way to do this is a quick self interview (alternatively you can query a coworker to speed this part along). We want to expose any gaps in the experience a user may encounter once your application has been ported to the netbook.

Intel® Atom™ Developer Program Part of the Intel® Software Network

Originally published as a blog by Brian Burrows at :http://appdeveloper.intel.com/en-us/article/conceptualizing-your-ported-application-netbookplatform

beta

Here are some basic questions you will want to ask:Should this application have the user’s full attention at all times or should it share the screen?

How critical is the device orientation and does your application handle orientation changes?

Is this application aware of the user’s location?

Are there any dependencies which are cell phone-specific (call creation, answer)

Does your application utilize Bluetooth*?

Does your application use Cocoa Touch trackers?

Does your application utilize Cocoa Multi-touch gestures?

Does this application make use of the iPhone* accelerometer?

Are you identifying the user?

Is it critical that your application only run in one instance?

Does this application make use of the iPhone* camera hardware?

By answering these questions, we have exposed many of the high-level user interface considerations in our iPhone application. We need to address each property and determine if and how the ported version will change the user experience. Below are a few areas which you will want to explore further in your application’s future state.

Screen size(s)The first thing most developers consider as they begin to visualize their application on the netbook is the screen size. Immediately we are presented with two options that impact how we envision our application:

Option #1 Go big

Taking advantage of all those pixels gives you much more space to take advantage of. By consuming the entire screen you

will also demand your customer’s attention — something that may be desirable in productivity applications.

Option #2 Keep your dimensions

By keeping your application’s current dimensions you will have fewer image assets to recreate and little to no layout changes to handle. Since the full screen on an iPhone is 480 x 320 pixels and the smallest netbook resolution you will see per Intel® Validation Guidelines is 1024 x 576 no additional work will need to be done to handle multiple resolutions.

In picturing your application in an expansive landscape, which the netbook presents, consider which option lends itself to a good user experience. Now that you are developing a vision of how your application will look, let’s take it from your mind to the paper. This is as simple as getting out your trusty pen and paper, and creating side-by-side sketches of your UI on the iPhone compared to the netbook. Remember to consider not only your primary interface but any additional forms, or modal windows. This is also the time at which you may evaluate new and exciting ways to use of the additional space you will gain on the netbook platform.

How about a digital mock-up? Obvious choices include the free Paint.NET (http://www.getpaint.net/ ), a simple drawing tool which supports layers, rounded corners, and the like. If you are looking for an online tool with collaboration capabilities have a look at MockFlow (http://www.mockflow.com/ ). This tool supports A/B comparisons, real-time wireframe sharing, and more.

Of note: Consider whether your applica-tion can take advantage of the Windows tray feature and whether you can leverage balloon tips as a non-invasive form of messaging your user.

OrientationOn the iPhone, it is quite common to han-dle changes in the device orientation. This

effectively maximizes the limited space available by dynamically positioning the application layout. While this functionality works quite well on the iPhone’s smaller screen, it will not work on the netbook due to a lack of sensors to determine the device’s orientation. That being said, we also have more than four times the screen real-estate to work with and most users have no desire to rotate their netbook.

Think about your application’s usability on the iPhone. Does it flow better in a portrait or landscape layout? By and large, most applications are more easily ported in landscape layout, as it maximizes available area for data sets and more closely matches the aspect ratio found on netbook screens.

Location servicesMany applications are at least partially based upon the user’s location, bringing added value in data personalization. While we can safely assume that all iPhones have a GPS receiver, the same cannot be said for the current offering of netbooks. Some netbooks do have GPS hardware in-stalled and there are libraries available to us to access this data from our application. If you intend to require that the user have GPS hardware please ensure that your application’s meta description includes an appropriate disclaimer.

That being said, we do have a viable alternative to GPS by way of Geolocation services. This technology has been used for a number of years with reasonably good success. By looking up the user’s IP address against any number of services we are able to determine their relative location. This will not give us the fine-grained detail of a GPS reading, but an approximation that may suffice for our application’s functionality. If knowing the state and, potentially, city of your customer’s location is close enough for your requirements, then geolocation services may be the solution for you.

One excellent source for location services that I have used in the past is

2

White Paper Title Placeholder Here

2

Intel® Atom™ Developer Program Part of the Intel® Software Network

beta

Ip2Location (http://www.ip2location.com/).

Keep in mind that these are generally subscription services and you will incur some cost for this feature unlike GPS.

Bluetooth* and phone functionalityIt is not uncommon for applications to be tied to certain mobile phone features such as dialing and the user’s phone book. At first glance it seems as if you would have to scrap any such functionality in your application that utilized these features. While it may be easiest to go ahead and remove any dependencies related to mobile phone functionality, I offer to you an alternate solution.

One valuable piece of hardware available in most every model of netbook is a Bluetooth* radio. Most mobile phones expose several Bluetooth profiles allowing for everything from file sharing to Internet tethering. Using the available profiles, may allow you to provide a method for keeping your application’s mobile phone-enabled features. You will need to acquire a Bluetooth library, which has provisions for the features you intend to retain. Here are a few common profiles which are implemented in nearly all mobile phones:

Hand-Free Profile

This profile allows us to place calls, as well as subscribe to incoming call notifications.http://www.bluetooth.com/ SiteCollectionDocuments/ HFP15_SPEC_V10r01.pdf

Phone Book Access Profile

This profile is responsible for providing an interface to recall and store contact details in the mobile phone’s phonebooks.http://www.mcpc-jp.org/news/pdf/ TR-010PBAP_V1.0.pdf

More details on the available Bluetooth profiles may be found here: http://www.bluetooth.org

TouchAlthough there are a few Atom™-based tablets coming soon, the vast majority of netbooks do not have a touch screen. That being said, many netbooks do have a multi- touch-capable touchpad installed that we can take advantage of.

Many netbooks’ touchpads do in fact support multi touch. You will need to query the device to determine its capabilities. The most common multi touch capable hardware is currently made by Synaptics.

Further reading: http://www.synaptics.com/solutions/tech-nology/gestures/touchpad

Bear in mind that while the touch pad responds in a similar way to multi-touch events, it is obviously not an LCD screen and presents itself as a somewhat different user experience. Consider that it will not be as natural to use multi-touch gestures on the netbooks, as the user must use the current mouse cursor position for reference. To assist the user you may wish to indicate that a particular user, interface object is gestural when the mouse is hovered.

Lastly, one key difference is the mouse cursor. While there is no such concept on the iPhone, it is a staple of the netbook environments user experience. Take into consideration mouse in/out events and their effect on making your application easy to use.

AccelerationThe accelerometers in the iPhone are an interesting input device. We use them often in place of clicking a button; for example, the common “Shake your phone to…” functionality. We also use them to move objects around the screen. The netbook platform does not have such hardware; however, we are not left without options. Consider using a mouse to double-click events or arrow keys as a quick and easy to implement substitute.

IdentificationAs iPhone users we can safely assume that in most cases there is generally only one user. As such, we store a single collection of settings and account details. When moving to the netbook platform, this assumption is replaced by the poten-tial for multiple profiles on each netbook. It is not uncommon for multiple people to have profiles on one netbook, and one user to have multiple profiles.

Does this affect your application’s usability or authentication methods? Should you consider creating an initial login screen facility? These are further questions you may wish to explore in an effort to get a feel for how your application will behave once ported.

InstancesThis is another core platform difference that has the potential to affect our application’s future state. How many instances of your application are you going to allow? If your application has account or performance constraints in place, you will want to implement a method to prevent users from executing more than one instance of your program. Of course, you will want to display a friendly message prior to exiting, indicating that your application is already running. The most common method of ensuring this is by use of a mutex. MSDN has an excellent article outlining this solution in C++: http://support.microsoft.com/kb/243953

Moving aheadIn summation, your goal is to compare the current state of your application against its potential future state. Close your eyes and walk through the typical use cases that your customers would, as if your application was running on a netbook. As you begin your porting process, take note of any areas that you may need to remove, modify, or rearchitect. For this modest investment, you will end up with an application that performs as well on the netbook as it does on the iPhone.

3

White Paper Title Placeholder Here

3

Intel® Atom™ Developer Program Part of the Intel® Software Network

beta