If you’re using Apple’s VoiceOver, both your phone and your computer will broadcast your assumed disability to the entire internet, unless and until you specifically tell it to stop.
Thursday, April 11th, 2019
Thursday, April 4th, 2019
I also discussed this accessibility events feature with my friend who is a screen reader user herself. She said it feels like it’s a first step towards a well-meant digital apartheid.
Friday, February 1st, 2019
It’s interesting to compare the release notes for each browser and see the different priorities reflected in them (this is another reason why browser diversity is A Good Thing).
A lot of the Firefox changes are updates to dev tools; they just keep getting better and better. In fact, I’m not sure “dev tools” is the right word for them. With their focus on layout, typography, and accessibility, “design tools” might be a better term.
Oh, and Firefox is shipping support for some CSS properties that really help with print style sheets, so I’m disproportionately pleased about that.
In Safari’s changes, I’m pleased to see that the
datalist element is finally getting implemented. I’ve been a fan of that element for many years now. (Am I a dork for having favourite HTML elements? Or am I a dork for even having to ask that question?)
And, of course, it wouldn’t be a Safari release without a new made up
meta tag. From the people who brought you such hits as
apple-mobile-web-app-capable, comes …
supported-color-schemes (Apple likes to make up
meta tags almost as much as Google likes to make up
There’ll be a whole bunch of improvements in how progressive web apps will behave once they’ve been added to the home screen. We’ll finally get some state persistence if you navigate away from the window!
Updated the behavior of websites saved to the home screen on iOS to pause in the background instead of relaunching each time.
Maximiliano Firtman has a detailed list of the good, the bad, and the “not sure yet if good” for progressive web apps on iOS 12.2 beta. Thomas Steiner has also written up the progress of progressive web apps in iOS 12.2 beta. Both are published on Ev’s blog.
Chrome 72 for Android shipped the long-awaited Trusted Web Activity feature, which means we can now distribute PWAs in the Google Play Store!
Very interesting indeed! I’m not sure if I’m ready to face the Kafkaesque process of trying to add something to the Google Play Store just yet, but it’s great to know that I can. Combined with the improvements coming in iOS 12.2, these are exciting times for progressive web apps!
Friday, December 28th, 2018
Well, this an interesting format experiment—the latest Black Mirror just dropped, and it’s a PDF.
Tuesday, July 10th, 2018
Twitter and Instagram progressive web apps
The two major candidates are Twitter and Instagram. I added them to my home screen, and banished the native apps off to a separate screen. I’ve been using both progressive web apps for a few months now, and I have to say, they’re pretty darn great.
There are a few limitations compared to the native apps. On Twitter, if you follow a link from a tweet, it pops open in Safari, which is fine, but when you return to Twitter, it loads anew. This isn’t any fault of Twitter—this is the way that web apps have worked on iOS ever since they introduced their weird
web-app-capable meta element. I hope this behaviour will be fixed in a future update.
Also, until we get web notifications on iOS, I need to keep the Twitter native app around if I want to be notified of a direct message (the only notification I allow).
Apart from those two little issues though, Twitter Lite is on par with the native app.
Instagram is also pretty great. It too suffers from some navigation issues. If I click through to someone’s profile, and then return to the main feed, it also loads it anew, losing my place. It would be great if this could be fixed.
For some reason, the Instagram web app doesn’t allow uploading multiple photos …which is weird, because I can upload multiple photos on my own site by adding the
multiple attribute to the
input type="file" in my posting interface.
Apart from that, though, it works great. And as I never wanted notifications from Instagram anyway, the lack of web notifications doesn’t bother me at all. In fact, because the progressive web app doesn’t keep nagging me about enabling notifications, it’s a more pleasant experience overall.
Something else that was really annoying with the native app was the preponderance of advertisements. It was really getting out of hand.
Well …(looks around to make sure no one is listening)… don’t tell anyone, but the Instagram progressive web app—i.e. the website—doesn’t have any ads at all!
Here’s hoping it stays that way.
Tuesday, April 10th, 2018
It’s so great to see the initial UX work that James and I prototyped in a design sprint come to fruition in the form of a progressive web app!
In the case of this web-app, if the tablets go offline, they will still store all the transactions that are made by customers. Once the tablet comes back online, it will sync it back up to the server. That is, essentially, what a Progressive Web App is — a kind of a website with a few more security and, most importantly, offline features.
Friday, March 9th, 2018
We hoped for a bicycle for the mind; we got a Lazy Boy recliner for the mind.
Nicky Case on how Douglas Engelbart’s vision for human-computer augmentation has taken a turn from creation to consumption.
When you create a Human+AI team, the hard part isn’t the “AI”. It isn’t even the “Human”.
It’s the “+”.
Thursday, January 25th, 2018
Squee! The next time there’s an update for OS X and iOS, Safari will magically have service worker support! Not only that, but Safari on iOS will start using the information in web app manifests for adding to home screen.
That’s an impressive turnaround.
Sunday, January 14th, 2018
An initiative by David Brin and the Arthur C. Clarke Center For Human Imagination at UC San Diego. You are confronted with a what-if scenario, and your task is to recall any works of speculative fiction that have covered it.
Accessing more than a hundred years of science fiction thought experiments, TASAT taps into a passionate, global community of writers, scholars, librarians, and fans. We aim to curate a reading list applicable to problems and possibilities of tomorrow.
Thursday, November 2nd, 2017
The slides from Yesenia’s talk on scenario-driven design.
Monday, October 9th, 2017
This is such a strange announcement from Microsoft. It’s worded as though they chose to use the WebKit engine on iOS. But there is no choice: if you want to put a browser on iOS, you must use the WKWebView control. Apple won’t allow any other rendering engine (that’s why Chrome on iOS is basically a skin for Safari; same for Opera on iOS). It’s a disgraceful monopolistic policy on Apple’s part.
A word to the Microsoft marketing department: please don’t try to polish the turd in the shit sandwich you’ve been handed by Apple.
Saturday, October 7th, 2017
I’ve written before about how I use apps on my phone:
If I install an app on my phone, the first thing I do is switch off all notifications. That saves battery life and sanity.
The only time my phone is allowed to ask for my attention is for phone calls, SMS, or FaceTime (all rare occurrences). I initiate every other interaction—Twitter, Instagram, Foursquare, the web. My phone is a tool that I control, not the other way around.
To me, this seems like a perfectly sensible thing to do. I was surprised by how others thought it was radical and extreme.
I’m always shocked when I’m out and about with someone who has their phone set up to notify them of any activity—a mention on Twitter, a comment on Instagram, or worst of all, an email. The thought of receiving a notification upon receipt of an email gives me the shivers. Allowing those kinds of notifications would feel like putting shackles on my time and attention. Instead, I think I’m applying an old-school RSS mindset to app usage: pull rather than push.
Don’t get me wrong: I use apps on my phone all the time: Twitter, Instagram, Swarm (though not email, except in direst emergency). Even without enabling notifications, I still have to fight the urge to fiddle with my phone—to check to see if anything interesting is happening. I’d like to think I’m in control of my phone usage, but I’m not sure that’s entirely true. But I do know that my behaviour would be a lot, lot worse if notifications were enabled.
I was a bit horrified when Apple decided to port this notification model to the desktop. There doesn’t seem to be any way of removing the “notification tray” altogether, but I can at least go into System Preferences and make sure that absolutely nothing is allowed to pop up an alert while I’m trying to accomplish some other task.
It’s the same on iOS—you can control notifications from Settings—but there’s an added layer within the apps themselves. If you have notifications disabled, the apps encourage you to enable them. That’s fine …at first. Being told that I could and should enable notifications is a perfectly reasonable part of the onboarding process. But with some apps I’m told that I should enable notifications Every. Single. Time.
Of the apps I use, Instagram and Swarm are the worst offenders (I don’t have Facebook or Snapchat installed so I don’t know whether they’re as pushy). This behaviour seems to have worsened recently. The needling has been dialed up in recent updates to the apps. It doesn’t matter how often I dismiss the dialogue, it reappears the next time I open the app.
In the grand scheme of things, it’s not a big deal, but I would appreciate some respect for my deliberate choice. It gets pretty wearying over the long haul. To use a completely inappropriate analogy, it’s like a recovering alcoholic constantly having to rebuff “friends” asking if they’re absolutely sure they don’t want a drink.
I don’t think there’s malice at work here. I think it’s just that I’m an edge-case scenario. They’ve thought about the situation where someone doesn’t have notifications enabled, and they’ve come up with a reasonable solution: encourage that person to enable notifications. After all, who wouldn’t want notifications? That question, if it’s asked at all, is only asked rhetorically.
I’m trying to do the healthy thing here (or at least the healthier thing) in being mindful of my app usage. They sure aren’t making it easy.
The model that web browsers use for notifications seems quite sensible in comparison. If you arrive on a site that asks for permission to send you notifications (without even taking you out to dinner first) then you have three options: allow, block, or dismiss. If you choose “block”, that site will never be able to ask that browser for permission to enable notifications. Ever. (Oh, how I wish I could apply that browser functionality to all those sites asking me to sign up for their newsletter!)
That must seem like the stuff of nightmares for growth-hacking disruptive startups looking to make their graphs go up and to the right, but it’s a wonderful example of truly user-centred design. In that situation, the browser truly feels like a user agent.
Saturday, September 23rd, 2017
This could be a one-word article: don’t.
More specifically, don’t design websites for any specific device. That way lies pain (and it is not the way of the web).
But read on for a textbook example of how not to introduce new CSS properties. Apple proposed the new syntax that they’re shipping. Now it’s getting standardised …with a different name. So basically Apple are shipping the equivalent of a vendor-prefixed property without the vendor prefix.
Thursday, September 21st, 2017
One more reason not to use sticky headers on mobile.
Sunday, June 25th, 2017
Bram hopes for a way to define aspect ratios natively in CSS. We can sort of manage it now, but all the solutions are pretty hacky.
Wednesday, May 31st, 2017
My argument is relatively simple: creating a comprehensive styling mechanism for building complex user interfaces is startlingly hard, and every alternative to CSS is much worse. Like, it’s not even close.
Saturday, October 8th, 2016
Finally! Apple are being sued for refusing to allow any non-Webkit browsers to be installed on iOS.
I’m not usually in favour of legal action but in this case, there doesn’t seem to be any other recourse.
We would be delighted at Nexedi to create a Web browser for iOS with better HTML5 support based on a recent version of Blink library for example. But as soon as we would publish it, it would be banned from Apple’s AppStore. Many developers have experienced this situation already. Many companies are being hurt by this situation. Some companies have already begged Apple to improve HTML5 support in iOS with little significant results.
Wednesday, June 29th, 2016
Colin pointed out this interesting perspective from an iOS developer moving to the web:
My work for the last few years has been on the web, and honestly, it’s a breath of fresh air. Instant refreshing, surprisingly good debugging / perf tools, intrinsically multi-platform, and most importantly, open.
Web tech gets a lot of shit from native devs (some of it deserved). But the alternatives are worse. I find the entire concept of App Review morally questionable despite Apple’s good intentions. So I sleep better at night not being part of that anymore. Sure, the web is messy, and it’s delicate, but it’s important and good and getting better fast.
Sunday, June 12th, 2016