Designing the Mobile Web: Guidelines for User Interaction and Experience Lisa Ring

Designing the Mobile Web: Guidelines for User Interaction and Experience Lisa Ring
Designing the Mobile Web:
Guidelines for User Interaction
and Experience
Lisa Ring
November 10, 2013
Master’s Thesis in Interaction and Design, 30 credits
Supervisor at TFE-UmU: Per Kvarnbrink
Examiner: Håkan Gulliksson
Umeå University
Department of Applied Physics and Electronics
SE-901 87 UMEÅ
SWEDEN
Abstract
The area of mobile web is evolving rapidly but there are still no consensus regarding recommendations or best practices within the topic. Therefore this thesis is focused on interaction
design within mobile web and compiles many different theories into guidelines for mobile
web design. The thesis may also be used as a foundation when deciding whether to develop
a native mobile application or a mobile adapted web application, or when choosing between
a separate mobile web application and a responsive web design.
Components that are especially considered in this thesis are form elements and navigation menus. These are discussed relative to interaction on small touch screens such as
smartphones and tablets. For example, text input elements can be optimized for the intended input format and one can take advantage of the device’s native components for e.g.
time and date input.
A prototype of a responsive web application is also developed to further exemplify the
theoretical theories. This is a exploratory study for the Swedish magazine Resumé in collaboration with The Mobile Life and is focused on convert the original site into a responsive
design, but still retain the overall Resumé look and feel.
Designing the Mobile Web: Guidelines for User
Interaction and Experience
ii
Contents
1 Introduction
1
1.1
The Mobile Life . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
1.2
Aim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
1.3
Purposes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
1.4
Mobile Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
1.5
Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
2 Methods
5
2.1
Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
2.2
Tools and Environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
2.3
Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
2.4
Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
3 Background of Web Development
7
3.1
HTML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
3.2
CSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
3.3
JavaScript . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
4 Native Mobile Applications vs. Mobile Web Applications
9
4.1
Definition of Native Mobile Applications . . . . . . . . . . . . . . . . . . . . .
9
4.2
Definition of Mobile Web Applications . . . . . . . . . . . . . . . . . . . . . .
9
4.3
Pros and Cons with Native Mobile Applications Compared to Mobile Web
Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
5 Separate Mobile Websites vs. Responsive Web Design
13
5.1
Definition of Separate Mobile Websites . . . . . . . . . . . . . . . . . . . . . . 13
5.2
Definition of Responsive Web Design . . . . . . . . . . . . . . . . . . . . . . . 14
5.3
Pros and Cons with Separate Mobile Websites
Compared to Responsive Web Design . . . . . . . . . . . . . . . . . . . . . . 14
iii
iv
CONTENTS
6 User Flow
6.1 Definition of User Flow . . . . . .
6.2 Design for User Flow . . . . . . . .
6.2.1 Identifying the Entry Points
6.2.2 Structuring the Events . . .
6.2.3 Creating a State Diagram .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
19
19
19
20
20
20
7 Guidelines for Mobile Web Usability
7.1 Considerations when Creating Mobile Websites . . .
7.1.1 Back End and Performance . . . . . . . . . .
7.1.2 Frontend and Usability . . . . . . . . . . . .
7.2 Components in Mobile Web Applications . . . . . .
7.2.1 Definition of Components . . . . . . . . . . .
7.2.2 Forms in Mobile Web . . . . . . . . . . . . .
7.2.3 Navigation Menus in Mobile Web . . . . . . .
7.3 Breakpoints of Screen Sizes . . . . . . . . . . . . . .
7.3.1 Analyzing Sizes and Resolutions . . . . . . .
7.3.2 Letting the Content Decide the Breakpoints .
7.4 Hardware Integration in Mobile Web Applications .
7.4.1 Detecting Features Supported by the Browser
7.4.2 Hardware Integration . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
25
25
25
27
31
31
31
45
53
53
54
54
54
54
to Exemplify the Theories
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Used in the Prototype . . . . . . . . . . . . . . . . . . . .
59
59
63
70
8 Prototype Developed
8.1 Accomplishment .
8.2 Results . . . . . . .
8.2.1 Breakpoints
9 Discussion
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
71
10 Conclusions
73
10.1 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
10.2 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
11 Acknowledgements
75
References
77
List of Figures
4.1
Decision tree to ease the decision making whether to develop a native mobile
application or a mobile web application. . . . . . . . . . . . . . . . . . . . . . 12
5.1
Decision tree to ease the decision making whether to develop a responsive
web application or a separate website. . . . . . . . . . . . . . . . . . . . . . . 17
6.1
Events leading to the user need and business objective. In this example the
entry point is a link in a search result and the business objective is fulfilled
when the user subscribes to the newsletter. . . . . . . . . . . . . . . . . . . . 21
6.2
Stacked events reaching the supreme business objective. In this example there
are two entry points and two business objectives that are fulfilled. . . . . . . 22
6.3
The structure of state diagrams. The left box shows what the user sees and
does now and the right box shows what the user sees and does next. . . . . . 22
6.4
An example of a state diagram for a web shop. In this example there are two
entry points; from a search result and from a newsletter. Both scenarios end
up in purchasing a product. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
7.1
An estimation of how many smartphone users that use their device in some
common locations 2012 [5]. However, this chart only shows usage of smartphones (not all mobile devices) and is not limited to just browsing the Internet. 30
7.2
Input element with type “text”. . . . . . . . . . . . . . . . . . . . . . . . . . . 32
7.3
Input element with type “password”. The letters are masked as dots. . . . . . 32
7.4
Input element with type “number”. The virtual keyboard only contains numbers and related characters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
7.5
Input element with type “tel”. . . . . . . . . . . . . . . . . . . . . . . . . . . 34
7.6
The @-character is specific for the virtual keyboard used with the input element of type “email”. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
7.7
Input elements with type “url”. . . . . . . . . . . . . . . . . . . . . . . . . . . 35
7.8
Input element with type “date”. A native date picker opens when the component is selected. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
v
vi
LIST OF FIGURES
7.9
7.10
7.11
7.12
7.13
7.14
7.15
7.16
7.17
7.18
7.19
7.20
7.21
7.22
7.23
7.24
7.25
7.26
7.27
7.28
Input element with type “datetime”. A native picker opens up when the
component is selected. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Input element with type “month”. A native month picker opens when the
component is selected. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Input elements with type “week”. This component is not widely supported
and is therefore captured from a LG Google Nexus 4 (with Android 4.2.2)
with Firefox (version 20.0.1). . . . . . . . . . . . . . . . . . . . . . . . . . . .
Input element with type “time”. A native time picker opens up when the
component is selected. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Group of input elements with type “checkbox”. . . . . . . . . . . . . . . . . .
An group of input elements with type “radio”. The components are enlarged
with CSS and the image is captured from a LG Google Nexus 4 (with Android
4.2.2) with Chrome (version 26.0.1410.58). . . . . . . . . . . . . . . . . . . . .
Input elements with type “range”. This component is not widely supported
and is therefore captured from a LG Google Nexus 4 (with Android 4.2.2)
with Opera (version 12.10.ADR-1301080958). . . . . . . . . . . . . . . . . . .
Input elements with type “button”. . . . . . . . . . . . . . . . . . . . . . . . .
Input elements with type “reset”. . . . . . . . . . . . . . . . . . . . . . . . . .
Input elements with type “submit”. . . . . . . . . . . . . . . . . . . . . . . .
Input elements with type “file”. This image is captured from a LG Google
Nexus 4 (with Android 4.2.2) with Opera (version 12.10.ADR-1301080958). .
View with native applications that can be chosen. The image is captured from
a LG Google Nexus 4 (with Android 4.2.2) with Chrome (version 26.0.1410.58).
View to select the path to a file that should be uploaded. The image is
captured from a LG Google Nexus 4 (with Android 4.2.2) with Opera (version
12.10.ADR-1301080958). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Input elements with type “color”. This component is not widely supported
and is captured from a LG Google Nexus 4 (with Android 4.2.2) with Opera
(version 12.10.ADR-1301080958). . . . . . . . . . . . . . . . . . . . . . . . . .
Ordinary hyperlink with its default color. . . . . . . . . . . . . . . . . . . . .
Smartphone specific hyperlinks. Opens up the phone’s native phone- respectively SMS-application. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Select element. Native selector is opened when the component is selected. . .
The Footer Anchor Menu on mobile and desktop. The image of the mobile
version is a montage where some content has been cut off to make it possible
to see the menu icon in the top right corner at the same time as the menu in
the footer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The Select Menu on mobile and desktop. The select menu opens a native
select list. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The CSS Drop Down Menu on mobile and desktop. The menu items overlap
the core content. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
36
37
37
38
38
39
40
40
40
41
41
42
42
43
44
44
44
47
48
49
LIST OF FIGURES
7.29 The Toggle Menu on mobile and desktop. The core content is forced down
by the menu items. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.30 The Multi-Toggle Menu on mobile and desktop. The different levels of menu
items are separated from each other with different colors. . . . . . . . . . .
7.31 The Side Panel Menu on mobile. The core content is pushed to the right
when the menu is revealed. . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.32 The Swipe In Menu on mobile and desktop. A new level of menu items swipe
in from the right when a category is selected. . . . . . . . . . . . . . . . . .
7.33 The top 14 mobile screen resolutions in the world from April 2012 to Mars
2013 [71]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Decision tree that shows the thoughts behind the decision to create a mobile
friendly web application instead of a native mobile application. . . . . . . .
8.2 Decision tree that shows the thoughts behind the decision to create a responsive web application instead of a separate mobile website. . . . . . . . . . .
8.3 The top of the prototype on different screen sizes. A: mobile portrait mode,
B: tablet portrait mode, C: desktop mode, D: tablet landscape mode. . . . . .
8.4 A: Header of the original site, B: Header of the prototype in desktop mode.
8.5 A: Header in tablet landscape mode, B: Header in tablet portrait mode, C:
Header in mobile portrait mode. . . . . . . . . . . . . . . . . . . . . . . . . .
8.6 The top of the prototype in mobile portrait mode. A: The main menu is
closed. B: The main menu is opened. C: One of the sub-menus is opened. .
8.7 The search field becomes visible when tapping the search toggle button. . .
8.8 The structure of the news feed in different modes. A: mobile portrait mode,
B: tablet portrait mode, C: desktop mode, D: tablet landscape mode. 1 - Latest
news, 2 - Most viewed, 3 - News ordered by time, 4 - Older news ordered by
time. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.9 The blog section in the prototype on different screen sizes. A: mobile portrait
mode, B: desktop mode, C: tablet landscape mode, D: mobile landscape mode
(the same as tablet portrait mode). . . . . . . . . . . . . . . . . . . . . . . .
8.10 Closeup on the blog carousel. A: mobile portrait mode, B: mobile landscape
mode (the same as tablet portrait mode). . . . . . . . . . . . . . . . . . . . .
8.11 The footer of the prototype on different screen sizes. A: tablet landscape
mode, B: desktop mode, C: tablet portrait mode, D: mobile portrait mode . .
8.12 A: Footer of the original site, B: Footer in desktop mode. . . . . . . . . . . .
vii
. 50
. 51
. 51
. 52
. 53
8.1
. 61
. 62
. 63
. 64
. 65
. 66
. 66
. 67
. 68
. 68
. 69
. 70
viii
LIST OF FIGURES
Chapter 1
Introduction
The emergence of the modern smartphone has fundamentally changed the way people access
the Internet [1]. In the future, the number of people accessing the Internet through a
mobile device will surpass the number of ordinary desktop web users [2]. But there are
already people who use their smartphones as their primarily access device to the Internet
[3]. According to Statistics Sweden, 59% of the swedes accessed Internet outside the home
through a smartphone or mobile phone during 2011 [4]. And according to Google’s Our
Mobile Planet, 73% of the world’s smartphone users browsed the Internet from their device
during 2012 [5]. Furthermore, the mobile data traffic in Sweden reached 73 290 terabyte
during the first six months of 2012 and at the end of June 2012 there were 6.2 million mobile
Broadbands in Sweden [6].
Since Apple released the Iphone in June 2007 the market for smartphones has exploded
[2]. The battle for the smartphone market has been waged by manufacturers of platforms
such as Iphone, Android, Blackberry, Symbian and Windows Phone [7]. As the market has
matured, the practices for native mobile application development have become more and
more standardized. However, mobile web development is not yet as mature and there is
an opportunity to determine recommendations and best practices for components and user
flows.
1.1
The Mobile Life
The thesis has been conducted at The Mobile Life (TML), which is an international software
development company with focus on mobile application and web solutions. TML is working
with a variety of different platforms and technologies, but mainly develops applications for
Iphone, Ipad, Android and Windows Phone. The company was founded in 2005 and has
since then created more than 100 mobile applications.
Mobile devices become better and can perform more tasks every day. At the same time
are more and more hardware components and sensors accessible from the web, which makes
mobile web a viable alternative to native mobile applications. These factors make it relevant
for TML to know how to develop usable and user friendly mobile web applications.
1
2
1.2
Chapter 1. Introduction
Aim
The primary aim for the thesis is to compile recommendations for interaction design within
mobile web applications, with focus on interaction components and user flows. The compilation is divided into smaller areas, e.g. when to develop a web application instead of a native
mobile application and when to choose different solutions of web application development.
Besides the theoretical study, a prototype has been implemented. The purpose for the
prototype is to further explain and exemplify the results from the study and is a mock-up
of a responsive design of the website resume.se. Resumé is a Swedish magazine focused on
media and marketing communication. The magazine is published 22 times a year, but the
digital news site is updated multiple times a day.
The aim of the prototype is to show how the news site may be interpreted with a
responsive design methodology. The prototype is based on the current website and uses
already existing texts and images as dummy content. No effort has been made to implement
any logic or integrate the solution with any Content Management System (CMS).
The thesis has been conducted on behalf of The Mobile Life, but will probably be
of interest for other software developers as well. It is preferable if the reader has some
basic knowledge of web development techniques, e.g. HTML, CSS and JavaScript, since
these are mentioned in conjunction with the thesis topic but are not very widely explained.
Furthermore, the reader should not be foreign to lightweight technical and topic specific
terms, e.g. platform, manufacturer, user interface and component. However, the thesis is
focused on interaction design and is not intended to provide any technical solutions more
than necessary to explain the concept.
1.3
Purposes
The purpose of the thesis is to simplify development of mobile web applications. The
compilation may hopefully ease the decision making and contribute to a market with more
satisfied users, developers and clients.
1.4
Mobile Devices
Since there are many different kinds of mobile devices there are some restrictions for what
is meant with a mobile device within this thesis. First of all, a mobile device is portable.
This means that it is possible to carry the device in the hand without restrictions from
weight or any kind of cables. Furthermore, the device is personal and got some kind of
wireless Internet connection. This thesis will also be limited to devices with touchscreen.
In other words, in this thesis laptops are not considered to be mobile devices. Examples
of devices that are considered to be mobile are smartphones and tablets. A mobile device
should typically be easy to use, without support, in a standing position. It should also be
possible to carry e.g. in a pocket, handbag or backpack for everyday use.
1.5
Related Work
According to Nielsen, it is twice as hard to read on a small screen compared to a desktop
monitor [8]. But as long as there have been mobile devices with Internet access there have
also been attempts to define guidelines for small screen web design. In 2002, long before the
modern smartphones and tablets, Kärkkäinen and Laarni came up with a set of guidelines
1.5. Related Work
3
for web optimization for PDAs (Personal Digital Assistants) [9]. Interestingly enough, some
of these guidelines are still relevant for mobile web developing for devices that are released
today. In 2010 West and Mace concluded that one of the major reasons for Apple’s large
impact on the mobile market when the Iphone was released in 2007, was that they made
it so much easier to browse the Internet from mobile phones [7]. During a live talk three
weeks before the release of the Iphone, Steve Jobs noted “they [Cingular Wireless LLC]
have spent and are spending a fortune to build these 3G networks, and so far there ain’t
a lot to do with them. People haven’t voted with their pocketbooks to sign up for video
on their phones. These phones aren’t capable of taking advantage of it. Youv’e used the
internet on your phone, it’s terrible! You get the baby internet, or the mobile internet –
people want the REAL internet on their phone. We are going to deliver that. We’re going
to take advantage of some of these investments in bandwidth.” [10].
4
Chapter 1. Introduction
Chapter 2
Methods
This section describes the process of the work and the methods used to conduct the thesis.
2.1
Process
The main goal of this thesis was to compile guidelines for interaction design within mobile
web. Since this is an enormous area there had to be some restrictions for the work. These
restrictions are first of all based on the requests from The Mobile Life.
The first phase of the thesis included literature research and writing the guidelines.
The guidelines were created simultaneously as the research were made. The next phase
of the thesis was to apply the theories to a real life assignment, in this case Resumé, by
developing a prototype. All the theories are not possible to apply on one single case (partly
because the theories deal with different techniques and some theories are usable in different
situations), but the prototype can be used as an example of how the theories may be used.
The prototype was first sketched with pen and paper to create a first idea of the structure
of the sections and elements. These were then translated into digital mock-ups using Adobe
Photoshop. This was an important step because it made it possible to see the structure of
elements and sections in real size without actually implementing anything. These digital
mock-ups were reviewed by some collaborators at Resumé and thereafter translated into a
HTML-prototype. Furthermore, also the prototype was reviewed by the collaborators at
Resumé continuously during the whole project. Other priorities driving the design, except
for the theories, was for example to keep advertisement visual and to sort sections based on
statistics about the users behavior.
2.2
Tools and Environments
A lot of tools and different environments have been used during the work with the thesis.
Google drive was used for creating a time schedule and for writing temporary documents.
This is also where a light weight backlog, or maybe better described as a to do-list, was
written for the work with the implementation. WiseMapping is an HTML5-based tool that
was used for mind mapping ideas and organizing facts. Adobe Illustrator and Adobe Photoshop were used to create figures for the report and icons for the prototype. Photoshop was
also used to create digital sketches for the prototype. Another tool used for the theoretical
part was Onlinecharttool that was used to create charts for the thesis.
5
6
Chapter 2. Methods
The prototype was implemented in a text editor called Sublime Text 2. Two frameworks
were used during the implementation as well, Bootstrap and SASS (Syntactically Awesome
Stylesheets). Bootstrap was used to implement image carousels and SASS was used to
simplify the styling of the prototype.
2.3
Resources
During the work the prototype has been tested in several browsers and operating systems
and on different kinds of devices. The most frequently used browsers for the testing was
Chrome for Windows 7, Firefox for Windows 7, Chrome for LG Nexus 4 (Android 4.2.2,
Jelly Bean), Safari for Iphone 4 and Iphone 5 and Safari for Ipad 2 and Ipad 3. This was
simply because these devices were available at The Mobile Life.
2.4
Methods
The prototype was developed with a method called Mobile first [11]. Mobile first is when
starting to design for the smallest screen and then scale the design up, restructure elements
and maybe add more functionality and/or more complex design for bigger screen sizes. This
technique is practiced because it is usually easier to scale a design up than scaling it down.
Therefore one should start to design the most difficult mode and then add more details
and/or restructure the content for bigger screens.
Chapter 3
Background of Web
Development
Mobile web development got the same fundamentals as desktop web development, namely
HTML, CSS and JavaScript. The generally accepted and recommended implementation
principle is to, as far as possible, separate the content (HTML) from the style (CSS) and
the functionality (JavaScript) by creating different files for each part. This chapter explains
the basics behind HTML, CSS and JavaScript.
3.1
HTML
HTML is an abbreviation of Hyper Text Markup Language and is, as the name suggests,
used to mark up the content of a website. There are several different versions of HTML.
The latest version is called HTML5 and is, if nothing else is specified, the version that is
referred to in this thesis whenever the expression HTML is used. However, HTML5 is still
not recommended as a standard, but is widely used by web developers, especially within
mobile web.
HTML creates elements that are the building blocks of a website. There are many
different elements (often referred to as tags) that specifies what kind of content to render.
Some of these elements are invisible for the end user (e.g. the <head>, <body> or <div>
tag), while other specifies what kind of component to be displayed [12]. Since this thesis
focuses on interaction design and usability, it will concentrate on visible components, and
especially those used for user input or user interaction.
3.2
CSS
Cascading Style Sheets (CSS) are used to add visual styles to the website. The generally
accepted and recommended implementation principle is to, as far as possible, separate the
HTML (the content) from the CSS (the style) by creating different files for each part. For
example, this makes it possible to change the style without changing the functionality or
the content, it makes it easier for different persons to work on different parts of a project
and the same resources can be used on several places without duplicating the code [13].
The latest version of CSS is called CSS3 and is often used together with HTML5. Both
HTML5 and CSS3 is developed to be lightweight for web browsers and ease the implemen7
8
Chapter 3. Background of Web Development
tation. HTML5 and CSS3 are better adapted to the modern use of the Internet and the
techniques and features that are known today [14].
3.3
JavaScript
JavaScript is a scripting language that often is used to add functionality to the web. For
example, JavaScript may be used to create animations, pop-ups or event listeners for buttons, but may also be used to create pure games directly in the web browser. Developers
often find JavaScript easy to learn since the syntax is similar to the programming languages
Java and C [14].
The interactivity JavaScript offers is possible to achieve since the script is running in the
client. A website is requested from a server, but the script is executed in the browser itself.
This makes it possible to dynamically change the website without reloading the page.
Chapter 4
Native Mobile Applications vs.
Mobile Web Applications
This chapter defines what a mobile web application actually is and what distinguishes it
from a native mobile application. There will also be a comparison between these approaches.
4.1
Definition of Native Mobile Applications
Native mobile applications are what people often denote when talking about mobile apps,
or just apps, in the context of smartphones, tablets or other mobile devices. Native mobile
applications can make use of the hardware components and sensors in the device. They
are downloaded from the platform’s specific application store and installed on the device.
This means that a native application needs to be developed for each specific platform it is
intended to support [12]. This is the explanation of why an application available on one
platform not necessarily is available on another.
4.2
Definition of Mobile Web Applications
A mobile web application can, from the user’s point of view, be more or less perceived as a
native application [15]. But even if the user interface might be hard to distinguish from a
native application there are some crucial differences. A web application is accessed through
the browser and is basically a website specifically optimized for small devices. This means
that a web application is, unlike native applications, not limited to one platform, but can be
visited from any device with an Internet connection and a browser. Since a web application
is independent of the platform the device is running, it can not be found in the platform
specific application store. Instead, the user visits the web application by typing the URL in
a browser as any other website [12].
4.3
Pros and Cons with Native Mobile Applications
Compared to Mobile Web Applications
There have been discussions about whether the native mobile applications or the mobile web
applications will win the battle of the mobile devices [16]. However, the spirit of this thesis
9
10
Chapter 4. Native Mobile Applications vs. Mobile Web Applications
is that there is no battle, only two techniques that supplement each other. This opinion is
based on that there are advantages and disadvantages with both of the solutions [12]. One
solution may be suitable for a specific application, while the other solution may be a better
choice for another. Table 4.1 [17, 18] shows a comparison between the properties of native
applications and mobile web applications.
Table 4.1: Comparison between Native Mobile Applications and Mobile Web Applications.
Native Mobile Applications
Mobile Web Applications
1
Need to be developed specifically for ev- One application can run on every deery platform
vice with an Internet connection and a
browser (even though different browsers
handle websites differently as well, but
more about this in Chapter 5)
2
Often more expensive to develop due to Often cheaper to develop due to propproperty 1
erty 1
3
Applications for each platform are de- Developed mainly in HTML5, CSS3
veloped in different languages. For ex- and JavaScript
ample, Objective-C for Iphone, Java for
Android and C# for Windows Phone
4
Need to be downloaded from platform No need for the user to download and
specific application store and installed install new software
on the device
5
Users may need to download and install Always up to date
new updates
6
Standard interface components are pro- Can be difficult to create a user invided by the manufacturer and plat- terface that satisfies users on different
form specific design patterns are avail- platforms since users of different platable
forms are used to different design patterns
7
The developer can charge a download There is no simple standard for chargprice in the application store
ing a download price
8
Requires Internet connection only de- Requires Internet connection (some
pending on application functionality
modern browsers indeed support
caching, but the general advice is that
an Internet connection is necessary)
9
Application are found and downloaded No central application store where users
from an application store that is specific can find and download applications
for the platform
10
Can access all hardware components Cannot access all hardware components
and sensors
and sensors (read more in Section 7.4)
11
Are typically faster and got better per- Are typically slower and got lower performance
formance
12
Can send push notifications
Cannot send push notifications
Which approach to choose for a specific application mainly depends on what kind of
application it is. But for most cases there will always be trade offs and the properties
will have to be prioritized. Figure 4.1 shows a decision tree designed to ease the decision
making of whether to develop a native mobile application or a mobile web application.
4.3. Pros and Cons with Native Mobile Applications Compared to Mobile Web
Applications
11
The figure is designed based on the content of Table 4.1. The questions in Figure 4.1 are
not intended to be unquestionable, even though they are simple yes-and-no questions. For
example, some hardware components are possible to access even from web applications,
but the general advice is to stick to native if the application will be dependent on builtin hardware components. The decision tree should not be confused with an ordinary flow
chart. One should check all the questions in the tree before a decision is made.
12
Chapter 4. Native Mobile Applications vs. Mobile Web Applications
Figure 4.1: Decision tree to ease the decision making whether to develop a native
mobile application or a mobile web application.
Chapter 5
Separate Mobile Websites vs.
Responsive Web Design
If web developers are frustrated over the number of different web browsers to considerate for
cross browser compatibility, some people argue that mobile web development is, if possible,
even more frustrating. Different devices do not only have unequal screen sizes and resolutions, they also run various browsers and have different hardware components and sensors
[2].
Within web development there are different approaches to choose when developing for
mobile devices. This chapter determines the dissimilarities and some advantages and disadvantages with the two approaches called separate mobile websites and responsive web
design.
Traditionally people tend to distinguish websites from web applications. Simplified one
can say that websites are more about the content (what the user sees) while web applications
are more about functionality (what the user can do) [19]. According to W3C (World Wide
Web Consortium) a web application is defined as “a Web page (XHTML or a variant thereof
+ CSS) or collection of Web pages delivered over HTTP which use server-side or clientside processing (e.g. JavaScript) to provide an ‘application-like’ experience within a Web
browser. Web applications are distinct from simple Web content (the focus of BP1) in that
they include locally executable elements of interactivity and persistent state” [20]. Worth
noticing is that, since this thesis aim to serve guidelines for mobile web development in
general, the words web application and website are treated as two different notions for the
same thing, even though this is not generally accepted.
5.1
Definition of Separate Mobile Websites
Websites developed for desktop computers are often hard to browse with mobile devices since
the content is not adapted to be viewed on small screens [8]. One way to solve this problem
is to create an additional website especially designed to show content on small screens [21].
In this paper this approach will be referred to as a separate mobile website. The mobile
version of a website is typically hosted at the same domain as the desktop version, but is
located at the subdomain m or mobile. For example, the website example.com may have
the corresponding mobile website m.example.com or mobile.example.com [22]. Since the
separate mobile website is located on its own URL it might not have the same markup as
13
14
Chapter 5. Separate Mobile Websites vs. Responsive Web Design
the original desktop website. This means that a separate mobile website can have different
content, structure and/or functionality.
5.2
Definition of Responsive Web Design
The term responsive web design was coined by Ethan Marcotte in 2010 [23, 21]. In contrast
to a separate mobile website, a responsive website got the same code base as the original
desktop site. What makes a responsive website so special is that it uses a flexible grid based
foundation. This flexible grid makes it possible to dynamically change the layout of the
website by changing the style of the content, depending on the size of the user’s viewing
area [23]. A responsive website is also located at the same URL as the desktop version of
the site, since this actually is the same. What makes it look differently is rather the usage
of CSS media queries [2].
5.3
Pros and Cons with Separate Mobile Websites
Compared to Responsive Web Design
For a long time, a separate mobile website was the only solution for optimization for mobile,
but today responsive web design has become a big hype. But, as in many other cases, the
preferable approach to choose may differ from case to case. The following list presents some
of the advantages and disadvantages with both these approaches.
Advantages with a Separate Mobile Website:
1. Possible to tailor the user experience especially for all different devices. If the users
require different content and/or functionality depending on the device used to access,
this is possible to tailor as wanted [23, 21].
2. Faster performance/load time. Separate mobile websites are faster [24]. However, this
is mainly noticeable when the web application contains heavy content and the gap
between mobile devices and desktop computers performance decreases for every day.
3. Possible to make separate changes to the different sites. If there is trouble on only one
platform, e.g. when accessing the site from a tablet, this can be adjusted without the
risk of ruin something on another platform [24].
Disadvantages with a Separate Mobile Website:
4. Time consuming to update the same content several times. When content is updated
this has to be done for each individual website. This might not be a problem if
there are only two versions (one for desktops and one for mobile devices with smaller
screens), but sometimes there may be a version especially optimized e.g. for tablets
and smaller tablets as well. The more versions, the greater time consumption [22].
5. Multiple URL’s that require redirection. When talking separate mobile web applications and support for multiple platforms, this means multiple URL’s. A mobile user
5.3. Pros and Cons with Separate Mobile Websites
Compared to Responsive Web Design
15
that enters the desktop version should be redirected to the mobile website, and redirections are time consuming. But even desktop users that access the mobile website
should preferably be redirected to the desktop website. If not, this may cause irritation when mobile users share links that are clicked by desktop users [24]. However,
to use so called device detection or browser sniffing to determine which site the user
should be redirected to is unreliable and difficult to maintain as the number of devices
increases [25].
6. Users may miss content that has been cut out for the mobile version. If all the versions
of the application do not offer the same content, some users may be frustrated trying
to find something that does not exist [24]. For example, if there originally is a desktop
version that is extended with a mobile version, but the mobile one lacks information
or functionality, there may be a mismatch between the users expectations and the
reality when the users are accustomed to use the desktop application.
7. Might need to develop new versions when new devices are released. When new devices
are released there is a risk that a new mobile application needs to be developed to fit
the new screen sizes. New versions means higher costs [22].
Advantages with Responsive Web Design:
1. Content is only entered/updated once but still available from all devices. One of the
main arguments for responsive web design is that responsive websites are easier to
maintain since all devices actually show the same web application and thereby only
need to be updated once [26].
2. One single URL that can be used and shared. The risk that desktop users enter the
mobile version of the website does not exist since there is only one web application
[24]. It does not matter if the URL is shared from a mobile device, the desktop users
will still see the desktop layout. One single URL may also be more advantageous for
Search Engine Optimization (SEO), since it makes it easier for search engines to track
visitor’s behavior.
3. Not necessary to implement new versions when new devices are released. Responsive
websites are supposed to be adaptable to all devices independent of their screen size.
This means that when a new device is released, there is no need to create a new version
of the website. In worst case the CSS-file might need some modifications to fit a larger
amount of screen sizes [27].
Disadvantages with Responsive Web Design:
4. The mobile users might not want the same content and/or functionality as desktop
users [28]. Responsive web applications contains the same markup independent of the
device it is view on. Elements are indeed possible to hide, but unnecessary content
will only result in larger files and thereby longer load time and worse performance.
For example, mobile users may want click-to-call functionality, scanning barcodes or
location or time based services.
16
Chapter 5. Separate Mobile Websites vs. Responsive Web Design
5. Slower performance/load time. Responsive web applications are slower than separate
mobile websites [24], but load time is mainly a problem for websites containing heavy
media or a lot of content. In other cases the time difference will be too small to notice.
There are also tricks to shrink the size of media as much as possible to keep the load
time short [23, 2] (read more in Chapter 7).
6. The mobile users might use different keywords when searching [29]. To search engine
optimize a website is it important to use thoughtful keywords. For example, mobile
users may search for nearest restaurant or nearest subway to greater extent than
desktop users. Within responsive web design there is no distinction between the
keywords for mobile and desktop.
7. The original website might be complex. A complex website is far more difficult to
make responsive than a not very complex one. And even more important, a complex
website may slow down the performance so much that the benefits are outshone [29].
For example, both CNN1 and ebay2 have separate mobile websites due to their heavy
and complex content.
Figure 5.1 shows a decision tree designed to ease the decision making of when to develop
a separate mobile website or a responsive web application. The figure is based on the
advantages and disadvantages in the list above. However, just as the decision tree in Figure
4.1 are the questions in Figure 5.1 not intended to be unquestionable, even though they are
simple yes-and-no questions. And again, the decision tree is no ordinary flow chart, and one
should therefore check all the questions in the tree before a decision is made.
1 http://edition.cnn.com/mobile/.
2 http://mobile.ebay.com/.
Accessed 2013-03-11.
Accessed 2013-03-11.
5.3. Pros and Cons with Separate Mobile Websites
Compared to Responsive Web Design
Figure 5.1: Decision tree to ease the decision making whether to develop a responsive web application or a separate website.
17
18
Chapter 5. Separate Mobile Websites vs. Responsive Web Design
Chapter 6
User Flow
A useful start when designing user interfaces is to create a User Flow. One great thing about
user flows is that the same course of action can be applied on several different areas and
techniques. This means that the following description may be used in all kinds of interaction
design, not necessarily only for mobile web. This chapter presents what a user flow is and
how to design it.
6.1
Definition of User Flow
A user flow, also called user workflow or user journey, is “the path a user follows through
your website interface to complete a task” [30]. The task the user should perform depends
on the purpose of the website. For example, purchase a ticket, subscribe to a newsletter or
make a reservation for the hairdresser. But, regardless of the purpose of the website, the
idea of the user flow is to help fulfilling the business objectives.
6.2
Design for User Flow
The user flow is important because it helps the user to perform the task at hand and thereby
fulfill the business objectives. If users get confused and do not find what they are looking
for, there is a probability that they will never return. And they will definitely not buy
anything if they cannot manage to figure out how to do so.
There are two things that have to be identified before starting to design the user flow.
1) The business objectives, and 2) what need the user desires to satisfy [30]. Worth noticing
is that there is no limit for how few or how many business objectives and user needs there
should be. However, the user needs should be clear and specific [31] and have to be matched
with the business objectives [30]. If there is no match between the user needs and the
19
20
Chapter 6. User Flow
business objectives, at least one of the involved will fail. For example, if the user wants
to watch a movie instantly and the site offers a streaming service there is a perfect match
of goals. However, if the user wants to watch a movie instantly, but the site only deliver
physical DVD-movies by mail there is a mismatch and the user either has to wait several
days to watch the movie or not watch the movie at all. The objectives have to match to
make satisfied users and prosperous businesses.
6.2.1
Identifying the Entry Points
The next thing is to identify the different entrances where the users first enter the site.
Some examples of common entry points [32] are:
• Organic searches - the site is found by a search engine
• Social media - a friend links to the site on any social network
• Media - the site is mentioned in an article or blog post
• Email - the site is recommended in a newsletter or other referral invitation
• Paid advertising - the user clicks a banner or other advertisement
• Direct entrance - the user knows the URL, e.g. from earlier visits or verbal recommendations
6.2.2
Structuring the Events
When the entry points are known, it is time to structure the events. Users may have different
knowledge and expectations of the site and need to be treated differently depending on the
different entry points, but each entry point should eventually lead to the business objective.
The possible events may be structured into chains starting from an entry point and ending
in the user goal (see Figure 6.1).
Sometimes there are two or more business objectives that are related. For example, at
the first visit the user subscribes to the newsletter and when a newsletter is received the
user purchases a product. In these cases the chains of events may be stacked until they
reach the supreme business objective (see Figure 6.2).
6.2.3
Creating a State Diagram
Once the events are known, it is time to evaluate what needs that has to be fulfilled in each
step of the process. It is important that this evaluation is based on real users if it should
actually give any new input for the design of the flow. These are some questions that need
to be answered to manage to understand the users motivations [30]:
6.2. Design for User Flow
21
Figure 6.1: Events leading to the user need and business objective. In this example the entry point is a link in a search result
and the business objective is fulfilled when the user subscribes
to the newsletter.
• What needs and desires do the users have about the product/service?
• Why do they need it?
• What qualities about the product/service is most important?
• What are their doubts, hesitations and questions about the product/service?
• What information and/or emotional bonds are required for them to take action?
When the questions are answered these may, together with the chains of events, be used
as the foundation when creating state diagrams. Each box in the state diagram is divided
with a horizontal line. The text above the line describes what the user sees, while the text
under the line describes what the uses does. The arrows between the boxes represents the
relation between what the user does and what he or she sees next (see Figure 6.3). Notice
that there may be several starts in the state diagram, each representing a possible entry
point [30]. There may also be several possible actions for one single box. A box might
lead to different other boxes depending on the action that is performed [33]. The example
in Figure 6.4 shows a state diagram with two possible entry points. Both ending up in
purchasing a product.
Each box of the state diagram contain the core value for each particular page of the site.
However, a box might contain several possible actions. When the state diagram covers all
the user goals and reaches the business objective, then the user flow is finished and it is
possible to move on to design the user interface.
22
Chapter 6. User Flow
Figure 6.2: Stacked events reaching the supreme business objective. In this example there are two entry points and two business
objectives that are fulfilled.
Figure 6.3: The structure of state diagrams. The left box shows what the user sees
and does now and the right box shows what the user sees and does next.
6.2. Design for User Flow
Figure 6.4: An example of a state diagram for a web shop. In this example there
are two entry points; from a search result and from a newsletter. Both scenarios
end up in purchasing a product.
23
24
Chapter 6. User Flow
Chapter 7
Guidelines for Mobile Web
Usability
Basically, mobile web applications are ordinary websites except for that they are especially
optimized to fit devices with smaller screens, battery constraints and less bandwidth. This
means that most of the design principles and standards applied on the web in whole are
also applicable on mobile web applications. However, there are some extra considerations to
have in mind when designing and developing for mobile web. In this chapter some guidelines
especially for mobile web development are stated and some commonly used components are
evaluated with respect to mobile web.
7.1
Considerations when Creating Mobile Websites
There are two main aspects of mobile web development to considerate, a) backend and
performance; which is about load time, functionality and overall performance and b) frontend
and usability; about the design and structure of the user interface. Alternative b) is the main
focus for this thesis, but a) will also be covered in some sense. The following sections contain
a subset of guidelines for mobile web development. However, these are only a few and should
not be considered to hold for all devices, environments and applications. The guidelines are
rather produced to facilitate the design and development of mobile web applications than
any absolute truths.
7.1.1
Back End and Performance
There are some actions that may be of great importance when it comes to backend and
performance of a website. The list below provides a subset of the most frequently used
tricks for speeding up load time and increasing performance. Some of them are valid for
25
26
Chapter 7. Guidelines for Mobile Web Usability
desktop web development as well, while some are more mobile specific. This section also
contains a more detailed explanation of each item in the list.
Subset of Things That Speed Up Load Time
• Reduce the content and size of media
• Reduce the number of HTTP-requests
• Use valid markup and code
• Avoid flash (and JavaScript)
• Load CSS-files before JavaScript-files
• Compress with GZip
• Enable Keep Alive
Regardless of which approach that is used (a separate mobile website or responsive web
application), is it important to try to reduce the size of the site. Especially media files such
as images, video and audio scale up the size and will slow down the load time. The amount
of data that is transmitted may not be crucial on a desktop, but for mobile devices with
unreliable connections the size might kill the user experience [2]. There are several ways
to decrease the amount of data. For example, for a separate mobile website the number of
images and other media files can be prioritized. Since a separate mobile website got its own
code base, only the images that are really necessary need to be retained [34]. The preferable
format of images differs depending on the type of image, e.g. if it is a photography or a
graphical image with high contrasts [35]. To optimize the file format for individual images,
lowering the resolution and optimizing the amount of colors are some simple tricks to reduce
file-size. Also e.g. removing HTML-comments and whitespaces will reduce the size of the
HTML-document [36].
The number of HTTP-request may as well be worth considering. For each file that is
used on the site there is one HTTP-request sent to the server. This means that there is
one request made for each CSS-file, JavaScript-file, HTML-file and image. And since each
request is adding up for the load time, a decrement of the number of files to be requested
will increase performance [37]. But sometimes images are crucial for the user experience.
Images that are part of the design, e.g. button icons, logotypes and custom borders and
bullets, can be streamlined by using sprites. A sprite is when several images are composited
into one single image, which may reduce the number of HTTP-requests drastically. When
the sprite is used, basically just a part of the composited image is shown [38].
Valid code will not only make the code more readable for the developer(s), but also for
the browsers. The most common used desktop browsers are usually fairly tolerant against
bad code, but this is not the case for mobile browsers. Mobile browsers are more sensitive to
bad code and might not show the site properly if the markup is not valid [2]. Furthermore,
the usage of proper element specifications in markup might not speed up the actual load
time, but may increase the perceived performance [39]. For example, specification of image
height and width helps the browser to render text content properly before all images are
7.1. Considerations when Creating Mobile Websites
27
loaded which will make the load time perceived as faster even though that might not be the
case [36].
One common technology to create more interactive user interfaces is Flash. However,
Flash is not supported by some of the most common mobile browsers (like Safari used on
Iphone) and should for this reason not be avoided [40]. Another popular technique for developing interactive user interfaces is JavaScript. If the primarily target group is smartphone
users, well coded JavaScript will probably work out well [41]. But even JavaScript might
not be supported on all mobile devices. For example, JavaScript is turned off by default on
Blackberry smartphones, which happens to be the third most used operating system in the
United States [42].
In the HTML-document, the CSS-file should always be loaded before any JavaScript-files
[43]. When the CSS-file is included first, this allows the CSS to load in parallel with the
JavaScript-file(s) which speeds up load time [44].
In the same way as files can be compressed before sent with an email to reduce the size,
websites can be compressed before requested from the server. This compression can be done
with GZip compression algorithm [39]. GZip simply compresses the site by temporarily
replacing repeated text strings (including whitespaces and tabs) before sending it from the
server to the browser. The browser decompresses the files and displays the site [45].
Traditionally when browsing the web, a new TCP (Transmission Control Protocol) connection opens each time a file is downloaded. In this case, a file may for example be the
HTML-document, all JavaScripts, stylesheets, images and other media. Keep Alive is a way
to keep the connection to the web browser open while browsing the website, which reduces
the number of times the server has to open new connections [39]. The idea of HTTP Keep
Alive (also referred to as HTTP persistent connection or HTTP connection reuse) is to use
a single TCP connection for several HTTP requests and responses, instead of reopening a
new connection each time [46].
7.1.2
Frontend and Usability
Regarding frontend and usability the design approach may have to be a little bit different
than when developing for desktop browsers. This section provides a subset of guidelines to
consider to make a mobile website usable.
Subset of Things That Improves Fronend and Usability
• Minimize user input
• Use appropriate input methods
• Stack elements on top of each other
• Increase hit areas
• Avoid hover functionality
28
Chapter 7. Guidelines for Mobile Web Usability
• Provide feedback on user interaction
• Include all information from the desktop site
• Design for light conditions
• Place content with respect to the device
• Use relative units for size
To enter text on a mobile device is time consuming and requires a lot of attention. The
user input can be optimized by changing text fields into radio buttons, checkboxes or other
tap friendly components [47]. Especially forms are hard to fill in on mobile devices, but
these can often partially be pre-filled with help of the devices hardware components [48] or
qualified guesses [49]. For example, when buying last minute flight tickets a built in GPS
can be used to automatically select a departure city and it is likely that the user wants to
see departures today (read more about available hardware components in Section 7.4).
The keyboard on mobile devices are rarely as large as on desktop computers, and hence
do often have a simplified set of keys. However, by specifying the input type of a text field
some devices can provide a keyboard that is optimized for the intended input [50] (read more
in Section 7.2.2). Autocorrect and autocapitalization are some other things worth to bear
in mind. These are intended to help the user, but in some situations they may cause more
harm than good. For example, the user probably knows how to spell his or her own name
and does not want the application to autocorrect. Email addresses are also an example of
input that should not be autocorrected, nor autocapitalized [51].
<!-- how to turn off autocorrect and autocapitalization -->
<input name="useremail" type="email" placeholder="name@email.com" autocorrect="off"
autocapitalize="off"/>
Mobile devices are relatively small and can not hold as much content as a screen for a
desktop computer. To not force the user to scroll in multiple directions, content on mobile
devices should be stacked vertically to avoid horizontal scrolling [34]. Due to this, e.g. labels
in forms should be placed above the form field. If the browsers zooms in, the user will still
keep the context of the input field [52].
Touch is the main interaction method of many mobile devices. The width of a human
finger is about 16-20 mm [53], the width of the fingertip is about 8-10 mm and the width
of the finger pad is about 10-14 mm [54]. When pushing buttons on a touchscreen humans
typically uses the finger pad. However, compared to a mouse pointer, a finger can be
perceived as quite big and imprecise. To compensate for this, touch areas have to be big
enough to avoid incorrect inputs, which also applies to the space between input controls
[47]. Different manufacturers provides different guidelines for the size of touchable elements,
but the most common recommendations is between 7x7 - 10x10 mm [55]. But mobile
devices does not only suffer from clumsy interaction technologies, they may also be used in
several different contexts, including in movement and with shared attention. The size of a
touchable area should therefore be decided with the application’s purpose in consideration.
For example, an application to be used in motion (such as during exercise or on the go for
the bus) may need even bigger touch areas than generally recommended.
7.1. Considerations when Creating Mobile Websites
29
It is impossible to hover on touch screens [56]. This means that navigation bars and other
content accessed from hover states should be avoided when designing for mobile devices.
A lot of todays mobile devices are equipped with touch screens as the major user interface. This means that these devices lack the natural tactile response that users are used to
get when pushing buttons on ordinary external keyboards or mouses. The lack of tactile
response makes it especially important to provide feedback to tell the user what an action
has caused. Feedback may also tell the user that something is going on even when the screen
is not updated immediately due to slow network [56]. For example, progress bars or loading
spinners may indicate when a page is updating and when filling a form the current text
box can be focused by color and input marker. There are even studies that show that good
feedback may increase the amount of users who finishes a form [58].
Early guidelines for mobile web design advocated that unnecessary content from an
original desktop site should be omitted when creating a mobile version, because mobile
users do not want the full content anyway since they are in a hurry and in motion. However,
the technology is developed rapidly and mobile devices are not used in the same manner
today as for a couple of years ago. Instead, the latest trends points towards the concept
called One web. According to W3C the notation of One web means “making, as far as is
reasonable, the same information and services available to users irrespective of the device
they are using. However, it does not mean that exactly the same information is available
in exactly the same representation across all devices” [57]. As stated by W3C, regardless of
the technology used and as far as reasonable, the same information that is accessible from
the desktop website should also be accessible from the mobile site. This course of action
may prevent users from being frustrated because they can not find the content they are
looking for when browsing on a different device than usual [24]. The trend of creating one
web also got support from newer statistics. According to Google’s Our Mobile Planet do
95% of the smartphone users use the phone at home [5], e.g. in the couch. This means that
mobile users cannot be assumed to need reduced content because they are in a hurry or on
the go anymore. Figure 7.1 shows some of the most common places where people use their
smartphone. Another recommendation (for separate mobile websites) is to provide a link
to the desktop website. This will make it possible for users who are used to brows the site
on desktop to use the same interface as usual.
Since mobile devices are portable they may be used in different contexts and environments than desktop computers. This means that mobile devices are more exposed to sunlight
during usage which leads to reflections. To minimize these, light colors are to prefer. Black
or dark background colors are harder to perceive in bright light and are more likely to show
fingerprints on the screen [59].
The optimal placement for components may differ between devices. Depending on the
size of the device, the user may hold the hands differently. A bigger device may be held
with two hands while a smaller one may be held with either a single-hand or a two-hand
grip [60]. This has to be taken into consideration since it would be unfortunate if important
information or controls would be obscured by the user’s own hands [61]. To avoid that the
user covers the content and controls with his or her hands components are recommended to
be placed under the content they control [60]. However, some devices also have hardware
buttons (for example Android and Windows Phone devices) which makes it cumbersome to
place buttons at the bottom of the screen. These would then be stacked directly upon the
30
Chapter 7. Guidelines for Mobile Web Usability
Figure 7.1: An estimation of how many smartphone users that use their device in some
common locations 2012 [5]. However, this chart only shows usage of smartphones (not all
mobile devices) and is not limited to just browsing the Internet.
hardware buttons, which may cause erroneous presses. An analysis of the target group and
the most frequently used devices may be helpful when creating the design.
The original size unit that is used within web design is pixels (px abbreviated). A tricky
thing about pixels is that a pixel does not have a determined size. In the non digital world
is one centimeter always ten millimeters and so on. In other words, one centimeter got a
determined size. However, the size of a pixel is dependent on the pixel density [62]. This
means that designing user interfaces based on fixed pixel sizes is not to prefer since different
screens got different pixel densities. The solution to this problem is relative units, e.g. ems
or percent. The size of one em is dependent of the current font size. This means that the
font size only need to be specified once, and then all other sizes on the entire page can be
determined relative it. For example, the width of a sidebar can be specified relative the size
of the text it contains. This does also mean that it is possible to specify different font sizes
for screens different sizes and/or different resolutions, but the rest of the content will adapt
to this size [63].
7.2. Components in Mobile Web Applications
7.2
31
Components in Mobile Web Applications
Except for the general performance and user interface guidelines there are also recommendations of components to use when designing for mobile web. As mentioned above, user input
can be really tricky on mobile devices. Partly because of the small screens that may add
visual constraints, but also because fingertips are clumsier and more imprecise than mouse
pointers. Research indicates that the bigger the target is, the easier it is to tap without
errors [64]. This means that some interface components might not be suitable, or may need
to be optimized especially for usage on touch screens. This section aims to define what a
component is and explain which components that are suitable to use in mobile web user
interfaces.
7.2.1
Definition of Components
The word component is used within several different areas and technologies. In this thesis
a component is the notation of a building block of the user interface. For example a text
block or an image. Some components are even interactive, such as buttons, text fields and
drop down lists. These interactive components are particularly interesting since they are
the direct link between the user and the device, thus are directly coupled to the device’s
interaction techniques.
7.2.2
Forms in Mobile Web
Small, virtual keyboards without tactile feedback makes filling out forms into one of the
trickiest things for mobile users. This section provides guidelines for how to design forms
for mobile web. Many of the guidelines explains different kinds of input-types, but there are
also other recommendations.
Even components that are supported by mobile web browsers need to be styled properly
to be accessible on small touch screens. The components in this section are styled and
enlarged with CSS to be more touch friendly. However, worth mentioning is that different
browsers render components differently. This means that some of the styles may be useful in
some browsers but not in other. The components in the following subsections are tested in
Chrome, Firefox and Opera on LG Nexus 4 (with Android 4.2.2) and Safari on Ipad 2 (with
iOS 6.0.1), and all images in this section are captured from Chrome (version 26.0.1410.58)
on a LG Nexus 4 (with Android 4.2.2).
Input Element with Type text
The input element with type text is one of the most common input methods in forms. This
is also the default type that other types of the input element defaults back to. This means
that the component will be showed as a text field if the browser does not support the type
that is specified. The text type is rendered as a single lined text field [65] (see Figure 7.2).
32
Chapter 7. Guidelines for Mobile Web Usability
<input type="text" />
Figure 7.2: Input element with type
“text”.
Input Element with Type password
The input element with type password looks like a regular text field, but the characters are
masked when the user starts to write (see Figure 7.3). The password type may be used for
all kinds of password fields, e.g. for login.
<input type="password" />
Figure 7.3: Input element with type
“password”. The letters are masked as
dots.
7.2. Components in Mobile Web Applications
33
Input Element with Type number
The input element with type number looks like a regular text field, but the keyboard that
is opened when the field is selected is numerical (see Figure 7.4). This means that the only
possible input is numbers or characters that may be used with numbers, e.g. dot (.), comma
(,), whitespace ( ) and hyphen (-). By default the interval in the number type is integers, but
the step attribute makes it possible to change this. It is also possible to limit the number
type by providing a min and/or max value and preselect a default value. However, these
attributes are not widely supported by mobile browsers.
<!-- OBS! The attributes "value" and "step" are not widely supported by mobile
browsers -->
<input type="number" min="0" max="10" value="5" step="0.5"/>
Figure 7.4: Input element with type
“number”. The virtual keyboard only
contains numbers and related characters.
Input Element with Type tel
The input element with type tel is similar to the number field. The component looks like a
text field and opens up a numerical keyboard when selected. However, the buttons on the
keyboard also contains letters even though numbers are default (see Figure 7.5). The tel
type should be used to input a telephone number.
<input type="tel" />
34
Chapter 7. Guidelines for Mobile Web Usability
Figure 7.5:
“tel”.
Input element with type
Input Element with Type email
The input element with type email looks like a regular text field, but got a email specific
keyboard associated with it. Characteristic for this keyboard is that it includes the @
character (see Figure 7.6).
<input type="email" />
Figure 7.6: The @-character is specific for
the virtual keyboard used with the input
element of type “email”.
Input Element with Type url
The input element with type url is similar to the email type. It looks like a text field and
opens up a specific keyboard when selected. Characteristic for this keyboard is that it may
include / and some devices also include a specific .com character (see Figure 7.7).
7.2. Components in Mobile Web Applications
35
<input type="url" />
Figure 7.7:
“url”.
Input elements with type
Input Element with Type date
The input element with type date automatically opens up the native date picker (see Figure
7.8). This means that the user will be able to use the control that he or she is used to from
native applications.
<input type="date" />
Figure 7.8: Input element with type
“date”. A native date picker opens when
the component is selected.
36
Chapter 7. Guidelines for Mobile Web Usability
Input Element with Type datetime
The input element with type datetime is similar to the date type but instead of opening up
the native date picker it opens up the native date picker that also includes a time picker
(seen Figure 7.9).
<input type="datetime" />
Figure 7.9: Input element with type
“datetime”. A native picker opens up
when the component is selected.
Input Element with Type month
The input element with type month opens up a native month picker (see Figure 7.10).
<input type="month" />
7.2. Components in Mobile Web Applications
37
Figure 7.10: Input element with type
“month”. A native month picker opens
when the component is selected.
Input Element with Type week
The input element with type week opens up the native week picker (see Figure 7.11). This
component is however not widely supported by different web browsers.
<!-- OBS! Not widely supported by all web browsers and operating systems -->
<input type="week" />
Figure 7.11: Input elements with type
“week”. This component is not widely
supported and is therefore captured from
a LG Google Nexus 4 (with Android
4.2.2) with Firefox (version 20.0.1).
38
Chapter 7. Guidelines for Mobile Web Usability
Input Element with Type time
The input element with type time opens up the native time picker (see Figure 7.12).
<input type="time" />
Figure 7.12: Input element with type
“time”. A native time picker opens up
when the component is selected.
Input Element with Type checkbox
The input element with type checkbox shows a regular checkbox that got two states (see
Figure 7.13). It is a simple yes or no component that may be grouped with several other
checkboxes. The checkbox should be used when the choice(s) are optional, it should be
possible to select several options but no choice needs to be selected.
However, the default checkbox is very small and is difficult to style properly with good
code convention. The styles should not be assumed to be compatible with multiple browsers
without proper testing.
<!-- OBS! Difficult to style for mobile friendliness -->
<input type="checkbox" />
Figure 7.13: Group of input elements
with type “checkbox”.
7.2. Components in Mobile Web Applications
39
Input Element with Type radio
The input element with type radio shows a regular radio button that, similar to the checkbox,
got two states. The difference between the radio button and the checkbox is that the radio
button should be used when there is a group of choices and it is mandatory to select one
and only one choice (see Figure 7.14). It should not be possible to select more than, or less
than one option. When a radio button is selected, it is only possible to unselect by selecting
another option in the same radio group.
However, just as the checkbox is the default radio button very small and difficult to style
properly for mobile devices.
<!-- OBS! Difficult to style for mobile friendliness -->
<input type="radio" />
Figure 7.14: An group of input elements with type “radio”. The components are enlarged with CSS and the image is captured from a LG Google Nexus
4 (with Android 4.2.2) with Chrome (version 26.0.1410.58).
Input Element with Type range
The input element with type range is rendered as a horizontal slider (see Figure 7.15), which
should be used to select a value from a range of numbers. It is possible to limit the input
values from the range type by specifying a min and/or max value, and a default value.
However, the range type is not widely supported in mobile browsers and even though some
of the browsers manage to render the slider properly is the slider head usually tricky to
move on touch screens. In browsers where the range type is not supported at all, the field
defaults to a number field. In this case, instead of showing a slider with a movable head,
the component shows a text field with an associated numerical keyboard.
<!-- OBS! Not widely supported by mobile browsers -->
<input type="range" min="0" max="100" value="25" />
40
Chapter 7. Guidelines for Mobile Web Usability
Figure 7.15: Input elements with type
“range”. This component is not widely
supported and is therefore captured from
a LG Google Nexus 4 (with Android
4.2.2) with Opera (version 12.10.ADR1301080958).
Input Element with Type button
The input element with type button shows a regular pushable button (see Figure 7.16).
This component needs to be attached to an event handler to know what action to call. For
example, JavaScript may be used to create an event handler. The value attribute is used to
display a text on the button.
<!-- OBS! Needs e.g. JavaScript to handle the click event -->
<input type="button" value="Click here" />
Figure 7.16: Input elements with type
“button”.
Input Element with Type reset
The input element with type reset is perceived as a regular button (see Figure 7.17), but
this do not need any custom event handler to be attached. By default the reset button
resets all the fields in the entire form. The value attribute is used to display a text on the
button.
<input type="reset" value="Reset form" />
Figure 7.17: Input elements with type
“reset”.
7.2. Components in Mobile Web Applications
41
Input Element with Type submit
The input element with type submit is rendered as a button that submits a form (see Figure
7.18). This component needs, just as the button type, to be attached to an event handler
that handles a press of the button. For example, JavaScript may be used to create an event
handler. The value attribute is used to display a text on the button.
<!-- OBS! Needs e.g. JavaScript to handle the click event -->
<input type="submit" value="Submit form" />
Figure 7.18: Input elements with type
“submit”.
Input Element with Type file
The input element with type file looks different in different web browsers. But what is
common is that there is a button for selecting a file and a text field where the name of
(or the path to) the selected file is shown (see Figure 7.19). In many browsers (e.g. in
Chrome and Firefox for Android) the buttons opens a view where the user can choose an
appropriate native application (see Figure 7.20), which may be used to capture or select a
file. For example, a camera or gallery application may be appropriate for selecting an image
file. However, there are also browsers that let the user choose a file from a more desktop
inspired view, e.g. Opera for Android (see Figure 7.21).
The file type may also be restricted with a MIME type. A MIME type specifies what
kind of file that may be selected. However, this specification is not supported by all browsers,
but a default file component is shown if the MIME type is not supported. The file type may
be one of the MIME types image/*, sound/* or video/* [66].
<!-- OBS! Might behave differently in different browsers -->
<input type="file" accept="image/*"/>
Figure 7.19: Input elements with type
“file”. This image is captured from a LG
Google Nexus 4 (with Android 4.2.2) with
Opera (version 12.10.ADR-1301080958).
42
Chapter 7. Guidelines for Mobile Web Usability
Figure 7.20: View with native applications that can be chosen. The image
is captured from a LG Google Nexus 4
(with Android 4.2.2) with Chrome (version 26.0.1410.58).
Figure 7.21: View to select the path to a
file that should be uploaded. The image
is captured from a LG Google Nexus 4
(with Android 4.2.2) with Opera (version
12.10.ADR-1301080958).
7.2. Components in Mobile Web Applications
43
Input Element with Type color
The input element with type color is rendered as a field that shows the current selected
color. A color picker opens up when the field is selected (see Figure 7.22). However, this
type is only supported by a few mobile browsers (e.g. Opera for Android) and even just a
few desktop browsers as well (e.g. Chrome and Opera).
<!-- OBS! Not widely supported by mobile nor desktop browsers -->
<input type="color" />
Figure 7.22: Input elements with type
“color”. This component is not widely
supported and is captured from a LG
Google Nexus 4 (with Android 4.2.2) with
Opera (version 12.10.ADR-1301080958).
Hyperlink
The purpose of a hyperlink (often referred to as an anchor link or just a-tag) is that it
links to another source, e.g. another page on the same website, another website or external
document. Links are typically used in the navigation bar and do not necessarily need to
contain a text. This means that the hyperlink may contain other elements [67], e.g. an
image.
<a href="http://www.example.com">www.example.com</a>
Hyperlinks are blue and underlined as default (see Figure 7.23), but are often styled to
better fit the overall design of the website. However, even though hyperlinks may be styled
to look differently than the default link, is it important to let the hyperlink have a look that
is distinguishable from regular text. It is hard to distinguish hyperlinks from regular text if
they are styled to look the same, and the lack of hover state on touch screens makes it even
more impossible on mobile devices.
Unique for mobile phones is that hyperlinks also may be used to enhance the usability
of contact pages for mobile users. A click on a link with a specified action and telephone
number opens up the native telephone, respectively SMS-application (see Figure 7.24).
<a href="tel:+46701234567">Tap to call 070-123 45 67</a>
44
Chapter 7. Guidelines for Mobile Web Usability
<a href="sms:+46701234567">Send SMS to 070-123 45 67</a>
<a href="sms:+46701234567?body=Hello%20World!">SMS ‘Hello World!’ to 070-123 45
67</a>
Figure 7.23: Ordinary hyperlink with its
default color.
Figure 7.24: Smartphone specific hyperlinks. Opens up the phone’s native
phone- respectively SMS-application.
Select Element
The select element looks like an ordinary drop down list but opens up a native select list
when pressed. The select element is used as a selector when there are several choices that
preferably are presented in a list and it is only possible to select one choice. For example,
when choosing a country or a city.
<label for="country">Select your country</label>
<select id="country" name="country">
<option value="den">Denmark</option>
<option value="fin">Finland</option>
<option value="nor">Norway</option>
<option value="swe">Sweden</option>
</select>
Figure 7.25: Select element. Native selector is opened when the component is
selected.
7.2. Components in Mobile Web Applications
7.2.3
45
Navigation Menus in Mobile Web
Navigation menus can be troublesome to design for small screens. In desktop browsers the
navigation menu of most websites are usually straightforward with links following each other
in a row or a list, but on mobile devices there may be a shortage of space. This subsection
contains a set of examples of how this problem may be addressed. However, unlike the
form components in Section 7.2.2 the examples in this section are not native or built in
components accessible directly from HTML, but rather common custom solutions that are
available in many different shapes all over the web.
Footer Anchor Menu
The Footer Anchor Menu is a menu located at the bottom of the screen. The menu may be
reached by tapping a menu icon on the top of the page where the menu traditionally should
have been placed. The menu icon points to the footer menu which makes it easy to access
but still out of the way for the core content (see Figure 7.261 ). The Footer Anchor Menu
saves space and is easy to access, but unaccustomed users may feel disoriented since they
are unexpectedly relocated to the bottom of the page [68].
Select Menu
The Select Menu is a regular drop down list that is populated with menu items (see Figure
7.272 ). This approach uses the built in HTML select element (see Section 7.2.2) and opens
the device’s native select list on mobile. The Select Menu looks different in different browsers.
To avoid this there are ways to style the select element, but this makes the Select Menu lose
its main advantage; that it is simple to implement. Styling the select menu should therefore
be avoided. Furthermore, if the menu should contain subitems the Select Menu might not
be the best solution [68].
CSS Drop Down Menu
The CSS Drop Down Menu is a more elegant alternative to the Select Menu. The functionality is the same, but the technique is slightly different. Instead of populating a build in
HTML select element with the menu items, the drop down is manually implemented. The
advantage with this approach is that it is possible to style the menu to fit into the overall
design, but it is a little bit more complex to implement [69]. However, the CSS Drop Down
Menu is dropped down on top of the core content even on mobile devices and is not opened
in a native select list as the Select Menu (see Figure 7.283 ).
1 http://builtwithmomentum.com/.
Accessed 2013-04-24.
Accessed 2013-04-24.
3 http://www.neovada.com/. Accessed 2013-04-24
2 http://retreats4geeks.com/.
46
Chapter 7. Guidelines for Mobile Web Usability
Toggle Menu
The Toggle Menu is kind of similar to the CSS Drop Down Menu. It is a drop down list
typically located at the top of the page that contains the menu items (see Figure 7.294 ). The
Toggle Menu can be styled to fit the overall design of the rest of the page and is accessed
by a menu icon [69]. The difference between the CSS Drop Down Menu is that with the
Toggle Menu the core content is forced down by the menu items that are revealed. The
Toggle Menu saves space and is elegant, but is dependent on JavaScript and it might be
tricky to make a smooth animation on all devices and different browsers when revealing the
menu items [68].
Multi-Toggle Menu
The Multi Toggle Menu is, as the name suggests, very similar to the Toggle Menu. The
difference is that the menu may contain even more menu items that are revealed in levels.
When a menu item is selected even more items are revealed in the list (see Figure 7.305 ). The
Multi-Toggle Menu is suitable for complex navigation menus with multiple levels of menu
items. The disadvantage is that the Multi-Toggle Menu requires JavaScript and might not
animate as smooth on all devices and browsers as one could wish [70].
Side Panel Menu
The Side Panel Menu is accessed from a menu button and is sliding in to the screen from
the left (see Figure 7.316 ). The core content is pushed to the right to give place for the
menu items [69]. The Side Panel Menu is stylish and may contain relatively many menu
items, but compared to many other solutions the Slide Panel Menu is relatively advanced
and easily broken. Also, it may be confusing for unaccustomed users when the core content
is forced far to the right which makes it more or less unreadable (depending on the size of
the screen) [68].
Swipe In Menu
At the first glance the Swipe In Menu looks like a CSS Drop Down Menu. But the first level
of the Swipe In Menu is populated with categories and not single menu items (see Figure
7.327 ). When a category is selected the next level of the menu swipes in from the right with
a smooth animation [70]. The Swipe In Menu is suitable for complex navigation menus that
are bulky and when multiple levels of menu items are required. However, the disadvantages
are that this approach got a lot of moving parts and may be complex to make smooth on
all devices and in all browsers.
4 http://www.starbucks.com/.
Accessed 2013-04-24.
5 http://webdesigntutsplus.s3.amazonaws.com/tuts/378_tessa/tessa-lt-dropdowns-21c7868/
index.html. Accessed 2013-04-24.
6 https://m.facebook.com/. Accessed 2013-04-24.
7 http://www.sony.com/index.php. Accessed 2013-04-24.
7.2. Components in Mobile Web Applications
47
Figure 7.26: The Footer Anchor Menu on mobile and desktop. The image of the mobile
version is a montage where some content has been cut off to make it possible to see the
menu icon in the top right corner at the same time as the menu in the footer.
48
Chapter 7. Guidelines for Mobile Web Usability
Figure 7.27: The Select Menu on mobile and desktop. The select menu opens a native select
list.
7.2. Components in Mobile Web Applications
49
Figure 7.28: The CSS Drop Down Menu on mobile and desktop. The menu items overlap
the core content.
50
Chapter 7. Guidelines for Mobile Web Usability
Figure 7.29: The Toggle Menu on mobile and desktop. The core content is forced down by
the menu items.
7.2. Components in Mobile Web Applications
51
Figure 7.30: The Multi-Toggle Menu on mobile and desktop. The different levels of menu
items are separated from each other with different colors.
Figure 7.31: The Side Panel Menu on mobile. The core content is pushed to the right when
the menu is revealed.
52
Chapter 7. Guidelines for Mobile Web Usability
Figure 7.32: The Swipe In Menu on mobile and desktop. A new level of menu items swipe
in from the right when a category is selected.
7.3. Breakpoints of Screen Sizes
7.3
53
Breakpoints of Screen Sizes
One decision that always has to be made when designing for mobile web is what screen sizes
and resolutions that will be supported by the new web application. The point where one
design replaces another due to screen resolution is called a breakpoint. This section covers
how to find the appropriate breakpoints and the most popular screen sizes.
7.3.1
Analyzing Sizes and Resolutions
A couple of years ago the strategy when designing for mobile web was to analyze which
devices and screen resolutions that were most frequently used when accessing the site and
then create a mobile website for each of these. Alternatively, if there were no available
statistics to analyze, to design for the most frequent used devices among the target group.
According to StatCounter is the most frequently used screen resolution for mobile devices
today (April 2013) 320x480 px [71], which is the screen resolution of the first Iphone8 .
Figure 7.33 shows the most common resolutions of mobile devices from April 2012 to Mars
2013. Furthermore, to design for a width of 320 px for mobile devices is a generally accepted
strategy [72]. The approach to design for some generally well used resolutions is widely used
and much more beneficial than not creating any mobile web at all [73]. But both the size
(in inch) and the resolution (in pixels) of new released devices just seem to get bigger and
bigger and will always be dependent on the prevailing trends.
Figure 7.33: The top 14 mobile screen resolutions in the world from April 2012 to Mars
2013 [71].
8 http://www.iphoneresolution.com/.
Accessed 2013-04-12.
54
7.3.2
Chapter 7. Guidelines for Mobile Web Usability
Letting the Content Decide the Breakpoints
In contrast to the previous strategy to find the breakpoints by analyzing the current most
common devices screen sizes and resolutions, the new recommendations and a more futureproof approach is to let the content decide the breakpoints. A popular start point is to
apply the mobile first technique , which is described in Section 2.4. When the design for
the smallest screen size is made, then the next thing to do is to resize the browser window
until the design breaks (i.e. looks bad). The procedure is repeated and a new breakpoint
is set for each time the design breaks [74]. In this way the design is subsequently getting
bigger and bigger for each time the content requires so.
7.4
Hardware Integration in Mobile Web Applications
A hardware component is a part of the device’s physical features and is possible to touch
and see if the device is disassembled [75]. For example, many mobile devices contain a
camera and a GPS (Global Positioning System). A sensor, also called detector, is a type of
hardware component that is used to measure a physical quantity in the device’s surroundings
and convert this into digital signals [76]. For example, popular sensors in mobile devices are
accelerometers, gyroscopes and photometers.
This section describes how hardware components may be used within mobile web applications. However, all devices do not contain the same hardware components and different
manufacturers may provide different support for accessing the available components. It is
also important to remember that the technique for accessing hardware components develops
rapidly and sensors that are not possible to access from a web application today might have
support in just a few months.
7.4.1
Detecting Features Supported by the Browser
Modernizr9 is a JavaScript library that may be used to easier detect HTML5 and CSS3
features in the user’s browser. It is possible to serve different functionality based on the
capabilities of the browser by detecting the support for the features. This means that it
is feasible to get the most out of the application for individual users, regardless of which
features that may or might not be supported by other browsers.
7.4.2
Hardware Integration
This section describes the hardware integration that is possible to achieve from mobile web
applications. But as already mentioned, some of the components may not be accessible from
all different devices.
9 http://modernizr.com/.
Accessed 2013-04-15.
7.4. Hardware Integration in Mobile Web Applications
55
Images, Camera, Video and Audio
The Media Capture API 10 is an extension of the File API 11 which lets the user access
files on the device through a file picker opened from a web application (see Section 7.2.2).
The file type may be one of the MIME types image/*, sound/* or video/* [66]. The file
input element opens up a view where the user can choose a suitable native application, e.g.
camera or gallery, to capture or select the media. This is the same technique as mentioned
in Section 7.2.2 (see Figure 7.19 and Figure 7.20).
<!-- example of how to capture image with HTML5 -->
<input type="file" id="photo" accept="image/*" />
However, the development of the Media Capture API has stopped in favor of the Media Capture and Streams API 12 , which is not yet standardized or supported by the most
common web browsers [77].
GPS and Geolocation
A GPS (Global Positioning System) is used to determine the geographical position of the device and may for example be used to track the user on a map or provide navigation features.
The Geolocation API 13 may be used to access the GPS from a mobile web application. The
GPS is accessed by JavaScript and is supported by most desktop and mobile web browsers.
However, before fetching the position the Geolocation API will force the browser to pop up
an infobar at the top of the page. The location cannot be received until the user grants the
web application access to the device [78]. This infobar is important to maintain the user’s
integrity.
Accelerometer, Gyroscope and Compass
Many mobile devices have a built-in accelerator, gyroscope and compass. These sensors are
used to measure the orientation of the device, and are often used together. An accelerometer
is used to measure the acceleration, also called velocity change, the device is exposed to [79].
A gyroscope is used to measure the maintaining orientation of the device [80], which means
that the gyroscope measures how the device is rotated in space. A compass is a navigation
detection instrument that is used to detect directions [81]. These three sensors may be
accessed though the Device Orientation API 14 for usage withing web applications, and may
e.g. be used in navigation applications or games.
10 http://www.w3.org/TR/media-capture-api/.
Accessed 2013-04-16.
Accessed 2013-04-16.
12 http://www.w3.org/TR/mediacapture-streams/Accessed 2013-04-16.
13 http://dev.w3.org/geo/api/spec-source.html. Accessed 2013-04-15.
14 http://dev.w3.org/geo/api/spec-source-orientation.html. Accessed 2013-04-15.
11 http://www.w3.org/TR/FileAPI/.
56
Chapter 7. Guidelines for Mobile Web Usability
Proximity sensor
Some mobile devices are equipped with a proximity sensor which makes it possible for
the device to detect nearby objects without touching them [82]. For example, there are
smartphones that use this sensor to turn off the screen when the user holds the device close
to the ear when talking in the phone. This prevents the user from pressing any buttons
by mistake. The Proximity Events API 15 may be used to access the proximity sensor from
a web application. However, the Proximity Events API is not yet standardized and is not
supported by all the most common web browsers [77].
Battery and Power Management
The Battery Status API 16 is for the moment (April 2013) not supported by most of the
common web browsers [77] but is intended to become a W3C Recommendation. The Battery
Status API may be used to detect if the device is charging or is low on battery and take
appropriate action. For example, a web mail application may check the server for new mails
more frequently when the device is charging or high on battery compared to when the device
is low on battery.
Vibrations
The Vibration API 17 provided from W3C may be used to make the mobile device vibrate for
an arbitrary length of time. The Vibration API is not standardized and does not work with
the most common web browsers. For example, the API does work for Firefox for Android,
but not for Chrome or Opera for Android (LG Google Nexus 4, Android 4.2.2).
Notifications
Push notification are not really hardware components but are often mentioned in the same
context. Push notifications are used within native mobile applications to tell the user that
a new event has occurred. For example, a new email or sms is received, a competitor in a
game has made its move or someone sent a message on a social network. The idea of a push
notification is to alert the user that something has happened, even though the application
itself might not be running at the moment [83]. However, notifications are not possible to
send from web applications [84].
15 https://dvcs.w3.org/hg/dap/raw-file/tip/proximity/Overview.html.
16 http://www.w3.org/TR/battery-status/.
Accessed 2013-04-16.
17 http://www.w3.org/TR/vibration/. Accessed 2013-04-22.
Accessed 2013-04-16.
7.4. Hardware Integration in Mobile Web Applications
57
Other Sensors and Hardware Components
Some mobile devices also contain other sensors and hardware components not mentioned
above. For example, a magnetometer, a thermometer and light sensors. There are work in
progress to develop APIs to make these accessible from web applications, but these are only
early drafts and are not planned to be stabilized in the near future and should therefore be
used with caution.
58
Chapter 7. Guidelines for Mobile Web Usability
Chapter 8
Prototype Developed to
Exemplify the Theories
A prototype was implemented to further exemplify some of the theoretical theories presented
above. The assignment was an exploratory study about how the swedish news site Resumé1
can be redesigned into a responsive website. The starting point was to keep the overall
design that is used today, but rearrange the content and adapt the interaction components
to mobile devices with touch screens. This chapter describes the accomplishment and the
result of the prototype.
8.1
Accomplishment
Based on the theories in Chapter 4 about native mobile application versus mobile web
applications one can conclude that a mobile web application suits the assignment particularly
well. Figure 8.1 visualizes how the decision has been made. Briefly one can say that in this
case a mobile friendly web application is suitable since there already is a website with a
well-functioning backend and CMS and with an already existing user base that uses many
different devices and operating systems. This user base is moreover already accustomed to
visit Resumé directly through the website’s URL and it is therefore preferable to keep this
entry point instead of forcing the users to download and install a native application.
The possibility to send push notifications is the only reason why it might had been
suitable to develop a native mobile application instead of a web application. However, to
send push notifications is not a necessity and nor are there any other requirements to use
any hardware components.
Chapter 5 describes the profits and the drawbacks regarding responsive web respectively
separate mobile websites. What one can see based on this chapter is that a responsive
1 http://www.resume.se/.
Accessed 2013-06-20.
59
60
Chapter 8. Prototype Developed to Exemplify the Theories
solution is particularly suitable for Resumé. Since Resumé is a news site is it obvious
that the content will be updated frequently and it is therefore important that all possible
versions always are up to date. The content will moreover also be the same on all platforms,
independent of if the site is visited from a desktop computer, tablet, smartphone or any
other kind of device.
Furthermore, it is not only important that the content is accessible from many different
kinds of devices and screen sizes, but also from different operating systems and platforms.
Another noteworthy thing is the possibility to share content easily between these different
platforms. Since Resumé is a news site one can assume that the articles may be shared
frequently in social media, blog posts, e-mails or any other possible way. This makes it
important for users to get direct access to the same content, independently of platform and
channel used when sharing and consuming.. All these circumstances are facilitated by a
responsive solution with one single code base. Figure 8.2 further visualizes the background
of the decision to create a responsive web application instead of a separate mobile website.
Chapter 6 declares the importance of creating a user flow. However, this was not considered necessary when working with the prototype since the fundamental design of the site
already existed. The aim was to keep the overall design and just rearrange the components
depending on the size of the view port, while the flow of the original site was maintained.
This means that there were no need to decide neither colors, fonts, icons and overall structure, nor the connection between different pages or content.
8.1. Accomplishment
Figure 8.1: Decision tree that shows the thoughts behind the
decision to create a mobile friendly web application instead of a
native mobile application.
61
62
Chapter 8. Prototype Developed to Exemplify the Theories
Figure 8.2: Decision tree that shows the thoughts behind the
decision to create a responsive web application instead of a separate mobile website.
8.2. Results
8.2
63
Results
The final result of the prototype is purposely very similar to the original website, especially
in desktop mode. The start page of the original site is more or less a typical news site start
page, and the prototype is a design proposition of how this could look like if remade into a
responsive design. This section describes the result of the prototype.
The prototype may be divided into four different modes. These modes are mobile portrait
mode, tablet portrait mode, tablet landscape mode and desktop mode. Worth mentioning is
that the tablet portrait mode also is applied on smartphones in landscape mode and the
structure of the whole site in desktop mode is the same as on the original site. Some minor
differences between the desktop mode and the original site is presented later in this section.
The top of the prototype on different screen sizes may be seen in Figure 8.3. The header
in desktop mode starts with a panorama advertisement followed by a quickmenu and links
for login and registration. The quickmenu contains links for quick access to important
pages such as a page for subscription to the paper magazine, a page for information about
advertisement and a contact page. The header also contains a logotype followed by the main
menu with a submenu, and a search field followed by links for subscribing to the newsletter
or to the RSS-feed. The header ends with another panorama advertisement.
Figure 8.3: The top of the prototype on different screen sizes. A: mobile portrait mode, B:
tablet portrait mode, C: desktop mode, D: tablet landscape mode.
The only significant difference between the header in desktop mode and the header on the
original site is that the prototype lacks a blog teaser that originally is located to the right
of the logotype and a widget for showing job advertisement at the bottom of the header.
However, the desktop mode of the prototype got an empty space where the blog teaser could
be inserted, and the job advertisement may be added underneath the header, if desired. A
closeup of the original header may be seen in Figure 8.4:A while a closeup of the header in
desktop mode of the prototype may be seen in Figure 8.4:B.
64
Chapter 8. Prototype Developed to Exemplify the Theories
Figure 8.4: A: Header of the original site, B: Header of the prototype in desktop mode.
The header in tablet landscape mode is very similar to the header in desktop mode.
However, there are some major changes in the arrangement. In this mode there is no empty
space reserved for the blog teaser to the right of the logotype. This is instead where one
can find the search field, the links for subscribing to the newsletter or RSS-feed and a menu
toggle button that replaces the main menu that originally where placed underneath the
logotype. When the menu toggle button is pressed it reveals a vertical list with the menu
items, and a link to the right of some of the menu items reveals the submenus. The header
of the tablet landscape mode may be seen in Figure 8.5:A. The open main menu looks similar
to the main menu in mobile and tablet portrait mode which may be seen in Figure 8.6:B and
Figure 8.6:C.
The header on tablet portrait mode and mobile portrait mode looks the same. These
kind of devices got a simplified header with a less detailed logotype. The quickmenu is
hidden as well as the links for subscribing to the newsletter or the RSS-feed. However, these
links are still accessible from the footer of the page. In these modes also the search field is
replaced with a search toggle button similar to the menu toggle button used to toggle the
main menu. When the search toggle button is tapped, a search field is revealed underneath
(see Figure 8.7). The menu toggle button, the logotype and the search toggle button are
also rearranged to float next to each other in a row (see Figure 8.5:B and 8.5:C). A closeup
of the open main menu in mobile portrait mode may be seen in Figure 8.6.
Since Resumé primarily is a news site the news feed is the main focus in all modes, and
this may be divided into four sections. These sections are Latest news, Most viewed, News
and Older news. At the original website the news feed is structured into three columns.
One main column that spans over half the page and two narrower columns each taking up a
8.2. Results
65
Figure 8.5: A: Header in tablet landscape mode, B: Header in tablet portrait mode, C: Header
in mobile portrait mode.
quarter. The main column contains the latest news and the news section, while most viewed
is located at the top of the two minor columns followed by the section for older news.
The desktop mode got the same structure for the news feed as the original site. The
tablet landscape mode is similar to desktop mode, but all the teasers in most viewed and
older news are stacked in one single narrow column to the right of the main column, instead
of two. As the size of the screen shrinks, so does the number of columns. In tablet portrait
mode all teasers are stacked into one column, but the teasers in most viewed and old news
are still floating next to each other two and two. However, in mobile portrait mode all teasers
for articles are stacked on top of each other in the main column. The structure of the news
feed in different modes is visualized in Figure 8.8. As one can see in Figure 8.8 latest news
and most viewed are always the sections that are prioritized. Therefore these are always at
the top of the page.
The news feed is followed by a blog section. The blog section on different screen sizes
may be seen in Figure 8.9. In desktop mode and tablet landscape mode the blog section
shows an image and a short teaser text for the latest published blog post for each blog
available at Resumé. The only difference between these modes and the original website is
that the original website shows a teaser text for the two latest blog post instead of only the
latest one. The tablet landscape mode also is a little bit narrower than the desktop mode
and each row of teasers can therefore not contain as many teasers as in desktop mode.
66
Chapter 8. Prototype Developed to Exemplify the Theories
Figure 8.6: The top of the prototype in mobile portrait mode. A: The main menu is closed.
B: The main menu is opened. C: One of the sub-menus is opened.
Figure 8.7: The search field becomes visible when tapping the search toggle button.
In tablet portrait mode and mobile portrait mode the teasers in the blog section are
transformed into a carousel due to lack of space. The carousel shows one image with
accompanying teaser text at a time. In tablet portrait mode the teaser text is located to the
right of the image, while it is located underneath the image in mobile portrait mode. This
difference is made to utilize the space optimally. A closeup of the blog carousel in mobile
portrait mode may be seen in Figure 8.10:A, while mobile landscape mode (that is the same
as tablet portrait mode) may be seen in Figure 8.10:B.
The blog section is followed by a few other sections with upcoming events, media campaigns and photographs from earlier events, but all these are arranged in a similar way
as the news feed or the blog section. Sections with a lot of images are transformed into
carousels similar to the blogs and text based sections are rearranged in a similar way as the
news feed.
8.2. Results
67
Figure 8.8: The structure of the news feed in different modes. A: mobile portrait mode, B:
tablet portrait mode, C: desktop mode, D: tablet landscape mode. 1 - Latest news, 2 - Most
viewed, 3 - News ordered by time, 4 - Older news ordered by time.
68
Chapter 8. Prototype Developed to Exemplify the Theories
Figure 8.9: The blog section in the prototype on different screen sizes. A: mobile portrait
mode, B: desktop mode, C: tablet landscape mode, D: mobile landscape mode (the same as
tablet portrait mode).
Figure 8.10: Closeup on the blog carousel. A: mobile portrait mode, B: mobile landscape
mode (the same as tablet portrait mode).
8.2. Results
69
The prototype ends with a footer that may be seen in Figure 8.11. The footer in desktop
mode and tablet landscape mode looks the same, but differs a little bit from the original site.
The original footer got a small Resumé logotype and red links spread sporadically over the
footer together with three columns of text and links with copyright and contact information.
In the prototype’s desktop mode and tablet landscape mode the logotype is removed and the
links are listed in their own column. Furthermore, the footer in the prototype also includes
three icons listed in a row at the absolute end of the page. These icons links to the RSS-feed
and to social media, and are present in all the modes of the prototype. Another difference
between the footer in the prototype and the original site is that all the links are black and
underlined. This change has been made to further adapt the website to touch screens since
the lack of hover state makes it harder to perceive links that are too similar to regular text.
A closeup of the original footer and the desktop mode may be seen in Figure 8.12.
In tablet portrait mode there are only three columns of text in the footer. These are the
same as the columns in the original footer and are copyright and contact information. The
links that originally were spread sporadically over the footer are instead listed in a typical
mobile friendly vertical list above the columns (see Figure 8.11:C). The footer in mobile
portrait mode is very similar to the footer in tablet portrait mode, except for the columns
of text that are listed on top of each other instead of next to each other. This makes the
footer more adapted to the small amount of space. The footer in mobile portrait mode may
be seen in Figure 8.11:D.
Another difference between the prototype and the original site is the introduction of
click to call-links. This is added to the contact information in the footer and is another way
to further adapt the website to mobile devices. This means that when the link is clicked on
a device with built in phone, the native phone application will be opened up automatically.
Figure 8.11: The footer of the prototype on different screen sizes. A: tablet landscape mode,
B: desktop mode, C: tablet portrait mode, D: mobile portrait mode
70
Chapter 8. Prototype Developed to Exemplify the Theories
Figure 8.12: A: Footer of the original site, B: Footer in desktop mode.
8.2.1
Breakpoints Used in the Prototype
The four modes of the prototype, mobile portrait mode, tablet portrait mode, tablet landscape
mode and desktop mode has been decided based on the method for finding breakpoints in
Section 7.3.2, about letting the content decide the breakpoints.
The original design of Resumé was first restructured into the design for the mobile
portrait mode. This was created first since the mobile first technique was applied and mobile
portrait mode was the smallest mode to be supported. It is difficult to describe exactly why
the specific sizes has been chosen since the method is rather subjective, but the original
layout has been one important reason during the decisions. For example, the main column
in the news feed is originally 520 px wide and therefore the news column(s) in the prototype
are never wider than this. Devices that are too wide to properly display an 520 px wide
column, but still too narrow to properly display a second column floating side by side with
the main column are handled by making the margins around the page become bigger. The
specific breakpoints used in the prototype may be seen in Table 8.1.
Table 8.1: Breakpoints used in the prototype.
Size and other properties
<600 px
≥600 px and portrait, or alternatively
≥320 px and <600 px and landscape
Tablet landscape
≥600 px and landscape
Desktop
>1200 px
Mode
Mobile portrait
Tablet portrait
Chapter 9
Discussion
Some of the theories within this thesis are mainly theoretical. This is important to have
in mind, since all theories might not be applicable or suitable for all applications. It is
important to choose solutions deliberately to reach satisfaction. This thesis may serve as a
guideline when making these conscious decisions but the topic is too big to give any absolute
directions that holds for all cases.
The prototype is entirely built with the original site as a starting point since this was a
stated request. However, before any further implementations are made it would be preferable
to evaluate the original site and maybe also the prototype. The original site contains a lot
of widgets and sections with different content and a reimplementation would be an excellent
opportunity to evaluate (based on user testing and/or statistics) which widgets and sections
that are necessary and desirable to keep for the new site. Some widgets and/or sections
may need to be redesigned or could even be completely removed.
Another thing worth thinking about regarding the prototype is that Resumé only contains very few form elements. Except for buttons (or actually mainly links that are styled
as buttons) there are only three form elements on the start page. These are the search field,
and a form for subscribing to the newsletter. The form is located directly above the footer
and is constructed of one text field (an input element with type text) and one select element.
In the prototype the text field is replaced with an input element of type email. However,
even though the select element only contains two options this is not replaced with radio
buttons. This decision was made because the select element is far more adapted to mobile
devices than the radio button is. The radio button can be very difficult to style properly
for touch screens, while the select element opens up a native selector.
Bootstrap1 is a framework among many others that provide functionality to fast and easy
develop good looking web interfaces. One of the main purposes with this kind of framework
is that there is a predefined styling for all regular elements and components. This also
includes the possibility to make the website responsive automatically. However, during the
work with the prototype this framework was only used for creating the carousels that are
1 Bootstrap,
http://twitter.github.io/bootstrap/. Accessed 2013-07-18.
71
72
Chapter 9. Discussion
used for e.g. the blog section on smaller screens. This decision was made because it was
relevant for the study and the assignment to have absolute control over all media queries
and styling without the need to overwrite the predefined styling from the framework. This
was actually more difficult than expected and to use a framework similar to Bootstrap may
be a good solution for the future, although it may require more work. However, the lack
of experience from these kinds of frameworks makes it impossible to decide whether the
decision was good or not only based on the work with the prototype.
Chapter 10
Conclusions
The goal of the thesis was to investigate the theories behind mobile web development.
This has been accomplished based on an investigation of available literature as well as best
practices provided by acknowledged experts within the topic. The overall impression is that
there are a lot of things that may enhance the performance and the usability of a website,
even though not all of them are mobile web specific. In summary, one can say that the main
focus when designing for mobile web is to make interaction components big enough for
tapping with finger pads, to structure content and components to avoid horizontal scrolling
and to make the content accessible without hover states.
The result from the prototype shows that a responsive solution is suitable for the future
of Resumé. The user interface can be adapted to be user friendly on small screens with
touch functionality, but still maintaining the original look and feel for Resumé’s brand. The
accomplishment is an example of that the technology continues to evolve and that modern
devices can manage to handle more heavy content applications. This may be a hint that
responsive design may replace separate websites more and more in the future. But it is still
important to remember that there always will be situations when a separate mobile website
is preferable depending on the purpose of the application. For example, some applications
are simply intended to be used on mobile only and not desktop computers.
10.1
Limitations
Most of the limitations exist due to lack of time. Since the design and implementation of
the prototype was a minor part of the thesis this was restricted to only show the startpage.
This is however the tricky part and most of the other pages may be based on this. There
has also been no attempts to make the prototype browser compatible more than necessary.
This means that the prototype is optimized for Android (version 4.2.2), Iphone (version 5
with iOS 6) and Ipad2 (version 5.1.1), but not for e.g. Blackberry or Windows Phone at
all. Since the focus for the prototype has been interaction design the theories for how to
improve the backend has not been prioritized and therefore not implemented.
73
74
10.2
Chapter 10. Conclusions
Future Work
The area of mobile web development is evolving every day. Many of the theories in this
thesis are general enough to be applicable on different areas and will probably still be useful
in the future, but some of them may be outdated soon. This means that one has to keep on
digging within this topic continuously as it evolves. A specific area that needs more attention
is hardware compatibility. This is somewhat mentioned in this thesis but definitely not fully
covered.
Regarding the prototype the future work will be to implement the site with backend
connection and all sub pages. Preferably one should also follow the recommendations in
Section 9 about evaluating the original site. This work will of course also include browser
compatibility and backend optimization.
Chapter 11
Acknowledgements
Before ending the thesis there are some persons that deserve a special thanks. These persons
has given their support and contributed their time during the work with the thesis.
Kenneth Anderson, supervisor at The Mobile Life.
Per Kvarnbrink, supervisor at Umeå University.
Johanna Björnholm, Webmaster at Resumé.
Terry Potter, Digital Development Manager at Bonnier Business Press.
Tor Sterner and David Eriksson for proofreading.
I would also like to thank all the employees at The Mobile Life for sharing their office with
me during this time.
75
76
Chapter 11. Acknowledgements
References
[1] Meier, R.: Professional Android 4 Application Development. John Wiley & Sons, Inc.
(2012)
[2] Gardner, D.L., Grigsby, J.: Head First Mobile Web. O’Reilly Media, Inc. (2012)
[3] Wac, K., Ickin, S., Hong, J.H., Janowski, L., Fiedler, M., Dey, K.A.: Studying the
experience of mobile applications used in different contexts of daily life. Unknown
Journal (2011) 7–12
[4] : Use of computers and the internet by private persons (2013)
[5] http://www.thinkwithgoogle.com/mobileplanet/en-gb/ Accessed: 2013-04-18.
[6] och telestyrelsen, P.: Svensk telemarknad första halvåret 2012.
http://pts.se/sv/Dokument/Rapporter/Telefoni/2012/
Svensk-telemarknad-forsta-halvaret-2012---PTS-ER-2012/ (2012) Accessed:
2013-03-15.
[7] West, J., Mace, M.: Browsing as the killer app: Explaining the rapid success of
apple’s iphone. Telecommunications Policy 34 (2010) 270–286
[8] Nielsen, J.: Mobile content is twice as difficult.
http://www.nngroup.com/articles/mobile-content-is-twice-as-difficult/
(2011) Accessed: 2013-03-22.
[9] Kärkkäinen, L., Laarni, J.: Designing for small display screens. In: Proceedings of
the second Nordic conference on Human-computer interaction. NordiCHI ’02, New
York, NY, USA, ACM (2002) 227–230
[10] Block, R.: Steve jobs live from d 2007.
http://www.engadget.com/2007/05/30/steve-jobs-live-from-d-2007/ (2007)
Accessed: 2013-03-22.
[11] Ledbetter, R.: Mobile website design. http://www.chicowebmasters.com/
mobile-website-design-separate-mobile-sites-vs-responsive-design/ (2013)
Accessed: 2013-04-12.
[12] Stark, J.: Building iPhone Apps with HTML, CSS, and JavaScript: Making App
Store Apps Without Objective-C or Cocoa. 1 edn. O’Reilly Media, ink. (2010)
77
78
REFERENCES
[13] Kyrnin, J.: The three layers of web design.
http://webdesign.about.com/od/intermediatetutorials/a/aa010707.htm
Accessed: 2013-04-04.
[14] Lourdudoss, P.: Cross-platform development of smartphone applications using web
technologies and single codebase frameworks. Master’s thesis, Royal Institute of
Technology (2012)
[15] Marohnic, V.: Would push notifications for html5 apps kill native apps?
http://thenextweb.com/dd/2013/02/09/
would-push-notifications-for-html5-apps-kill-native-apps/ (2013)
Accessed: 2013-04-15.
[16] Apps vs. Open Web: The Battle of the Decade. (2011)
[17] Mudge, J.: Native app vs. mobile web app: A quick comparison.
http://sixrevisions.com/mobile/native-app-vs-mobile-web-app-comparison/
(2012) Accessed: 2013-03-06.
[18] Romy, B.: There is more than one way to build a mobile app.
http://infospace.ischool.syr.edu/2012/06/13/
theres-more-than-one-way-to-build-a-mobile-app/ (2012) Accessed:
2013-03-06.
[19] Kudryavtsev, I.: Website vs web application. the difference.
http://www.bitworks-software.com/blog/company/2011/01/
website-vs-web-application-the-difference/ (2011) Accessed: 2013-04-17.
[20] W3C. http://www.w3.org/TR/mwabp/#webapp-defined Accessed: 2013-04-19.
[21] Kadlec, T.: Implementing Responsive Design: Building Sites for an Anywhere,
Everywhere Web. New Riders (2013)
[22] Robbins, J.N.: Learning Web Design: A Beginenr’s Guide to HTML, CSS, JavaScript
and We Graphics. 4 edn. O’Reilly Media, Inc. (2012)
[23] Frain, B.: Responsive Web Design with HTML5 and CSS3. Packt Publishing (2012)
[24] Johansson, J.: A comparison of methods for building mobile-optimized websites.
http://sixrevisions.com/mobile/methods-mobile-websites/ (2013) Accessed:
2013-03-11.
[25] Lawson, B.: Why we should not make separate mobile websites.
http://mobile.smashingmagazine.com/2012/04/19/
why-we-shouldnt-make-separate-mobile-websites/ (2012) Accessed: 2013-03-11.
[26] Consulting, R.: Why is responsive web design important for your website.
http://www.ridivi.com/knowledge-base/
why-responsive-web-design-matters-for-your-website/ Accessed: 2013-03-11.
[27] Agarwal, A.: Responsive web design – a dummies guide.
http://www.labnol.org/internet/responsive-web-design-faq/21361/ (2012)
Accessed: 2013-03-11.
REFERENCES
79
[28] Randolph, B.: When responsive design is not an option: a checklist for optimizing
your mobile site. http://www.seomoz.org/blog/how-to-optimize-a-mobile-site
(2013) Accessed: 2013-03-11.
[29] Meunier, B.: When responsive web design is bad for seo. http:
//searchengineland.com/when-responsive-web-design-is-bad-for-seo-149109
(2013) Accessed: 2013-03-08.
[30] Laya, P.: Build it with the user in mind: How to design user flow.
http://conversionxl.com/how-to-design-user-flow/ (2012) Accessed:
2013-04-08.
[31] Ramsey, J.: Designing for flow.
http://alistapart.com/article/designingforflow (2007) Accessed: 2013-04-09.
[32] Brown, M.: Stop designing pages and start designing flows.
http://uxdesign.smashingmagazine.com/2012/01/04/
stop-designing-pages-start-designing-flows/ (2012) Accessed: 2013-04-09.
[33] Ryan: A shorthand for designing ui flows.
http://37signals.com/svn/posts/1926-a-shorthand-for-designing-ui-flows
(2009) Accessed: 2013-04-09.
[34] Webcredible: 7 usability guidelines for websites on mobile devices.
http://www.webcredible.co.uk/user-friendly-resources/web-usability/
mobile-guidelines.shtml (2012) Accessed: 2013-03-18.
[35] LaCount, R.: Gifs, jpgs and pngs, oh my!
http://www.portent.com/blog/design-dev/gifs-jpgs-and-pngs.htm (2012)
Accessed: 2013-03-18.
[36] Jalili, A.: 15 tips to speed up your website.
http://www.seomoz.org/blog/15-tips-to-speed-up-your-website (2012)
Accessed: 2013-03-18.
[37] Craig, N.: How to reduce web page download time in 4 (fairly) simple steps.
http://www.thedotproduct.org/2010/10/
how-to-reduce-web-page-download-time-in-4-simple-steps/ (2010) Accessed:
2013-03-18.
[38] W3schools: Css image sprites.
http://www.w3schools.com/css/css_image_sprites.asp Accessed: 2013-03-15.
[39] Lurie, I.: How we made portent.com really freaking fast. http://www.portent.com/
blog/design-dev/how-we-made-portent-com-really-freaking-fast.htm (2012)
Accessed: 2013-03-18.
[40] Raasch, J.: How to build a mobile website. http://mobile.smashingmagazine.com/
2010/11/03/how-to-build-a-mobile-website/#more-66989 (2010) Accessed:
2013-03-18.
[41] C, M.: Javascript to build mobile websites.
http://www.onbile.com/info/javascript-for-building-mobile-websites/
(2012) Accessed: 2013-03-18.
80
REFERENCES
[42] N, I.: How to make mobile website for blackberry.
http://www.onbile.com/info/how-to-make-mobile-website-for-blackberry/
(2012) Accessed: 2013-04-12.
[43] van der Zee, T.: Why css should be loaded before js.
http://www.themepartner.com/blog/24/why-css-should-be-loaded-before-js/
(2010) Accessed: 2013-03-18.
[44] Gentilcore, T.: Properly including stylesheets and scripts.
https://developers.google.com/speed/articles/include-scripts-properly
(2012) Accessed: 2013-03-18.
[45] Khaw, K., Higgins, E.: How gzip compression works.
https://developers.google.com/speed/articles/gzip (2012) Accessed:
2013-03-18.
[46] Wikipedia: Http persistent connection.
http://en.wikipedia.org/wiki/HTTP_persistent_connection Accessed:
2013-03-27.
[47] Agustina, F., Agushinta, R.D., Purnamasari, E., Wijayanti, H., Alqadri, Y.: User
interface design of mobile web application for job vacancies information: in
comparison with jobsdb mobile. International Journal of Computer Science and
Information Technology & Security 2(2) (2012)
[48] Ohtamaa, M.: Improving mobile site form usability with html5.
http://css.dzone.com/articles/improving-mobile-site-form (2012) Accessed:
2013-03-21.
[49] Tan, C.C.: Mobile form design strategies.
http://www.uxbooth.com/articles/mobile-form-design-strategies/ (2011)
Accessed: 2013-03-18.
[50] Wroblewski, L.: Forms on mobile devices: Modern solutions.
http://uxdesign.smashingmagazine.com/2010/03/11/
forms-on-mobile-devices-modern-solutions/#more-34361 (2010) Accessed:
2013-03-18.
[51] Richa: Improve form usability on mobile safari. http:
//blog.55minutes.com/2012/04/improve-form-usability-on-mobile-safari/
(2012) Accessed: 2013-03-21.
[52] Bustos, L.: 10 mobile web design best practices.
http://www.getelastic.com/10-mobile-web-design-best-practices/ (2012)
Accessed: 2013-03-18.
[53] Srinivasan, A.M., Dandekar, K., Raju, I.B.: 3-d finite-element models of human and
monkey fingertips to investigate the mechanics of tactile sense. Journal of
Biomechanical Engineering 125 (October 2003) 682–691
[54] Saffer, D.: Designing Gestural Interfaces. O’Reilly Media, Inc. (2009)
[55] Wroblewski, L.: Touch target sizes. http://www.lukew.com/ff/entry.asp?1085
(2010) Accessed: 2013-03-21.
REFERENCES
81
[56] Todish, T.R.: Not your parents mobile phone: Ux design guidelines for smartphones.
http://uxdesign.smashingmagazine.com/2011/10/06/
not-your-parents-mobile-phone-ux-design-guidelines-smartphones/ (2011)
Accessed: 2013-03-18.
[57] W3C: Mobile web best practices 1.0. http://www.w3.org/TR/mobile-bp/ (2008)
Accessed: 2013-03-18.
[58] Brauer, R.: Removing stumbling blocks in mobile forms.
http://uxdesign.smashingmagazine.com/2012/05/03/
removing-stumbling-blocks-in-mobile-forms/ (2012) Accessed: 2013-03-19.
[59] Kyrnin, J.: Does your website work on touch screen tablets?
http://webdesign.about.com/od/mobile/a/design-for-touch-screens.htm
Accessed: 2013-03-21.
[60] Clark, J.: Designing for touch.
http://www.netmagazine.com/features/designing-touch (2012) Accessed:
2013-03-21.
[61] Rogers, S.: Swipe This!: The Guide to Great Touchscreen Game Design. John Wiley
and Sons, Ltd. (2012)
[62] Koch, P.P.
http://www.quirksmode.org/blog/archives/2010/04/a_pixel_is_not.html
(2010) Accessed: 2013-07-11.
[63] Muller, S. http://www.stephanmuller.nl/ems-relative-media-queries/ (2012)
Accessed: 2013-07-11.
[64] Target Size Study for One-Handed Thumb Use on Small Touchscreen Devices. In:
MobileHCI06. (September 2006)
[65] W3schools: Html <input>type attribute.
http://www.w3schools.com/tags/att_input_type.asp Accessed: 2013-03-27.
[66] James, M.: Creating web apps - the camera api. http://www.i-programmer.info/
programming/htmlcss/4966-creating-web-apps-the-camera-api.html (2013)
Accessed: 2013-04-16.
[67] W3School. http://www.w3schools.com/html/html_links.asp Accessed:
2013-04-22.
[68] Frost, B.: Responsive navigation patterns.
http://bradfrostweb.com/blog/web/responsive-nav-patterns/ (2012) Accessed:
2013-04-08.
[69] Liew, K.: Responsive mobile navigation menu – methods and solutions.
http://www.queness.com/post/13093/
responsive-mobile-navigation-menumethods-and-solutions (2012) Accessed:
2013-04-08.
[70] Frost, B.: Complex navigation patterns for responsive design. http://bradfrostweb.
com/blog/web/complex-navigation-patterns-for-responsive-design/ (2012)
Accessed: 2013-04-08.
82
REFERENCES
[71] Statcounter. http://gs.statcounter.com/ Accessed: 2013-04-12.
[72] Street, K.: 10 tips for designing mobile websites. http://labs.thesedays.com/
blog/2010/07/16/10-tips-for-designing-mobile-websites/ (2010) Accessed:
2013-04-12.
[73] Rieger, B.: Effective design for multiple screen sizes. http:
//mobiforge.com/designing/story/effective-design-multiple-screen-sizes
(2009) Accessed: 2013-04-12.
[74] Johnson, J.: Responsive design: Why you are doing it wrong. http://designshack.
net/articles/css/responsive-design-why-youre-doing-it-wrong/ (2012)
Accessed: 2013-04-04.
[75] Wikipedia: Personal computer hardware.
http://en.wikipedia.org/wiki/Personal_computer_hardware Accessed:
2013-04-15.
[76] Wikipedia: Sensor. http://en.wikipedia.org/wiki/Sensor Accessed: 2013-04-15.
[77] W3C: Standards for web applications on mobile: current state and roadmap.
http://www.w3.org/2012/08/mobile-web-app-state/ (2012) Accessed:
2013-04-16.
[78] Pilgrim, M.: You are here (and so is everybody else).
http://diveintohtml5.info/geolocation.html Accessed: 2013-04-16.
[79] Wikipedia: Accelerometer. http://en.wikipedia.org/wiki/Accelerometer
Accessed: 2013-04-15.
[80] Wikipedia: Gyroscope. http://en.wikipedia.org/wiki/Gyroscope Accessed:
2013-04-15.
[81] Wikipedia: Compass. http://en.wikipedia.org/wiki/Compass Accessed:
2013-04-15.
[82] Wikipedia: Proximity sensor. https://en.wikipedia.org/wiki/Proximity_sensor
Accessed: 2013-04-16.
[83] Akemann, L.: What are push notifications (and how do i turn them on or off?) – plus
details on app discovery week. http://momswithapps.com/2011/04/11/
what-are-push-notifications-and-how-do-i-turn-them-on-or-off/ (2011)
Accessed: 2013-04-15.
[84] Builder, A.: Native apps vs web apps (1).
http://blog.apps-builder.com/native-apps-vs-webapps-1/ (2013) Accessed:
2013-04-15.
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Related manuals

Download PDF

advertising