fberriman

Despite my advertising myself as a front-end developer, writing a lot of HTML and JS, I find my most productive days taken up considering and designing digital products and services, ideally with data and evidence.

I enjoy it a lot, but it as left me with a bit of a “am I a developer or designer?” identity crisis.

Colleagues suggest I’m in denial about being a designer – mostly because I’m not a visual designer; I don’t do pictures and graphics and I don’t wield photoshop as my tool of choice – I work in-browser. They also suggest that if I don’t start labelling myself better, I won’t be able to continue finding work doing the sorts of things I enjoy, which it turns out are mostly around supporting and, sadly, defending the user.

If I’m honest, I think I have actually just always had a bit of a problem with designers.

I unfairly (despite being very much into, and doing, art throughout my life) considered “design” to be a soft subject – engineering being the one with the greater level of difficulty. Wrong assumption, I realise, but easily encouraged during my time with computer scientists during my degree years where the concept of service design for the human-being end of software was treated as a “nice extra” and usually quite glossed over.

Along with the engineering bias, the industry as I entered it wasn’t exactly doing much for changing those wrong assumptions. When I started out, I had, as many people did in the early 00s until relatively recently, a lot of up-hill conversations and experiences with designers who were traditionally working in print and had somehow found themselves on the web, and they were doing a pretty crappy job of it.

They didn’t get it.

Those of us building websites then, early adopters of proper web-standards and sites that worked for lots of different kinds of users, tried desperately to make them understand that this isn’t print and it is a flexible, changing, growing, responsive, versatile, medium. They didn’t get it. We fell out. I had some fairly horrible run-ins with the then design director in my first job as a junior developer… Every day I am glad my current one can take me calling him an idiot and see it as a positive (not snark, genuine <3).

So, all that had left me with a fairly bitter taste. I very much knew that in my career, I not only wanted to distance myself from people who didn’t get it, but also myself from being anywhere near them in terms of the work I did, which is pretty much why I have always very clearly said “I do the code, I don’t do the design”. I’m not one of them. As if there should ever really have been a them and us.

It has meant I have had to push back into the “design” aspects of organisations I work for, because I hadn’t aligned myself from the start as part of the design team, where most of the user-orientated decisions tend to get made (which, I do think, is a mistake on most organisations part… designing for your users should be a concern from everybody on your team, no matter their role).

I think all developers should be more engaged with the overall site experience, but I realise that specialisms exist and some of us want to be nearer to that area than others. I’m one of those people who wants to make design decisions as well as code them up where I can. I want to have my cake and eat it too.

In hindsight, the problem was never really the art director when I was a junior. It wasn’t the designers that didn’t want to include me in decisions because I was a developer. It was the organisation, like many others at the time, as a whole not getting it. It’s part of the reason why it’s been great to work with other people over the years that have got it, allowing me to do the things I like and change early biases, and most recently at the Government Digital Service where I honestly believe they get it better than anyone I’ve ever worked for before. And that’s not just down to the amazing people they’ve hired – they get it at a basic level in the ethos of the department. My current contract may say “software engineer” but I am in the design team and like it very much.

I don’t really want a label. I hate labels. I loathe the term “user experience designer”, because I still believe that “user experience” is just a fundamental to what you’re doing, and shouldn’t need stating. There is nothing but user experience design if you’re building products for people.

I have a sneaking suspicion that’s what I am though and probably have always been, in the wide world of jobs people are already doing. User experience service product developer maker dogsbody thing. I am a designer who writes code, who will defend better user experiences and probably be able to tell you how to get them. But I still won’t do the pictures. Deal?

As promised, here’s a list of the resources and links and other stuff I mentioned today at TXJS in my talk

• Government Digital Service Design Principles
• Designing for Usability (pdf) – IBM
• Design Processes, Not Interfaces – Tiffany Conroy
• Designing in Browser – Divya Manian
• Interview with Jonathan Ive in the Telegraph

If I mentioned anything else you’d like more background on, leave a comment and I’ll find you further resources or explanation.

And my slides are available here on slideshare, although obviously my notes on the slides may be a bit too scrappy for you to re-follow along, so I’ll post a link to the video when that’s available.

A normal conversation in the GovUK (or any office I frequent) today went*: “Can we get some microformats on that page?”, I suggest as I spot a section of our site outputting a boat-load of addresses. “No problem – but what’s this about schema-org?”. “Yeah, yeah.. we can hedge our bets and throw their mark-up in there too, it’s just some extra itemprops. *flippant scoff* I’ll send you a complete snippet example, because I’m just nice like that.”

And that’s what I did. And it looked like this:

<div itemscope itemtype="schema.org/Organization">
  <p itemprop="name">Department for Transport</p>
  <p itemprop="address" itemscope 

itemtype="schema.org/PostalAddress">
    <span itemprop="streetAddress">
      <span>Great Minster House</span>
      <span>76 Marsham Street</span>
    </span>
      <span itemprop="addressLocality">London</span>
      <span itemprop="postalCode">SW1P 4DR</span>
  </p>

    <p>Telephone: <span 

itemprop="telephone">0300 330 3000</span></p>
    <p>Website: <a class="www.dft.gov.uk" 

itemprop="url">www.dft.gov.uk</a></p>
    <p>Email: <a 

class="mailto:firstname.surname@dft.gsi.gov.uk" 

class="email" itemprop="email">firstname.surname@dft.gsi.gov.uk</a></p>
</div>

Holy massive-code-snippet batman. I was surprised by the size. I know, I can feel people digging up links already on attack and defence of “bloat” when using microformats alone, but seriously guys, IT’S HUGE. I felt guilty saying “this is what you’ve gotta add to get this mark-up to mean something“. Here’s a more broken down comparison:

Here’s the address, raw, at just over a tweet’s worth (167 chars):

Department for Transport
Great Minster House
76 Marsham Street
SW1P 4DR
Telephone: 0300 330 3000
Website: www.dft.gov.uk
Email: firstname.surname@dft.gsi.gov.uk

Here’s the address with the elements on it to get at the separate pieces of the address, bringing us up to 356:

<p>Department for Transport</p>
<p>
  <span>Great Minster House</span>
  <span>76 Marsham Street</span>
  <span>London</span>
  <span>SW1P 4DR</span>
</p>

<p>Telephone: 0300 330 3000</p>
<p>Website: <a class="www.dft.gov.uk">www.dft.gov.uk</a></p>
<p>Email: <a class="mailto:firstname.surname@dft.gsi.gov.uk" 
>firstname.surname@dft.gsi.gov.uk</a></p>

Now let’s throw some classes on to those and get a bit of meaning in there (I mean, you may want to style them up, get things on new lines etc etc. so using the microformat classes are handy for that alone.**). We’ve got a vCard, people! (565):

<div>
  <p>Department for Transport</p>
  <p>
    <span>Great Minster House</span>
    <span>76 Marsham Street</span>

    <span>London</span>
    <span>SW1P 4DR</span>
  </p>

    <p>Telephone: <span 

class="tel">0300 330 3000</span></p>
    <p>Website: <a class="www.dft.gov.uk" 

class="url">www.dft.gov.uk</a></p>
    <p>Email: <a 

class="mailto:firstname.surname@dft.gsi.gov.uk" 

class="email>firstname.surname@dft.gsi.gov.uk</a></p>
</div>

And now let’s make it schema-org friendly using microdata (863):

<div itemscope itemtype="schema.org/Organization">
  <p itemprop="name">Department for Transport</p>
  <p itemprop="address" itemscope 

itemtype="schema.org/PostalAddress">
    <span itemprop="streetAddress">
      <span>Great Minster House</span>
      <span>76 Marsham Street</span>
    </span>
      <span itemprop="addressLocality">London</span>
      <span itemprop="postalCode">SW1P 4DR</span>
  </p>

    <p>Telephone: <span 

itemprop="telephone">0300 330 3000</span></p>
    <p>Website: <a class="www.dft.gov.uk" 

itemprop="url">www.dft.gov.uk</a></p>
    <p>Email: <a 

class="mailto:firstname.surname@dft.gsi.gov.uk" 

class="email" itemprop="email">firstname.surname@dft.gsi.gov.uk</a></p>
</div>

And we’re done. All I wanted to do was say “this, dear Computer, is an address”. Just getting some frankly useless out-of-the-box HTML elements on the raw data more than doubles it’s size (167 to 356), then we double it again to actually make it useful.

Now, I know size isn’t everything, and this is a pedantic, slightly silly, and probably less than accurate example. We’re not crazy obsessed with keeping our pages below a certain size anymore (Ah… I remember back when the BBC S&Gs insisted that every page had to be less than 200k down the wire including script and CSS AND images. Those were the days.), but it’s not something to be sniffed at either. Particularly with mark-up. Increased size probably suggests increased complexity – more work for everyone, more chance of someone bungling the order or nesting, more simply “I can’t be bothered”. Colour me dubious. I just want to highlight how much we add on to HTML to make it actually do what we need.

Itemscope and itemtype, a brief diversion

I had one of those Am I crazy, but why are there two properties on these things? moments. When would you ever use one without the other? The spec says you can use itemscope alone, but without itemtype, it’s a bit meaningless. I think I’d do away with itemscope and have itemtype only but with a value, either a URI or something meaningful to the internal vocabulary. itemscope seems to exist solely to say “the things in side me are related”, but by the very nature of it being the parent of those items, that’s already implied, and with a class name of something meaningful (say, hcard), or just the itemtype (with a useful value), explicit to data consumers.

This isn’t sarcasm: I would gratefully receive an explanation as to why there are two attributes instead of one.

Back in the room: Is this seriously what we expect authors to do?

I think I’m still struggling to understand why microdata is a separate specification (or even exists if it’s not being used as a mechanism to get stuff into HTML long-term). You can achieve exactly this richness with the current attributes supplied in HTML, and I don’t even mean just the microformats class way. The data- attribute is pretty handy, though, and seems ripe for stuffing with machine data (why shouldn’t it take a URI if you really need it?).

But I digress.

Microdata with schema-org is solving a problem we’ve already solved in microformats, but in an equally not-quite-there way (having to specify itemtype with a URI more than once in a page for items that are the same, but not within the same parent, feels filthy, for example). They are just as bad as each other, in slightly varying ways. Useful for proving a point, allowing growth and putting out examples (not that all of these bonuses are currently being made the best of), but crappy if this is all we can muster for the long-term, high-volume, regularly published, data representation patterns in HTML. We’re asking authors to jump through hoops still for things they shouldn’t have to.

Microformats, schema-org, whatever… is this really our game plan now? Just keep throwing ever more bloat into already creaking elements when you just want to do something really common? What’s the strategy for getting this stuff out of this mess and into the language?

You might be asking why bother aiming to get those stronger patterns into HTML, if this mechanism basically works for getting a machine to figure out what the hell you’re trying to say, but you may as well be asking why you have any semantically meaningful elements in HTML at all if that’s the case. HTML version 5 is redefining some elements to have better semantic meaning because HTML is the language of authors, and to authors and consumers meaning matters.

Without a plan for gathering evidence for popularly used patterns directly from microformats or microdata (and using them as formal methods of research, testing and development), or what people (actual, real developers – not just the big search engines) are doing in general, we’ll end up with no progress or the wrong progress in HTML, and I believe that a formal process for how and when this happens should be made (i.e. definitions of what constitutes critical mass of common patterns, how the information should be gathered, how they will be proposed formally in the WG and promoted into the language proper, etc.).

I want evidence-based HTML that will evolve using clearly defined mechanisms.

*Conversation shortened and re-written with an artistic license and possibly some (many; “nice” may be a stretch) inaccuracies.

**Yes, I’m casually suggesting that microformats are “free” if all you want to do is get your stuff out there with the minimum you’ll need to be machine-friendly and human-eyes-pretty.

On the side

• Categories

  • Books
  • Craft
  • Design
  • external posts
  • Film
  • Games
  • Illustration
  • Life
  • Microformats
  • Music
  • Site
  • Speaking
  • Travel
  • Web Dev
  • Website

• Me Elsewhere

  • Dopplr
  • Flickr
  • Github
  • Instagram
  • Jam
  • Lanyrd
  • Last.fm
  • LinkedIn
  • Lytro
  • oo5
  • Tumblr
  • Twitter

• Search

• RSS Feeds

  • All posts
  • All comments