satisfies this with a virtual button; Android and BlackBerry devices rely on a
physical hardware back button; webOS
uses a back button and a back gesture.
Whatever the method, users expect
that they will be able to “go back” in
your application.
Users also expect context menus.
In the default Android and BlackBerry
browser, the context menu is accessed
through a physical button found at the
bottom of the screen, close to the natural position of the thumbs. On iOS and
webOS the context menu is accessed
through a persistent virtual tab bar positioned close to the thumb at the bottom of the screen. The persistent tab
bar at the bottom of the screen on devices other than iOS and webOs often
produces a poor experience because
users can easily accidentally hit their
context menu or back buttons, causing
an app to close unexpectedly. These are
limitations with which both native and
Web apps must contend.
Developers must consider approaches that make good sense for
both data and users. HTML5 does support the concept of a menu element
so a common abstraction is possible
here, but the work has yet to be done.
Environment is the greatest wild
card of all! Is it daytime or nighttime?
Is the user standing or sitting? Standing still or in motion? One or two
hands free? In a busy place? The variables are endless.
Where does that leave us? Expectations borne out of the context are not
inherently cross platform. Both native
and Web implementations must provide designs and code that support
these expectations. The good news for
Web developers is that they can fall
back on a familiar paradigm in the
Web technology stack to satisfy user
expectations.
Implementation. To produce the
best possible user experience, implementations must deliver designs and
code that support expectations set out
by a user’s particular context.
Performance: the hobgoblin
of software Development
Without a doubt, performance is a cornerstone of a great user experience.
Like security, it is the most misunderstood and oft-used scapegoat of the
software developer. It’s not uncommon to hear developers reject ideas
with a flippant, “We can’t do that, it
will negatively impact performance.”
Rarely quantified and frequently cited,
performance is the hobgoblin of software development. How do we quan-
figure 2. Variety of contexts across android devices.
figure 3. the variety of mobile Web browsers.
tify performance? Latency is a form of
performance. Execution, the time an
operation takes to perform, is another.
We’ll address these separately.
Latency is a huge consideration
in the mobile world. Be it a native or
a Web application, there is a performance penalty to downloading an app
and the data it consumes or publishes
through the network. Obviously, the
smaller the payload, the faster the app.
Using JavaScript Object Notation
(JSON)-formatted data is a good idea as
it tends to result in a smaller data payload compared with an equivalent XML
payload, depending on how the XML
is formatted. On the other hand, XML
data can make sense when returning
HTML fragments that are to be inserted
into a Web page rather than returning
JSON-formatted data that, while smaller over the wire, needs to be converted
to an HTML fragment using JavaScript.
Your mileage will vary. Benchmarking
is the only way to know for sure.
Another latency issue can be the ini-tialization of code. Once we actually get
the code into memory, it still needs to
be parsed. There can be a noticeable
performance penalty in this process.
We can fake it and enhance the perception of performance with determinate
or indeterminate progress indicators.
Execution time is, of course, a key
facet of performance. When interpreting code (as we do for the Web with JavaScript), the more there is to interpret,
the longer the execution time. Here the
Web technology stack has some catching up to do. JavaScript, for all its leaps
in performance, is still slower than native counterparts. On the other hand,
the time it takes a programmer to write
comparable logic in a native compiled
language on multiple mobile devices
may be worth the time penalty for execution; however, this will certainly
require more maintenance than one
code base written in JavaScript that can
run on multiple devices, maybe some
tweaks per platform. Less code often
leads to less and easier maintenance.
That said, the benefit of less code
doesn’t matter to the end user, who
expects a responsive interface. The developer tradeoff is a larger code base—
often vastly larger, considering support
for multiple native platforms. In the
world of native code, the main challenge is reimplementing to multiple