Journal tags: hardware

I was chatting with my new colleague Alex yesterday about a link she had shared in Slack. It was the Nielsen Norman Group’s annual State of Mobile User Experience report.

There’s nothing too surprising in there, other than the mention of Apple’s app clips and Google’s instant apps.

Remember those?

Me neither.

Perhaps I lead a sheltered existence, but as an iPhone user, I don’t think I’ve come across a single app clip in the wild.

I remember when they were announced. I was quite worried about them.

See, the one thing that the web can (theoretically) offer that native can’t is instant access to a resource. Go to this URL—that’s it. Whereas for a native app, the flow is: go to this app store, find the app, download the app.

(I say that the benefit is theoretical because the website found at the URL should download quickly—the reality is that the bloat of “modern” web development imperils that advantage.)

App clips—and instant apps—looked like a way to route around the convoluted install process of native apps. That’s why I was nervous when they were announced. They sounded like a threat to the web.

In reality, the potential was never fulfilled (if my own experience is anything to go by). I wonder why people didn’t jump on app clips and instant apps?

Perhaps it’s because what they promise isn’t desirable from a business perspective: “here’s a way for users to accomplish their tasks without downloading your app.” Even though app clips can in theory be a stepping stone to installing the full app, from a user’s perspective, their appeal is the exact opposite.

Or maybe they’re just too confusing to understand. I think there’s an another technology that suffers from the same problem: progressive web apps.

Hear me out. Progressive web apps are—if done well—absolutely amazing. You get all of the benefits of native apps in terms of UX—they even work offline!—but you retain the web’s frictionless access model: go to a URL; that’s it.

So what are they? Are they websites? Yes, sorta. Are they apps? Yes, sorta.

That’s confusing, right? I can see how app clips and instant apps sound equally confusing: “you can use them straight away, like going to a web page, but they’re not web pages; they’re little bits of apps.”

I’m mostly glad that app clips never took off. But I’m sad that progressive web apps haven’t taken off more. I suspect that their fates are intertwined. Neither suffer from technical limitations. The problem they both face is inertia:

The technologies are the easy bit. Getting people to re-evaluate their opinions about technologies? That’s the hard part.

True of progressive web apps. Equally true of app clips.

But when I was chatting to Alex, she made me look at app clips in a different way. She described a situation where somebody might need to interact with some kind of NFC beacon from their phone. Web NFC isn’t supported in many browsers yet, so you can’t rely on that. But you don’t want to make people download a native app just to have a quick interaction. In theory, an app clip—or instant app—could do the job.

In that situation, app clips aren’t a danger to the web—they’re polyfills for hardware APIs that the web doesn’t yet support!

I love having my perspective shifted like that.

The specific situations that Alex and I were discussing were in the context of museums. Musuems offer such interesting opportunities for the physical and the digital to intersect.

Remember the pen from Cooper Hewitt? Aaron spoke about it at dConstruct 2014—a terrific presentation that’s well worth revisiting and absorbing.

The other dConstruct talk that’s very relevant to this liminal space between the web and native apps is the 2012 talk from Scott Jenson. I always thought the physical web initiative had a lot of promise, but it may have been ahead of its time.

I loved the thinking behind the physical web beacons. They were deliberately dumb, much like the internet itself. All they did was broadcast a URL. That’s it. All the smarts were to be found at the URL itself. That meant a service could get smarter over time. It’s a lot easier to update a website than swap out a piece of hardware.

But any kind of technology that uses Bluetooth, NFC, or other wireless technology has to get over the discovery problem. They’re invisible technologies, so by default, people don’t know they’re even there. But if you make them too discoverable— intrusively announcing themselves like one of the commercials in Minority Report—then they’re indistinguishable from spam. There’s a sweet spot of discoverability right in the middle that’s hard to get right.

Over the past couple of years—accelerated by the physical distancing necessitated by The Situation—QR codes stepped up to the plate.

They still suffer from some discoverability issues. They’re not human-readable, so you can’t be entirely sure that the URL you’re going to go to isn’t going to be a Rick Astley video. But they are visible, which gives them an advantage over hidden wireless technologies.

They’re cheaper too. Printing a QR code sticker costs less than getting a plastic beacon shipped from China.

QR codes turned out to be just good enough to bridge the gap between the physical and digital for those one-off interactions like dining outdoors during a pandemic:

I can see why they chose the web over a native app. Online ordering is the only way to place your order at this place. Telling people “You have to go to this website” …that seems reasonable. But telling people “You have to download this app” …that’s too much friction.

Ironically, the nail in the coffin for app clips and instant apps might’ve been hammered in by Apple and Google when they built QR-code recognition into their camera software.

I was listening to some items in my Huffduffer feed when I noticed a little bit of synchronicity.

First of all, I was listening to Tom talking about Thington, and he mentioned seamful design—the idea that “seamlessness” is not necessarily a desirable quality. I think that’s certainly true in the world of connected devices.

Then I listened to Jeff interviewing Matt about hardware startups. They didn’t mention seamful design specifically (it was more all cricket and cables), but again, I think it’s a topic that’s lurking behind any discussion of the internet of things.

I’ve written about seams before. I really feel there’s value—and empowerment—in exposing the points of connection in a system. When designers attempt to airbrush those seams away, I worry that they are moving from “Don’t make me think” to “Don’t allow me to think”.

In many ways, aiming for seamlessness in design feels like the easy way out. It’s a surface-level approach that literally glosses over any deeper problems. I think it might be driven my an underlying assumption that seams are, by definition, ugly. Certainly there are plenty of daily experiences where the seams are noticeable and frustrating. But I don’t think it needs to be this way. The real design challenge is to make those seams beautiful.

Last year Benedict Evans wrote about the worldwide proliferation and growth of smartphones. Nolan referenced that post when he extrapolated the kind of experience people will be having:

As Benedict Evans has noted, the next billion people who are poised to come online will be using the internet almost exclusively through smartphones. And if Google’s plans with Android One are any indication, then we have a fairly good idea of what kind of devices the “next billion” will be using:

• They’ll mostly be running Android.
• They’ll have decent specs (1GB RAM, quad-core processors).
• They’ll have an evergreen browser and WebView (Android 5+).
• What they won’t have, however, is a reliable internet connection.

This is the same argument that Tom made in his presentation at Responsive Field Day. The main point is that network conditions are unreliable, and I absolutely agree that we need to be very, very mindful of that. But I’m not so sure about the other conditions either. They smell like assumptions:

Assumptions are the problem. Whether it’s assumptions about screen size, assumptions about being able-bodied, assumptions about network connectivity, or assumptions about browser capabilities, I don’t think any assumptions are a safe bet. Now you might quite reasonably say that we have to make some assumptions when we’re building on the web, and you’d be right. But I think we should still aim to keep them to a minimum.

It’s not necessarily true that all those new web users will be running WebView browser like Chrome—there are millions of Opera Mini users, and I would expect that number to rise, given all the speed and cost benefits that proxy browsing brings.

I also don’t think that just because a device is a smartphone it necessarily means that it’s a pocket supercomputer. It might seem like a reasonable assumption to make, given the specs of even a low-end smartphone, but the specs don’t tell the whole story.

Alex gave a great presentation at the recent Polymer Summit. He dives deep into exactly how smartphones at the lower end of the market deal with websites.

I don’t normally enjoy listening to talk of hardware and specs, but Alex makes the topic very compelling by tying it directly to how we build websites. In short, we’re using waaaaay too much JavaScript. The message here is not “don’t use JavaScript” but rather “use JavaScript wisely.” Alas, many of the current crop of monolithic frameworks aren’t well suited to this.

Alex’s talk prompted Michael Scharnagl to take a look back at past assumptions and lessons learned on the web, from responsive design to progressive web apps.

We are consistently improving and we often have to realize that our assumptions are wrong.

This is particularly true when we’re making assumptions about how people will access the web.

It’s not enough to talk about the “next billion” in abstract, like an opportunity to reach teeming masses of people ripe for monetization. We need to understand their lives and their priorities with the sort of detail that can build empathy for other people living under vastly different circumstances.

That’s from an article Ethan linked to, noting:

When I read articles defining “the mobile web” as “decent hardware and evergreen browsers”, I start thinking hard about our industry biases.

— Ethan Marcotte (@beep) October 13, 2016

Most pundits call it “the Internet of Things” but there’s another phrase from Andy Huntington that I first heard from Russell Davies: “the Geocities of Things.” I like that.

I’ve never had much exposure to this world of hacking electronics. I remember getting excited about the possibilities at a Brighton BarCamp back in 2008:

I now have my own little arduino kit, a bread board and a lucky bag of LEDs. Alas, know next to nothing about basic electronics so I’m really going to have to brush up on this stuff.

I never did do any brushing up. But that all changed last week.

Seb is doing a new two-day workshop. He doesn’t call it Internet Of Things. He doesn’t call it Geocities Of Things. He calls it Stuff That Talks To The Interwebs, or STTTTI, or ST4I. He needed some guinea pigs to test his workshop material on, so Clearleft volunteered as tribute.

In short, it was great! And this time, I didn’t stop hacking when I got home.

First off, every workshop attendee gets a hand-picked box of goodies to play with and keep: an arduino mega, a wifi shield, sensors, screens, motors, lights, you name it. That’s the hardware side of things. There are also code samples and libraries that Seb has prepared in advance.

Now, remember, I lack even the most basic knowledge of electronics, but after two days of fiddling with this stuff, it started to click.

On the first workshop day, we all did the same exercises, connected things up, getting them to talk to the internet, that kind of thing. For the second workshop day, Seb encouraged us to think about what we might each like to build.

I was quite taken with the ability of the piezo buzzer to play rudimentary music. I started to wonder if there was a way to hook it up to The Session and have it play the latest jigs, reels, and hornpipes that have been submitted to the site in ABC notation. A little bit of googling revealed that someone had already taken a stab at writing an ABC parser for arduino. I didn’t end up using that code, but it convinced me that what I was trying to do wasn’t crazy.

So I built a machine that plays Irish traditional music from the internet.

The hardware has a piezo buzzer, an “on” button, an “off” button, a knob for controlling the speed of the tune, and an obligatory LED.

The software has a countdown timer that polls a URL every minute or so. The URL is http://tune.adactio.com/. That in turn uses The Session’s read-only API to grab the latest tune activity and then get the ABC notation for whichever tune is at the top of that list. Then it does some cleaning up—removing some of the more advanced ABC stuff—and outputs a single line of notes to be played. I’m fudging things a bit: the device has the range of a tin whistle, and expects tunes to be in the key of D or G, but seeing as that’s at least 90% of Irish traditional music, it’s good enough.

Whenever there’s a new tune, it plays it. Or you can hit the satisfying “on” button to manually play back the latest tune (and yes, you can hit the equally satisfying “off” button to stop it). Being able to adjust the playback speed with a twiddly knob turns out to be particularly handy if you decide to learn the tune.

I added one more lo-fi modification. I rolled up a piece of paper and placed it over the piezo buzzer to amplify the sound. It works surprisingly well. It’s loud!

I’ll keep tinkering with it. It’s fun. I realise I’m coming to this whole hardware-hacking thing very late, but I get it now: it really does feel similar to that feeling you would get when you first figured out how to make a web page back in the days of Geocities. I’ve built something that’s completely pointless for most people, but has special meaning for me. It’s ugly, and it’s inefficient, but it works. And that’s a great feeling.

(P.S. Seb will be running his workshop again on the 3rd and 4th of February, and there will a limited amount of early-bird tickets available for one hour, between 11am and midday this Thursday. I highly recommend you grab one.)

We’ve had an internship programme at Clearleft for a few years now, and it has served us in good stead. Without it, we never would have had the pleasure of working with Emil, Jon, Anna, Shannon, and other lovely, lovely people. Crucially, it has always been a paid position: I can’t help but feel a certain level of disgust for companies that treat interns as a source of free manual labour.

For the most recent internship round, Andy wanted to try something a bit different. He’s written about it on the Clearleft blog:

So this year we decided to try a different approach by scouring the end of year degree shows for hot new talent. We found them not in the interaction courses as we’d expected, but from the worlds of Product Design, Digital Design and Robotics. We assembled a team of three interns , with a range of complementary skills, gave them a space on the mezzanine floor of our new building, and set them a high level brief to create a product that turned an active digital behaviour into a passive one.

The three interns were Killian, Zassa, and Victor—thoroughly lovely chaps all. It was fun having them in the office—and at Hackfarm—especially as they were often dealing with technologies beyond our usual ken: hardware hacking, and the like. They gave us weekly updates, and we gave them feedback and criticism; a sort of weekly swoop’n’poop on all the work they had been doing.

It was fascinating to watch the design process unfold, without directly being a part of it. At the end of their internship, they unveiled Chüne. They describe it as:

…a playful social music service that intelligently curates playlists depending on who is around, and how much fun they’re having.

They specced it out, built a prototype, and walked us through the interactions involved. It’s a really nice piece of work.

You can read more about it around the web:

• An Ingeniously Designed Speaker That Creates Crowdsourced Playlists on Wired.
• Social Radio : Let’s Talk about Chüne with Victor Johansson on The Globe’s Finest Treasures.

Victor has written about the experience from his perspective, concluding:

Clearleft is by far the nicest company and working environment I have come across. All I can say is, if you are thinking about applying for next years internship programme, then DO IT, and if you aren’t thinking about it, well maybe you should start thinking!

Aw, isn’t that nice?

One of the great pleasures of putting on Brighton SF right before last year’s dConstruct was how it allowed me to mash up two of my favourite worlds: the web and science fiction (although I don’t believe they’re that far removed from one another). One day I’m interviewing Jeff Noon about his latest book; the next, I’m introducing Tom Armitage on stage at the Brighton Dome.

Those two have since been collaborating on a new project.

You may have seen Jeff’s microspores—a collection of tweet-sized texts, each one an individual seed for a sci-fi story. Here’s Spore #50:

After the Babel Towers attack, lo-fi operators worked the edges of the language, forging new phrases from the fragments of literature. They filled boxes with word shards in the hope of recreating lost stories.

Tom has taken that as the starting point for creating a machine called the literary operator

It’s quite beautiful. It fits inside a suitcase. It has an LED interface. It has a puck that nestles into the palm of your hand. It comes with a collection of books. You take the puck in your hand, pass it over the spine of one of the books, and wait for the LEDs to change. Then you will receive a snippet of reconstructed text, generated Markov-style from the book.

As Tom says:

It is an object that is both entirely fictional, and entirely real. Not “design fiction”; just fiction.

You can use/play with the literary operator—and hear from Tom and Jeff—this Thursday evening, September 26th at the Brighton Museum as part of Digital Late. Sarah and Chris are also on the bill so don’t miss it: tickets are a fiver if you book ahead of time.

While I was compering dConstruct, I interspersed the between-talk banter with information about some of the events taking place under the banner of the Brighton Digital Festival. It’s a busy month, to put it mildly.

The day after dConstruct, Brighton played host to a Mini Maker Faire in the foyer of the Brighton Dome. I went along in the morning to check it out and MY HEAD ASPLODE!

It was splendid. So much creativity, so much fun and so many lovingly-crafted gadgets, all under one roof. It was immensely popular too. The crowds didn’t let up all day. I hope that the next time there’s a Maker Faire in Brighton—‘cause it should definitely happen again—that it can take place in a bigger venue (like the Corn Exchange) so that we call all geek out in comfort together.

I commend Emily and all of the other organisers. Top job, hardware hackers, top job.

Like many others, I was the grateful recipient of a Kindle this Christmas. I’m enjoying having such a lightweight reading device and I’m really enjoying the near-ubiquitous free connectivity that comes with the 3G version.

I can’t quite bring myself to go on a spending spree for overpriced DRM’d books with shoddy layout and character encoding, so I’ve been getting into the swing of things with the freely-available works of Cory Doctorow. I thoroughly enjoyed For The Win—actually, I read that one on my iPod Touch—and I just finished Makers on the Kindle.

The plot rambles somewhat but it’s still an entertaining near-future scenario of hardware hackers creating and destroying entire business models through the ever-decreasing cost and ever-increasing power of street-level technology.

Cracking open the case of a particularly convincing handset, he offers advice on identifying a fake: a hologram stuck on the phone’s battery is usually a good indication that the product is genuine. Two minutes later, Chipchase approaches another stall. The shopkeeper, a middle-aged woman, leans forward and offers an enormous roll of hologram stickers.

Chipchase, mouth agape, takes out the Canon 5D camera that he uses to catalogue almost everything he sees. “What are these for?” he asks, firing off a dozen photographs in quick succession. “You stick them on batteries to make them look real,” she says, with a shrug. Chipchase smiles, revelling in the discovery. “I love this!” he yelps in delight, and thanks the shopkeeper before heading off to examine the next stall.

That isn’t a passage from Makers. That’s from a Wired magazine article by Bobbie: a profile of Jan Chipchase and his predilection for Shanzai; counterfeit electronic goods on the streets of Shanghai …not unlike the Bambook Kindle clone.