In my role at CSC as Lead Global Mobility Architect, I am often asked to support or refute a team’s mobility development choices. I tend to avoid these discussions entirely by leveraging our reference architecture and focusing on RESTful based back ends built in flexible and “future proof” ways. That said, we still have to give some kind of direction so we have a checklist to think about when making the decision. During this process we attempt to hide our own personal bias and try to get the typically technology-focused team to put aside their own biases. It is kind of like trying to avoid religious discussions with highly religious family members…not easy.
One of the most important things to take into consideration when making mobile technology decisions is that no single factor can be considered independently and each team must decide which factors are most critical in making a decision. These include:
- Level of consumer experience required
- Desire to have a single, or as close to single code base as possible
- Number of discrete platforms that MUST be supported (Web, iOS, Android, etc.) and should they work the same on all platforms?
- Cost factors & development team core competencies
- Requirements to work in an intermittent network environment (i.e., offline access)
Coding For The “Best” User Experience
Mobile device users are using a device that has been explicitly built by the major OS/device vendors to behave and act a certain way. Most, if not all users have learned to use their devices and have downloaded and purchased applications that also act in this user-centric way. That said, most users also do not understand what it is about those applications that make them “feel right.” They also may not understand why a certain application doesn’t.
From a developer’s perspective, all development techniques can provide some level of support to meet these end user expectations. The OS/device vendors have created rich API eco-systems that perform a myriad of data driven functions and softer user interactions. Rich image blending, complex touch interfaces, visually appealing screen and action transitions are a few of the techniques that are expected for consumer-targeted solutions.
Some will argue that many enterprise applications, and some consumer applications may not need to meet this user expectation bar. A user rarely interacting with a specific application or using a rarely needed function may be more than happy using a generalized experience.
Consider a personal email experience. Using a web-like client is “fine” and, with a fast connection, may even be desired for a certain user base. On a slow connection, the message-to-message transition may begin to concern even the most accommodating user. Most major device/OS platforms contain native mail clients and most users are accustomed to those solutions. Sub-second message-to-message transitions are the expected norm. Moving to a 3 second message-to-message transition would be jarring to the experience.
Using the same email example. What happens when new email is available? Does the user have to hit a refresh button and all the mail comes down, including the new email? Does the single email come down and slide into the right sort order position with slick animations? What about when the user is not running the application. How are they told about new emails? When they act on the notification do they still need to wait 3-5 seconds or is the data immediately available?
This most basic example – which remains arguably the killer app on your smartphone – shows just how end user needs and experiences should help determine the most appropriate development techniques.
In future blog posts I will dive into the other four factors.
This post is written by Michael Bonnette
Michael Bonnette is CSC’s Global Lead Mobility Architect. In that capacity, Michael defines CSC’s overall Mobility Technology roadmap and is responsible for its Mobility Reference Architecture and outreach to CSC’s Global 1000 customers.
Michael has spent over 20 years within the Mobility space working with some of the largest companies in the world to formulate and execute mobile solutions. For several years Michael started and ran one of the original Apple Newton ISV’s and subsequently was a leading technologist at Palm Computing from 2000-2008. While at Palm, Michael authored 2 patents and was the lead client architect for Treo smart phones and Palm organizer email solutions. Most recently, Michael was part of a healthcare mobile start-up focusing on best-in-class iOS and Android solutions targeted to doctors and nurses.
Michael received his BS in Computer Science and Print Industry Technology from RIT and his MBA from Boston University.