Azure Monitor & Application Insight to monitor Infrastructure & Application
Getting Started: Designing HTML5 Web Apps
1. Getting Started with
Mobile Web Apps
Ray Matsil
www.infostretch.com | info@infostretch.com | +408.727.1100 | 2880 Lakeside Drive, Ste 200, Santa Clara, CA
2. InfoStretch is a leading provider of
mobile and enterprise QA services
and solutions. Our offerings range
from enterprise QA, mobile application
development, testing, and automation
to certification and sustenance.
www.infostretch.com | info@infostretch.com | +408.727.1100 | 2880 Lakeside Drive, Ste 200, Santa Clara, CA
7. “ By 2015, 60% of mobile
applications and 40% of consumer
applications will be web based
applications.
”
www.infostretch.com | info@infostretch.com | +408.727.1100 | 2880 Lakeside Drive, Ste 200, Santa Clara, CA
8. “ 60% of developers
worldwide will start using
HTML5 by end of 2012.
”
www.infostretch.com | info@infostretch.com | +408.727.1100 | 2880 Lakeside Drive, Ste 200, Santa Clara, CA
9. Form Factor
One of the biggest challenges is going to be the
hundreds/thousands of different device
sizes/resolutions
Droid X2 Droid Charge iPhone 4
10. The Android Developer Guide is a great place to start
Android Normal Android Large iOS Retina
13. Browser Compatibility
Not every browser is going to support every
feature
HTML5Test.com
mobilehtml5.org
www.infostretch.com | info@infostretch.com | +408.727.1100 | 2880 Lakeside Drive, Ste 200, Santa Clara, CA
14. Frameworks
Figure out what you want to achieve, then decide if you
can do so with a framework
(Not actually a
framework)
www.infostretch.com | info@infostretch.com | +408.727.1100 | 2880 Lakeside Drive, Ste 200, Santa Clara, CA
15. • Quick to get started
• Nice feature set
• Takes a little longer to learn
• Robust Feature set
• Not Really a Framework
• Template
• Modify it to fit your own needs
16. • Some transition animations don’t work on certain
browsers
• Use fallback transitions
• Transitions can also look choppy on partially
supported browsers (Android and Windows
phone)
• Show Demos on iPhone
• Gives you the flexibility to really give your web
based apps a native feel
• Some nice plug ins available
• Such as datepickers and other controls
• Quick to learn if you are familiar with JQuery
www.infostretch.com | info@infostretch.com | +408.727.1100 | 2880 Lakeside Drive, Ste 200, Santa Clara, CA
17. Touch Events
Considerations
• Platform
• Some touch events which work on iOS and
Android won’t work on Windows Phone
• Frameworks
• Different frameworks capture different touch
events
www.infostretch.com | info@infostretch.com | +408.727.1100 | 2880 Lakeside Drive, Ste 200, Santa Clara, CA
18. What to watch out for after you start designing
Design with Caution
23. Screen Real Estate
Considerations
• Size of on-screen elements
• Font Size
• Graphical assets
• Interactive elements (input
fields, buttons, etc)
24. Font size should generally be set
to “medium”
• A good way to maximize your
real estate is to get creative
25. When sizing interactive elements you should
consider touch target size
Different platforms recommend different sizes:
• 44 x 44
• 34 x 34
• 7-10 mm
• (26-37px)
26. HTML5 Forms
New form input types
Color
Date
Email
Month
Tel
Time
URL
Think beyond enhanced validation
www.infostretch.com | info@infostretch.com | +408.727.1100 | 2880 Lakeside Drive, Ste 200, Santa Clara, CA
27. Enhancing the UX for a form goes beyond popping
up the right keyboard
Mobile.delta.com
28. HTML5 validation will not look the same
across all browsers
Depending on your target you will likely need to use a framework to
help validate
h5validate
www.infostretch.com | info@infostretch.com | +408.727.1100 | 2880 Lakeside Drive, Ste 200, Santa Clara, CA
33. • Try to only ask for a user’s location once
• If a user receives multiple notifications it can become
irritating and they may decide to deny access
• Ask in context
• Only ask if you are going to enhance the user’s experience
• Make sure you are clear about who is
asking
34. Compatibility with older devices
Considerations:
• What are you allowing the user to do?
• Does it make sense to allow users with less advanced
devices to access the same content?
• How important is the task?
www.infostretch.com | info@infostretch.com | +408.727.1100 | 2880 Lakeside Drive, Ste 200, Santa Clara, CA
35. • If you want to support older devices you will have to
detect what device the user is viewing from
• You will probably need to have a separate style
sheet for less advanced devices
• Design for the least advanced device
• Users who are on less advanced devices may not be
as open to performing that task on a mobile device
36. Useful Links
• HTML5test.com
• http://ericleads.com/h5validate/
• iOS Developer Library
• Android Design Patterns
• Android Developer Guide
• www.Phonegap.com
• jQuerymobile.com
• http://www.sencha.com/products/touch/
• Touch Target Size Calculator
• Mozilla Blog
• W3schools
• Does your webpage need to look the same in every
browser
• http://www.adobe.com/devnet/devices/articles/design_tips_mobile_ri
a.html
• http://www.mobilehtml5.org
www.infostretch.com | info@infostretch.com | +408.727.1100 | 2880 Lakeside Drive, Ste 200, Santa Clara, CA
38. If you have any questions or
would like more information on
services, contact us.
www.infostretch.com
info@infostretch.com
+408.727.1100
Editor's Notes
Here’s a little bit about the company that has made this session possible.
A little about me:I’m the User Interface Designer at InfoStretch CorporationI have over 4 years of experience in the UX fieldI’m a UX professional so many of the topics I will cover will be from that point of view. While I do have some technical knowledge of HTML5, we will not really be getting into the technical side today.
HTML5 allows you to design your application one timeLowers time to production Lowers cost for productionWorks across multiple platformsThere are frameworks such as phonegapwhich make it very easy to port HTML5 apps to native device codeiOS, Android, Blackberry, and Windows Phone supported
A few of the companies currently using HTML5 are:
Industry predictions:Gartner predicts that by the year 2015 60% of mobile applications and 40% of consumer applications will be web based application
Industry predictions:Forrester predicts 60% of developers worldwide will start using HTML5 by end 2012So as you can see HTML5 is picking up steam and will be used more and more as the year progresses
One of the biggest challenges is going to be the hundreds/thousands of different device sizes/resolutions currently available in the market. Some of the main considerations when designing for this are:Screen SizeResolutionScreen Real EstateAspect RatioWe have been working on a mobile web app internally which I will share with you today. Here I am showing 2 Androids and an iPhone side by side, the screen sizes and pixels per inch ratios are different, and as you can see this affects what is displayed as well as where it is displayed.
The Android Developer guide is a great place to start, especially since they have the most variance in their device sizes and resolutions. On the Android Developer guide you can find guidelines which group screen types by pixel density and screen size. To support all these different devices sizes and resolutions you will likely have to generate multiple sets of assets (again depending on what you are trying to do). For the iAir project we generated 3 sets of assets: 1 “Normal” size Android resolution, as well as a set for Android “Large”. We also generated an iOSretna version. You may also need to generate a tablet set of assets if you are targeting those devices.
One important consideration to keep in mind when developing for mobile is that you should really be validating your designs on the actual target devices.Emulators or viewing in a desktop browser often gives you results which are not a true representation of what you are actually going to getI have a few more examples to show you, here you can see a screenshot of an early version of the iAir app from a desktop browser. As you can see it doesn’t look very good. But when we look at the same URL from a Droid Charge you can see it appears as designed.These screenshots were taken from the same URL, and yet, as you can see the desktop browser gives me an incorrect representation of what the page will look like on a mobile device browser.
Another problem with testing on your desktop browser is that you can’t properly test touch gestures. Here is a prototype I defined early on in the development cycle to convey what it was I wanted the functionality to be for our home screen. I’m going to go ahead and run it, and as you can see the user can swipe left or right to navigate this menu. This feature can’t be tested in a desktop browser and for that matter touch gestures in general can’t be tested in a desktop browser.
Another consideration before you start designing is Browser Compatibility. As I’m sure most of you know not every browser is going to correctly render your HTML5. I have run into issues with Animations and Form Validation. CSS3 3D transform animations are not supported across all browsers, and this is something you must be aware of. You can actually perform device compatibility tests by navigating this website on the target device. AS you can see this website detects the browser you are using and runs compatibility checks on a lot of the new HTML5 elements, and tells you whether they are supported or not.Another good site to see a more generalized list of what is supported is mobilehtml5.orgAll of the links mentioned in this presentation are at the end for reference purposes.
Before you jump into developing an entire app from scratch, first define what it is you are trying to achieve, and see if any of it is possible with some of the available HTML5 mobile development frameworks. Some of the major frameworks I will touch on today are:JQuery MobileSencha TouchHTML5 Boilerplate, which is actually not a framework, I’ll get into that in more detail on the next slide.
Here is a brief overview of some of the available frameworks:JQuery MobileQuick to get started—especially if you already have Jquery experience Nice feature setSencha TouchTakes a little longer to learn, but also has the most robust feature set of all the current frameworksHTML5 BoilerplateNot Really a FrameworkTemplateModify it to fit your own needsThe idea is that it will provide you with a starting point, so you aren’t forced to start from scratch
The framework I have the most experience with is JQuery mobile. Here are some tips I have picked up while working with it:Some transition animations don’t work on certain browsersYou can define “fallback transitions” which will automatically use a compatible transition if the detected browser doesn’t support the originally defined transitionTransitions can also look choppy on partially supported browsers (Android and Windows phone)Due to this I recommend showing JQM demos on iPhone which supports the majority of the transition animations.JQM Gives you the flexibility to really give your web based apps a native feel by utilizing docked controls and toolbars.Some nice plug ins available(such as datepickers and other input controls)Quick to learn if you are familiar with JQuery
Touch events are also something which need to be mapped out before you start designing Considerations are:PlatformSome touch events which work on iOS and Android won’t work on Windows PhoneFrameworksDifferent frameworks capture different touch eventsYou can navigate to the respective framework websites and check out what events are supported.JQM has a nice list of events which are supportedSencha has a cool interactive page which you can play around with and see what events are supported
Now that we’ve covered what to do before you get started, lets talk about what to watch out for after you get started designing.
Screen orientation is a huge consideration when you are designing a mobile web app.You must consider both portrait and landscape mode. Part of the reason for this is that there is not really an easy way to lock the screen orientation. You will also realize that elements that look good in portrait may not necessarily look good in landscape so make sure you test both!
Here is an example from an early version of the iAir app. Here I have a screenshot of portriat mode, and you can see here that the background image looks fine in portrait mode, But once I show landscape it appears stretched and doesn’t look good.
What you will probably need to do to support both orientations is detect device orientation and use a different style sheet for portrait and landscape mode. You will likely have to create a second set of landscape specific assets, depending on what content you have. A recommendation I have is use assets which can be generated by code as much as possible, which should help limit the amount of assets you have to produce. Here I am showing the same app, but an updated version.Again, here is the portrait view, but when we look at the landscape view you can see that the background image does not appear stretched and the orientation of the UI elements has changed to a more landscape friendly orientation. What we have done here is detect device orientation and utilize the appropriate style sheet to render the correct view. We are generating a lot of the elements shown here from html, including the header, and subheader, as well as the footer
Another good example of code-generated UI elements is using a webkit gradient. Here I am showing the flight search screen from the iAir app. Take note of the nice blue to light blue gradient in the background.As you can see here the gradient looks good in both portrait and landscape mode, and we only had to define it one time, without the need for me to even create any graphical assets.
Screen real estate is also something you will have to think about during the design processConsiderationsSize of on-screen elementsFont SizeGraphical assetsInteractive elements (input fields, buttons, etc)On a mobile device you won’t have quite this much space
A good benchmark to start out with for text size is “medium”, this will render as readable on the majority of current devices. A nice way to maximize your screen real estate is to get creative. I am going to show a video here which illustrates a feature of our iAir app. We are starting from the flight search screen which I have pre-populated and once we get the flight results we can see that the overlay explains that we can drag the logo to refresh search results.This is a nice way to allow users to make sure they are viewing the most up to date prices without taking up too much screen real estate
When determining the size for interactive elements you need to consider touch target size recommendations. The different operating systems naturally recommend different touch target sizes, which you can find in their respective developer guides. Here I am showing a screen shot of a mobile site that shall remain nameless but you can clearly see that the touch targets are too small for the average person’s finger.
When designing a highly interactive app you will inevitably run into the need for forms. HTML5 offers better support for forms and validation, but just adding instant validation to your forms will only enhance the experience so much, you need to think beyond just the “smart validation” and think about actually inputting data into the form on the target device. HTML5 offers a variety of new form attributes as I’m sure you’ve heard, some of these include color, date, email, month, tel, time and url. These attributes allow you to better control what input method the end user sees when a field has been given focus.
That being said, enhancing the UX goes beyond popping up the right keyboard, depending on what the user is doing you may want to utilize an input control.Here I have a screenshot from mobile.delta.com, let’s focus on the date of birth input fields. In this case delta has utilized drop down fields for month and day, and then a free text input for year. This is a nice start and does limit the amount of typing a user has to do, but lets take a look at the iAir app. Here you can see that we have one input field for date of birth. The user clicks one time, then a more android-native style pop up opens which is optimized for touch screen input (this is a custom plugin for JQM). Some of you might be thinking that this control may amount in more clicks since the year could require many taps to get to the desired year but the inputs here are easy, the touch target is not moving, which allows users a low stress way to input this data, AND they can also tap on the fields in the middle to pop up their numeric keyboard.
As I mentioned earlier HTML5 offers new validation methods, here are a few tips about using them:HTML5 validation will not look the same across all browsersHere is an example from the mozilla blog illustrating how the same “required” attribute will produce 3 different styles of error validation across 3 different browsersDepending on your target device you may need to use a validation framework.This is an example of h5validate, which will allow you to normalize your validation across different browsers
While notifications are not specific to HTML5 you will need to deal with themScreen size and real estate as well as the importance of the task the user is currently performing are what you are going to want to watch out for
When creating notifications the importance of the notification should dictate how you notify usersWhen trying to decide how/when to notify make sure you mind what the user is doing, if its something important make sure the alert is front and center like the picture I’m showing here, this seems to be a very in your face notification (albeit not a very important one)If the task is less important make the alert more subtleE.g. inline messages
What I’ve found ***(ONLY CLICK ONE TIME BOTH SCREENSHOTS WILL OPEN)***Frameworks can offer a way to stylize pop up notification windowsThat being said, most devices (if not all) will recognize native pop upsThis is what I would consider best practice because it works across the majority of device browsersAs you can see the native pop up is asking for a user’s location, which is coincidental because the next slide is about geo-location
Considerations: When should you ask?How can you avoid alienating users
Try to only ask for a user’s location onceIf a user receives multiple notifications it can become irritating and they may decide to deny accessAsk in context, don’t just ask when your users come to the site, ask them for their location when they come to the part of your site which actually will be using the locationOnly ask if you are going to enhance the user’s experienceDon’t ask because it is good for your analyticsMake sure you are clear about who is askingHere I am showing a screenshot from a version of our app rendered for iOS in phonegap
And finally the last major consideration when designing an html5 mobile web app is compatibility with older devicesWhat are you allowing the user to do?Does it make sense to allow users with less advanced devices to access the same content?How important is the task?Ok you probably won’t support devices this old…
What I’ve found is that:If you want to support older devices you will have to detect what device the user is viewing fromYou will probably need to have a separate style sheet for less advanced devicesDesign for the least advanced deviceUsers who are on less advanced devices may not be as open to performing that task on a mobile deviceThis is a screenshot from southwest airlines mobile site, as you can see it is very simple and is likely supported on a large percentage of mobile phones.
