Tags: friends

17

sparkline

Monday, December 5th, 2022

Jamie

Jamie Freeman passed away yesterday.

I first met Jamie as a fellow web-nerd way back in the early 2000s when I was freelancing here in Brighton. I did a lot of work with him and his design studio, Message. Andy was working there too. It’s kind of where the seeds of Clearleft were planted.

I remember one day telling them about a development with Salter Cane. Our drummer, Catherine, was moving to Australia so we were going to have to start searching for someone new.

“I play drums”, said Jamie.

I remember thinking, “No, you don’t; you play guitar.” But I thought “What the heck”, and invited him along to a band practice.

Well, it turns that not only could he play drums, he was really good! Jamie was in the band.

It’s funny, I kept referring to Jamie as “our new drummer”, but he actually ended up being the drummer that was with Salter Cane the longest.

Band practices. Concerts. Studio recordings. We were a team for years. You can hear Jamie’s excellent drumming on our album Sorrow. You can also his drumming (and brilliant backing vocals) on an album of covers we recorded. He was such a solid drummer—he made the whole band sound tighter.

But as brilliant as Jamie was behind a drumkit, his heart was at the front of the stage. He left Salter Cane to front The Jamie Freeman Agreement full-time. I loved going to see that band and watching them get better and better. Jonathan has written lovingly about his time with the band.

After that, Jamie continued to follow his dreams as a solo performer, travelling to Nashville, and collaborating with loads of other talented people. Everyone loved Jamie.

This year started with the shocking news that he had inoperable cancer—a brain tumor. Everyone sent him all their love (we recorded a little video from the Salter Cane practice room—as his condition worsened, video worked better than writing). But somehow I didn’t quite believe that this day would come when Jamie was no longer with us. I mean, the thought was ridiculous: Jamie, the vegetarian tea-totaller …with cancer? Nah.

I think I’m still in denial.

The last time I had the joy of playing music with Jamie was also the last time that Salter Cane played a gig. Jamie came back for a one-off gig at the start of 2020 (before the world shut down). It was joyous. It felt so good to rock out with him.

Jamie was always so full of enthusiasm for other people, whether that was his fellow musicians or his family members. He had great stories from his time on tour with his brother Tim’s band, Frazier Chorus. And he was so, so proud of everything his brother Martin has done. It was so horrible when their sister died. I can’t imagine what they must be going through now, losing another sibling.

Like I said, I still can’t quite believe that Jamie has gone. I know that I’m really going to miss him.

I’m sending all my love and my deepest sympathies to Jamie’s family.

Fuck cancer.

Tuesday, March 9th, 2021

March

March 2020 was the month when the coronavirus really hit the fan for much of Europe and North America.

It’s now March 2021. People are understandably thinking about this time last year. Tantek wrote about this anniversary:

We reached our disembarkation stop and stepped off. I put my mask away. We hugged and said our goodbyes. Didn’t think it would be the last time I’d ride MUNI light rail. Or hug a friend without a second thought.

I recently added an “on this day” page to my site. Now that page is starting to surface events from this time last year.

Today, for example, is the one year anniversary of the last talk I gave in a physical space. Myself and Remy travelled to Nottingham to give our talk, How We Built The World Wide Web In Five Days.

The next morning, before travelling back to Brighton (where we’ve been ever since), we had breakfast together in a nice café.

I wrote:

Eating toast with @Rem.

Usually when I post toast updates, it’s a deliberate attempt to be banal. It harks back to the early criticism of blogging as just being people sharing what they’re having for lunch.

But now I look back at that little update and it seems like a momentous event worth shouting from the rooftops. Breaking bread with a good friend? What I wouldn’t give to do that again!

I can’t wait until I can be together with my friends again, doing utterly ordinary things together. To “wallow in the habitual, the banal” as the poet Patrick Kavanagh put it.

I miss hanging out with Tantek. I miss hanging out with Remy. I miss hanging out.

But I’m looking forward to being in a very different situation in March 2022, when I can look back at this time as belonging to a different era.

Between now and then, there’ll be a gradual, bumpy, asynchronous reintroduction of the everyday social pleasures. I won’t take them for granted. I’ll be posting about toast and other everyday occurrences “wherever life pours ordinary plenty.”

Sunday, September 1st, 2019

Why These Social Networks Failed So Badly

Ignore the clickbaity headline and have a read of Whitney Kimball’s obituaries of Friendster, MySpace, Bebo, OpenSocial, ConnectU, Tribe.net, Path, Yik Yak, Ello, Orkut, Google+, and Vine.

I’m sure your content on Facebook, Twitter, and Instagram is perfectly safe.

Monday, July 15th, 2019

How to run a small social network site for your friends

This is a great how-to from Darius Kazemi!

The main reason to run a small social network site is that you can create an online environment tailored to the needs of your community in a way that a big corporation like Facebook or Twitter never could. Yes, you can always start a Facebook Group for your community and moderate that how you like, but only within certain bounds set by Facebook. If you (or your community) run the whole site, then you are ultimately the boss of what goes on. It is harder work than letting Facebook or Twitter or Slack or Basecamp or whoever else take care of everything, but I believe it’s worth it.

There’s a lot of good advice for community management and the whole thing is a lesson in writing excellent documentation.

Monday, October 20th, 2014

Baby Steps - Petra Gregorová

Petra has always been the strong one. She was the best friend that Chloe could have possibly had. Little wonder then that Chloe’s death continues to hit her so hard.

I still can’t fully comprehend it all nor do I have any idea how to learn to move on. All I know is that ever since the day I found out, I’ve been on an emotional rollercoaster. I go from being in shock, to being sad and angry, or completely numb.

Petra is getting help now. That’s good. She’s also writing about what she has been going through. That’s brave. Very brave.

She is one of the best human beings I know.

Thursday, June 21st, 2012

Aio e Oio: Food for Friendship | Born Hungry

This beautiful piece of writing from Steph is making me hungry.

Friday, March 16th, 2012

Photo Booth - Annie Ray Photo

Pictures from the photo booth at Jeffrey’s Hall of Fame celebration party on the last night of South by Southwest.

Saturday, January 8th, 2011

Facebook hype will fade - CNN.com

Douglas Rushkoff on the repeating circle of life that all big online companies live through.

Wednesday, September 9th, 2009

CSSquirrel : Comic: Kyle Weems

I've been comicified (again), this time with my HTML5 Super Friends.

Monday, August 31st, 2009

HTML 5 Super Friends

My buddies and I express our support for HTML5 ...with caveats ...and unicorns.

Sunday, August 30th, 2009

HTML5 and me

I can never pinpoint the exact moment at which I “get into” a particular technology. CSS, DOM Scripting, microformats …there was never any Damascene conversion to any of them. Instead, I’d just notice one day, after gradually using the technology more and more, that I was immersed in it.

That’s how I feel about now.

There’s another feeling that accompanies this realisation. I remember feeling it about CSS in the late 90s and about DOM Scripting half a decade ago. At the same time as I look up from my immersion, I cast a glance around the web development landscape and ask Why aren’t more people paying attention to this?

In the case of HTML5, this puzzling state of affairs can, to a large extent, be explained by the toxic 2022 meme. Working web developers with an idle interest in HTML5 would google the term, find a blog post telling that it won’t be “ready” until 2022, and then happily return to their work, comforted by the knowledge that HTML5 was some distant dream on the horizon—one that doesn’t affect them in any way today.

Nothing could be further from the truth. The Last Call Working Draft status is (optimistically) planned for October; that’s one month away.

And what rough beast, its hour come round at last, slouches towards Bethlehem to be born?

If you want to have a say in the formation of the most important web standard in existence, don’t put off getting involved. As Bruce says, If you don’t vote, you can’t bitch.

Still, I think the attitude of most web developers towards HTML5 right now is, at the very least, “interested, if a little sceptical”—that’s certainly how I felt when I started dabbling in it.

A little while back, I got together with some of my interested (if a a little sceptical) colleagues in New York, thanks to a generous invitation from Zeldman.

Dan Cederholm, Jeremy Keith, Eric Meyer, Ethan Marcotte, Tantek Çelik, Nicole Sullivan, Wendy Chisholm

After a fairly intense two days of poring over the spec, I think it’s fair to say that, on balance, the interest increased and the scepticism decreased. That’s not to say that everything looks rosy in the current incarnation of HTML5. When you’ve got some of the smartest front-end web developers I know of in the same room together and they all agree that some parts of the spec are confusing or downright wrong, that’s quite worrying.

On the plus side, most of the issues are pretty minor in the grand scheme of things. It’s fair to say that most of the stuff that interests web authors—the semantic side of things—only accounts for a small part of HTML5. Most of the HTML5 specification is about error handling, APIs and shiny new interactive content. There are plenty of programmers and browser makers forging those powerful new tools. But as qualified as they are to hammer out those complex constructs, they are not necessarily the most qualified to make decisions on creating new structural elements. For that, you need the input of authors. And authors have been decidedly slow to get involved with HTML5.

It’s time for authors to get involved. I believe our voices will be welcomed. According to the HTML design principles:

…consider users over authors over implementors over specifiers over theoretical purity.

I’ll get the ball rolling with my own little list of things that are troubling me…

small

I’m with Bruce and Remy. If the small element is being redefined for disclaimers, caveats, legal restrictions, or copyrights, it needs to be handling how that kind of content is published in the wild. That means it needs to be able to wrap paragraphs, lists and other flow content.

Alternatively, it should go the way of its evil twin, the big element, and simply be deprecated …sorry, I mean obsolete and non-conforming.

time

I’ll join in the chorus of people who think that the restrictions on the information that the new time element can contain are unnecessarily draconian. You can encode a date and time, you can encode a date, but you can’t encode just a month and a year. So you can’t make a piece of information like “April 1912” machine-readable. The spec says the time element:

…is intended as a way to encode modern dates and times in a machine-readable way

Which is great. But the sentence doesn’t finish there. It goes on:

so that user agents can offer to add them to the user’s calendar.

That’s one use case! I don’t think it’s wise to rain on the parade of anyone wanting to build, say, timeline mashups. Trying to mandate use cases ahead of time is not just counter-productive, it’s probably impossible. Can you imagine if Flickr had launched their API with strict instructions that it could only be used for one particular purpose?

figure

I have nothing against the figure element itself, although it does seem uncomfortably close to aside, but the insistence on recycling the legend element to handle the caption is problematic.

Don’t get me wrong: I’m all for re-using existing elements rather then creating new ones, and I know that Hixie looked at all the options. But the way that browsers currently treat the legend element makes it unusable outside of a form.

I think that the label element could work instead.

details

Just like figure, the details element reuses legend. In this case, label won’t do the trick. details is an interactive element and it doesn’t look like the label element can be made keyboard accessible.

In this case, as undesirable as it is, a new element may be called for.

article

I’ve got two issues with the article element.

  1. Firstly, its definition sounds awfully similar to section. I’m not convinced that there needs to be two different elements. Having two elements that look like a duck, walk like a duck and quack like a duck is just going to lead to confusion amongst authors wondering which duck to use.

  2. The article element, unlike the section element can take an optional pubdate attribute to encode the publication date. I’m all in favour of having this information be machine-readable but the pubdate attribute smells like dark data, subject to metacrap rottage. In most cases, the publication date will be repeated in the content of the article anyway, so I’m in favour of adding a flag there rather than duplicating data. A Boolean pubdate attribute on a time element within an article header or footer should do the trick.

    Update: Belay that last gripe, ensign. As proof of just how fast this spec moves, less than 24 hours after I published this, Hixie has implemented what I was suggesting.

Speaking of footer, this one is the biggie…

footer

There is a big disconnect between what the HTML5 spec calls a footer and what authors on the web call a footer.

According to the spec, you’re only supposed to put some kinds of content inside a footer:

Flow content, but with no heading content descendants, no sectioning content descendants, and no header or footer element descendants.

That means no nav or headings in footer. The way that the footer element is defined in the spec, it’s a slightly more expanded version of address.

Ah, address! One of the most problematic elements in HTML 4. It is often incorrectly used to mark up street addresses. But is it any wonder? When an element has a name address, it’s hardly surprising that authors are going to use it for marking up addresses. The same thing is going to happen with footer.

The term “footer” was not invented for HTML5. It’s been in use on the web for years and in print for even longer. But if you ask any author to define what they mean by the term “footer”, you’ll get a very different definition to the one in the HTML5 spec. They may even point to specific examples of footers on sites like Flickr or on blogs, where they contain headings and navigation.

To be fair, when the new structural elements were being forged back in 2005, there wasn’t as much prevalence of what Derek Powazek termed fat footers. So when Hixie ran his analytics on a shitload of web pages crawled by Google and found that “footer” was by far the most common class name, most footer content was pretty meagre. But usage changes (see also: time).

The way that the element named footer is defined in HTML5—to be used multiple times in a single document in sections and articles as well as at the document level—is very different from the convention named footer in common usage on the web today. Most of the instances of what authors call a footer are more like what the HTML5 spec defines as aside.

I don’t want to spend the next decade telling authors not to mark up their footers as footers. It was bad enough telling people not to mark up addresses as addresses. In any case, authors aren’t going to listen. If they see there’s an element called footer, they will assume it refers to the device known as a footer, and mark up their content accordingly. At that point, the HTML5 spec will have become a work of fiction instead of documenting what’s actually on the web.

One of two things needs to happen. Either:

  1. The content model of footer is updated to match that of header, which is much more liberal in what it accepts, or:
  2. The name of the element currently called footer should be changed to match the current, restrictive definition. I suggest using contentinfo, which is the name of an existing ARIA role for exactly this kind of content.

ARIA roles, by the way, are an excellent addition to HTML5. ARIA integration is a win for ARIA and a win for HTML5, in my opinion. Most of all, it’s a win for authors who now have a whole swathe of extra semantics they can sprinkle into their documents (and use as styling hooks with attribute selectors).

Thus endeth my list of things I want to see fixed in HTML5. I’m leaving out the massive issue of canvas accessibility because:

  1. that’s beyond my area of expertise,
  2. smarter people than me are working on it, and
  3. I think that canvas would probably benefit from being spun off into a separate spec.

There are other little things that bother me in HTML5—hgroup smells funny, cite shouldn’t be restricted to titles of works, and I miss the rev attribute on links—but those are all personal foibles; opinions unsupported by data. I’d rather concede than argue without data.

Because, make no mistake, data is what’s needed if you want to affect change in HTML5. Despite the attempts to paint Hixie as a stubborn, opinionated dictator, he is himself a slave to data. He shows an almost robot-like ability to remove his own ego from a debate and follow where the data leads.

If you are an author of HTML documents, I strongly encourage you to get involved in the HTML5 process.

  1. Read the spec.
  2. Join the mailing list.
  3. Hang out in the IRC channel.

Like I said, most of the spec and discussion is about APIs rather than semantics, but it’s precisely because the spec isn’t directly aimed at authors that authors need to get involved.

Tuesday, March 10th, 2009

"Social Media is Here to Stay... Now What?"

danah boyd addresses the Microsoft Research Tech Fest.

Tuesday, January 6th, 2009

Tuesday, April 1st, 2008

Flickr: Find your friends

Now this is how to do the "find your friends" trick. For GMail, Yahoo Mail, and Hotmail, Flickr never once asks for your password. Bravo!

Sunday, January 20th, 2008

If all your friends jumped off of a bridge… at Ben Brown, Internet Rockstar

Ben Brown outlines the reasons why he left Facebook: "I think it is important to note that Facebook, though they claim to be a tool for staying connected, is actually a software tool designed *primarily* to deliver marketing messages to its audience."

Monday, November 27th, 2006

HTML Mastery - Semantics, Standards and Styling by Paul Haine

Paul's book will be out in a few weeks. Looks like it'll be a good one.

Sunday, March 26th, 2006

Friendster lost steam. Is MySpace just a fad?

Danah Boyd writes an essay that would've been a blog post but it got too long.