A thoroughly fascinating look at which parts of a browser’s interface are available to prevent phishing attacks, and which parts are available to enable phishing attacks. It’s like trench warfare for pixels.
Monday, January 16th, 2017
Tuesday, January 3rd, 2017
When I was first styling Resilient Web Design, I made heavy use of
vh units. The vertical spacing between elements—headings, paragraphs, images—was all proportional to the overall viewport height. It looked great!
Then I tested it on real devices.
Here’s the problem: when a page loads up in a mobile browser—like, say, Chrome on an Android device—the URL bar is at the top of the screen. The height of that piece of the browser interface isn’t taken into account for the viewport height. That makes sense: the viewport height is the amount of screen real estate available for the content. The content doesn’t extend into the URL bar, therefore the height of the URL bar shouldn’t be part of the viewport height.
But then if you start scrolling down, the URL bar scrolls away off the top of the screen. So now it’s behaving as though it is part of the content rather than part of the browser interface. At this point, the value of the viewport height changes: now it’s the previous value plus the height of the URL bar that was previously there but which has now disappeared.
I totally understand why the URL bar is squirrelled away once the user starts scrolling—it frees up some valuable vertical space. But because that necessarily means recalculating the viewport height, it effectively makes the
vh unit in CSS very, very limited in scope.
In my initial implementation of Resilient Web Design, the one where I was styling almost everything with
vh, the site was unusable. Every time you started scrolling, things would jump around. I had to go back to the drawing board and remove almost all instances of
vh from the styles.
I’ve left it in for one use case and I think it’s the most common use of
vh: making an element take up exactly the height of the viewport. The front page of the web book uses
min-height: 100vh for the title.
But as soon as you scroll down from there, that element changes height. The content below it suddenly moves.
Let’s say the overall height of the browser window is 600 pixels, of which 50 pixels are taken up by the URL bar. When the page loads,
100vh is 550 pixels. But as soon as you scroll down and the URL bar floats away, the value of
100vh becomes 600 pixels.
(This also causes problems if you’re using vertical media queries. If you choose the wrong vertical breakpoint, then the media query won’t kick in when the page loads but will kick in once the user starts scrolling …or vice-versa.)
There’s a mixed message here. On the one hand, the browser is declaring that the URL bar is part of its interface; that the space is off-limits for content. But then, once scrolling starts, that is invalidated. Now the URL bar is behaving as though it is part of the content scrolling off the top of the viewport.
The result of this messiness is that the
vh unit is practically useless for real-world situations with real-world devices. It works great for desktop browsers if you’re grabbing the browser window and resizing, but that’s not exactly a common scenario for anyone other than web developers.
It’s such a shame. A piece of CSS that’s great in theory, and is really well supported, just falls apart where it matters most.
Update: There’s a two-year old bug report on this for Chrome, and it looks like it might actually get fixed in February.
Friday, December 23rd, 2016
Wednesday, December 14th, 2016
Monday, December 5th, 2016
I always loved the way that Gov.uk styled their radio buttns and checkboxes with nice big visible labels, but it turns out that users never used the label area. And because it’s still so frickin’ hard to style native form elements, custom controls with generated content is the only way to go if you want nice big hit areas.
Sunday, December 4th, 2016
Henrik points to some crucial information that slipped under the radar at the Chrome Dev Summit—the Android OS is going to treat progressive web apps much more like regular native apps. This is kind of a big deal.
It’s a good time to go all in on the web. I can’t wait to see what the next few years bring. Personally, I feel like the web is well poised to replace the majority of apps we now get from app stores.
Thursday, November 24th, 2016
An illustrated history of digital iconography.
Wednesday, November 23rd, 2016
This is so wonderful! A 3D fly-through of the Apollo 11 command module, right in your browser. It might get your fan whirring, but it’s worth it.
Click through for lots of great details on the interface controls, like which kinds of buttons and switches were chosen for which tasks.
And there’s this lovely note scrawled near the sextant by Michael Collins (the coolest of all the astronauts):
Spacecraft 107, alias Apollo 11, alias ‘Columbia.’ The Best Ship to Come Down the Line. God Bless Her.
Monday, November 21st, 2016
J. Renée Beach writes on Ev’s blog about three things to consider when planning for offline experiences:
- Reach, and
How will you express to your users that the content is up to date, safe and available across their network?
Wednesday, November 16th, 2016
Usability Testing of Inline Form Validation: 40% Don’t Have It, 20% Get It Wrong - Articles - Baymard Institute
I saw Christian speak on this topic at Smashing Conference in Barcelona. Here, he takes a long hard look at some of the little things that sites get wrong when doing validating forms on the fly. It’s all good sensible stuff, although it sounds a bit medical when he takes about “Premature Inline Validation.”
Wednesday, October 5th, 2016
Krystal’s excellent annotated collection of onboarding examples.
Tuesday, October 4th, 2016
Interviews with the designers who make on-screen interfaces for sci-fi films.
Monday, September 5th, 2016
The imitation game
Jason shared some thoughts on designing progressive web apps. One of the things he’s pondering is how much you should try make your web-based offering look and feel like a native app.
Start by forgetting everything you know about conventional web design, and instead imagine you’re actually designing a native app.
This makes me squirm. I mean, I’m all for borrowing good ideas from other media—native apps, TV, print—but I don’t think that inspiration should mean imitation. For me, that always results in an interface that sits in a kind of uncanny valley of being almost—but not quite—like the thing it’s imitating.
With that out of the way, most of the recommendations in Owen’s article are sensible ideas about animation, input, and feedback. But then there’s recommendation number eight: Provide an easy way to share content:
PWAs are often shown in a context where the current URL isn’t easily accessible, so it is important to ensure the user can easily share what they’re currently looking at. Implement a share button that allows users to copy the URL to the clipboard, or share it with popular social networks.
See, when a developer has to implement a feature that the browser should be providing, that seems like a bad code smell to me. This is a problem that Opera is solving (and Google says it is solving, while meanwhile penalising developers who expose the URL to end users).
Anyway, I think my squeamishness about all the advice to imitate native apps is because it feels like a cargo cult. There seems to be an inherent assumption that native is intrinsically “better” than the web, and that the only way that the web can “win” is to match native apps note for note. But that misses out on all the things that only the web can do—instant distribution, low-friction sharing, and the ability to link to any other resource on the web (and be linked to in turn). Turning our beautifully-networked nodes into standalone silos just because that’s the way that native apps have to work feels like the cure that kills the patient.
If anything, my advice for building a progressive web app would be the exact opposite of Owen’s: don’t forget everything you’ve learned about web design. In my opinion, the term “progressive web app” can be read in order of priority:
- Progressive—build in a layered way so that anyone can access your content, regardless of what device or browser they’re using, rewarding the more capable browsers with more features.
- Web—you’re building for the web. Don’t lose sight of that. URLs matter. Accessibility matters. Performance matters.
- App—sure, borrow what works from native apps if it makes sense for your situation.
Jason asks questions about how your progressive web app will behave when it’s added to the home screen. How much do you match the platform? How do you manage going chromeless? And the big one: what do users expect?
Will people expect an experience that maps to native conventions? Or will they be more accepting of deviation because they came to the app via the web and have already seen it before installing it?
These are good questions and I share Jason’s hunch:
My gut says that we can build great experiences without having to make it feel exactly like an iOS or Android app because people will have already experienced the Progressive Web App multiple times in the browser before they are asked to install it.
In all the messaging from Google about progressive web apps, there’s a real feeling that the ability to install to—and launch from—the home screen is a real game changer. I’m not so sure that we should be betting the farm on that feature (the offline possibilities opened up by service workers feel like more of a game-changer to me).
People have been gleefully passing around the statistic that the average number of native apps installed per month is zero. So how exactly will we measure the success of progressive web apps against native apps …when the average number of progressive web apps installed per month is zero?
I like Android’s add-to-home-screen algorithm (although it needs tweaking). It’s a really nice carrot to reward the best websites with. But let’s not carried away. I think that most people are not going to click that “add to home screen” prompt. Let’s face it, we’ve trained people to ignore prompts like that. When someone is trying to find some information or complete a task, a prompt that pops up saying “sign up to our newsletter” or “download our native app” or “add to home screen” is a distraction to be dismissed. The fact that only the third example is initiated by the operating system, rather than the website, is irrelevant to the person using the website.
My hunch is that the majority of people will still interact with your progressive web app via a regular web browser view. If, then, only a minority of people are going to experience your site launched from the home screen in a native-like way, I don’t think it makes sense to prioritise that use case.
The great thing about progressive web apps is that they are first and foremost websites. Literally everyone who interacts with your progressive web app is first going to do so the old-fashioned way, by following a link or typing in a URL. They may later add it to their home screen, but that’s just a bonus. I think it’s important to build progressive web apps accordingly—don’t pretend that it’s just like building a native app just because some people will be visiting via the home screen.
I’m worried that developers are going to think that progressive web apps are something that need to built from scratch; that you have to start with a blank slate and build something new in a completely new way. Now, there are some good examples of these kind of one-off progressive web apps—The Guardian’s RioRun is nicely done. But I don’t think that the majority of progressive web apps should fall into that category. There’s nothing to stop you taking an existing website and transforming it step-by-step into a progressive web app:
- Switch over to HTTPS if you aren’t already.
- Use a service worker, even if it’s just to provide a custom offline page and cache some static assets.
- Make a manifest file to point to an icon and specify some colours.
See? Not exactly a paradigm shift in how you approach building for the web …but those deceptively straightforward steps will really turbo-boost your site.
I’m really excited about progressive web apps …but mostly for the “progressive” and “web” parts. Maybe I’ll start calling them progressive web sites. Or progressive web thangs.
Wednesday, August 31st, 2016
Choosing the right input type for your form field.
Tuesday, August 30th, 2016
Some interesting interface ideas here for informing users when a service worker is doing its magic.
In the future users may expect a site to work offline after visiting again, but until this happens, I think it is a good idea to let the users know about this feature.
Wednesday, August 3rd, 2016
This is witchcraft. I’ve been deconstructing the CSS to figure out how this works and it’s really clever.
(Hint: try commenting out some of the CSS and see what happens.)
Wednesday, July 27th, 2016
An entertaining presentation from South By Southwest on the UI element of last resort.
It’s funny because it’s true.
Sunday, July 24th, 2016
The trouble with overflow menus is that you didn’t actually take anything away, you just obnoxiously obfuscated it.
Words of warning and advice from Daniel.
Instead of prioritizing, we just sweep complexity under the rug and pretend that it doesn’t exist.
Wednesday, July 20th, 2016
Jason breaks down the myths of inputs being tied to device form factors. Instead, given the inherent uncertainty around input, the only sensible approach is progressive enhancement.
Now is the time to experiment with new forms of web input. The key is to build a baseline input experience that works everywhere and then progressively enhance to take advantage of new capabilities of devices if they are available.
Tuesday, June 28th, 2016
Accessibility Matters: Meet Our New Book, “Inclusive Design Patterns” (Pre-Release) – Smashing Magazine
I think it’s a safe bet that this new book by Heydon will be absolutely brilliant.
It’s a handbook with valuable, time-saving techniques that will help you avoid hacky workarounds and solve common issues effectively.