File over app — Steph Ango
In the fullness of time, the files you create are more important than the tools you use to create them. Apps are ephemeral, but your files have a chance to last.
In the fullness of time, the files you create are more important than the tools you use to create them. Apps are ephemeral, but your files have a chance to last.
A false sense of security persists surrounding digitized documents: because an infinite number of identical copies can be made of any original, most of us believe that our electronic files have an indefinite shelf life and unlimited retrieval opportunities. In fact, preserving the world’s online content is an increasing concern, particularly as file formats (and the hardware and software used to run them) become scarce, inaccessible, or antiquated, technologies evolve, and data decays. Without constant maintenance and management, most digital information will be lost in just a few decades. Our modern records are far from permanent.
Years before becoming Prime Minister of the UK, Rishi Sunak wrote this report, Undersea Cables: Indispensable, insecure.
Time capsules on the moon, using NanoFiche as the storage medium.
Last week Phil posted a little update about his excellent site, ooh.directory:
If you’re in the habit of visiting the Recently Updated Blogs page, and leaving it open, the times when each blog was updated will now keep up with the relentless passing of time.
Does that make sense? “3 minutes ago” will change to “4 minutes ago” and so on and on and on, until you refresh the page.
I thought that was a nice little addition, and I immediately thought of The Session. There are time
elements all over the site with relative times as the text content: 2 minutes ago, 7 hours ago, 1 year ago, and so on. Those strings of text are generated on the server. But I figured it would be nice enhancement to periodically update them in the browser after the page has loaded.
I viewed source to see how Phil was doing it. The code is nice and short, using a library called Day.js with a plug-in for relative time.
“Hang on”, I thought, “isn’t there some web standard for doing this kind of thing?” I had a vague memory of some JavaScript API for formatting dates and times.
Sure enough, we’ve now got the Intl.RelativeTimeFormat
object. It’s got browser support across the board.
I’ve got a function that loops through all the time
elements with datetime
attributes. It compares the current timestamp to that value to get the elapsed time. Then that’s formatted using the format()
method and output as innerText
.
You need to tell the format()
method which units you want to use: seconds, minutes, hours, days, etc. So there’s a little bit of looping to figure out which unit is most appropriate. If the elapsed time is less than a minute, use seconds. If the elapsed time is less than an hour, use minutes. If the elapsed time is less than a day, use hours. You get the idea.
It’s a pity there isn’t some kind of magic unit like “auto” to do this, but it’s not much extra code to figure it out.
Anyway, that function runs periodically using setInterval()
. I’ve set it to run every 30 seconds in my gist. On The Session I’ve set it to one minute.
You’ll notice that I’m grabbing all the relevant time
elements—using document.querySelector('time[datetime]')
—every time the function is run. That may seem inefficient. Couldn’t I just grab them once and then keep them stored as an array? But I want this to work even if the page contents have been updated with Ajax. (Do people even say “Ajax” any more? Get off my lawn, you pesky kids!)
I think I’ve written this code in an abstract way so that you should be able to drop it into any web page. For the calculations to work, you’ll need to either make sure that your datetime
attributes are using timezones. Or, if there’s no timezone info, UTC is assumed.
This was a fun little piece of functionality to play around with. Now I know a little more about this Intl.RelativeTimeFormat
object. The way I’m using it as a classic example of progressive enhancement. If a browser doesn’t support it, or if my code breaks, it’s no big deal. The funtionality is a little bonus that almost nobody will notice anyway. Just a small delighter …if you’re the kind of person who finds it delightful when relative time strings automatically update.
AMP succeeded spectacularly. Then it failed. And to anyone looking for a reason not to trust the biggest company on the internet, AMP’s story contains all the evidence you’ll ever need.
This is a really good oral history of how AMP soured Google’s reputation.
Full disclosure: I’m briefly cited:
“When it suited them, it was open-source,” says Jeremy Keith, a web developer and a former member of AMP’s advisory council. “But whenever there were any questions about direction and control… it was Google’s.”
As an aside, this article contains a perfect description of the company cultures of Facebook, Apple, and Google:
“You meet with a Facebook person and you see in their eyes they’re psychotic,” says one media executive who’s dealt with all the major platforms. “The Apple person kind of listens but then does what it wants to do. The Google person honestly thinks what they’re doing is the best thing.”
Spot. On.
Ahmad runs through some of the scenarios where text-wrap: balance
could be handy.
Even though it’s not well-supported yet in browsers, there’s no reason not to start adding it to sites now; it’s classic progressive enhancement.
A new organisation with the stated goal of keeping podcasting open.
Their first specification is a consolidation of what already exists. That’s good. We don’t want a 927 situation.
My only worry is that many of the companies behind this initiative are focused on metrics and monetization—I hope they don’t attempt to standardise tracking and surveillance in podcasts.
The Podcast Standards Project, a grassroots coalition working to establish modern, open standards, to enable innovation in the podcast industry.
Define “innovation”.
Boom! The Clearleft podcast is back!
The first episode of season four just dropped. It’s all about design transformation.
I’ve got to be honest, this episode is a little inside baseball. It’s a bit navel-gazey and soul-searching as I pick apart the messaging emblazoned on the Clearleft website:
The design transformation consultancy.
Whereas most of the previous episodes of the podcast would be of interest to our peers—fellow designers—this one feels like it might of more interest to potential clients. But I hope it’s not too sales-y.
You’ll hear from Danish designer Maja Raunbak, and American in Amsterdam Nick Thiel as well as Clearleft’s own Chris Pearce. And I’ve sampled a talk from the Leading Design archives by Stuart Frisby.
The episode clocks in at a brisk eighteen and a half minutes. Have a listen.
While you’re at it, take this opportunity to subscribe to the Clearleft podcast on Overcast, Spotify, Apple, Google or by using a good ol’-fashioned RSS feed. That way the next episodes in the season will magically appear in your podcatching software of choice.
But I’m not making any promises about when that will be. Previously, I released new episodes in a season on a weekly basis. This time I’m going to release each episode whenever it’s ready. That might mean there’ll be a week or two between episodes. Or there might be a month or so between episodes.
I realise that this unpredictable release cycle is the exact opposite of what you’re supposed to do, but it’s actually the most sensible way for me to make sure the podcast actually gets out. I was getting a bit overwhelmed with the prospect of having six episodes ready to launch over a six week period. What with curating UX London and other activities, it would’ve been too much for me to do.
So rather than delay this season any longer, I’m going to drop each episode whenever it’s done. Chaos! Anarchy! Dogs and cats living together!
Container queries can’t be used in the sizes
attribute for responsive images. Here, Jason breaks down why that is (spoiler: it’s the lookahead pre-parser) and segues into a truly long term solution: a “magical” image format.
If you’ve ever thought it felt weird to put media conditions inside the HTML for responsive images, this will resonate.
I’ve been redesigning UX London. I don’t mean the website. I mean the event itself.
Don’t worry, it’s nothing too radical. It’s not like we’re changing the focus of the event, which remains a nerdfest for all things design-related.
But there are plenty of other opportunities for tweaking a conference like this: the format, the timings, the location.
For 2023 we’re not changing the location. Tobacco Dock worked out well for last year’s event, although it is very expensive (then again, so is anywhere decent in London). Last year there were a lot of unknowns in play because it was our first time using the venue. It feels good that this year we don’t have to go through quite as much uncertainty.
The most obvious change to UX London this year is the length. The event will last for two days instead of three.
Running a three-day event was a lot of work, so this helps relieve the pressure. It was also asking a lot of attendees. That’s why we also offered one-day tickets. For the people who couldn’t commit to three days at a conference, there was the option to pick and choose.
But that brought its own issues. Instead of everyone having the same shared experience, the audience was a bit fractured.
Now that we’ve slimmed it down to two days, we’re selling the same two-day tickets for everyone. No more single-day tickets; no more partial attendance. Judging by the way ticket sales have been going, this is a very welcome move.
(Even before announcing any speakers, we had already sold a healthy amount of tickets. That’s probably testament to the great reputation that UX London has built up over the years. I need to make sure I don’t squander that good will. No pressure.)
On the subject of everyone having a shared experience, there’s something about the format of UX London that’s bothered me for a while…
Each day is split into two halves. In the morning, you’ve got inspirational talks. That’s one single track. Then in the afternoon, you’ve got hands-on practical workshops. They happen in parallel.
That makes for a great mix, but the one downside is that the day ends with the audience split across the different workshops.
This year I’m tweaking the format slightly. We’ll still have a single track of talks in the morning followed by multiple workshops in the afternoon, but I’m shortening the workshop length slightly to fit in one last talk at the end of the day. That way, everybody will come back together again after their workshops to participate in a shared experience.
The audience will converge at the beginning of the day, diverge in the afternoon, and this time we’ll converge again at day’s end.
The workshops are a big part of what makes UX London stand out. But they also pose a big design challenge. How do you ensure that everyone gets to attend the workshops they want?
We could make people pick their workshops in advance. But then you end up with the office Christmas dinner party problem—you know the one; everyone has to choose their meal way in advance, and then on the day, no one remembers what they ordered.
Besides, if we make people choose in advance, it’s not fair on people who buy their ticket close to the event.
In the end, using a first-come, first-served strategy on the day has worked out best. But it’s not ideal. You could miss out on attending your first choice of workshop if you’re not fast enough.
This year we’re trying something new. Each afternoon there’ll be a choice of workshops, as always. But this time, it’ll be the same workshops on both days. That way, every attendee gets a second chance to get to the workshops they want. And it’ll help reduce the FOMO—Fear Of Missing Out. It still won’t be possible to attend all the workshops without cloning yourself, but this way, you get to attend half of them.
To recap, here’s the redesigned format for UX London 2023:
The line-up is coming together nicely. I’ve got more confirmed speakers, who I don’t want to reveal just yet. But trust me, you won’t want to miss this!
Oh, and you should probably grab your ticket this week if you haven’t already: early-bird pricing ends on midnight on Friday, February 24th.
Mat has written this free course for you all about images on the web. Covering image formats, responsive images, and workflows, this is one to keep on speed dial.
I’ve always liked the idea that your website can be your API. Like, you’ve already got URLs to identify resources, so why not make that URL structure predictable and those resources parsable?
That’s why the (read-only) API for The Session doesn’t live at a separate subdomain. It uses the same URL structure as the regular site, but you can request the resources in an alternative format: JSON, XML, RSS.
This works out pretty well, mostly because I put a lot of thought into the URL structure of the site. I’m something of a URL fetishist, but I think that taking a URL-first approach to information architecture can be a good exercise.
Most of the resources on The Session involve nouns like tunes, events, discussions, and so on. There’s a consistent and predictable structure to the URLs for those sections:
/things
/things/new
/things/search
And then an idividual item can be found at:
things/ID
That’s all nice and predictable and the naming of the URLs matches what you’d expect to find:
Tunes, events, discussions, sessions. Those are all fine. But there’s one section of the site that has this root URL:
When I was coming up with the URL structure twenty years ago, it was clear what you’d find there: track listings for albums of music. No one would’ve expected to find actual recordings of music available to listen to on-demand. The bandwidth constraints and technical limitations of the time made that clear.
Two decades on, the situation has changed. Now someone new to the site might well expect to hit a link called “recordings” and expect to hear actual recordings of music.
So I should probably change the label on the link. I don’t think “albums” is quite right—what even is an album any more? The word “discography” is probably the most appropriate label.
Here’s my dilemma: if I update the label, should I also update the URL structure?
Right now, the section of the site with /tunes
URLs is labelled “tunes”. The section of the site with /events
URLs is labelled “events”. Currently the section of the site with /recordings
URLs is labelled “recordings”, but may soon be labelled “discography”.
If you click on “tunes”, you end up at /tunes
. But if you click on “discography”, you end up at /recordings
.
Is that okay? Am I the only one that would be bothered by that?
I could update the URLs to match the labelling (with redirects for the old URLs, of course), but I’m not so keen on this URL structure:
/discography
/discography/new
/discography/search
/discography/ID
It doesn’t seem as tidy as:
/recordings
/recordings/new
/recordings/search
/recordings/ID
But if I don’t update the URLs to match the label, then I’m just going to have to live with the mismatch.
I’m just thinking out loud here. I think I should definitely update the label. I just won’t make any decision on changing URLs for a while yet.
Guess which format is going to outlast all these proprietary syndication formats. I’d say RSS, which I believe to be true, but really, it’s HTML.
A great write-up from Hidde on dConstruct 2022 and how the speakers tackled the theme of design transformation:
They talked about turning a series of penstrokes into art, lasers into fireworks, human experiences into novels and patient data collection into a minimal effort task.
A lot of our work in web design and technology has a power to transform and that is wonderful, especially when we manage to be intentional about the how and why.
Kevin takes my eleven-year old remark literally and points out at least you can emulate LaserDiscs:
So LaserDiscs aren’t the worst things to archive, networks of servers running code that isn’t available or archivable are, and we are building a lot more of those these days, whether on the web or in apps.
I love this: Terence takes eleven years to reflect on a comment I made on stage at an event here in Brighton. It’s all about the longevity of the web compared to native apps:
If you wrote an app for an early version of iOS or Android, it simply won’t run on modern hardware or software. APIs have changed, SDKs weren’t designed with forward compatibility, and app store requirements have evolved.
The web has none of that. The earliest websites are viewable on modern browsers.
As wrote at the time, I may have been juicing things up for entertainment:
Now here’s the thing when it comes to any discussion about mobile or the web or anything else of any complexity: an honest discussion would result in every single question being answered with “it depends”. A more entertaining discussion, on the other hand, would consist of deliberately polarised opinions. We went for the more entertaining discussion.
But I think this still holds true for me today:
The truth is that the whole “web vs. native” thing doesn’t interest me that much. I’m as interested in native iOS development as I am in native Windows development or native CD-ROM development. On a timescale measured in years, they are all fleeting, transient things. The web abides.
Here’s a really excellent, clearly-written case study that unfortunately includes this accurate observation:
In recent years the practice of information architecture has fallen out of fashion, which is a shame as you can’t design something successfully without it. If a user can’t find a feature, it’s game over - the feature may as well not exist as far as they’re concerned.
I also like this insight:
Burger menus are effective… at hiding things.
Shockingly little. So you should try it, too.
I was talking to someone recently about a forgotten battle in the history of the early web. It was a battle between search engines and directories.
These days, when the history of the web is told, a whole bunch of services get lumped into the category of “competitors who lost to Google search”: Altavista, Lycos, Ask Jeeves, Yahoo.
But Yahoo wasn’t a search engine, at least not in the same way that Google was. Yahoo was a directory with a search interface on top. You could find what you were looking for by typing or you could zero in on what you were looking for by drilling down through a directory structure.
Yahoo wasn’t the only directory. DMOZ was an open-source competitor. You can still experience it at DMOZlive.com:
The official DMOZ.com site was closed by AOL on February 17th 2017. DMOZ Live is committed to continuing to make the DMOZ Internet Directory available on the Internet.
Search engines put their money on computation, or to use today’s parlance, algorithms (or if you’re really shameless, AI). Directories put their money on humans. Good ol’ information architecture.
It turned out that computation scaled faster than humans. Search won out over directories.
Now an entire generation has been raised in the aftermath of this battle. Monica Chin wrote about how this generation views the world of information:
Catherine Garland, an astrophysicist, started seeing the problem in 2017. She was teaching an engineering course, and her students were using simulation software to model turbines for jet engines. She’d laid out the assignment clearly, but student after student was calling her over for help. They were all getting the same error message: The program couldn’t find their files.
Garland thought it would be an easy fix. She asked each student where they’d saved their project. Could they be on the desktop? Perhaps in the shared drive? But over and over, she was met with confusion. “What are you talking about?” multiple students inquired. Not only did they not know where their files were saved — they didn’t understand the question.
Gradually, Garland came to the same realization that many of her fellow educators have reached in the past four years: the concept of file folders and directories, essential to previous generations’ understanding of computers, is gibberish to many modern students.
We are finding a persistent issue with getting (undergrad, new to research) students to understand that a file/directory structure exists, and how it works. After a debrief meeting today we realized it’s at least partly generational.
We live in a world ordered only by search:
While some are quite adept at using labels, tags, and folders to manage their emails, others will claim that there’s no need to do because you can easily search for whatever you happen to need. Save it all and search for what you want to find. This is, roughly speaking, the hot mess approach to information management. And it appears to arise both because search makes it a good-enough approach to take and because the scale of information we’re trying to manage makes it feel impossible to do otherwise. Who’s got the time or patience?
There are still hold-outs. You can prise files from Scott Jenson’s cold dead hands.
More recently, Linus Lee points out what we’ve lost by giving up on directory structures:
Humans are much better at choosing between a few options than conjuring an answer from scratch. We’re also much better at incrementally approaching the right answer by pointing towards the right direction than nailing the right search term from the beginning. When it’s possible to take a “type in a query” kind of interface and make it more incrementally explorable, I think it’s almost always going to produce a more intuitive and powerful interface.
Directory structures still make sense to me (because I’m old) but I don’t have a problem with search. I do have a problem with systems that try to force me to search when I want to drill down into folders.
I have no idea what Google Drive and Dropbox are doing but I don’t like it. They make me feel like the opposite of a power user. Trying to find a file using their interfaces makes me feel like I’m trying to get a printer to work. Randomly press things until something happens.
Anyway. Enough fist-shaking from me. I’m going to ponder Linus’s closing words. Maybe defaulting to a search interface is a cop-out:
Text search boxes are easy to design and easy to add to apps. But I think their ease on developers may be leading us to ignore potential interface ideas that could let us discover better ideas, faster.