2010: The childhood OF MOBILE WEB

iPad and iPhone 4G just released
Android market has 80,000 apps
Smartphones are <10% web trafic
Mobile OS wannabes: "Windows Mobile 7", Bada, WebOS

Apps are cooler

SLOW AND BORING

double the costs. Every time.

and pretend Windows Phone does not exist

BET ON Mobile web ?

UserS

DEVS

Web

"Mobile
Web"

"Desktop
Web ?"

The most common strategy at the time
to split desktop and mobile users was
User Agent sniffing

https://adrianroselli.com/2011/10/detecting-mobile-devices.html

https://user-agents.net/download

but how do you decide if some device is "mobile" or not ?

what made you decide ?

Screen size ? Screen definition ?

Inputs ? Touch screen or keyboard/mouse ?

Connectivity ? Bandwidth ? Latency ?

Device power ? Capabilities ?

Usage context, user intent ?

YET, decisions based on this ABSTRACT
frontier Are done every day

Functional specs:
show a different content here for mobile users
Web design:
display a different navigation menu on mobile
Front-end dev:
load an alternative version of a component on mobile
Client / Product owner:
focus on tickets from mobile users

Why do we make
these bad decisions ?

1. mobile as an excuse

for commercials, to sell more
for project managers, to create new tasks and extend deadlines
for devs, to do half of the job (I plead guilty !)

Bad arguments:

"you can't handle all devices"
→ yes, you can, with the right level of abstraction
"we have to make generalizations at some point"
→ unnecessary "sacrificial" decisions
"my client doesn't use mobile"
→ my client is stuck with big screens because of me

2. works on my machine

the gap between dev and user
environments and usage contexts

Emulating small resolutions, touch controls, bad performance with CPU and network throttling, does not replace testing with a real device

Address all usecases. Test without mouse. Then test without keyboard. Then test with only one hand, lying on a sofa.
Testing panels: have your app tested by your boss, your roommate, your children, your mother
Don't blame the user ! Your job is to make the website usable

3. User stories are just stories

Reasoning cognitive bias lead to a poor perception of reality:

Hypothesis confirmation bias :
prefer elements which confirm rather than invalidate a hypothesis
Representativeness bias:
consider one or more elements as representative of a population
Selective perception:
selectively interpret information based on own experience.

User scenarios → are you sure about the order of the actions ? the timing ?

Mockups on Illustrator → what happens to your pixel-perfect layout if we slightly change the width, or zoom in text because user is myopic ?

This "mobile web" thing is a user story

How to fix this ?

CSS Media Queries have been thought this way:

Think in variables, not categories

They also tried to make device categories, but it did not work in the end:

Cut into smaller parts

Move from full-page mockups to components and graphic charter

The smaller the component is, the easier it is to adapt
to all the variables: screen size, input methods...

Things to ban: "mobile" mockups, fixed layouts, ideally prefilled data

cut into smaller parts

Modularize everything: components, inputs, actions, services...
For each part, define hypotheses, constraints and options

Example: a photo gallery component

~~gallery-lib.desktop.js / gallery-lib.touch.js~~

what image size to load ?
→ check screen resolution and network conditions
how will the user interact with the component ?
→ load gallery-mouse-controls module if mouseover event,
load gallery-touch-controls module if touchstart event
what should be the loading strategy ? preload next pictures ?
→ based on first image loading time or user actions
do not assume mobile should not preload