Journal tags: trans

25

sparkline

Negativity bias

When I wrote about my hopes and fears for the View Transitions API, a few people latched on to this sentiment:

If the View Transitions API only works for single page apps, it could be the single worst thing to happen to the web in years.

But I also wrote:

If the View Transitions API works across page navigations, it could be the single best thing to happen to the web in years.

I think it’s worth focusing on that.

Part of the problem is that I gave my hopes and fears an equal airing. But they’re not equally likely.

Take the possibility that the View Transitions API only ships for single page apps, but never ships for regular page transitions. The consequences of that would be big—the API would act as an incentive to build single page apps. But the likelihood of that happening is small. In fact, according to Jake, there’s already an implemention for page transitions in the works at Chrome.

Now what if the View Transitions API ships for pages? The consequences would be equally big—the API would act as an incentive to ditch single page apps and build in a more performant, resilient way. Best of all, the chances of that happening are very large indeed (pretty much a certainty now, given Jake’s update).

So I made a comparison between both of the consequences, which are equally large, but I didn’t make a corresponding comparison of the likelihoods, which are not equally large. Mea culpa!

I should’ve made it clearer that, although the consequences would be really bad if the View Transitions API only supports single page apps, the actual likelihood of that is pretty slim.

That’s probably my negativity bias showing through. (The reason I have a negativity bias is because I am a human. Like, have you ever noticed that if you get feedback on something and 98% of it is positive, you inevitably fixate on the 2%?)

Anyway, the real takeaway here is that if the View Transitions API ships for pages, then the consequences will be really, really good! It would be another nail in the coffin for monolithic JavaScript frameworks slowing down the web. And best of all, the likelihood of this happening is very high!

So let me amend my closing sentences from my previous post:

If the View Transitions API only works for single page apps—which is very unlikely—it could be the single worst thing to happen to the web in years.

If the View Transitions API works across page navigations—which is very, very likely—it could be the single best thing to happen to the web in years.

The glass is half full and it’s only going to get fuller. Time to start planning for a turbo-charged web now.

If you’ve got a website with full page navigations, start thinking about how you’ll be able to apply the View Transitions API as a progressive enhancement to improve the user experience.

If you’ve got a single page app, start thinking about how to ditch a whole bunch of uneccessary dependencies to make a more lightweight foundation of HTML instead of JavaScript, and still get all those slick transitions you get in a single page app!

Time for transitions

I am simultaneously very excited and very nervous about the View Transitions API.

You may know it by its former name—Shared Element Transitions. The name change is very recent.

I’ve been saying for years that some kind of API like this would be brilliant:

I honestly think if browsers implemented this, 80% of client-rendered Single Page Apps could be done as regular good ol’-fashioned websites.

Miriam Suzanne describes the theory of View Transitions succinctly:

Shared-element transitions are designed to work with standard web navigation across multiple page loads, as well as page transitions in ‘single-page’ apps (often called SPAs).

This all sounds brilliant. But the devil is in the implementation details. Right now, the API only works for single page apps. This is totally understandable. For purely pragmatic reasons, single page apps are a simple use case to solve for. It’s going to take a lot more work to get this API to work for multi-page apps (or as we used to call them, websites).

If we get a View Transitions API that works across page navigations, it could potentially turbo-charge the web. It will act as a disencentive to building single page apps—you’d be able to provide swish transitions without sacrificing performance or resilience at the alter of a heavy-handed JavaScript-only architecture.

But if the API only ever works for single page apps (which is the current situation), then it will act as an incentive to make any kind of website into a single page app, regardless of whether it’s actually the appropriate architecture.

That prospect has me very worried indeed.

I’m making my feelings on this known just in case any of the implementators out there are thinking, “Hey, maybe it’s fine that this API only works for single page apps—I’m sure most people would be happy with that.”

If the View Transitions API works across page navigations, it could be the single best thing to happen to the web in years.

If the View Transitions API only works for single page apps, it could be the single worst thing to happen to the web in years.

Update: Jake says:

We’re currently landing code in Chrome for the MPA version.

Very happy to hear that! It’s already in the spec, but it’s good to hear that the implementation isn’t going to lag too much.

Also, read this follow-up.

Talking about style

I’ve published a transcription of the talk I gave at CSS Day:

In And Out Of Style.

The title is intended to have double meaning. The obvious reference is that CSS is about styling web pages. But the talk also covers some long-term trends looking at ideas that have appear, disappear, and reappear over time. Hence, style as in trends and fashion.

There are some hyperlinks in the transcript but I also published a list of links if you’re interested in diving deeper into some of the topics mentioned in the talk.

I also published the slides but, as usual, they don’t make much sense out of context. They’re on Noti.st too.

I made an audio recording for your huffduffing pleasure.

There are two videos of this talk. On Vimeo, there’s the version I pre-recorded for An Event Apart online. On YouTube, there’s the recording from CSS Day.

It’s kind of interesting to compare the two (well, interesting to me, anyway). The pre-recorded version feels like a documentary. The live version has more a different vibe and it obviously has more audience interaction. I think my style of delivery suits a live audience best.

I invite you to read, watch, or listen to In And Out Of Style, whichever you prefer.

Publishing The State Of The Web

Back in April I gave a talk at An Event Apart Spring Summit. The talk was called The State Of The Web, and I’ve published the transcript. I’ve also published the video.

I put a lot of work into this talk and I think it paid off. I wrote about preparing the talk. I also wrote about recording it. I also published links related to the talk. It was an intense process, but a rewarding one.

I almost called the talk The Overview Effect. My main goal with the talk was to instil a sense of perspective. Hence the references to the famous Earthrise photograph.

On the one hand, I wanted the audience to grasp just how far the web has come. So the first half of the talk is a bit of a trip down memory lane, with a constant return to just how much we can accomplish in browsers today. It’s all very positive and upbeat.

Then I twist the knife. Having shown just how far we’ve progressed technically, I switch gears the moment I say:

The biggest challenges facing the World Wide Web today are not technical challenges.

Then I dive into those challenges, as I see them. It turns out that technical challenges would be preferable to the seemingly intractable problems of today’s web.

I almost wish I could’ve flipped the order: talk about the negative stuff first but then finish with the positive. I worry that the talk could be a bit of a downer. Still, I tried to finish on an optimistic note.

I won’t spoil it any more for you. Watch the video or have a read of The State Of The Web.

BBC feedback

I just filled out this form on the BBC website. Here’s what I wrote, based on this open letter to the BCC Upper Management and Editorial Staff.

What is your complaint about?

BBC website or apps

Which website or app is your complaint about?

BBC News website

Please give the URL, or name of the app

https://www.bbc.co.uk/news/uk-england-57853385

Are you contacting us about a previous complaint?

No

Select the best category to describe your complaint

Standards of interviewing/presenting

What is the subject of your complaint?

Innacurate reporting and unreliable source

Please enter your complaint

The article is based on a single self selected study of 80 individuals sourced from Get The L Out, a group who, prior to the survey, were already united by anti-trans views.

This study breaks the BBC’s own guidelines about using surveys as sources for claims in coverage, as it is self-selected, with a small sample size and a clear bias held by those self-selected to respond.

The article dangerously frames this as a widespread issue, whilst simultaneously acknowledging that there is no actual evidence to that effect outside of isolated claims and cherry picked individual cases.

The article routinely implies that transgender women are not women, uncritically quoting people who call transgender women men without at any point clarifying that this is ignoring their legal status as women in the UK.

SafarIE

I was moaning about Safari recently. Specifically I was moaning about the ridiculous way that browser updates are tied to operating system updates.

But I felt bad bashing Safari. It felt like a pile-on. That’s because a lot of people have been venting their frustrations with Safari recently:

I think it’s good that people share their frustrations with browsers openly, although I agree with Baldur Bjarnason that’s good to avoid Kremlinology and the motivational fallacy when blogging about Apple.

It’s also not helpful to make claims like “Safari is the new Internet Explorer!” Unless, that is, you can back up the claim.

On a recent episode of the HTTP 203 podcast, Jake and Surma set out to test the claim that Safari is the new IE. They did it by examining Safari according to a number of different measurements and comparing it to the olden days of Internet Explorer. The result is a really fascinating trip down memory lane along with a very nuanced and even-handed critique of Safari.

And the verdict? Well, you’ll just to have to listen to the podcast episode.

If you’d rather read the transcript, tough luck. That’s a real shame because, like I said, it’s an excellent and measured assessment. I’d love to add it to the links section of my site, but I can’t do that in good conscience while it’s inaccessible to the Deaf community.

When I started the Clearleft podcast, it was a no-brainer to have transcripts of every episode. Not only does it make the content more widely available, but it also makes it easier for people to copy and paste choice quotes.

Still, I get it. A small plucky little operation like Google isn’t going to have the deep pockets of a massive corporation like Clearleft. But if Jake and Surma were to open up a tip jar, I’d throw some money in to get HTTP 203 transcribed (I recommend getting Tina Pham to do it—she’s great!).

I apologise for my note of sarcasm there. But I share because I care. It really is an excellent discussion; one that everyone should be able to access.

Update: the bug with that episode of the HTTP 203 podcast has been fixed. Here’s the transcript! And all future episodes will have transcripts too:

An email to The Guardian

Hello,

My name is Jeremy and I’ve been a paid subscriber to The Guardian for a few years now. But I’m considering cancelling my account after reading this editorial.

On the face of it, the headline of the article sound reasonable and hard to disagree with. But the substance of the article downplays anti-trans views as simply being “gender critical.” This is akin to describing segregationist views as “integration critical.”

This line is particularly egregious:

As a society, we need to resolve the question of how to protect the privacy, dignity and rights of trans women while also respecting the privacy, dignity and rights of those born female.

Setting up these positions as though one in any way invalidates the other gives oxygen to those who wish to paint someone’s identity as a threat. I’m very disappointed to see this viewpoint expressed in an editorial on The Guardian website.

Yours,

Jeremy Keith

Portals and giant carousels

I posted something recently that I think might be categorised as a “shitpost”:

Most single page apps are just giant carousels.

Extreme, yes, but perhaps there’s a nugget of truth to it. And it seemed to resonate:

I’ve never actually seen anybody justify SPA transitions with actual business data. They generally don’t seem to increase sales, conversion, or retention.

For some reason, for SPAs, managers are all of a sudden allowed to make purely emotional arguments: “it feels snappier”

If businesses were run rationally, when somebody asks for an order of magnitude increase in project complexity, the onus would be on them to prove that it proportionally improves business results.

But I’ve never actually seen that happen in a software business.

A single page app architecture makes a lot of sense for interaction-heavy sites with lots of state to maintain, like twitter.com. But I’ve seen plenty of sites built as single page apps even though there’s little to no interactivity or state management. For some people, it’s the default way of building anything on the web, even a brochureware site.

It seems like there’s a consensus that single page apps may have long initial loading times, but then they have quick transitions between “pages” …just like a carousel really. But I don’t know if that consensus is based on reality. Whether you’re loading a page of HTML or loading a chunk of JSON, you’re still making a network request that will take time to resolve.

The argument for loading a chunk of JSON is that you don’t have to make any requests for the associated CSS and JavaScript—they’re already loaded. Whereas if you request a page of HTML, that HTML will also request CSS and JavaScript.

Leaving aside the fact that is literally what the browser cache takes of, I’ve seen some circular reasoning around this:

  1. We need to create a single page app because our assets, like our JavaScript dependencies, are so large.
  2. Why are the JavaScript dependencies so large?
  3. We need all that JavaScript to create the single page app functionlity.

To be fair, in the past, the experience of going from page to page used to feel a little herky-jerky, even if the response times were quick. You’d get a flash of a white blank page between navigations. But that’s no longer the case. Browsers now perform something called “paint holding” which elimates the herky-jerkiness.

So now if your pages are a reasonable size, there’s no practical difference in user experience between full page refreshes and single page app updates. Navigate around The Session if you want to see paint holding in action. Switching to a single page app architecture wouldn’t improve the user experience one jot.

Except…

If I were controlling everything with JavaScript, then I’d also have control over how to transition between the “pages” (or carousel items, if you prefer). There’s currently no way to do that with full page changes.

This is the problem that Jake set out to address in his proposal for navigation transitions a few years back:

Having to reimplement navigation for a simple transition is a bit much, often leading developers to use large frameworks where they could otherwise be avoided. This proposal provides a low-level way to create transitions while maintaining regular browser navigation.

I love this proposal. It focuses on user needs. It also asks why people reach for JavaScript frameworks instead of using what browsers provide. People reach for JavaScript frameworks because browsers don’t yet provide some functionality: components like tabs or accordions; DOM diffing; control over styling complex form elements; navigation transitions. The problems that JavaScript frameworks are solving today should be seen as the R&D departments for web standards of tomorrow. (And conversely, I strongly believe that the aim of any good JavaScript framework should be to make itself redundant.)

I linked to Jake’s excellent proposal in my shitpost saying:

bucketloads of JavaScript wouldn’t be needed if navigation transitions were available in browsers

But then I added—and I almost didn’t—this:

(not portals)

Now you might be asking yourself what Paul said out loud:

Excuse my ignorance but… WTF are portals!?

I replied with a link to the portals proposal and what I thought was an example use case:

Portals are a proposal from Google that would help their AMP use case (it would allow a web page to be pre-rendered, kind of like an iframe).

That was based on my reading of the proposal:

…show another page as an inset, and then activate it to perform a seamless transition to a new state, where the formerly-inset page becomes the top-level document.

It sounded like Google’s top stories carousel. And the proposal goes into a lot of detail around managing cross-origin requests. Again, that strikes me as something that would be more useful for a search engine than a single page app.

But Jake was not happy with my description. I didn’t intend to besmirch portals by mentioning Google AMP in the same sentence, but I can see how the transitive property of ickiness would apply. Because Google AMP is a nasty monopolistic project that harms the web and is an embarrassment to many open web advocates within Google, drawing any kind of comparison to AMP is kind of like Godwin’s Law for web stuff. I know that makes it sounds like I’m comparing Google AMP to Hitler, and just to be clear, I’m not (though I have myself been called a fascist by one of the lead engineers on AMP).

Clearly, emotions run high when Google AMP is involved. I regret summoning its demonic presence.

After chatting with Jake some more, I tried to find a better use case to describe portals. Reading the proposal, portals sound a lot like “spicy iframes”. So here’s a different use case that I ran past Jake: say you’re on a website that has an iframe embedded in it—like a YouTube video, for example. With portals, you’d have the ability to transition the iframe to a fully-fledged page smoothly.

But Jake told me that even though the proposal talks a lot about iframes and cross-origin security, portals are conceptually more like using rel="prerender" …but then having scripting control over how the pre-rendered page becomes the current page.

Put like that, portals sound more like Jake’s original navigation transitions proposal. But I have to say, I never would’ve understood that use case just from reading the portals proposal. I get that the proposal is aimed more at implementators than authors, but in its current form, it doesn’t seem to address the use case of single page apps.

Kenji said:

we haven’t seen interest from SPA folks in portals so far.

I’m not surprised! He goes on:

Maybe, they are happy / benefits aren’t clear yet.

From my own reading of the portals proposal, I think the benefits are definitely not clear. It’s almost like the opposite of Jake’s original proposal for navigation transitions. Whereas as that was grounded in user needs and real-world examples, the portals proposal seems to have jumped to the intricacies of implementation without covering the user needs.

Don’t get me wrong: if portals somehow end up leading to a solution more like Jake’s navigation transitions proposals, then I’m all for that. That’s the end result I care about. I’d love it if people had a lightweight option for getting the perceived benefits of single page apps without the costly overhead in performance that comes with JavaScripting all the things.

I guess the web I want includes giant carousels.

Design systems on the Clearleft podcast

If you’ve already subscribed to the Clearleft podcast, thank you! The first episode is sliding into your podcast player of choice.

This episode is all about …design systems!

I’m pretty happy with how this one turned out, although as it’s the first one, I’m sure I’ll learn how to do this better. I may end up looking back at this first foray with embarrassment. Still, it’s fairly representative of what you can expect from the rest of the season.

This episode is fairly short. Just under eighteen minutes. That doesn’t mean that other episodes will be the same length. Each episode will be as long (or as short) as it needs to be. Form follows function, or in this case, episode length follows content. Other episodes will be longer. Some might be shorter. It all depends on the narrative.

This flies in the face of accepted wisdom when it comes to podcasting. The watchword that’s repeated again and again for aspiring podcasters is consistency. Release on a consistent schedule and have a consistent length for episodes. I kind of want to go against that advice just out of sheer obstinancy. If I end up releasing episodes on a regular schedule, treat it as coincidence rather than consistency.

There’s not much of me in this episode. And there won’t be much of me in most episodes. I’m just there to thread together the smart soundbites coming from other people. In this episode, the talking heads are my colleagues Jon and James, along with my friends and peers Charlotte, Paul, and Amy (although there’s a Clearleft connection with all of them: Charlotte and Paul used to be Clearlefties, and Amy spoke at Patterns Day and Sofa Conf).

I spoke to each of them for about an hour, but like I said, the entire episode is less than eighteen minutes long. The majority of our conversations ended up on the cutting room floor (possibly to be used in future episodes).

Most of my time was spent on editing. It was painstaking, but rewarding. There’s a real pleasure to be had in juxtaposing two snippets of audio, either because they echo one another or because they completely contradict one another. This episode has a few examples of contradictions, and I think those are my favourite moments.

Needless to say, eighteen minutes was not enough time to cover everything about design systems. Quite the opposite. It’s barely an introduction. This is definitely a topic that I’ll be returning to. Maybe there could even be a whole season on design systems. Let me know what you think.

Oh, and you’ll notice that there’s a transcript for the episode. That’s a no-brainer. I’m a big fan of the spoken word, but it really comes alive when it’s combined with searchable, linkable, accessible text.

Anyway, have a listen and if you’re not already subscribed, pop the RSS feed into your podcast player.

Gormless

I sometimes watch programmes on TG4, the Irish language broadcaster that posts most shows online. Even though I’m watching with subtitles on, I figure it can’t be bad for keeping my very rudimentary Irish from atrophying completely.

I’m usually watching music programmes but occassionally I’ll catch a bit of the news (or “nuacht”). Their coverage of the protests in America reminded me of a peculiar quirk of the Irish language. The Black community would be described as “daoine gorm” (pronunced “deenee gurum”), which literally translated would mean “blue people”. In Irish, the skin colour is referred to as “gorm”—blue.

This isn’t one of those linguistic colour differences like the way the Japanese word ao means blue and green. Irish has a perfectly serviceable word for the colour black, “dubh” (pronounced “duv”). But the term “fear dubh” (“far duv”) which literally means “black man” was already taken. It’s used to describe the devil. Not ideal.

In any case, this blue/black confusion in Irish reminded me of a delicious tale of schadenfreude. When I was writing about the difference between intentions and actions, I said:

Sometimes bad outcomes are the result of good intentions. Less often, good outcomes can be the result of bad intentions.

Back in 2017, the Geeky Gaeilgeoir wrote a post called Even Racists Got the Blues. In it, she disects the terrible translation job done by an Irish-American racist sporting a T-shirt that reads:

Gorm Chónaí Ábhar.

That’s completely nonsensical in Irish, but the intent behind the words was to say “Blue Lives Matter.” Except… even if it made grammatical sense, what this idiot actually wrote would translate as:

Black Lives Matter.

What a wonderful chef’s kiss of an own goal!

If only it were a tattoo.

Words

I like words. I like the way they can be tethered together to produce a satisfying sentence.

Jessica likes words even more than I do (that’s why her website is called “wordridden”). She studied linguistics and she’s a translator by trade—German into English. Have a read of her post about translating Victor Klemperer to get an inkling of how much thought and care she puts into it.

Given the depth of enquiry required for a good translation, I was particularly pleased to read this remark by John Le Carré:

No wonder then that the most conscientious editors of my novels are not those for whom English is their first language, but the foreign translators who bring their relentless eye to the tautological phrase or factual inaccuracy – of which there are far too many. My German translator is particularly infuriating.

That’s from an article called Why we should learn German, but it’s really about why we should strive for clarity in our use of language:

Clear language — lucid, rational language — to a man at war with both truth and reason, is an existential threat. Clear language to such a man is a direct assault on his obfuscations, contradictions and lies. To him, it is the voice of the enemy. To him, it is fake news. Because he knows, if only intuitively, what we know to our cost: that without clear language, there is no standard of truth.

It reminds me of one of my favourite Orwell essays, Politics and the English Language:

Political language — and with variations this is true of all political parties, from Conservatives to Anarchists — is designed to make lies sound truthful and murder respectable, and to give an appearance of solidity to pure wind.

But however much I agree with Le Carré’s reprise of Orwell’s call for clarity, I was brought up short by this:

Every time I hear a British politician utter the fatal words, “Let me be very clear”, these days I reach for my revolver.

Le Carré’s text was part of a speech given in Berlin, where everyone would get the reference to the infamous Nazi quote—Wenn ich Kultur höre … entsichere ich meinen Browning—and I’m sure it was meant with a sly wink. But words matter.

Words are powerful. Words can be love and comfort — and words can be weapons.

Listen to Brighton SF

Brighton SF really was a wonderful event: Brian Aldiss, Jeff Noon, and Lauren Beukes all gathered together for an evening of chat and readings, hosted by yours truly.

Brian Aldiss, Jeff Noon, and Lauren Beukes on the Brighton SF panel, chaired by Jeremy Keith

But you don’t have to take my word for it. Thanks to Drew’s tireless efforts, the audio is now available for your listening pleasure on Huffduffer. I’ve also published a transcript.

Brighton SF with Brian Aldiss, Lauren Beukes, and Jeff Noon on Huffduffer

I highly recommend giving it a listen: readings from Jeff and Lauren, together with wonderful tales from the life of Brian Aldiss …superb stuff!

#BrightonSF It's Brian Aldiss, Jeff Noon, Jeremy Keith, and Lauren Beukes on stage for Brighton SF.

If that whets your appetite, there’s more audio goodness from each of the authors to be found on Huffduffer:

In the meantime, enjoy Brighton SF with Brian Aldiss, Lauren Beukes, and Jeff Noon.

Publishing Paranormal Interactivity

I’ve published the transcript of a talk I gave at An Event Apart in 2010. It’s mostly about interaction design, with a couple of diversions into progressive enhancement and personality in products. It’s called Paranormal Interactivity.

I had a lot of fun with this talk. It’s interspersed with videos from The Hitchhiker’s Guide To The Galaxy, Alan Partridge, and Super Mario, with special guest appearances from the existentialist chalkboard and Poshy’s upper back torso.

If you don’t feel like reading it, you can always watch the video or listen to the audio.

Adactio: Articles—Paranormal Interactivity on Huffduffer

You could even look at the slides but, as I always say, they won’t make much sense without the context of the presentation.

Cool your eyes don’t change

At last November’s Build conference I gave a talk on digital preservation called All Our Yesterdays:

Our communication methods have improved over time, from stone tablets, papyrus, and vellum through to the printing press and the World Wide Web. But while the web has democratised publishing, allowing anyone to share ideas with a global audience, it doesn’t appear to be the best medium for preserving our cultural resources: websites and documents disappear down the digital memory hole every day. This presentation will look at the scale of the problem and propose methods for tackling our collective data loss.

The video is now on vimeo.

The audio has been huffduffed.

Adactio: Articles—All Our Yesterdays on Huffduffer

I’ve published a transcription over in the “articles” section.

I blogged a list of relevant links shortly after the presentation.

You can also download the slides or view them on speakerdeck but, as usual, they won’t make much sense out of context.

I hope you’ll enjoy watching or reading or listening to the talk as much as I enjoyed presenting it.

Audio Update

Aral recently released the videos from last September’s Update conference. You can watch the video of my talk if you like or, if video isn’t your bag, I’ve published a transcription of the talk.

It’s called One Web, Many Devices and I’m pretty happy with how it turned out. It’s a short talk—just under 17 minutes—but I think I made my point well, without any um-ing and ah-ing. At the time I described the talk like this:

I went in to the lion’s den to encourage the assembled creative minds to forego the walled garden of Apple’s app store in favour of the open web.

It certainly got people talking. Addy Osmani wrote an op-ed piece in .net magazine after seeing the talk.

The somewhat contentious talk was followed by an even more contentious panel, which Amber described as Jeremy Keith vs. Everyone Else. The video of that panel has been published too. My favourite bit is around the five-minute mark where I nailed my colours to the mast.

Me: I’m not going to create something specifically for Windows Phone 7. I’m not going to create a specific Windows Phone 7 app. I’m not going to create a specific iPhone app or a specific Android app because I have as much interest in doing that as I do in creating a CD-ROM or a Laserdisc…

Aral: I don’t think that’s a valid analogy.

Me: Give it time.

But I am creating stuff that can be accessed on all those devices because an iPhone and Windows Phone 7 and Android—they all come with web browsers.

I was of course taking a deliberately extreme stance and, as I said at the time, the truthful answer to most of the questions raised during the panel discussion is “it depends” …but that would’ve made for a very dull panel.

Unfortunately the audio of the talks and panels from Update hasn’t been published—just videos. I’ve managed to extract an mp3 file of my talk which involved going to some dodgy warez sitez.

Adactio: Articles—One Web, Many Devices on Huffduffer

I wish conference organisers would export the audio of any talks that they’re publishing as video. Creating the sound file at that point is a simple one-click step. But once the videos are up online—be it on YouTube or Vimeo—it’s a lot, lot harder to get just the audio.

Not everyone wants to watch video. In fact, I bet there are plenty of people who listen to conference talks by opening the video in a separate tab so they can listen to it while they do something else. That’s one of the advantages of publishing conference audio: it allows people to catch up on talks without having to devote all their senses. I’ve written about this before:

Not that I have anything against the moving image; it’s just that television, film and video demand more from your senses. Lend me your ears! and your eyes. With your ears and eyes engaged, it’s pretty hard to do much else. So the default position for enjoying television is sitting down.

A purely audio channel demands only aural attention. That means that radio—and be extension, podcasts—can be enjoyed at the same time as other actions; walking around, working out at the gym. Perhaps it’s this symbiotic, rather than parasitic, arrangement that I find engaging.

When I was chatting with Jesse from SFF Audio he told me how he often puts video podcasts (vodcasts?) on to his iPod/iPhone but then listens to them with the device in his pocket. That’s quite a waste of bandwidth but if no separate audio is made available, the would-be listener is left with no choice.

SFFaudio with Jeremy Keith on Huffduffer

So conference organisers: please, please take a second or two to export an audio file if you’re publishing a video. Thanks.

One Web, transcribed

I spoke at the DIBI conference back in June. It was a really good event, despite its annoying two-track format.

My talk was entitled One Web:

The range of devices accessing the web is increasing. We are faced with a choice in how we deal with this diversity. We can either fracture the web by designing a multitude of device-specific silos, or we can embrace the flexibility of the web and create experiences that can adapt to any device or browser.

The video has been online for a while now and I finally got ‘round to getting it transcribed. You can pop on over to the articles section and read One Web. I should really re-name that section of my site: “articles” isn’t the most accurate label for a lot of the stuff there.

If you prefer listening to reading, the audio is available for your huffduffing pleasure.

Adactio: Articles—One Web on Huffduffer

I also put the slides on Speakerdeck so you play along with the presentation.

I reprised this talk in Italy recently at the From The Front gathering. The audio from that is also online if you want to compare and contrast.

Jeremy Keith at From The Front 2011: One Web on Huffduffer

DIBI 2011

Hot topics, transcribed

As ever, I had a lot of fun moderating the hot topics panel at this year’s Web Directions @media in London. Thanks to all of you who left questions on my blog post.

I had a great line-up of panelists:

We discussed publishing, mobile, browsers, clients and much much more. The audio is available for your huffduffing pleasure and I’ve had it transcribed. I’ve published the transcription over in the articles section of this site, so if you prefer reading to listening, I direct your attention to:

Web Directions @media 2011 Hot Topics Panel

Web Directions @media 2011: Jeremy Keith — Panel: Hot Topics on Huffduffer

Mobilism transcription

Remember that mobile browser panel I moderated at the Mobilism conference in Amsterdam earlier this year? Well, I’ve had the whole thing transcribed. You can now:

Enjoy!

Podchatting

There was an episode of the SitePoint podcast a little back wherein Max Wheeler and Myles Eftos discussed many matters mobile, including a look at responsive design. A post of mine—Sea Change—came up in the conversation.

Now admittedly this was before I published my clarification to make my point clearer, but I felt that my view was somewhat misrepresented on the show and I left a comment to that effect. I also said I’d be happy to come on the show and have a natter. Louis, the host of the show, was kind enough to take me up on the offer and we had a really good chat about responsive web design.

Have a listen for yourself or if you’d rather not hear my voice in your head, I’ve published the transcript amongst my articles.

SitePoint Podcast #111: Responsive Web Design with Jeremy Keith on Huffduffer

Shanghai

My trip to Shanghai went swimmingly. It kicked off with W3C Tech, which was a thoroughly lovely event.

W3C Tech

I gave my talk—The Design Of HTML5—with the help of an excellent interpreter performing . It was my first time experiencing that—I had previously experienced simultaneous interpretation in Spain and Japan—and it was quite a good exercise in helping me speak in complete, well-formed sentences (the translation usually occurred at the end of a sentence).

Translating Speaking

Once my talk was done, I took some questions from the audience and was then showered with good wishes and tea-related gifts. They really made me feel like a rockstar there; I’ve never had so many people want to have their picture taken with me or have me sign their copies of my books—the publishers of the Chinese translations of DOM Scripting and Bulletproof Ajax were also at the conference.

Book buyers DOM Scripting, translated Posing Signing

W3C Tech was held on the east side of the river so I spent the first few days in the futuristic surroundings of . Once the event wrapped up, myself and Jessica moved across to a more central location just off . I quite liked the hustle and bustle, especially once I remembered the cheat code of “bu yao!” to ward off the overly-enthusiastic street merchants. I wish there were something similar for the chuggers here in the UK, but I have the feeling that the literal translation—“do not want!”—will just make me sound like a lolcat.

Futurescape Gliding down Nanjing road

Anyway, I had a great time in Shanghai, doing touristy things and taking lots of pictures. I particularly enjoyed getting stuck in at street-level exploring the markets, whether it was electronics or food. The fried dumplings——were particularly wonderful. I plan to deliver a full report over at Principia Gastronomica.

Food carts Dumplings

So long, Shanghai. ‘Till the next time.

Pudong illuminated