Developing for Mobile

A discussion on how to not exclude customers

Created by Brian Duffey

Who am I?

Brian Duffey
4 years consultant at michaels, ross, and cole
4+ years web application developer
3 years on mobile application solutions

Roadmap

Introduction
Traditional vs. Mobile

Differences
Concerns

What can you do?

Native
Web App
Hybrid

Conclusion

What will you do?

Ultimately, I'd like this to be more of a discussion than a lecture, so please feel free to ask questions as they arise, as well as to share your own personal experiences
You won't necessarily come away from this today with all of the answers, however I can guarantee you will be able to at least ask the right questions in order to determine the best approach for yourself and/or your company
This also won't be as technical of a presentation as I normally give, in order to highlight what the possible answers are instead of how to actually implement them
With that in mind, here is a loose outline of what I hope to cover today, starting with why we are here, talking about the different approaches available to you, and finishing up with a wrap-up of what we talked about and steps you may consider taking next

Roadmap

Introduction
Traditional vs. Mobile

Differences
Concerns

What can you do?

Native
Web App
Hybrid

Conclusion

What will you do?

Has anyone done any mobile work?

Good Mobile Sites

Abercrombie & Fitch: |
- Simplified interface sized for the device you are using
Caribou Coffee: |
- Brand awareness through colors
Mountain Dew: |
- Busy, interactive view that avoids feeling cluttered

Abercrombie & Fitch, in case you are unfamiliar, is a clothing store.
Like their style or not, their mobile site is one of the best around as it is sized directly for the device your on, and gives you easy access to buying their clothing using an interface many people are familiar with (similar to a native app)
Caribou Coffee also sizes the view very well for the device you are on, however they also effectively using coloring in order to better brand their pages. They also use the menu approach effectively
Finally, Mountain Dew takes a slightly different approach. While the viewport is still sized well, their site is much busier with content that users can click on to view further details, all without leaving the page. Additionally, the content can be customized by selecting/deselecting categories in the top right of the screen
While these three sites have a few things in common, they each do their own thing uniquely while still providing site visitors with the best experience possible, regardless of the device used.
Now let's switch gears and take a look at some sites they do not provide as good of an experience over mobile

Not So Good Mobile Sites

Alabama Legislature: |
- Overlapping, hard to read text
Judiciary Committee: |
- No mobile version, slow-loading content
Velokraft: |
- Little content that is not sized for small devices

While most business now are realizing the benefit to developing for mobile, smaller businesses as well as government shops can be painfully behind
The Alabama Legislature website is one example of this, with essentially the same site as the PC version, shrunken down and nearly unusable.
Another government site is the House of Representatives Judiciary Committee, which not only has content that is too wide to fit on a mobile screen, but also has some sites with large/slow content, such as this GIF page, causing issues when trying to load it on a mobile device
Velokraft is apparently a European manufacturer of bicycles, however you'd never know it from their website. There are no links, no content, and nothing else to speak of. Unfortunately, this is the same for the PC version, meaning not only did they not design for mobile, they hardly designed for the web in general
Clearly, there are some common factors in what to do vs. what not to do, including sizing the page appropriately for each device, giving users easy to find, useful information that isn't cluttered, and providing an easy to use design/interface
However, many of these factors are not common to mobile development, but rather development in general.
So, let's look next at the specifics of mobile development and how it differs from developing more traditionally

Traditional vs. Mobile

Taken from http://unit1project.web.unc.edu

Traditional vs. Mobile

Traditional	vs.	Mobile
Layout Design Interactivity	vs.	Touch Speed Agility Connectivity Input

Before we look at the specific differences between these two, let's define what we're talking about
Traditional development, in this instance, is referring to the development of web pages as it was since the HTML spec first came about
In this sense, device size was never a major consideration as phones were not smart and tablets were not yet a mainstream device
Instead, developers focused on things like layout, design, and interactivity with the site's users
However, as we'll see in a bit, if this is how you are still developing, you are missing out not just on a portion of your customers, but potentially the majority
Even if we lump all phones into one category, all tablets into another, and finally all PCs in the last, that is still three very different groups of users that need to be accounted for
When you also begin to consider the different sizes of screen just amongst phones, such as the iPhone 6 vs. the 5, you can see how this becomes a larger issue about how you can realistically create and maintain your site for every user, regardless of the device they use to view it
The five primary differences between traditional and mobile development come down to touch, speed, agility, connectivity and input
Let's look at what each of these are and what they mean to you as a developer

Traditional vs. Mobile

Touch

Mouse and cursor vs. Finger

Pressable areas should be 45-72 pixels wide

Taken from http://www.smashingmagazine.com

The reach zone:

Taken from http://www.lukew.com
Destructive buttons require more space

A big difference between PC websites and mobile ones is how users interact with it
On the PC, you have a mouse and a cursor, which allows for things like clicking, hovering, highlighting, etc.
On mobile devices, your finger is both the mouse and the cursor, so sites need to adapt to this
For instance, a mouse is very precise, and most people can click within a couple pixels without too much issue
A finger is not as precise and users need a much larger area to work with
An MIT Touch Lab study says that based upon the average size of a human finger, any clickable area needs to be at least 45 - 57 pixels wide on mobile, compounding the issue of less screen real estate with larger buttons. Additionally, a thumb is bigger, 72 pixels on average so if you want to support one handed use, your buttons have to be much larger on mobile than on PC
Speaking of one handed use, you also have even less screen real estate when considering this, as you should keep any clickable elements in the reach zone, highlighted by this image
Additionally, highlighting is not as easy to accomplish and currently there is no touch "hover"
Finally, since touchscreens are much less accurate than PCs, you will also need to allot extra space, as well as potentially confirmations or other protections, on "destructive buttons". Destructive buttons are any buttons that have consequences to the user, such as delete.

Traditional vs. Mobile

Speed

Average attention span is ~8 seconds
.5 second delay = 20% drop in traffic
50% will abandon if not loaded in 3 seconds
79% will refuse to return to a site
44% will tell friends/family to avoid
Take advantage of perceived speed

In modern, fast-paced times, where all information is at the our fingertips, users have less patience than ever
In fact, according to the National Center for Biotechnology Information, in 2013 humans average attention span dropped to only 8 seconds. For the record, this is 1 second less than a goldfish
If that image made you start thinking about how crowded the pool is right now, then hopefully you can see the issue
Almost a decade ago, Google found that a half-second delay in load time resulted in a 20% drop in traffic, so you can imagine how bad that would be now
Other studies have found similar results, with one saying half of web users will abandon a site if it isn't loaded in three seconds, and 79% of web shoppers will refuse to return to a poorly performing site and 44% would go so far as to tell friends and family to avoid the site in the future
For internal pages, this could be as simple as employees not fully utilizing data or resources
Externally, however, you are not only potentially losing customers, but as much as friends and family of the people visiting your site
Outside of the actual speed of loading, is something called perceived performance. This is a simple term to describe what users think of the performance of the site
This can actually be more important, as evidenced by the mobile app, Polar, a polling application. Basically, the developers behind this app worked very hard to improve performance and were successfully able to decrease the loading time by a significant amount. However, at the same time, they added in an animated spinner to visually show the decreased loading time. This had the opposite effect, as surveys taken after this update showed users felt the site took much longer to load, solely because their attention was drawn to exactly how long it took to load. They immediately removed the spinner and surveys then indicated how much quicker it felt, despite to taking the same amount of time to load as before
On the other hand, some animations and transitions can actually make your site felt snappier by making events more immediate. One example of this is adding touch states to buttons to indicate hold and release. With this, feedback is immediate, without it, users have to wait before they see the result of their tap
Ultimately, both actual and perceived performance is important, so you should focus on both, however actual performance can only be increased to a point, where perceived performance is almost limitless in how you apply it

Traditional vs. Mobile

Agility

Waterfall or linear approach is more traditional
Agile approach might be quicker
Comparison:

Taken from http://www.agilenutshell.com

Very simply, agility refers to the development cycle, in terms of how quickly can you develop, test, release, maintain, etc.
Traditionally, changes could take weeks or even months using a waterfall, or linear approach. Using this approach, every stage would need to be fully completed before moving to the next. For instance, all models and wireframes would need to be done before the coding could begin
However, since mobile app development is constantly evolving and changing in response to the device and browser landscape, mobile apps must be created and altered quickly to avoid becoming one of the bad site examples
Consider using an Agile approach, which is iterative in nature, and will you to build and obtain feedback without getting locked into a specific look, feel, or set of features that may end up not working well for your particular application

Traditional vs. Mobile

Connectivity

Everyone has experienced the dreaded "no signal"
Build in offline modes?
Turn off app when no connection?
Turn off some parts of the app?

Connectivity is a rather new issue, as previously, you either had internet or you didn't, as your connection device (a computer) was not portable
However, now connectivity is a much bigger issue as many devices are small enough to fit in people's pockets and can go through periods of connectivity interspersed with periods without
This issue therefore becomes more of how do you want to handle this? Do you build in offline modes to your applications? Do you not allow the application to be used when no internet is available? Do you do some combo of these? Unfortunately, there is no one right answer, only the right answer for you, as each has their own set of pros and cons that will need to be weighed in order to figure out what your end users can live with
Certainly the easiest approach is to simply not allow the application to be used when no internet is available, however this is also the riskiest approach as you could alienate potential customers if they are unable to use your site in areas of low service

Traditional vs. Mobile

Input

Virtual keyboards are 2.72 times slower
Make input as easy as possible for users
Kayak uses GPS and calendar
Dribble demo by Murat Mutlu uses camera for input
Kickstarter checks for typos

Typing on a physical keyboard is much easier than trying to do so on a virtual one. In an ideal world, mobile apps would not require input from the user so as to avoid having them type out information
One study found that users are on average 2.72 times slower in words typed per minute on a mobile device than a computer keyboard
Instead, you can limit the inputs as much as possible, however there is no current way to completely get rid of them
When needed, make some things easier for your users, such as automatically switching to the number keypad when requiring numeric information like a phone number. In addition, auto format the input where possible, such as automatically inserting parentheses and dashes in our phone number example
Similar to our discussion of buttons and other touchable elements, inputs should be designed for fingers on mobile apps
This might mean making them span the entire screen, or at least the 72 pixels we talked about earlier, as well as making the height larger enough to register a tap
Everyone has seen poor mobile forms, from tiny inputs to little search helpers
However, here are a couple ones that stand out for their great mobile designed in collecting information from users
Kayak, a travel website, can use the device's built-in GPS to fill in the location field, and also uses a giant calendar to collect date information
Not an actual website, but this demo site on Dribble shows how the device's camera can be used to fill out credit card information, while the progress icons across the top show exactly where the user is in the process at all times
Kickstarter, an independent funding website, looks at inputs such as email and offers corrections for common mistakes such as email address, making input much easier for users in the case of typos
There are many other such examples on mobile apps, however you can get the idea that you should require actual typing input from your users as little as you can to make their visit enjoyable

Traditional vs. Mobile

April 21st, 2015
SEO - Search Engine Optimization
Tool to check what Google sees https://www.google.com/webmasters/tools/mobile-friendly/

One very recent development, is that Google began processing SEO differently last week on April 21st, 2015
SEO stands for search engine optimization, and is most basically a ranking of websites for how they show up in search results
There are many factors that go into this, as well as many tools for helping you improve your site's rank, however for the purposes of this presentation, the reason I bring it up is since last Tuesday, Google now considers how well your site plays on mobile
Ultimately, this a complex topic for us to talk about, however as a part of site indexing and SEO rank, Google will now analyze sites and ding them hard if they do not play well on mobile
This may not be something you care about, however for those that do care about SEO rankings, going mobile may not be a choice any longer

Traditional vs. Mobile

Why is this a concern?

Why change if we'll soon be on to other devices?
As of January 2014, mobile device traffic overtook PC
Basic websites are not built for mobile

So, why is all of this a concern? Won't holograms soon take over and render all of this pointless?
Maybe, I cannot see the future, however why you might care about this is that mobile internet usage overtook PC usage for the first time in history back in January 2014
As mobile is continuing to trend upward, businesses can no longer afford to ignore their site's mobile visitors
As many businesses are beginning to realize, its no longer a question of should we develop for mobile, but rather how can we best take advantage of our mobile traffic?
Finally, with regards to website design, most companies have a website in place, so why can't your site visitors just view that from their smartphone?
As we saw earlier, traditional PC websites are not sized or designed for mobile devices, meaning at best 90% of your content is off screen and at worst the site is too tiny for anyone to use it without vigorously zooming in

Roadmap

Introduction
Traditional vs. Mobile

Differences
Concerns

What can you do?

Native
Web App
Hybrid

Conclusion

What will you do?

What can you do?

What can you do?

Native

Def.: written in language of device and installed locally

Pros	Con
Best performance Least connectivity issues High visibility in app store Transactions handled by app store	Most expensive in terms of money and time Little reusability across devices App store requires approval App store takes cut from revenue

A native application is most commonly what people think of when they hear mobile application or the phrase "There's an app for that!"
This type of application is written in the language of the device (Objective-C, Java, etc.) and is downloaded and installed onto the mobile device, most commonly through some central repository like an App Store
They then live on the device and can be accessed by tapping on their icon through the application listing of the device
So, why would one choose a native app?
For starters, they offer the best performance of all choices, as they live directly on the device and can operate as fast as the device will run them
Additionally, they are stored on the device, not online, so they will generally offer the best usage in areas of poor to no internet connectivity
For potential customers, they might offer more visibility in the central app store vs. word of mouth or advertising
Its much easier to buy a native app vs buying access to a web app since the app store handles all transactions, albeit for a slice of the pie
Why might you not want to choose a native app?
They are generally the most expensive and time consuming approach, as you must write the app for the native language of the device you want to support. Even choosing a single platform can be expensive and time consuming since it all must be custom coded in potentially complicated languages
There is often little reusability across more than one device, meaning creation and maintainability both will need to be heavily weighed as a single change will need to be made to each device's code base
The same app store that could be a positive in terms of visibility and transactions can also be a pain, as you have to jump through hoops initially to get your app in the store through the store's approval process
Some app updates also require the same approval process each time, making each update a pain
Though not a common occurrence, I have also heard of apps being pulled from the app store without warning or reason as they essentially decide whether your app is suitable or not
Additionally, if you are selling your app or generating any other revenue, you must give the app store a percentage of your revenue. This can be as high as 30% for Apple's app store

What can you do?

Native - OS

iOS	Android	Windows Mobile

Speaking of Apple, in terms of the different platforms I mentioned, the most commonly known ones are iOS with the iPhone and iPad, as well as Android with the plethora of devices by companies such as Samsung, LG, and Sony. There is also Symbian and Windows Mobile, that take up some market share.
In terms of which OSes you might focus on, Android and iOS were the most common so you would hit the majority of the market with those two, however that is still quite a bit of money and time as the two are very different platforms to develop for
Additionally, as this chart from the Mac Observer illustrates, Android has continued to dominate the market share, however Windows Mobile now looks like it will overtake iOS for the second place spot this year, after it partnered up with Nokia
So, if you were looking at developing for mobile in 2011, you might have targeted different devices than you would today
Regardless of the specific platforms you would pick, its pretty easy to see how you could sink a ton of time and money into native apps
Let's turn our attention now to a strategy that works across all devices after one build

What can you do?

Web Apps

Def.: software that runs in browser, uses HTML, CSS, JavaScript

Pros	Con
Most universal approach Written in simpler languages Performance is increasing No app store or installation Updates can be pushed out quickly	Runs on interpreted code Not able to access all hardware features All advertising and marketing must be done by you Browsers still do not all agree

A web application is any piece of software that runs in a web browser. Most commonly written with HTML, CSS, and/or JavaScript, it does not require any specific software to be installed locally, as the browser loads and renders everything the user needs to see.
In the past, web apps were seen as inferior solutions for a wide variety of reasons, however that is not necessarily the case any more, as we'll talk about
First, let's talk about some of the reasons why you might choose a web app
As I hinted at a moment ago, web apps are much more universal than native apps as HTML is a standard every browser understands. While there are browser differences, the web app will still load on any platform as long as there is some browser installed
This saving of time and money is increased when you consider the relative complexities of learning native languages like Java or Objective-C vs. the relative simplicity of HTML and CSS
Web apps are constantly increasing their performance, thanks to updated language specifications and browser updates, making the performance difference between native and web apps closer as time goes on
There is also no app store, so you bypass both the approval process as well as any revenue sharing
Additionally, updates can go out much quicker as you simply update the files and then they are accessible
Finally, the app is easier to access as a simple link is all that is needed and nothing is needed to install or prepare ahead of time
On the flip side of the coin, web apps are displayed using interpreted code, so the performance differences between native, which use compiled code, and web apps will never completely disappear.
While more and more features are made accessible to the browser and therefore web apps, as of right now there are still hardware features that web apps cannot access such as push notifications
As mentioned, there is no app store, so you have to handle advertising and any revenue models needed for your application
Finally, while there is an actual standard for HTML and other web technologies, browsers still differ in how they render pages so without careful design and testing, a user you have on Internet Explorer 8 could have a different experience than a user on the latest Chrome
Speaking of rendering web apps, recently the spec for HTML5 was published, which is great news for web apps as it makes development a lot better, however there are a lot of myths and half-truths surrounding HTML5, so let's take a brief look at what it is and what it means for developers

What can you do?

Web Apps - HTML5

What it is		What it is not
Added semantic elements to make code easier to read Added input elements such as date and time Added new features like web workers and offline app support		Not a type of app Not something different than HTML No conversion process Not responsible for appearance

HTML is the language of the browsers. While there are many technologies potentially involved in any given website, HTML is generally served up to the browser and then rendered in order to display content to the end user
HTML4 used to be the standard prior to 2014, however it was no longer adequate to handle the growing web needs
The HTML5 spec was therefore released last year to handle these additional needs and make the web more powerful
While it has many features and updates that make it very useful and powerful for web developers, you might want to think of it as more of an update to HTML4 than anything different
Some things were added, some were updated, some were deprecated, however web sites continue to operate the same way in the world of HTML5 that they did previously in HTML4
Some of the added features include more semantic elements like header, footer, and article. There are some new form elements that previously required addons now built into HTML such as date and time inputs, required fields, and autofocus. Finally, there are some other features that make web apps more attractive in HTML5 such as better video and audio handling, offline app support, and web workers which can offload the heavy processing of a web page behind the scenes so the user is uninterrupted in their access to the web app
With all that being said, there is no real HTML5 web app or any sort of HTML5 compatibility test as HTML is still HTML
Instead, think of HTML as the language and HTML5 as features you can choose to utilize in that language
Additionally, some people seem to think their web apps need to be converted to HTML5, which as mentioned, is simply not the case
I also mentioned how HTML5 supports offline apps, however this does not mean that every app automatically works offline. Much like the other HTML5 features we discussed, HTML5 allows you to make your app work offline, however it is something you have to implement, not something built-in
Finally, a large misconception is that HTML5 makes all web apps look just like native apps. While some of the features, like access to hardware on the device such as GPS and camera, make the app appear more integrated with the device OS, the appearance of web apps is actually controlled through the CSS. CSS also recently had its spec updated to CSS3, so even things like manipulating images and rotating elements is possible through this, which also makes web apps looks more native based
CSS primarily accomplishes this through one of two techniques

What can you do?

Web Apps - Techniques

Adaptive	Responsive
Identifies user's device and serves up a prepared layer for them	Uses a fluid structure to display one layer in different ways
Taken from http://www.nitinh.com	Taken from http://stild.com

These two techniques mentioned are called adaptive and responsive
Adaptive web design involves targeting specific screen sizes for your content. This might be done on the server before the page is rendered by detecting the device and then showing them the HTML layer for that particular device, or after the page is rendered, using client-side JavaScript to detect the device and then change the HTML structure to fit that device
Responsive web design uses some strategies called media queries and fluid grids to always show the same HTML, but still be fluid enough to display on any device
As the pictures illustrate, adaptive uses different HTML structures to fit the screen, while responsive is more fluid and auto-fills the screen depending upon size
Ultimately, both techniques accomplish the same things, which we saw earlier with some of the good mobile app examples, however which one you choose is dependent upon several factors
One, which language are you more comfortable with, HTML, JavaScript or CSS? While you will need all, adaptive is more heavy on the HTML and/or JavaScript side, while responsive is much heavier on the CSS side.
Two, what sort of features do you require? If you want mobile to basically look the same across all devices, just be sized better for each screen, responsive may be a better choice for you as it uses one set of HTML across all devices. On the other hand, maybe you want PC to not only look different from smartphone and tablet versions, but you also want the content and/or features to differ, in which case adaptive may be better suited for you as you can have an HTML file for each device you wish to support.
This is not as important as a decision to make as how you will handle mobile apps, especially since the two techniques can be used together and are not mutually exclusive

What can you do?

Hybrid

Def.: uses a native wrapper or compiler to display one set of code across multiple devices

Pros	Con
Quicker development time than native May be able to access all hardware features Uses app store	Uses app store Performance is not as good as native

Back to our strategies for handling mobile, we have our last strategy, called hybrid
Much like the name sounds, this strategy is actually a combination of the two we previously talked about that attempts to bridge the gap, so to speak, to provide the best of both worlds. It involves building a web app, but then using some technology that then takes that app and installs it on the device, using a sort of frame.
To see if it does provide the best of both worlds, let's look at its set of pros and cons
First, it provides for quick development times as it does run as a web app. Maintenance is theoretically just as quick for this as a web app, however you will spend some additional time in the initial development stage picking out the right framework to handle the OS code, as well as ensuring the framework works across all desired OSes
Depending upon the framework you choose, the API may have access to some, if not all, of the same set of features native apps have access to like the aforementioned push notifications
Finally, being a native app, it will be in the app store which brings all the pros we talked about for the native apps
Which, also brings all the negatives we talked about for native apps in the app store as well
Performance is also still not as good as native app as it is a web app that relies on interpreted code for the actual content
If you are interested in this approach, you would first need to pick out a framework for creating the native code that runs your web app

What can you do?

Hybrid - Types

WebView

Native wrapper to display web app

Compiled

Written in language that gets compiled into native languages

In the world of hybrid mobile apps, there are considered to be two primary types.
A webview app is one where the native part is essentially a browser that then displays all of your web app content. Some of the hardware functionality can be made available to your web app through this method. Some of the more common examples of this are Adobe PhoneGap and Trigger.io
A compiled hybrid app is a little different, in the sense that it is actually written in some language (commonly C# or JavaScript) but then gets compiled to actual native code for each device you wish to support. You generally have access to more of the hardware features, however you sacrifice some of your freedom during development since one code base has to be translated into many. Some common examples of this are Xamarin (C#), Appcelerator Titanium (JS), and Embarcadero FireMonkey (multiple)

Roadmap

Introduction
Traditional vs. Mobile

Differences
Concerns

What can you do?

Native
Web App
Hybrid

Conclusion

What will you do?

Conclusion

You should already have a website
You should also ensure your website is mobile compatible
The real question is not native vs. web app
The real question is do you need a native app as well

First, every business needs a website. These can be both internal and external, but with all of the commerce taking place over the internet, it is hard to ever justify not having web visibility as a company
Since you already have a website (or should) something like a web app is a much more attractive solution as you can leverage existing skills, if not the actual existing web pages, into mobile apps. Especially since Google now ranks sites according to their mobile prowess, this becomes a no-brainer
Additionally, when you consider that lately, mobile devices have become the norm for web site visits, the question no longer becomes native vs. web app
Instead, what I have found is that all businesses should have a mobile version of their site that works across all devices and screen sizes
Focus on that first, and then once completed, ask yourself if you also need a native app solution

Conclusion

Questions to ask

Does my target audience need this?
What devices do my target audience use?
Will this integrate into my existing systems?
What hardware capabilities are needed?
How will future maintenance be handled?

When deciding on a native app, here are some questions to ask yourself ahead of time to avoid wasting time and money
First, figure out your target audience and whether or not they need or want it. Are you doing this to address a business need or just to build a mobile app
Second, ask what devices your target audience uses, as well as if this is expected to change. As we saw from the market share forecast, you don't know what next year will bring, so you don't necessarily want to lock yourself in to one or more specific platforms
Next, consider your existing systems, and ask how this app will integrate into them. Ideally, they fit together smoothly as you will spend plenty of time developing for native, and you don't want to have to maintain two separate sets of systems in the future as well
After that, ask yourself what hardware capabilities you will need. You might not need a native app if this is your sole reason, however if you do, it will help you to determine the proper direction to take by figuring out this requirement upfront
Lastly, consider future maintenance and how you will address it. Remember that development is only the first step, every time you want to fix something or add a new feature, you will need to modify the codebases, as well as wait for approval from the app store
Finally, once done, look at your answers and figure out if you can leverage a hybrid approach using your existing web content to be able to save time and money

Conclusion

What do you need?

Native - Best performance, most costly
Web App - Universal approach, not capable of every feature
Hybrid - Features of a native, performance of a webapp

Taken from http://wiay3s2amryahya.blogspot.com

Credits

http://www.impactbnd.com/blog/9-awesome-examples-of-effective-mobile-website-design
http://www.abercrombie.com/
http://www.cariboucoffee.com
http://www.mountaindew.com/
http://www.webpagesthatsuck.com/dailysucker
http://www.legislature.state.al.us/aliswww/aliswww.aspx
http://judiciary.house.gov/index.cfm/press-releases?ID=62B4FDF5-C8F8-4674-9C2B-08E9A0E7E908
http://www.velokraft.com/
http://www.penthouse-magic.com/9-essential-responsive-web-design-best-practices/
http://www.smashingmagazine.com/2012/02/21/finger-friendly-design-ideal-mobile-touchscreen-target-sizes/
http://www.mrc-productivity.com/blog/2014/11/6-development-mistakes-that-will-kill-a-mobile-app/
http://www.mrc-productivity.com/blog/2014/04/10-keys-to-a-great-mobile-user-experience/
http://glinden.blogspot.com/2006/11/marissa-mayer-at-web-20.html
https://blog.kissmetrics.com/speed-is-a-killer/
http://www.statisticbrain.com/attention-span-statistics/
http://www.mobify.com/blog/beginners-guide-to-perceived-performance/
http://www.agilenutshell.com/agile_vs_waterfall
https://econsultancy.com/blog/64669-21-first-class-examples-of-effective-web-form-design/
http://searchenginewatch.com/sew/opinion/2353616/mobile-now-exceeds-pc-the-biggest-shift-since-the-internet-began
http://www.sitepoint.com/native-hybrid-or-web-apps/
http://www.macobserver.com/tmo/article/isuppli_joins_others_in_predicting_windows_phones_edge_over_ios_by_2015
https://econsultancy.com/blog/64914-what-is-adaptive-web-design-awd-and-when-should-you-use-it/
http://www.lukew.com/ff/entry.asp?1649

Developing for Mobile

A discussion on how to not exclude customers

Who am I?

Roadmap

Roadmap

Has anyone done any mobile work?

Good Mobile Sites

Not So Good Mobile Sites

Traditional vs. Mobile

Traditional vs. Mobile

Traditional vs. Mobile

Touch

Traditional vs. Mobile

Speed

Traditional vs. Mobile

Agility

Traditional vs. Mobile

Connectivity

Traditional vs. Mobile

Input

Traditional vs. Mobile

Traditional vs. Mobile

Why is this a concern?

Roadmap

What can you do?

What can you do?

Native

What can you do?

Native - OS

What can you do?

Web Apps

What can you do?

Web Apps - HTML5

What can you do?

Web Apps - Techniques

What can you do?

Hybrid

What can you do?

Hybrid - Types

Roadmap

Conclusion

Conclusion

Questions to ask

Conclusion

What do you need?

Links

Credits