Journal tags: fun

8

sparkline

Fonts or food?

At the end of every Thursday afternoon at Clearleft, we wrap up the working week with an all-hands (video) meeting. Yes, I know that the week finishes on Friday, but Fridays have been declared the no-meetings day at Clearleft: a chance to concentrate on heads-down work without interruption. Besides, some of us don’t work on Fridays. So Thursday really is the new Friday.

At this Thursday afternoon meeting we give and get updates on what’s been happening with project work, new business, events, marketing. We also highlighted any shout-outs that have posted in the #beingsplendid Slack channel during the week. Once that’s all taken care of, the Thursday afternoon meeting often finishes with a fun activity.

The hosting of the Thursday afternoon meeting is decided by fate. Two weeks ago, Rebecca and Chris hosted an excellent end-of-week meeting that finished with an activity around food—everyone had submitted their dream meal and we had to match up the meal to the person. Lorenzo, however, couldn’t help commenting on the typography in the slide deck. “Lorenzo”, I said, “What are you more judgmental about—fonts or food?”

The words were barely out of my mouth when I realised I had the perfect activity for the next Thursday afternoon meeting, which fate had decreed I was to host. I put together a quiz called …fonts or food!

It’s quite straightforward. There are 25 words. All you have to do is say whether it’s the name of a font or the name of a food.

It was good fun! So I thought I’d share it with you if you fancy a go.

Ready?

Here we go…

  1. Arrowroot
  2. Ensete
  3. Tahu
  4. Tako
  5. Lato
  6. Fira
  7. Adzuki
  8. Roselle
  9. Poke
  10. Plantin
  11. Dabberlocks
  12. Estampa
  13. Amaranth
  14. Gentium
  15. Challum
  16. Mayhaw
  17. Pawpaw
  18. Nopal
  19. Raksana
  20. Daylily
  21. Bilanthy
  22. Laver
  23. Orache
  24. Broadley
  25. Cardoon

Total: 0/25

Making things happen

I have lovely friends who are making lovely things. Surprisingly, lots of these lovely things aren’t digital (or at least aren’t only digital).

My friends Brian and Joschi want to put on an ambitious event called Material:

A small conference based in Reykjavik, Iceland, looking into the concept of the Web as a Material — 22nd July 2016, https://material.is

They’re funding it through Kickstarter. If you have any interest in this at all, I suggest you back it. Best bet is to pledge the amount that guarantees you a ticket to the conference. Go!

My friend Matt has a newsletter called 3 Books Weekly to match his Machine Supply website. Each edition features three book recommendations chosen by a different person each time.

Here’s the twist: there’s going to be a Machine Supply pop-up bookshop AKA a vending machine in Shoreditch. That’ll be rolling out very soon and I can’t wait to see it.

My friend Josh made a crazy website to tie in with an art project called Cosmic Surgery. My friend Emily made a limited edition run of 10 books for the project. Now there’s a Kickstarter project to fund another run of books which will feature a story by Piers Bizony.

An Icelandic conference, a vending machine for handpicked books, and a pop-up photo book …I have lovely friends who are making lovely things.

Just what is it that you want to do?

The supersmart Scott Jenson just gave a talk at The Web Is in Cardiff, which was by all accounts, excellent. I wish I could have seen it, but I’m currently chilling out in Florida and I haven’t mastered the art of bilocation.

Last week, Scott wrote a blog post called My Issue with Progressive Enhancement (he wrote it on Google+, which is why you might not have seen it).

In it, he takes to task the idea that—through progressive enhancement—you should be able to offer all functionality to all browsers, thereby foregoing the use of newer technologies that aren’t universally supported.

If that were what progressive enhancement meant, I’d be with him all the way. But progressive enhancement is not about offering all functionality; progressive enhancement is about making sure that your core functionality is available to everyone. Everything after that is, well, an enhancement (the clue is in the name).

The trick to doing this well is figuring out what is core functionality, and what is an enhancement. There are no hard and fast rules.

Sometimes it’s really obvious. Web fonts? They’re an enhancement. Rounded corners? An enhancement. Gradients? An enhancement. Actually, come to think of it, all of your CSS is an enhancement. Your content, on the other hand, is not. That should be available to everyone. And in the case of task-based web thangs, that means the fundamental tasks should be available to everyone …but you can still layer more tasks on top.

If you’re building an e-commerce site, then being able to add items to a shopping cart and being able to check out are your core tasks. Once you’ve got that working with good ol’ HTML form elements, then you can go crazy with your enhancements: animating, transitioning, swiping, dragging, dropping …the sky’s the limit.

This is exactly what Orde Saunders describes:

I’m not suggesting that you try and replicate all your JavaScript functionality when it’s disabled, above all that’s just not practical. What you should be aiming for is being able to complete the basics - for example adding a product to a shopping cart and then checking out. This is necessarily going to be clunky as judged by current standards and I suggest you don’t spend much time on optimising this process.

Scott asked about building a camera app with progressive enhancement:

Here again, the real question to ask is “what is the core functionality?” Building a camera app is a means to an end, not the end itself. You need to ask what the end goal is. Perhaps it’s “enable people to share photos with their friends.” Going back to good ol’ HTML, you can accomplish that task with:

<input type="file" accept="image/*">

Now that you’ve got that out of the way, you can spend the majority of your time making the best damn camera app you can, using all the latest browser technologies. (Perhaps WebRTC? Maybe use a canvas element to display the captured image data and apply CSS filters on top?)

Scott says:

My point is that not everything devolves to content. Sometimes the functionality is the point.

I agree wholeheartedly. In fact, I would say that even in the case of “content” sites, functionality is still the point—the functionality would be reading/hearing/accessing content. But I think that Scott is misunderstanding progressive enhancement if he think it means providing all the functionality that one can possibly provide.

Mat recently pointed out that there are plenty of enhancements on the Boston Globe site that require JavaScript, but the core functionality is available to everyone:

Scott again:

What I’m chaffing at is the belief that when a page is offering specific functionality, Let’s say a camera app or a chat app, what does it mean to progressively enhance it?

Again, a realtime chat app is a means to an end. What is it enabling? The ability for people to talk to each other over the web? Okay, we can do that using good ol’ HTML—text and form elements—with full page refreshes. That won’t be realtime. That’s okay. The realtime part is an enhancement. Use Web Sockets and WebRTC (in the browsers that support them) to provide the realtime experience. But everyone gets the core functionality.

Like I said, the trick is figuring out what’s core functionality and what’s an enhancement.

Ethan provides another example. Let’s say you’re building a browser-based rich text editor, that uses JavaScript to do all sorts of formatting on the fly. The core functionality is not the formatting on the fly; the core functionality is being able to edit text:

If progressive enhancement truly meant making all functionality available to everyone, then it would be unworkable. I think that’s a common misconception around progressive enhancement; there’s this idea that using progressive enhancement means that you’re going to spend all your time making stuff work in older browsers. In fact, it’s the exact opposite. As long as you spend a little bit of time at the start making sure that the core functionality works with good ol’ fashioned HTML, then you can spend most of your time trying out the latest and greatest browser technologies.

As Orde put it:

What you are going to be spending the majority of your time and effort on is the enhanced JavaScript version as that is how the majority of your customers will be experiencing your site.

The other Scott—Scott Jehl—wrote a while back:

For us, building with Progressive Enhancement moves almost all of our development time and costs to newer browsers, not older ones.

Progressive Enhancement frees us to focus on the costs of building features for modern browsers, without worrying much about leaving anyone out. With a strongly qualified codebase, older browser support comes nearly for free.

Approaching browser support this way requires a different way of thinking. For everything you’re building, you need to ask “is this core functionality, or is it an enhancment?” and build accordingly. It takes a bit of getting used to, but it gets easier the more you do it (until, after a while, it becomes second nature).

But if you’re thinking about progressive enhancement as “devolving” down—as Scott Jenson describes in his post—then I think you’re on the wrong track. Instead it’s about taking care of the core functionality quickly and then spending your time “enhancing” up.

Scott asks:

Shouldn’t we be allowed to experiment? Isn’t it reasonable to build things that push the envelope?

Absolutely! And the best and safest way to do that is to make sure that you’re providing your core functionality for everyone. Once you do that, you can go nuts with the latest and greatest experimental envelope-pushing technologies, secure in the knowledge that you don’t even need to worry about the fact that they don’t work in older browsers. Geolocation! Offline storage! Device APIs! Anything you can think of, you can use as a powerful enhancement on top of your core tasks.

Once you realise this, it’s immensely liberating to use progressive enhancement. You can have the best of both worlds: universal access to core functionality, combined with all the latest cuting-edge technology too.

Promo

The lovely and talented Paul and Kelly from Maxine Denver were in the Clearleft office to do some video work last week. After finishing a piece I was in, I suggested they keep “rolling” (to use an anachronistic term) so I could do a little tongue-in-cheek piece about the Clearleft device lab, a la Winnebago Man.

Here’s the result.

It reminded me of something, but I couldn’t figure out what. Then I remembered.

Community service

I returned from Spain at the weekend after a really enjoyable time at Fundamentos Web. The conference was very well organised and had a nice grassroots feel to it (helped, no doubt, by the very, very reasonable ticket price of just €130 for two days!). My sincerest thanks to Encarna, Martin, Andrea and everyone else who helped put the event together. It was an honour to be invited.

After the conference proper, Tantek taught a one-day microformats workshop. I might be a bit biased but I thought he did a great job. But I think I was even more impressed with the audience and the smart questions they were asking.

In fact, the best thing about the conference wasn’t any particular presentation or panel—it was the people. The language barrier didn’t get in the way of having a good ol’ natter with fellow geeks. I was introduced to a Spanish web standards community called Cadius. They have meetups in various parts of Spain to drink and discuss design and development… my kind of people.

I count myself very fortunate to live somewhere where there’s a vibrant real-world community. As I’ve said before, Brighton seems to have an inordinately high number of geeky gatherings. Why, on the very night that I got back from Spain, I found myself playing Werewolf thanks to Simon and Nat. The night after that, I had the pleasure of attending a talk by Steven Pinker (hey, language geekiness is still geeky).

The most recent Brighton geek meetup I attended was the £5 App where local entrepreneurs and developers get together to showcase things they’ve built. This time, it was my turn. I gave a talk on the past, present and future of The Session.

As it turned out, I had quite a lot to say. Without really intending to, I spoke for about two hours, occasionally demonstrating a point by playing a quick jig or reel on the bouzouki. I’m sure I must have bored everyone senseless but once I got started, there was no shutting me up. I touched on some of the technical aspects of the site but mostly I focussed on the community side of things, recounting how sites like Fray inspired me to start getting stuff out there—if there was one downside to being at Fundamentos Web last week, it was that I didn’t get to see Derek Powazek who was in London for The Future Of Web Apps.

I decided to forego slides for my £5 App presentation but I did put together an outline of points I wanted to make. I hope I managed to put the site in context of the aural and written history of Irish traditional music, focussing in particular on the rip-roaring tale of . For the record, here’s the outline in format:

  1. Irish traditional music
    1. Itinerent harpers, e.g. Carolan composed tunes.
    2. Traveling dancing masters. Pipes, fiddles, flutes and whistles.
    3. Dance music:
      1. Jigs—East at Glendart
      2. Reels—The Wind that Shakes the Barley
      3. Hornpipes—The Rights of Man
      4. Slip Jigs—Hardiman the Fiddler
      5. Polkas—Jessica’s
      6. Slides—O’Keefe’s
    4. Usually no known composers.
    5. Aural transmission.
  2. Francis O’Neill
    1. 1848: Born on August 28th in Tralibane, County Cork.
    2. 1865: Ran away to sea. Mediterranean, Dardanelles, Black Sea.
    3. 1866:
      1. Liverpool to New York on the Emerald Isle (meeting his future wife, Anna Rogers).
      2. New York to Japan on the Minnehaha.
      3. Shipwrecked on Baker’s Island.
      4. Rescued by the Kanaka crew of the Zoe: 34 days to Hawaii.
    4. 1869: Teaching in Missouri before moving to Chicago (sailing the Great Lakes).
    5. 1873: Sworn in as a policeman. Shot a few months later by a gangster (bullet never removed).
    6. 1901: Chief of Police.
    7. 1903: The Music of Ireland.
    8. 1905: Retires.
    9. O’Neill’s 1001: “The Book”.
  3. Pub sessions
    1. 1947: The Devonshire Arms, Camden, London.
    2. No set lists. Not the same as jamming.
  4. Folk Revival
    1. 1960s: Sean O’Riada, The Chieftains, Planxty.
    2. 1970s: The Bothy Band.
  5. The Internet
    1. Mailing lists like IRTRAD-l.
    2. ABC format.
  6. The Session
    1. 1999? Original site with no domain
      1. Very little interaction.
      2. Weekly updates: a new tune.
      3. Email subscribers.
    2. Relaunch, June 3rd 2001, thesession.org
      1. Member profiles and tunebooks.
      2. User-submitted tunes, recordings and links.
      3. Discussions.
    3. Incrementally:
      1. Sessions.
      2. Events.
  7. Community management
    1. One rule: Be civil.
    2. A little attention every day.
    3. Benevolent dictatorship.
  8. Tech specs
    1. LAMP: Linux Apache MySQL PHP
    2. Edit in place for admins… just me.
    3. JavaScript for progressive disclosure, faux pop-ups for forms
    4. Ajax for pagination.
    5. Lean, mean standards-based markup is good for SEO.
    6. Minimal use of graphics means speed, even on dial-up.
  9. Show me the money!
    1. Tip jar.
    2. Amazon shop.
  10. The Future
    1. More network effects from more user data.
    2. Travel section?
    3. Ratings?
    4. Better back-end code. An API?
    5. Expose more data like most popular tunes.

Lock up your data

There have been a number of experiments carried out to investigate the effects of video on communication. I recall hearing about one experiment done with mothers and babies. The mothers were placed in one room with a video camera and the babies were placed in another room with a monitor showing a video feed from the mother. The babies interacted just fine with the video representations of their mothers. Then a one second lag was introduced. The babies freaked out.

I was reminded of this during the closing panel on day two of Fundamentos Web. Tim Berners-Lee dialed in via iChat to join a phalanx of panelists in meatspace. Alas, the signal wasn’t particularly strong. Add to that the problem of simultaneous translation, which isn’t really simultaneous, and you’ve got a gap of quite a few seconds between Asturias and Sir Tim’s secret lair. The resultant communication was, therefore, not really much of a conversation. It was still fascinating though.

Some of the most interesting perspectives came from George and Hannah—the people who are working at the coalface of social media. George asked Sir Tim for advice on the cultural side-effects of open data—how to educate people that publishing on sites like Flickr means that your pictures can and will be viewed in other contexts. Interestingly, Sir Tim’s response indicated that he was more concerned with educating people in how to keep their data private.

This difference in perspective might be an indication of a generation gap. The assumption amongst, say, teenagers is that everything is public except what they explictly want to keep private. The default assumption amongst older folks (such as my generation) is the exact opposite: data is private except when it is explictly made public. The first position matches the sensibilities of Flickr and Last.fm. The second position is more in line with Facebook’s walled garden approach.

I was really glad that George raised this issue. It’s something that has been occupying my mind lately, particular in reference to Flickr.

Flickr provides a range of ways of accessing your photos; the website, RSS, KML, LOL… and of course, the API. It’s a wonderful API, certainly the best one that I’ve played with. I had a blast putting together the Flickr portion of Adactio Elsewhere.

Using the API, I was able to put together my own interface onto my photos and the latest photos from my contacts. There’s nothing particularly remarkable about that—there are literally hundreds, if not thousands, of third-party sites that use the Flickr API to do the same thing. However, a lot of those sites use Flash or non-degrading Ajax. But I use Hijax. That means that, even though I’ve built an Ajax interface, the fundamental interaction is RESTful with good ol’ fashioned URLs. As a result—and this is just one of the benefits of Hijax—the Googlebot can spider all possible states of my application.

You can probably see where this is going. It’s a similar situation to what happened with my pirate-speak page converter. Even though I’m not providing a direct interface onto anyone’s pictures, Google is listing deep links in its search results.

This has resulted in a shitstorm on the Flickr forum. Reading through the reactions on that thread has been illuminating. In a nutshell, I’m getting penalised for having search-engine friendly pages. I, along with some other people on that thread, have tried to explain that Adactio Elsewhere is just one example of public Flickr data appearing beyond the bounds of Flickr’s domain—an issue tangentially relatred to intellectual property rights.

In this particular sitution, I was able to take some steps to soothe the injured parties by creating a PHP array called $stroppy_users. I also added a meta element instructing searchbots not to index Adactio Elsewhere which, I believe, will prevent any future grievances. As I said in the forum:

If a tree falls in the forest and Google doesn’t index it, does it make a noise?

I think the outburst of moral panic on the Flickr forum is symptomatic of a larger trend that has accompanied the growth of the site’s user base. Two years ago, Flickr was not your father’s photo sharing website. Now, especially with the migration from Yahoo Photos, it is. If you look at some of the frightened reactions to Flickr’s pirate day shenanigans you’ll see even more signs of this growth (Tom has a great in-depth look at the furore).

As sites like Flickr and Last.fm move from a user base of early adopters into the mainstream, this issue becomes more important. What isn’t clear is how the moral responsibility should be distributed. Should Flickr provide clearer rules for API use? Should Google index less? Should the people publishing photos take more care in choosing when to mark photos as public and when to mark photos as private? Should developers (like myself) be more cautious in what we allow our applications to do with the API?

I don’t know the answers but I’m fairly certain that we’re not dealing with a technological issue here; this is a cultural matter.

Web Fundamentals

Day one of Fundamentos Web just wrapped up here in Gijón.

I got my talk out of the way pretty early on: I was the second speaker, right after Bert Bos. He invented CSS; I… um… build websites… sometimes.

Not everyone was listening to the simultaneous translation. I estimated that less than 50% of the audience were wearing headphones (I’m assuming that they weren’t all listening to their iPods). Either way, I made a conscious effort to speak slowly. In fact, I overdid it a bit and over-ran. If recollection serves, that’s something I’ve never done before.

I played it pretty straight, leaving out a lot of jokes and culturally-specific references. I couldn’t tell whether the audience was completely bored or just paying close attention. People came later and told me they liked it so I hope it was the latter.

One person who told me that I made Ajax understandable was my interpreter. I thanked her for the compliment but I was kind of surprised. When I’ve talked to interpreters, I got the impression that the key to simultaneous translation is to become a conduit—to remove yourself (literally your “self”) from the equation. So I’m amazed that my interpreter, Priscilla, was able to translate and pay attention to the content at the same time. But then, I’m somewhat in awe of the ability to do simultaneous translation. As Priscilla said, when it’s done really well, it’s invisible—kind of like what Jared says about good design.

I wonder how Priscilla managed to cope with the talk after mine. If you’ve ever seen Jeff Veen talk, you’ll know that he’s quite animated. I must find out how she translated “Tingle Fizz.” Jeff managed to out-do my pitiful attempt at localisation: I just translated some slides; he gave a short speech in Spanish (although that’s still not quite as impressive as Joe’s Icelandic benediction).

The day wrapped up with an impressive panel of representatives from browser vendors: Microsoft, Mozilla, Opera, Konquerer and Nokia, moderated by Bert.

I noticed a certain dichotomy in the panel (dichotomy is a milder word than hypocrisy).

There was a lot of talk about standards and innovation and debates about what features browsers should implement. The general concensus was that browsers should implement what the developers are asking for… or, even better, implement what developers are actually doing.

That’s fine. It sounds great in theory. But the reality that I saw was that each browser vendor had their own hobby horse. For some, it was SVG. For others, it’s canvas. The actual technology is irrelevant. That reality conficts with the theory: instead of implementing what’s relevant, browser vendors sometimes push their own agendas. That’s all well and good but the real problem arises because those browser makers are W3C contribitors. Those hobby horses don’t get checked at the door. The result is that browser verndor politics end up having a big influence on the W3C process—they become W3C politics. And who gets the blame? The W3C.

I started typing this in the hotel bar in Gijón and, as I was writing, the browser representatives one-by-one showed up. So now I’ve ended up having this rant IRL as well as having a good ol’ blog rant.

Ah, that feels better.

Update: You can download the slides of my presentation and scoff at my attempts at localisation.

España

I’m about to head off to Gatwick airport and catch a flight to Spain. I’m going to the Fundamentos Web conference in Gijón in the prinicipality of Asturias, somewhere I’ve never been. I was asked to speak last year but it was right after Web Directions South and I didn’t want to cut short my trip to Oz. This year I face no such dilemma so I jumped at the chance.

I’ll be speaking about Ajax. Nothing new there. What is new is that most of the audience will be non-native English speakers who will be relying on an interpreter for simultaneous translation. I wonder if I should adjust my presentation style accordingly (like, maybe slow down a bit). I’ve already tried to localise my slides; because most of my slides consist of one great big word, I’ve tried to get that word translated into Spanish (of course that doesn’t apply to coding terms like XMLHttpRequest). It remains to be seen how successful my attempts at cultural sensitivity turn out to be.

I’ll be landing in Asturias fairly late this evening and then speaking early tomorrow so I’ll need to hit the ground running. Pre-presentation nervousness has already begun and I haven’t even left Brighton yet.