Journal tags: quote

A bunch of the UX London speakers have been saying very nice things about the event over on LinkedIn. I’m going to quote a few of them for my future self to look at when I’m freaking out about curating the next event…

Valentina D’Efilippo:

Still buzzing … UX London smashed all expectations!

Huge shoutout to Jeremy Keith and the entire Clearleft team for their tireless efforts in making this event truly special. Three days packed with inspiration, insights, and true gems – I left feeling inspired, grateful, and already looking forward to next year’s event!

Eleni Beveratou:

Huge thanks to my fellow speakers for the inspiring talks, and to the team at Clearleft (Jeremy Keith, Louise Ash, and so many more!) for putting together such a brilliant event.

Videha Sharma:

I’ve loved learning and sharing this week! Feeling super inspired and looking forward to building new friendships!

Carolina Greno:

Last week in UX London I got to witness event planning mastery, I was in awe. Things ran smoothly and people were united under a premise: to share knowledge and build community.

This doesn’t happen by chance, it’s the mastery that pros like Jeremy and Louise bring to the table.

Sayani Mitra

Bold, thought-provoking talks. Hands-on workshops that challenged and stretched thinking. And a real sense of community that reminded me why spaces like this matter so much.

Nina Mathilde Dyrberg:

The conference was packed with inspiration, thoughtful conversations, and a strong focus on accessibility and inclusivity. Thank you Luke Hay, Jeremy Keith, Louise Ash, and the whole Clearleft team for creating such a welcoming and inspiring space!

Craig Abbott:

Jeremy Keith, Richard Rutter, Louise Ash, Chris How, Sophie Count, Luke Hay and the rest of Clearleft, take a bow! Hands down one of the best conference experiences I’ve had!

The curation was excellent, the talks complimented each other so well, it was almost like we’d all met up and rehearsed it beforehand!

ÌníOlúwa Abíódún:

A huge thank you to Jeremy Keith, Louise Ash and the Clearleft team for the opportunity and the brilliant conference you’ve put together.

It’s been inspiring to experience every moment of it.

Laura Dantonio:

Shoutout to the organisers for curating such a rich experience—3 themed days focused on Discovery, Design, and Delivery.

We remember through stories. And this event was full of them. Already looking forward to next year.

And I’m just going to quote Rachel Rosenson’s post in its entirety:

Spoke at UXLondon last week—and while the talks were great, it was something off-stage that really stuck with me.

After the Day 1 talks wrapped, a bunch of us speakers grabbed a drink, and someone pointed out: Every single speaker that day—every one—was a woman. 5 talks. 4 workshops. All women.

And it wasn’t a “Women in Tech” day. It was just… the conference.

No one made a fuss. No banners. No “look at us go!”

Just incredible women, giving incredible talks, like it was the most normal thing in the world. (Spoiler: it should be.)

Jeremy Keith mentioned how frustrating it is that all-male line-ups are still so common—and how important it is to actively design for inclusion. Major props to Jeremy and the Clearleft team for curating a line-up that was intentional without performativity.

It was refreshing. No tokenism. No checkbox energy. Just great voices on great stages. And a big honor to be one of them.

There you are reading an article when suddenly it’s interrupted by a big piece of text that’s repeating something you just read in the previous paragraph. Or it’s interrupted by a big piece of text that’s spoiling a sentence that you are about to read in subsequent paragraphs.

There you are reading an article when suddenly it’s interrupted by a big piece of text that’s repeating something you just read in the previous paragraph.

To be honest, I find pull quotes pretty annoying in printed magazines too, but I can at least see the justification for them there: if you’re flipping through a magazine, they act as eye-catching inducements to stop and read (in much the same way that good photography does or illustration does). But once you’re actually reading an article, they’re incredibly frustrating.

You either end up learning to blot them out completely, or you end up reading the same sentence twice.

You either end up learning to blot them out completely, or you end up reading the same sentence twice. Blotting them out is easier said than done on a small-screen device. At least on a large screen, pull quotes can be shunted off to the side, but on handheld devices, pull quotes really make no sense at all.

Are pull quotes online an example of a skeuomorph? “An object or feature which imitates the design of a similar artefact made from another material.”

I think they might simply be an example of unexamined assumptions. The default assumption is that pull quotes on the web are fine, because everyone else is doing pull quotes on the web. But has anybody ever stopped to ask why? It was this same spiral of unexamined assumptions that led to the web drowning in a sea of splash pages in the early 2000s.

I think they might simply be an example of unexamined assumptions.

I’m genuinely curious to hear the design justification for pull quotes on the web (particularly on mobile), because as a reader, I can give plenty of reasons for their removal.

A recent simplequiz over on HTML5 Doctor threw up some interesting semantic issues. Although the figure element wasn’t the main focus of the article, a lot of the comments were concerned with how it could and should be used.

This is a subject that has been covered before on HTML5 Doctor. It turns out that we may have been too restrictive in our use of the element, mistaking some descriptive text in the spec for proscriptive instruction:

The element can thus be used to annotate illustrations, diagrams, photos, code listings, etc, that are referred to from the main content of the document, but that could, without affecting the flow of the document, be moved away from that primary content, e.g. to the side of the page, to dedicated pages, or to an appendix.

Steve and Bruce have been campaigning on the HTML mailing list to get the wording updated and clarified.

Meanwhile, in an unrelated semantic question, there was another HTML5 Doctor article a while back about quoting and citing with blockquote and its ilk.

The two questions come together beautifully in a blog post on the newly-redesigned A List Apart documenting this pattern for associating quotations and authorship:

<figure>
 <blockquote>It is the unofficial force—the Baker Street irregulars.</blockquote>
 <figcaption>Sherlock Holmes, <cite>Sign of Four</cite></figcaption>
</figure>

Although, unsurprisingly, I still take issue with the decision in HTML5 not to allow the cite element to apply to people. As I’ve said before we don’t have to accept this restriction:

Join me in a campaign of civil disobedience against the unnecessarily restrictive, backwards-incompatible change to the cite element.

In which case, we get this nice little pattern combining figure, blockquote, cite, and the hCard microformat, like this:

<figure>
 <blockquote>It is the unofficial force—the Baker Street irregulars.</blockquote>
 <figcaption class="vcard"><cite class="fn">Sherlock Holmes</cite>, <cite>Sign of Four</cite></figcaption>
</figure>

Or like this:

<figure>
 <blockquote>Join me in a campaign of civil disobedience against the unnecessarily restrictive, backwards-incompatible change to the cite element.</blockquote>
 <figcaption class="vcard"><cite class="fn">Jeremy Keith</cite>, <a href="http://24ways.org/2009/incite-a-riot/"><cite>Incite A Riot</cite></a></figcaption>
</figure>

A recent post on the Twitter developer blog called Changes coming in Version 1.1 of the Twitter API has been causing a lot of consternation amongst developers of Twitter apps (and users of said apps). Now it may well be that a lot of this consternation may be caused by some misunderstandings—the post is not very clearly written.

For example, in the section headed Display Guidelines will be Display Requirements, the following dictum is issued:

We will require all applications that display Tweets to adhere to these. Among them: linking @usernames to the appropriate Twitter profile, displaying appropriate Tweet actions (e.g. Retweet, reply and favorite) and scaling display of Tweets appropriately based on the device. If your application displays Tweets to users, and it doesn’t adhere to our Display Requirements, we reserve the right to revoke your application key.

As it happens, I’ve started recently embedding tweets on my site here using the embed code provided by Twitter. But it seemed pretty clear to me that the new proclamation wouldn’t apply to me: the blog post is talking about usage of the Twitter API. So if you retrieve a tweet using the API, you must display it according to the display guideli—er, requirements. Fair enough.

Just to double-check, I asked one of my (many) friends who work at Twitter. “These display requirements …they don’t apply to me quoting a tweet on my blog, right?”

The answer I got surprised me. Apparently the display guidel… requirements do apply to me. If I want to quote a tweet on my website, I’m supposed to use the embed code to make sure that people can favourite/retweet/follow, etc.

Fuck. That. Shit.

If I want to quote something from another URL, I will do it. I’ll use a blockquote element of course, but I will not be told what markup and JavaScript I must include on my site.

This reminds of those companies that don’t get the web, that have rules in their terms and conditions about how you’re supposed to link back to their website. Twitter’s hammerheaded approach seems remarkably clueless for such a hitherto clued-up company.

I’ve gone back through my previous blog posts where I was using the official embed code and I’ve stripped it out of each and every one. If you are quoting a tweet on your site, I strongly encourage you not to use the offical embed code. I strongly encourage Twitter to stick their display requirements where the sun don’t shine.

Here’s something Jason Kottke said:

I love Twitter the service and I am starting to really dislike Twitter the company.

That’s a tweet. I’m quoting it. I’m not using Twitter’s embed code. I’m not adhering to the display requirements.

Come at me, bird.

Update: So, according to Ryan Sarver the new display gui…requirements only apply to API-retrieved tweets after all (as I first thought). I told him that wasn’t what I heard from a Twitter employee and he said:

We need to be clearer, internally as well.

He went on to say:

We don’t expect every reporter/blogger to do the full thing. However, we do want them to link back to author, attribute, etc.

I said a guideline to that effect would be just fine, but a requirement would not. He agreed, comparing it to journalistic standards and ethics.

I could have linked to those tweets I just quoted from. I chose not to.

Over on the HTML5 Doctor site, Oli has written a great article called Quoting and citing with <blockquote>, <q>, <cite>, and the cite attribute.

Now, I still stand by my criticism of the way the cite element has been restrictively redefined in HTML5 such that it’s not supposed to be used for marking up a resource if that resource is a person. But I think that Oli has done a great job in setting out the counter-argument:

By better defining <cite>, we increase the odds of getting usable data from it, though we now need different methods to cover these other uses.

Oli’s article also delves into the blockquote element, which is defined in HTML5 as a sectioning root.

Don’t be fooled by the name: sectioning roots are very different to sectioning content in a fundamental way. Whereas sectioning content elements—section, article, nav and aside—are all about creating an explicit outline for the document from the headings contained within the sectioning content (using the new outline algorithm), the headings within sectioning roots (blockquote, td, fieldset, figure, etc.) don’t contribute to the document outline at all! But what sectioning roots and sectioning content have in common is that they both define the scope of the header and footer elements contained within them.

The footer element is defined as containing information about its section such as who wrote it, links to related documents, copyright data, and the like.

This gives a rise to rather lovely markup pattern that’s used on HTML5 Doctor: why not use the footer element within a blockquote to explicitly declare its provenance:

<blockquote>
<p>The people that designed .mobi were smoking crack.</p>
<footer>&mdash;<cite class="vcard">
<a class="fn url" href="http://tantek.com/">Tantek Çelik</a>
</cite></footer>
</blockquote>

(and yes, I am using the cite element to mark up a person’s name there).

Well, apparently that blockquote pattern is not allowed according to the spec:

Content inside a blockquote must be quoted from another source.

Because the content within the blockquote’s footer isn’t part of the quoted content, it shouldn’t be contained within the blockquote.

I think that’s a shame. So does Oli. He filed a bug. The bug was rejected with this comment:

If you want the spec to be changed, please provide rationale and reopen.

That’s exactly what Oli is doing. He has created a comprehensive document of block quote metadata from other resources: books, plays, style guides and so on.

Excellent work! That’s how you go about working towards a change in the spec—not with rhetoric, but with data.

That’s why my article complaining about the restrictions on the cite element is fairly pointless, but the wiki page that Tantek set up to document existing use cases is far more useful.

Twitter continues to fascinate. There’s so much wrong with this app—the interface, the documentation, the usability—and yet somehow it exerts a strange hold over all who come in contact with it… for now, anyway.

The site offers a nice feature in the shape of “favorites” (sic), those extra special gems that you’ve plucked from the ebb and flow of Twittery chatter. Here are some of mine:

Kitta: having my legs waxed, trying to explain Twitter and why I just got 4 SMS’s to her, I think she thinks i’m either a drug dealer or a secret agent

Relly: wonders if her husband would fancy her even more with a bargain star tattooed to her butt and a permenant reflection in front of her boobs.

Dunstan: Mmm-mmm, I am now baby-wipe clean… boy I hope they fix my shower soon.

Pete: just took the phone away from the chickens - he’s had enough of the crank calls they keep making…

Anton: thinks of how cool a zeppelin on a monorail would look.

Craig: I sometimes fear that the pinhole iSight built into my MBP is secretly recording me when I pick my nose. Is it just me?

And possibly my favourite so far:

Glenda: On AIM Mobile you can now “snowball a friend.” Oh, REALLY now?