How do you stay ahead of the pack in the mobile world inundated with new products, services, solutions on a daily basis? As business expectations increase manifold, how can mobile technologists play the role of a trusted steward for their clients, in carving out a successful mobile strategy? This prez focuses on an approach/framework to identify the right technology solution in a given context.
15. 15
NATIVE APPS
A binary application which is compiled using the Native APIs and the native device runtime
Pros Cons
User experience
High performance
High interactivity
Access to device
capabilities
Extensibility
No reusability
Multiplication of
efforts
Specialist team
Redistribution
Version zoo
Apps misuse access
Use Case
• High power performance, slick and glossy interactions
and rich graphics
• Highly integrated to the device
• Regular use and frequently accessing personal
information
16. 16
WRAPPER APP
Wrapper Apps use a standardized native shell which is available for several platforms (e.g. PhoneGap).
The shell defines a runtime environment for implementing UI and functionality using web technologies
(HTML, CSS, JS). It especially exposes device features by JS APIs. In contrast to a Hybrid App, the web
code is compiled into the App.
Pros Cons
One code for all
platforms.
No special skills
needed, web
developer can do
the
implementation.
Device-specific adaptions and
workarounds
Performance and memory
problems are common.
Functionality is restricted to
what the shell has to offer (if
Passbook is e.g. not supported,
it can not be used).
Heavy-weight apps
Compromized user experience
Use Case
• Where budgets are constrained and rapid change is required
• Users will be resistant to installing app
• To reach broad base of devices/platforms
17. 17
CROSS-PLATFORM COMPILERS
To address the platform fragmentation problems, several technologies have been developed that allow to
compile one source code to native code for all supported platforms. The results are Native Apps.
Pros Cons
One code for all platforms
Easy to support newer
versions
Proprietary technology
Compromized user
experience
Heavy-weight Apps
Performance and memory
problems
Restricted functionality due to
SDK
Support for newer version
dependent on 3rd party
Use Case
• Unified experience where overall polish and finish doesn't need
to be native
• Frequently interacting with personal information
• Need to use 3rd party technologies for complete app
18. 18
MOBILE WEB
Web page / application which is run from the device web browser and has access to browser APIs
Pros Cons
Standards based
One code for all devices
No special skills
Fast updates
Multi-Channel solutions
- RESS approach
HTML5 functionalities
are available in latest
OS versions.
Compromised user
expectations
Limited access to
device
Device browser
fragmentation
Partly supported HTML5
features
Performance and
memory problems
No App store presense
Use Case
• Quickly accessible public information
• Where budgets are constrained and rapid change is
required
• Users will be resistant to installing app
• To reach broad base of devices/platforms
19. 19
RESPONSIVE WEB DESIGN
One design with a fluid layout is used for all devices. The page adapts itself on device
Pros Cons
• No additional server-side technology
• Robust solution. Support for new
devices.
• Fallback behavior available.
• Only one user flow over all channels
• Physical display size not available
(only viewport size).
• Complex code
• High CSS and JS overhead
• Performance might become an issue
• Additional latency as larger images
are scaled down in browser.
Use Case
• Same page is delivered to all devices.
• RWD uses modern browser features to adjust the site layout to the device
viewport. This does not happen automatically
• Often images are used in one size (largest target device) and scaled down on
client side
• RWD does not reduce or solve cross-browser or device problems
20. 20
ADAPTIVE WEB DESIGN
Each class of devices gets its own layout and flow. Device is detected on server and page gets adapted
before being delivered to device.
Pros Cons
High quality pixel-accurate layouts possible.
Handling of device specific bugs and
incompatibilities possible.
Device gets optimized page and content. No
CSS/JS overhead, images scaled to device
before delivery. Fast page load time and
overall page performance.
Easier to maintain because server-side
capabilities can be used
Better classification of devices possible
Adaptions in flow and layout to channel
possible
High dependency on completeness and
quality of device database. No graceful
degradation
Problems with browsers that don‘t deliver any
device id for detection.
Layouts are normally pixel-accurate and
therefore inflexible
Additional technology needed on server-side
(device database, rendering layer).
Effort for new features or bug fixes in many
cases multiplies by number of channels.
Use Case
Current device and browser are detected utilizing a device database
A switch is implemented mapping the device to the corresponding channel
Within a channel each page is adapted to a specific device or device group before delivery
Pages can be delivered with a pixel accurate layout
21. 21
HYBRID APPS
A binary application using a 3rd party runtime able to accessing Native APIs including HTML5, Flash or
equally suitable runtimes.
Pros Cons
Trade-off between user-
experience and cost.
Evolutionary
enhancement based on
feedback
Leverages Mobile Portal
Fast changes without
redistribution.
Look & feel gap between
native and web parts
Additional effort on portal
side
Native shell for all
supported platforms.
Use Case
• In a content rich application, gaming
• Unified experience where overall polish and finish doesn't need
to be native
• Frequently interacting with personal information
• Need to use 3rd party technologies for complete app
23. 23
CLIENT Vs USERS CONSIDERATIONS
• Time and cost
effective
• Largest customer
base reach
• User
Experience
• Performance
Clients Users
24. 24
CHOOSING AN APPROACH
Mobile PortalNative App
+ Access to device capabilities
+ Changeability
+ Reusability
+ Standards based
+ Security
+ Technical flexibility
+ Marketing
+ Platform independent
Hybrid
App
+ User Experience
25. 25
BASIC DECISION TREE
Can we utilize a mobile portal?
HYBRID
APP
High customer
expectations
And/or
needs native capabilities
NATIVE
APP
HYBRID
APP
WRAPPER
APP
WEB
APP
Do I need the AppStore?
Can we utilize a
mobile portal?
YES
YES
YES
YES
NO
NO
NO
NO
27. 27
GUIDING PRINCIPLES
Adapt to
diversifying market
of mobile devices
Quick time
to market
Guiding Principles
for Mobile
Experience
Creation
Go beyond
mobile and multi-
channel to Omni-
Channel
Lower the
incremental cost
of software
creation
28. Let’s take the plunge
into ever evolving, innovating,
crowded & fast paced mobility space
to build great experiences
for our users
Cons:
Only one user flow over all channels. No adaption to channel specific use cases possible.
Physical display size not available (only viewport size). High res small screen smart-phones and tablets get the same layout.
Handling of device or browser bugs and incompatibilities difficult or impossible.
High CSS and JS overhead because all devices get the superset of code for all platforms (including the specific adaptions for single devices). The increased code complexity leads to bad maintainability. Worsens over time because new devices appear which need additional modifications.
Load and performance on mobile devices in most cases not satisfactory due to code overhead. Additional latency in low bandwidth networks if image for largest device is used and scaled down in browser.
Use Case
Same page is delivered to all devices.
RWD uses modern browser features to adjust the site layout to the device viewport. This does not happen automatically – behavior has to be defined in concept phase (fluid grid layouts) and implemented with CSS MediaQueries.
Often images are used in one size (largest target device) and scaled down on client side. More enhanced image handling needs server side support.
RWD does not reduce or solve cross-browser or device problems. Any necessary adaptions to the specific device have to be detected on client side and handled there (Javascript code).
Pros
High quality pixel-accurate layouts possible.
Handling of device specific bugs and incompatibilities possible. Older devices and browsers can be supported.
Device gets optimized page and content. No CSS/JS overhead, images scaled to device before delivery. Fast page load time and overall page performance.
Easier to maintain because server-side capabilities can be used (libraries, development tools, computing power, ...). Maintainability of server side code is much better than JS code.
Better classification of devices possible due to device database information (e.g. distinguishing high resolution smartphones from tablets with same viewport size).
Adaptions in flow and layout to channel possible (e.g. if channel corresponds to a different use case).
Cons
High dependency on completeness and quality of device database. No graceful degradation: If detection fails, device only gets fallback.
Problems with browsers that don‘t deliver any device id for detection.
Layouts are normally pixel-accurate and therefore inflexible (e.g. orientation change from portrait to landscape leads to elements being much to high because element aspect ratio is conserved).
Additional technology needed on server-side (device database, rendering layer).
Effort for new features or bug fixes in many cases multiplies by number of channels.
Use Case
Current device and browser are detected utilizing a device database
A switch is implemented mapping the device to the corresponding channel
Within a channel each page is adapted to a specific device or device group before delivery (adaption of HTML/CSS/JS, resizing of images) - based on information about its capabilities from a device database
Pages can be delivered with a pixel accurate layout