Archive for the 'mobile' Category

Briefing to the UK Competition and Markets Authority on Apple’s iOS browser monopoly and Progressive Web Apps

On 4 March this year, the UK Competition and Markets Authority announced that it is

investigating Apple’s conduct in relation to the distribution of apps on iOS and iPadOS devices in the UK, in particular, the terms and conditions governing app developers’ access to Apple’s App Store.

Submissions from the public were invited, so I replied and was invited, with “Clark Kent” (a UK iOS Web-Apps developer who wishes to be anonymous) and Stuart Langridge to brief the CMA in more detail. We were asked to attend for 2 hours, so spoke for one hour, and then took questions.

CMA are happy for our presentations to be published (they’re eager to be seen to be engaging with developers) but asked that the questions be kept private. Suffice it to say that the questioning went over the allocated time, and showed a level of technical understanding of the issues that surpasses many engineers. (The lawyers and economists knew, for example, that iOS browsers are all compelled to use WebKit under the hood, so Chrome/ Firefox/ Edge on iOS share only a name and a UI with their fully-fledged real versions on all other Operating Systems).

Clark’s presentation

Clark talked of how Steve Jobs’ 2007 announcement of apps for iPhone inspired him to use his webdev skills to make iOS web-apps.

you can write amazing Web 2.0 and Ajax apps that look exactly and behave exactly like apps on the iPhone. And these apps can integrate perfectly with iPhone services … And guess what? There’s no SDK that you need! You’ve got everything you need if you know how to write apps using the most modern web standards to write amazing apps for the iPhone today.

Unfortunately, Safari’s bugs made development much more expensive by breaking Indexed DB; breaking scrolling etc. Also, Apple refuses to support Web Bluetooth, so his customers had to purchase expensive iOS-compatible printers for printing receipts, at 11 times the cost of Bluetooth printers. iOS apps can integrate with Bluetooth, however.

He can’t ask his customers to jettison their iPads and buy Android tablets. Neither can he ask them to use an alternative browser, because there isn’t any meaningful choice on iOS. Clark simply wants to be able to make “amazing Web 2.0 and Ajax apps that look exactly and behave exactly like apps on the iPhone”, as Jobs promised. He summed up:

All these business costs inevitably get passed onto consumers. Or worse applications simply never get built, due to the increased cost.

From the perspective of software developers there is no browser competition on iOS.

Apple has banned all the other browser engines and Safari’s bugs and missing features means that web-apps struggle to compete with the AppStore. If third party browsers were allowed, with full access to all the APIs that Apple gives Safari, this would provide Apple the incentive to keep pace with the other browsers and give consumers a means of voting with their feet by moving to a competing browser if they fail to do so.

This would then lead to a universal open app development and distribution platform which would substantially reduce development and maintenance costs for a wide range of business and consumer applications. The open web offers an alternative future where the control from corporate intermediaries along with their fees are replaced with consumer choice and the freedom to easily shift from one platform to another. Instead of having to write multiple separate applications for every device, it allows developers to build their application once and have it work on all consumer devices be it desktop, laptop, tablet or phone.

Write once, deploy everywhere, no gatekeepers, no fees. just as Steve Jobs originally promised.

Stuart’s presentation

Stuart examined whether Apple’s assertion that lack of real browser diversity is actually better for consumers’ privacy and security.

My presentation

Here’s my captioned video. Below is the marked-up transcript with links. Note: this submission is my personal opinion and does not represent the opinion of any of my past or present clients or employers.

Transcript and Links

Hi, I’m Bruce Lawson, and I’m here to talk about Progressive Web Apps and iOS. I’ve been mucking around on the web since about 2002, mostly as a consultant working on expanding people’s websites to be truly worldwide, so they’re performant and work with constrained devices and networks in emerging markets. I’m also involved with making websites that are accessible for people with disabilities. And I was on the committee with the British Standards Institution writing BS8878, the British standard for commissioning accessible websites that last year got a rolled into the ISO. And before that, I was deputy for the chief technical officer at Opera software that makes a popular web browser used by about 250 million people worldwide, predominantly in emerging markets.

Most of my customers are in the UK, USA, or Israel, and they’re largely focused on UK and US markets. In the month of June this year, stats counter showed that 30% of all US web traffic was on iOS, 28% windows, 22% Android. And to drill that into just mobile browsers, 57% were iOS and 42% were Android.

In the UK, 30% of people use Windows to browse the web, 27% iOS, 25% Android. And that jells pretty well with stats from the GDS, the government digital services. Their head of front-end, Matt Hobbs, every month tweets some stats. He said that in June, iOS accounted for 44% of traffic, Android 28%. (Although he does note that because you have to opt in to be tracked, it tends to over-represent the mobile browsers). But we can see that in the UK, 50% of traffic is on iOS and 49% is Android.

So, we obviously have to be concerned with iOS as well as Android, Windows, et cetera, and all the different browsers that are available on every non-iOS operating system. And so, I always recommend to my customers that they use the web. After all, that’s what it’s for.

The principle of universality allows the web to work no matter what hardware, software, network connection or language you use, and to handle information of all types and qualities. This principle guides Web technology design

And that was said by Sir Tim Berners-Lee, and his parents were both from Birmingham, as am I. So he’s practically a relative. And with my work in web standards, those principles still hold true for the web standards we make today. So, I wanted to use the web and I wanted to use what’s called a Progressive Web App, which is basically a website plus. It’s a website and it’s web pages, each of which has a URL. It’s built with web technology, but in modern browsers, conforming browsers, it can look and feel more app-like.

In fact, the UK government itself recommends these. Our government writes,

advances in browser technology have made it possible to do things on the mobile web that you could previously only do with native apps. Services that take advantage of these modern browser enhancements are often called mobile web apps or Progressive Web Apps. The user experience of PWAs and a handset is almost identical to a native app, but unlike native apps, PWAs have a single code base that works on the web, like any normal website. A benefit of PWAs over native apps for the government is that there is no need to maintain lots of different operating system versions of the same app. This makes them relatively inexpensive to develop compared to native apps.

And just like government, business likes to reduce costs, and therefore can reduce costs to the end user. Our government goes on to say,

users can choose to install PWAs on any device that supports technology. If a user chooses to install a PWA, they typically take up less space than the equivalent native app.

And this is very important in emerging markets where lower priced phones have lower specifications and less storage space. The government continues,

PWAs cost less than native apps since they need to be only developed once for different platforms. They are also forward compatible with future upgrades to operating systems

And then it lists browsers that do support PWAs, and it lists Apple, Safari and iOS, but this is only partially true. Apple themselves make this claim in their February 2021 submission to the Australian investigation into monopolies. Apple said of PWAs,

Web browsers are used not only as a distribution portal, but also as platforms themselves, hosting progressive web applications that eliminate the need to download a developer’s app through the app store or other means at all

Therefore, Apple is suggesting that PWAs are a viable alternative to the app store. Apple continues,

PWAs are increasingly available for and through mobile based browsers and devices, including on iOs [my emphasis]. PWAs are apps that are built using common web technology like HTML 5, but have the look feel and functionality of a native app

But, as we will see this, isn’t true. PWAs do not have the same functionality as a native app.

Let’s recap about what a PWA actually is. It’s a bit of an umbrella term, but fundamentally it’s a website, but it can install to the home screen of your mobile device, just like a native app. And it can have its own icon defined by the web developer, launch full screen, portrait or landscape, depending up on what the developer chooses, but it lives on the web.

And this is a really important. It’s important for several reasons. Firstly, because it lives on the web, you’re not downloading everything in one go. A native app is like downloading a whole website all at once. A PWA, you download just the shell, and as you navigate around it, it will get any content it doesn’t already have stored from the web server. Another advantage is that means that you have instant publication. The moment you press the button and it goes on your web server, the next person who opens your app on their device will see the new version. Great for security updates and also great for time-sensitive material.

Another great thing is, of course, is that because there’s no app store, no gatekeeper. Smaller shops don’t have to pay the 15 to 30% tax to Google and Apple. And also, for industries that are not compatible with the app stores, such as adult entertainment, gambling, et cetera, it’s a mechanism of giving an app because they can’t use the app store. And PWAs can work offline.

Let’s briefly look at one. I’m here speaking in a personal capacity. I don’t represent any of my clients or employers, so I can’t show you one of their apps, but I took 15 minutes to convert my WordPress blog into a PWA.

Okay, here, I’m using Firefox on Android. Android, unlike iOS, allows not only different badged browsers, but it actually allows that full browser on, so Firefox on Android is using Firefox’s own Gecko engine. Here, Firefox and Android are collaborating and they can tell when a user goes to my website that it is a PWA, and it offers the opportunity to the visitor to add it to the home screen. You can see it says “you can easily add this website to your device’s home screen to have instant access and browse faster with an app-like experience”. As a developer, I didn’t make this and the user doesn’t have to know anything because the operating system and the browser just show this. If the user chooses, they can add to home screen, they can click on the icon, and it will add automatically or else they can drag it themselves to where they want it.

And here, as you can see, it’s now on my Android home screen. There’s a little Firefox icon at the bottom of my logo to tell the user it’s a PWA. Chrome doesn’t do this, but it does also detect that it’s a PWA and offer to add it to the home screen. And as you can see from the screenshot on the right, when they tickle that icon into life, up pops my website full screen, without an address bar, looking like a native app. If however, a user goes to my website in a browser that doesn’t support PWAs, such as UC Web here, they don’t get offered the add to homescreen thing, they just see my website and navigate it as normal. So people with capable browsers get an app like experience, everybody else just gets the website and nobody loses out.

On iOS it’s subtly, but importantly, different.

So on iOS, if you go to my website, you’re not told anything about this being installable. You have to know to click that icon in the bottom bar that I’ve circled in red. And once you’ve done that, then you get the screen on the right. And you just have to know as a user to scroll down, whereupon you’ll see add to home screen there with no instructions or explanation of what’s going to happen. Anyway, once you click that, then you confirm, and finally it’s on the homescreen. And when you press it, it launches full screen without an address bar. But it still, even though it’s much harder to discover this, it still can’t do everything that a native app could do.

This is Echo Pharmacy. It’s a service that I’ve been using during the pandemic. It’s nothing to do with my employers or clients. I’m just a customer. I use it to get my repeat prescriptions, and I used it and it worked really well. And on the confirmation screen, after I’d ordered some more medication, it said, “Hey, why not use our app?” And I thought, well, why would I need an app, because this website has worked perfectly well for me. So I asked on Twitter, I said, “Why does it need me to download the app?” The website allows me to place and track my meds, why clog up my device, because it’s a download, right? Is it for push notifications, because on iOS websites and PWAs cannot send push notifications. And for a pharmacy like this, it’s important for them to say, “It’s 8:00 PM, have you taken this tablet?” Or, “We notice in four days time, you’re going to run out of this medication. Please come back and order.”

And I got a reply from the CTO of Echo Pharmacy saying,

Hey Bruce, you’re right about push notifications, which for some people are preferable to email or SMS reminders. Beyond that our app and website have feature parity,so it’s really just about what you prefer.

In other words, these people at Echo Pharmacy, not only have they got a really great website, but they also have to build an app for iOS just because they want to send push notifications. And, perhaps ironically, given Apple’s insistence that they do all of this for security and privacy, is that if I did choose to install this app, I would also be giving it permission to access my health and fitness data, my contact info, my identifiers sensitive info, financial info, user content, user data and diagnostics. Whereas, if I had push notifications and I were using a PWA, I’d be leaking none of this data.

So, we can see that despite Apple’s claims, I cannot recommend a PWA as being an equal experience an iOS simply here because of push notifications. But it’s not just hurting current business, it’s also holding back future business. A lot of my clients are looking to expand into new markets. The UN has said by the end of this century, 50% of the population of the world will live in these 10 countries. And as you can see, only one of them is a traditional market for a UK business, the US. And it’s obvious why people want to do this. Whereas, the population of the “west”is not increasing, it’s increasing a lot in new markets.

“The Southeast Asian internet economy is expected to reach $200 billion by 2025“, for example, but all countries are not equal in the technological stakes. Here, for example, is the percentage of monthly income that it takes to buy one gigabyte of mobile data. In the UK, for a gigabyte, (not actually that much [data]), it costs me 0.16% of my monthly income. In India, it’s a little bit more at 0.05%. In the states, 0.1%. In Rwanda, where one of my customers is doing great business, it’s 0.5% of monthly income. In Yemen, where I was born, it’s very nearly 16% of monthly income. So, big downloads cost a lot of money, particularly for something like a medication tracking system, which I might use only once every quarter. It’s a heck of a lot to download at these prices.

VisualCapitalist.com say worldwide, the highest average costs for one gigabyte of data is 30,000% more than the cheapest average price. And it’s not just about data costs either. It’s about data speed. Here, for example, in the UK, the average or the median UK speed is 28.51 megabits per second, in the States, it’s 55. In Hong Kong, it’s 112. In Rwanda, it’s 0.81. In Cambodia, it’s 1.29. In India, it’s 4. In Indonesia, it’s 1.88.

So, a big download not only costs potential customers more, but it takes a lot longer. Facebook recognized this when they released their Facebook Lite app. Facebook said

downloading a typical app with 20 megabyte APK can take more than 30 minutes on a 2G network, and the download is likely to fail before completion due to the flaky nature of the network

Twitter released something called Twitter Lite, which is now just everybody’s Twitter. The Lite’s a PWA, and Twitter said

Twitter Lite is network resilient. To reach every person on the planet, we need to reach people on slow and unreliable networks. Twitter Lite is interactive in under five seconds over 3G on most devices. Most of the world is using 2G or 3G networks. A fast initial experience is essential

So, if we could offer PWAs, we would have a competitive advantage over other people, have much faster installation and a much cheaper installation. Penny McLachlan, who works as a product manager at Google said,

A typical Android app size [a native app, in other words], is about 11 megabytes. Web APKs, TWAs, [this is technical speak for a Progressive Web App], are usually in the range of seven to 900 kilobytes

So, only about 10% of the size of an Android app. So, we can see that PWAs is a competitive advantage for people trying to do business in the wider world, because at post-Brexit, global Britain, et cetera.

It’s no coincidence that the majority of the early PWAs that we saw coming out in 2016, 2017 came out of Asia and Africa, and that’s because when people who make websites and web apps use the same devices and the same networks as their consumers, they absolutely understand why PWAs are great.

But, we can’t make a PWA because we have to care about Safari, which is more than 50% of our traffic in our home market. So, what can I advise my clients to do? Well, a lot of them have settled on something called React Native. They can’t afford to have one developer team for Android, one developer team for iOS, and one developer team for web.

If you’re a massive organization such as Google or Amazon, of course you can afford that, but developers ain’t cheap. And three teams is prohibitively expensive for a smaller organization. React Native, which is open source (but stewarded by Facebook), promises that you write once and it works across platforms, where you’re writing in a language called React, and it compiles down to native applications. So you write in React, you press a button, and it squirts out a native Android app and a native iOS app. And it’s pretty good, I guess.

There’s pros and cons, of course. The pros we write just once. Great. The cons. Well, it still emits a native app, so we still have to submit to app stores, and the timing of that is at the whim of the whoever’s moderating the app store, et cetera. It’s still a big download because it’s a native app.

It’s a more complex built process. There’s not a great deal of build to the web. React Native requires lots of moving parts, internally. It’s harder for us to test the functionality because although we write it once, we have to test it on iOS and we had to test it on Android, and Android testing isn’t as simple as iOS because there’s a massive difference between a top-of-the-range Google Pixel device, or the expensive Samsung devices and the kind of no name cheap Android devices you can get in street markets in Bangkok and Jakarta and Mumbai.

And a problem for me, and for one of my clients, is accessibility. Accessibility is making sure that your app or your site can be used by people with disabilities. Apple and Google have done great jobs making iOS and Android accessible, but React Native has some quirks under the hood, which make it much trickier.

One of the reasons for this is that React Native is quite a new technology and the web is a mature technology, and accessibility on the web is pretty much a solved problem. It isn’t solved if developers don’t do the right thing, but Chrome is 98.5% compliant with the W3C guidelines for accessibility. Microsoft Edge is a 100%. Firefox is 94%. Safari is 97%.

But because we’re writing in React and it’s doing magic tricks under the hood, there are holes in its accessibility. Facebook themselves say,

we found that React Native APIs provide strong support for accessibility. However, we also found many core components do not yet fully utilize platform accessibility APIs. Support is missing for some platform specific features.

They say it’s true, that support is missing. But for example, if you have an external keyboard plugged into an Android device, perhaps because you have Parkinson’s, or (like me) you have multiple sclerosis and you prefer to use a keyboard than the tiny little software keyboards. But if you have an external keyboard, you cannot use that keyboard to focus in to enter any information in any input field that’s made with React Native [on Android]. This of, course, is a huge problem.

Facebook has done some effort into writing up all of their accessibility problems. Here, for example, we can see this is a GitHub board with all the issues and I scroll, scroll, scroll, scroll, scroll through them. There is apparently a fix for the inability to focus into any input fields with Android and a keyboard, but we are at the mercy of Facebook’s release schedules here.

So, what could I advise my clients to do? I tend to advise them, go PWA and let’s hope that the CMA make Apple do the right thing. What I would really like to do is say to them, “Okay, just put this notice on your web app. Say: ‘we’d like to send you push notifications, if that’s okay by you. Please download Microsoft Edge, Mozilla Firefox, or Google Chrome on iOS’.”

However, if they do download Edge for iOS, Firefox for iOS, or Chrome for iOS, that’s no help at all because Apple prohibits those browsers using their own more capable engines and they have to use the Safari engine under the hood. So, consumers get no choice at all.

Random Expo.io tips

I’m doing some accessibility testing on a React Native codebase that uses Expo during development. If you’ve done something seriously wrong in a previous life and karma has condemned you to using React Native rather than making a Progressive Web App, Expo is jolly useful. It gives you a QR code that you can scan with Android or iOS to ‘install’ the app on your device and you get live reload of any changes. It’s like sinking in a quagmire of shit but someone nice is bringing you beer and playing Abba while it happens. (Beats me why that isn’t their corporate strapline.)

Anyway, I struggled a bit to set it up so here are some random tips that I learned the hard way:

  • If your terminal yells “Error: EMFILE: too many open files, watch at FSEvent.FSWatcher._handle.onchange (internal/fs/watchers.js:178:28) error Command failed with exit code 1” when you start Expo, stop it, do brew install watchman and re-start Expo. Why? No idea. Someone from StackOverflow told me. Most npm stuff is voodoo magic–just install all the things, hope none of them were made by in Moscow by Vladimir Evilovich of KGB Enterprises, ignore all the deprecation warnings and cross your fingers.
  • If you want to open your app in an iOS simulator, you need xcode and you need to install xcode command line tools or it’ll just hang.
  • Scrolling in iOS simulator is weird. Press the trackpad with one hand and scroll with other hand. Or enable three finger drag and have one hand free for coffee, smoking or whatever other filthy habits you’ve developed while working from home.
  • If you don’t want it, you can turn off the debugging menu overlay.
  • If you like CSS, under no circumstances view source of the app running in the browser. It is, however, full of lots of ARIA nourishment thanks to React Native for Web.

Who knows? One day, Apple may decide not to hamstring PWAs on iOS and we can all use the web to run on any device and any browser, just as Sir Uncle Timbo intended.

No to Service Worker, Yes to Wank!

My chum and co-author Remington Sharp tweeted

We need a universally recognised icon/image/logo for "works offline".

Like the PWA or HTML5 logo. We need to be able to signal to visitors that our URLs are always available.

To the consumer, the terms Progressive Web App or Service Worker are meaningless. So I applied my legendary branding, PR and design skills to come up with something that will really resonate with a web user: the fact that this app works online, offline – anywhere.

So the new logo is a riff on the HTML5 logo, because this is purely web technologies. It has the shield, a wifi symbol on one side and a crossed out wifi symbol on the other, and a happy smile below to show that it’s happy both on and offline. Above it is the acronym “wank” which, of course, stands for “Works anywhere—no kidding!”

Take it to use on your sites. I give the fruits of my labour and creativity free, as a gift to humanity.

The practical value of semantic HTML

Bruce’s guide to writing HTML for JavaScript developers

It has come to my attention that many in the web standards gang are feeling grumpy about some Full Stack Developers’ lack of deep knowledge about HTML. One well-intentioned article about 10 things to learn for becoming a solid full-stack JavaScript developer said

As for HTML, there’s not much to learn right away and you can kind of learn as you go, but before making your first templates, know the difference between in-line elements like <span> and how they differ from block ones like <div>. This will save you a huge amount of headache when fiddling with your CSS code.

This riled me too. But, as it’s Consumerfest and goodwill to all is compulsory, I calmed down. And I don’t want to instigate a pile-on of the author of this piece; it’s indicative of an industry trend to regard HTML as a bit of an afterthought, once you’ve done the real work of learning and writing JavaScript. If the importance of good HTML isn’t well-understood by the newer breed of JavaScript developers, then it’s my job as a DOWF (Dull Old Web Fart) to explain it.

Gather round, Fullstack JavaScript Developers – together we’ll make your apps more usable, and my blood pressure lower.

What is ‘good’ HTML?

Firstly, let’s reach a definition of ‘good’ HTML. Many DOWFs used to get very irked about (X)HTML being well-formed: proper closing tags, quoted attributes and the like. Those days are gone. Sure, it’s good practice to validate your HTML, just like you lint your JavaScript (it can catch errors and make your code more maintainable), but browsers are very forgiving.

In fact, part of what we commonly call ‘HTML5’ is the Parsing Algorithm which is like an HTML ninja – incredibly powerful, yet rarely noticed. It ensures that all modern browsers construct the same DOM from the same HTML, regardless of whether the HTML is well-formed or not. It’s the greatest fillip to interoperability we’ve ever seen.

By ‘good’ HTML, I mean semantic HTML, a posh term for choosing the right HTML element for the content. This isn’t a philosophical exercise; it has directly observable practical benefits.

For example, consider the <button> element. Using this gives you some browser behaviour for free:

  • A button is focusssable via the keyboard. I bet you, dear reader, know all the keyboard shortcuts for your IDE; it makes development much faster. Many people use only the keyboard when using a webpage. I do it because I have multiple sclerosis – therefore the fine motor control required to use a mouse can be difficult for me. My neighbour has arthritis, so she prefers to use the keyboard.
  • Buttons can be activated using the space bar or the enter key; you don’t have to remember to listen for these keypresses in your script.
  • Inside a <form>, it doesn’t even need JavaScript to work.

“What’s that?”, you say. “Everyone has JavaScript”. No, they don’t. Most people do, most of the time. But I guarantee you that everyone is without JavaScript sometimes.

Here’s another example: semantically linking a <label> to its associated <input> increases usability for a mouse-user or touch-screen user, because clicking in the label focusses into the input field. See this in action (and how to do it) on MDN.

This might be me, with my MS; it might be you, on a touch-screen device on a bumpy train, trying to check a checkbox. How much easier it is if the hit area also includes the label “uncheck to opt out of cancelling us not sending you spam forever”. (Compare the first and second identical-looking examples in a checkbox demo.)

But the point is that by choosing the right element for the job, you’re getting browser behaviour for free that makes your app more usable to a range of different people.

Invisible browser behaviours

With me so far? Good. The browser behaviours associated with the semantics of <button> and <label> are obvious once you know about them – because you can see them.

Other semantics aren’t so obvious to a sighted developer with a desktop machine and a nice big monitor, but they are incredibly useful for those who do need them. Let’s look at some of those.

HTML5 has some semantics that you can use for indicating regions on a page. For example, <nav>, <main>, <header>, <footer>.

If you wrap your main content – that is, the stuff that isn’t navigation, logo and main header etc – in a <main> tag, a screen reader user can jump immediately to it using a keyboard shortcut. Imagine how useful that is – they don’t have to listen to all the content before it, or tab through it to get to the main meat of your page.

And for people who don’t use a screenreader, that <main> element doesn’t get in the way. It has no default styling at all, so there’s nothing for you to remove. For those that need it, it simply works; for those that don’t need it, it’s entirely transparent.

Similarly, using <nav> for your primary navigation provides screenreader users with a shortcut key to jump to the navigation so they can continue exploring your marvellous site. You were probably going to wrap your navigation in a <div class=”nav”> to position it and style it; why not choose <nav> instead (it’s shorter!) and make your site more usable to the 15% of the world who have a disability?

For more on this, I humbly point you to my 2014 post Should you use HTML5 header and footer?. A survey of screenreader users last year showed that 80% of respondents will use regions to navigate – but they can only do so if you choose to use them instead of wrapping everything in <div>s. Now you know they exist, why wouldn’t you use them?

Update: here’s a YouTube video of blind screenreader user Leonie Watson talking through how she navigates this site using the HTML semantics we’ve discussed.

YouTube video

New types of devices

We’re seeing more and more types of devices connecting to the web, and semantic HTML can help these devices display your content in a more usable way to their owners. And if your site is more usable than your competitors’, you win, and your boss will erect a massive gold statue of you in the office car park. (Trust me, your boss told me. They’ve already ordered the plinth.)

Let’s look at one example, the Apple Watch. Here are some screenshots and excerpts from the transcript of an Apple video introducing watchOS 5:

We’ve brought Reader to watchOS 5 where it automatically activates when following links to text heavy web pages. It’s important to ensure that Reader draws out the key parts of your web page by using semantic markup to reinforce the meaning and purpose of elements in the document. Let’s walk through an example. First, we indicate which parts of the page are the most important by wrapping it in an article tag.

diagram of an article element wrapping content on an Apple Watch

Specifically, enclosing these header elements inside the article ensure that they all appear in Reader. Reader also styles each header element differently depending on the value of its itemprop attribute. Using itemprop, we’re able to ensure that the author, publication date, title, and subheading are prominently featured.

Apple Watch diagram showing how it uses microdata attributes to layout and display information about an article

itemprop is an HTML5 microdata attribute. There are shared vocabularies documented at schema.org, which is founded by Google, Microsoft, Yahoo and Yandex. Using schema.org vocabularies with microdata can make your pages display better in search results:

Many applications from Google, Microsoft, Pinterest, Yandex and others already use these vocabularies to power rich, extensible experiences.

Update: Google published numbers on how using structured data boosts conversions.

(If you plan to put things into microdata, please note that Apple, being Apple, go their own way, and don’t use a schema.org vocabulary here. Le sigh. See my article Content needs a publication date! for more. Or view source on this page to see how I’m using microdata on this article.)

Apple WatchOS also optimises display of items wrapped in <figure> elements:

Reader recognizes these tags and preserves their semantic styles. For this image, we use figure and figcaption elements to let the Reader know that the image is associated with the below caption. Reader then positions the image alongside its caption.

Apple Watch diagram showing how it lays out figures and captions if appropriately marked up

You probably know that HTML5 greatly increased the number of different <input> types, for example <input type=”email”> on a mobile device shows a keyboard with the “@” symbol and “.” that are in all email addresses; <input type=”tel”> on a mobile device shows a numeric keypad.

On desktop browsers, where you have a physical keyboard, you may get different User Interface benefits, or built-in validation. You don’t need to build any of this; you simply choose the right semantic that best expresses the meaning of your content, and the browser will choose the best display, depending on the device it’s on.

In WatchOS, input types take up the whole watch screen, so choosing the correct one is highly desirable.

First, choose the appropriate type attribute and element tag for your form controls.
WebKit supports a variety of form control types including passwords, numeric and telephone fields, date, time, and select menus. Choosing the most relevant type attribute allows WebKit to present the most appropriate interface to handle user input.

Secondly, it’s important to note that unlike iOS and macOS, input methods on watchOS require full-screen interaction. Label your form controls or specify aria label or placeholder attributes to provide additional context in the status bar when a full-screen input view is presented.

Apple Watch showing different full-screen keyboards for different email types

I didn’t choose to use <article> and itemprop and input types because I wanted to support the Apple Watch; I did it before the Apple Watch existed, in order that my code is future-proof. By choosing the right semantics now, a machine that I don’t know about yet can understand my content and display it in the best way for its users. You are opting out of this if you only use <div> or <span> because, by definition, they have “no special meaning at all”.

Summary

I hope I’ve shown you that choosing the correct HTML isn’t purely an academic exercise. Perhaps you can’t use all the above (and there’s much more that I haven’t discussed) but when you can, please consider whether there’s an HTML element that you could use to describe parts of your content.

For instance, when building components that emit banners and logos, consider wrapping them in <header> rather than <div>. If your styling relies upon classnames, <header class=”header”> will work just as well as <div class=”header”>.

Semantic HTML will give usability benefits to many users, help to future-proof your work, potentially boost your search engine results, and help people with disabilities use your site.

And, best of all, thinking more about your HTML will stop Dull Old Web Farts like me moaning at you.

What’s not to love? Have a splendid holiday season, whatever you celebrate – and here’s to a semantic 2019!

More!

Notes on Google’s HTTPS Usage report

On Friday’s reading list I linked to Google’s HTTPS Usage report which said that

Secure web browsing through HTTPS is becoming the norm. Desktop users load more than half of the pages they view over HTTPS and spend two-thirds of their time on HTTPS pages. HTTPS is less prevalent on mobile devices, but we see an upward trend there, too.

(The report is undated, but as the data continues after October 2016, I assume it’s current. As an aside, please put dates on research and stats you publish!)

Erik Isaksen tweeted me asking “I’m wondering why ‘especially on desktop”. I replied with my speculations, reproduced here in longer form :

Despite the rise in mobile use, desktop numbers aren’t declining, and perhaps many people do as I do: I might search and compare products on my mobile, but I actually do the purchases on my desktop machine. It’s a lot easier to type on a full-sized keyboard than a virtual keyboard, and purchases on the web are still laborious. I doubt it’s just me; generally, users abandon mobile purchases twice as often as desktop purchases. (That figure is from Google’s tutorial on the Payment Request API. I’m eagerly awaiting completion of Opera’s implementation.)

Similarly, I never do online banking on my mobile, I always use my desktop machine which has a direct line into it. (Even though I know that my bank’s website is HTTPS. But when I visit my branch, I notice their internal systems are all using IE6…)

It’s also worth bearing in mind that many of the regions that are mobile-first are home to large populations of unbanked people, or populations who don’t use credit cards much. There’s a lot less imperative to offer local websites securely when there is no money changing hands through them, while the services that are popular everywhere (Gmail, Facebook etc) are already HTTPS.

I’m told that HTTPS is comparatively expensive for site owners in the developing economies, and advertising revenues are declining as more and more people use Ad-blockers: 36% of smartphone users in Asia-Pacific use ad-blockers; two-thirds of people in India and Indonesia (source) and statistics from Opera’s built-inn ad-blocker shows that Indonesia has the most ads blocked per person in the region.

I suppose the crux of my speculation is: do people perform different kinds of tasks on mobile and desktop? Some tasks – banking, purchasing – require more convoluted input and are thus more suited to desktop devices with a full-sized keyboard, and such tasks are performed on HTTPS sites.

But this is only speculation. Anyone have any hard data on why HTTPS is more prevalent on desktop than mobile?

8 November 2016: Amelia Bellamy-Royds suggested on Twitter “No hard data, but my guess: secure websites for social media, email, etc., are replaced by native apps on mobile.” This certainly maps to my own experience, as I used the Gmail and Twitter apps on Android.

On URLs in Progressive Web Apps

I’m writing this as a short commentary on Stuart Langridge’s post The Importance of URLs which you should read (he’s surprisingly clever, although he looks like the antichrist in that lewd hat).

Stuart says

I approve of the Lighthouse team’s idea that you don’t qualify as an add-to-home-screen-able app if you want a URL bar

Opera’s implementation of Progressive Web Apps differs from Chrome’s here (we only take the content layer of Chromium; we implement all the UI ourselves, precisely so we can do our own thing). Regardless of whether the developer has chosen display: standalone or display: fullscreen in order to hide the URL bar, Opera will display it if the app is served over HTTP because we think that the user should know exactly where she is if the app is served over an insecure connection. Similarly, if the user follows a link from your app that goes outside its domain, Opera spawns a new tab and forces display: browser so the URL bar is shown.

But I take Jeremy Keith’s point:

I want people to be able to copy URLs. I want people to be able to hack URLs. I’m not ashamed of my URLs …I’m downright proud.

One of the superpowers of the Web is URLs, and fullscreen progressive web apps hide them (deliberately). After our last PWA meeting with the Chrome team in early February, I was talking about just this with Andreas Bovens, the PM for Opera for Android. We mused about some mechanism (a new gesture?) that would allow the user to see and copy (if they want) the URL of the current page. I’ve already heard of examples when developers are making their own “share this” buttons — and devs re-implementing browser functionality is often a klaxon signalling something is missing from the platform.

When I mentioned our musings on Twitter this morning, Alex Russell said “we’ve been discussing the same.” It is, as Chrome chappie Owen Campbell-Moore said “a difficult UX problem indeed”, which is one reason that Andreas and I parked our discussion. One of Andreas’ ideas is long press on the current page, and then get an option to copy/share the URL of the page you’re currently viewing (this means that a long press is not available as an action for site owners to use on their sites. Probably not a big deal?)

What do you think? How can we best allow the user to see the current URL in a discoverable way?

web.next: Progressive Web Apps and Extensible Web

Here’s the keynote talk I did at Render Conference, Oxford in April. (Slides.)

All the other talks are available. Yay!

I told the nice organising types that I wouldn’t accept the speaker fee because public speaking is my job. Rather than just pocket the money, they suggested we donate it to a worthy cause, which is very good of them.

So I asked them to send it to a rural school in Cambodia, where a friend of mine has been volunteering. They’re building a computer lab to train kids and the local people. In one of the poorest countries on earth (average salary is $80/ month) a second hand laptop at $250 is still a luxury. As someone who was a primary teacher in Bangkok, this ticks all my personal boxes: education, S.E. Asia and the web.

Thank you, Ruth and all at Render Conference.

One weird trick to get online — designers hate it!

At the Google Progressive Web Apps afterparty last night, I had two very different conversations within five minutes of each other.

Conversation #1 went

Hey Bruce, lucky you weren’t at REDACTED conference last week. They were bad mouthing Opera! One speaker said, “Anyway, who cares about Opera Mini?”

In the time it took to drink another 5 bottles of free beer (two minutes), conversation #2 happened:

Oh Bruce, hi. We’ve just raised £100million in funding for our business in Asia, and 35% of our users are on Opera Mini.

What’s the difference? Well, for a start, one was apparently said by a European designer to a room full of European designers, in Europe. The second is the word “users”: the second conversation focussed on the fact that a technology is used by human beings, which is always, always the point.

Now, I don’t care about Opera Mini per se (I’m not its Product Manager). In the same way, I don’t care about walking sticks, wheelchairs, mobility scooters or guide dogs. But I care deeply about people who use enabling technologies — and Opera Mini is an enabling technology. It allows people on feature phones, low-powered smartphones, people in low-bandwidth areas, people with very small data plans, people who are roaming (you?) to connect to the web.

Sure, I get that Opera Mini can frustrate some designers and developers; your rounded corners, gradients and JavaScript-only APIs don’t work. But CSS isn’t content, and a progressively enhanced website will work (albeit more clunkily) with JavaScript throttled after 3 seconds. (I wrote Making websites that work well on Opera Mini if you want more information on how Mini works.)

I ran the stats today. Of more than 250 million Opera Mini users, 50% are on Android/iOS and 50% are on feature phones. The second group almost certainly have no choice in which browser to use to get a full web experience. That’s 125 million people that designer-on-stage doesn’t care about. People like Donald from Nigeria, people like Silma from Bangladesh. People.

The top territories for Opera Mini use are India, Indonesia, Nigeria, Bangladesh and South Africa. Because conversation #2 was about tangible stuff – millions of pounds, and numbers, let’s look at the economic growth of these nations full of interlopers to our WWW (Wealthy Western Web).

Country Population PPP Growth Rate
India 1,251,695,584 $6,300 7.3%
Indonesia 255,993,674 $11,300 4.7%
Bangladesh 168,957,745 $3,600 6.5%
Nigeria 181,562,056 $6,400 4%
South Africa 53,675,563 $13,400 1.4%

(PPP= Gross Domestic Product per Capita, figures from CIA World Fact Book)

Sure, those PPP numbers might be low compared with the home countries of designer-on-a-stage and audience, but how do the growth rates compare? These are dynamic, emerging markets. Who cared about China ten years ago?

If you don’t care about Opera Mini users in these areas, you can bet your competitors soon will.

Dear webdevs, from European Blind Union

Many of you lovely readers aren’t on Twitter 24/7, so heres’s a blog retweet. Or a “re-bleet” as I like to call it.

This was posted yesterday by the European Blind Union (“The voice of 30 million #blind and partially sighted people in Europe”)

In other words: yes, please use viewport meta to make content responsive. But don’t muck around with maximum-scale, minimum-scale, and user-scalable properties, as these restrict zooming.

Couldn’t be clearer, could it? We’ve been asked nicely, by those who are affected, so let’s not do it anymore.

Why we can’t do real responsive images with CSS or JavaScript

I’m writing a talk on <picture>, srcset and friends for Awwwards Conference in Barcelona next month (yes, I know this is unparalleled early preparation; I’m heading for the sunshine for 2 weeks soon). I decided that, before I get on to the main subject, I should address the question “why all this complex new markup? Why not just use CSS or JavaScript?” because it’s invariably asked.

But you might not be able to see me in Catalonia to find out, because tickets are nearly sold out. So here’s the answer.

All browsers have what’s called a preloader. As the browser is munching through the HTML – before it’s even started to construct a DOM – the preloader sees “<img>” and rushes off to fetch the resource before it’s even thought about speculating about considering doing anything about the CSS or JavaScript.

It does this to get images as fast as it can – after all, they can often be pretty big and are one of the things that boosts the perceived performance of a page dramatically. Steve Souders, head honcho of Velocity Conference, bloke who knows loads about site speed, and renowned poet called the preloader “the single biggest performance improvement browsers have ever made” in his sonnet “Shall I compare thee to a summer’s preloader, bae?”

So, by the time the browser gets around to dealing with CSS or script, it may very well have already grabbed an image – or at least downloaded a fair bit. If you try

<img id=thingy src=picture.png alt="a mankini">
…
@media all and (max-width:600px) {
 #thingy {content: url(medium-res.png);}
 }

@media all and (max-width:320px) {
 #thingy {content: url(low-res.png);}
 }

you’ll find the correct image is selected by the media query (assuming your browser supports content on simple selectors without :before or :after pseudo-elements) but you’ll find that the preloader has downloaded the resource pointed to by the <img src> and then the one that the CSS replaces it with is downloaded, too. So you get a double download which is not what you want at all.

Alternatively, you could have an <img> with no src attribute, and then add it in with JavaScript – but then you’re fetching the resource until much later, delaying the loading of the page. Because your browser won’t know the width and height of the image that the JS will select, it can’t leave room for it when laying out the page so you may find that your page gets reflowed and, if the user was reading some textual content, she might find the stuff she’s reading scrolls off the page.

So the only way to beat the preloader is to put all the potential image sources in the HTML and give the browser all the information it needs to make the selection there, too. That’s what the w and x descriptors in srcset are for, and the sizes attribute.

Of course, I’ll explain it with far more panache and mohawk in Barcelona. So why not come along? Go on, you know you want to and I really want to see you again. Because I love you.