The slides from Yesenia’s talk on scenario-driven design.
Thursday, November 2nd, 2017
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
Tuesday, May 31st, 2016
So remember when I was talking about “the ends justify the means” being used for unwise short-term decisions? Here’s a classic example. Chris thinks that Progressive Web Apps should be made mobile-only (at least to start with …something something something the future):
For now, PWAs need to be the solution for the next mobile users.
End users deserve to have an amazing, form-factor specific experience.
I couldn’t disagree more. End users deserve to have an amazing experience no matter the form-factor of their device.
Wednesday, April 6th, 2016
While many challenges remain, the good news is … it’s progressive. Developers can already see the benefits by sprinkling in these technologies to their existing websites and proceed to build on them as browsers and operating systems increase support.
Monday, January 11th, 2016
When I wrote about mobile Safari adding support for
touch-action: manipulation, I finished with this snarky observation:
Anyway, I’m off to update my CSS even though this latest fix probably won’t land in mobile Safari until, oh ….probably next October.
Historically, Apple have tied mobile Safari updates to iOS version number increments, and they happen about once a year. But this time, it looks like my snark was unfounded:
On Safari for iOS, the 350 ms wait time to detect a second tap has been removed to create a “fast-tap” response. This is enabled for pages that declare a viewport with either width=device-width or user-scalable=no. Authors can also opt in to fast-tap behavior on specific elements by using the CSS touch-action property, using the manipulation value.
That’s from the release notes for Safari 9.1—a point release.
I’m very pleased to have been absolutely wrong with my prediction of Apple’s timing.
Wednesday, December 16th, 2015
This solution to the mobile tap delay by the WebKit team sounds like what I was hoping for:
touch-action: manipulation;on a clickable element makes WebKit consider touches that begin on the element only for the purposes of panning and pinching to zoom. This means WebKit does not consider double-tap gestures on the element, so single taps are dispatched immediately.
It would be nice to know whether this has been discussed with other browser makers or if it’s another proprietary addition.
Sunday, November 29th, 2015
Apple offers its users the power to turn off much of the Web: fonts, styles, scripts, and more.
He rightly points out that the answer to building a robust, resilient web has been here all along:
Tuesday, November 17th, 2015
Brighton device lab
People of Brighton (and environs), I have a reminder for you. Did you know that there is an open device lab in the Clearleft office?
That’s right! You can simply pop in at any time and test your websites on Android, iOS, Windows Phone, Blackberry, Kindles, and more.
The address is 68 Middle Street. Ring the “Clearleft” buzzer and say you’re there to use the device lab.. There’ll always be somebody in the office. They’ll buzz you in and you can take the lift to the first floor. No need to make a prior appointment—feel free to swing by whenever you like.
There is no catch. You show up, test your sites on whatever devices you want, and maybe even stick around for a cup of tea.
Tell your friends.
I was doing a little testing this morning, helping Charlotte with a pesky bug that was cropping up on an iPad running iOS 8. To get the bottom of the issue, I needed to be able to inspect the DOM on the iPad. That turns out to be fairly straightforward (as of iOS 6):
- Plug the device into a USB port on your laptop using a lightning cable.
- Open Safari on the device and navigate to the page you want to test.
- Open Safari on your laptop.
- From the “Develop” menu in your laptop’s Safari, select the device.
- Use the web inspector on your laptop’s Safari to inspect elements to your heart’s content.
It’s a similar flow for Android devices:
- Plug the device into a USB port on your laptop.
- Open Chrome on the device and navigate to the page you want to test.
- Open Chrome on your laptop.
chrome://inspectinto the URL bar of Chrome on your laptop.
- Select the device.
- On the device, grant permission (a dialogue will have appeared by now).
- Use developer tools on your laptop’s Chrome to inspect elements to your heart’s content.
Tuesday, March 17th, 2015
A walkthrough on using the iOS app Workflow to huffduff audio files from just about any app.
Friday, January 9th, 2015
I’ve spoken at quite a few events over the last few years (2014 was a particularly busy year). Many—in fact, most—of those events were overseas. Quite a few were across the atlantic ocean, so I’ve partaken of quite a few transatlantic flights.
Most of the time, I’d fly British Airways. They generally have direct flights to most of the US destinations where those speaking engagements were happening. This means that I racked up quite a lot of frequent-flyer miles, or as British Airways labels them, “avios.”
Frequent-flyer miles were doing gamification before gamification was even a thing. You’re lured into racking up your count, even though it’s basically a meaningless number. With BA, for example, after I’d accumulated a hefty balance of avios points, I figured I’d try to the use them to pay for an upcoming flight. No dice. You can increase your avios score all you like; when it actually comes to spending them, computer says “no.”
So my frequent-flyer miles were basically like bitcoins—in one sense, I had accumulated all this wealth, but in another sense, it was utterly worthless.
(I’m well aware of just how first-world-problemy this sounds: “Oh, it’s simply frightful how inconvenient it is for one to spend one’s air miles these days!”)
Early in 2014, I decided to flip it on its head. Instead of waiting until I needed to fly somewhere and then trying to spend my miles to get there (which never worked), I instead looked at where I could possibly get to, given my stash of avios points. The BA website was able to tell me, “hey, you can fly to Japan and back …if you travel in the off-season …in about eight months’ time.”
Alrighty, then. Let’s do that.
Now, even if you can book a flight using avios points, you still have to pay all the taxes and surcharges for the flight (death and taxes remain the only certainties). The taxes for two people to fly from London to Tokyo and back are not inconsiderable.
But here’s the interesting bit: the taxes are a fixed charge; they don’t vary according to what class you’re travelling. So when I was booking the flight, I was basically presented with the option to spend X amount of unspendable imaginary currency to fly economy, or more of unspendable imaginary currency to fly business class, or even more of the same unspendable imaginary currency to fly—get this—first class!
Hmmm …well, let me think about that decision for almost no discernible length of time. Of course I’m going to use as many of those avios points as I can! After all, what’s the point of holding on to them—it’s not like they’re of any use.
The end result is that tomorrow, myself and Jessica are going to fly from Heathrow to Narita …and we’re going to travel in the first class cabin! Squee!
Not only that, but it turns out that there are other things you can spend your avios points on after all. One of those things is hotel rooms. So we’ve managed to spend even more of the remaining meaningless balance of imaginary currency on some really nice hotels in Tokyo.
We’ll be in Japan for just over a week. We’ll start in Tokyo, head down to Kyoto, do a day trip to Mount Kōya, and then end up back in Tokyo.
We are both ridiculously excited about this trip. I’m actually going somewhere overseas that doesn’t involve speaking at a conference—imagine that!
There’s so much to look forward to—Sushi! Ramen! Yakitori!
And all it cost us was a depletion of an arbitrary number of points in a made-up scoring mechanism.
Wednesday, December 17th, 2014
Curiosity’s journey so far, nicely visualised.