Conquer the command line with a hands-on bash workshop!

2007-05-24: widgets to the left, widgets to the right...

For a long time I really couldn't get into widgets. I found them too clunky for the functionality they offered - a bad ROI. Konfabulator in particular was not kind to my aging PC's performance.

But then two things happened: I got a second monitor at work and installed some Opera widgets. So no I use a few widgets - some obvious stuff like the weather and the fuzzy clock; plus some very niche stuff like Stay Secure.

The extra monitor was a no-brainer - that just gave me extra room to have widgets in view. The real kicker was having the widgets piggyback my browser - something I'm running all day anyway.

With all the options out there for widgets, Opera has two big advantages going: first, it doesn't require a whole new platform on your computer. If you have Opera, you already have the platform. Second, they're cross-browser and from what I'm told will ultimately be cross-device as well courtesy of Opera Mobile.

Opera have put widgets right where you've already installed software - you can just hit widgets.opera.com and away you go. Of course, if you have OSX or Vista you might choose their widget offerings for much the same reason.

spoiled for choice

So anyway, I know I'm late to the widgets party. But there are an awful lot of users out there who haven't even heard about them yet, or just don't really know where to start.

It's a classic barrier to adoption: widgets sound techy and more than a little geeky; there are lots of competing options, with no clear differentiation for the casual observer; and you have to install stuff before you really know whether you want it.

I was trying to give someone a "quick overview" of widgets a couple of weeks back. I dashed off what was supposed to be a quick email. It took a whole screen just to list and describe the widget engines I could remember off the top of my head (don't look at me like that, they actually needed the info - I wasn't doing a misguided geek braindump!).

If you're an average user, you probably don't even modify your browser settings - much less install add-ons, widgets and customisations. There are plenty of users out there who haven't really got their heads around XML feeds. Can you imagine their confusion trying to figure out widgets?

Then from the publisher's perspective, with all these options how do you pick a widget to release?

don't look now, it's another cowpath thing

Realistically you have to offer widgets wherever people are already using them - even if it is still a wide range of options with small user bases. If someone's not using widgets yet, chances are they're not going to be starting just for you - they'll keep using whatever they're already comfortable with, even if that means visiting your site randomly via in-browser bookmarks.

About the best thing you can do is find all the widget engines you think have a decent user base and release a widget for all of them. With all the quirks and weirdness, you could be spending a lot of time making widgets.

it's like we need a standard or something

A standard format would definitely be useful here - something like the Netvibes Universal Widget API (hat tip to Lachlan for that one). It remains to be seen whether UWA will become a standard, or if everyone will just publish their own "standard" leaving us no better off than before (RSS anyone?).

people are tired of beige boxes

Perhaps widgets will encourage more average, non-geek users to customise their computer. I've observed over the years that a lot of people really are nervous about using computers, while others are simply disinterested. I have a vague theory that only fear could drive someone to put doilies on a computer monitor, but that's probably more about my view of doilies ;)

I don't think fear is too strong a word - people are still worried they could "break the computer" by pressing the wrong key. It doesn't help that current affairs TV spots regularly scream about privacy and security online.

So anyway - whether they're afraid or just ambivalent, a lot of people don't get much enjoyment out of the computer. Even so there's a good chance they're stuck using it all day at work anyway.

giving the humans a look in

Being able to whack the weather, traffic report and your favourite newsfeed right on the desktop gets people to engage with their computer a bit more. It lets them get useful information (or fun, useless information) and gives a simple opportunity to make the machine a bit less threatening (or boring). The computer might be forcing them through the agonies of spreadsheets, but it can also tell them they need an umbrella at lunchtime and to avoid the freeway on the way home because it's backed up for miles.

Sure you can get that info from websites, but widgets are right there already. They're little bite sized bits of web.

To think of it another way, widgets are about the user. They're generally free, most of them are still free of overt advertising. They just fun, or useful, but most of all personal. It's technology which actually does something nice for the humans. Which is a nice change.

So anyway, there's a lot of potential in widgets - if only users can be convinced to use them. Here's hoping a clear standard format emerges to make it easier to give the people what they want...

2007-05-17: limits vs. creativity

Most standardistas encounter the "standards and accessibility limit creativity" argument at some stage. Yes, even in 2007. In fact these days it often morphs into "don't criticise AJAX just because it's not accessible", but I'll save that rant for another day.

Personally I don't think standards compliance adds any limitations beyond the natural limitations of the web (all media have their limits). But even if it did, does that prevent creativity?

rewind...

ansi art - mpc by sq2 ansi art - conspiracy by sq2 ansi art - perpetual winter by sq2

ANSI art by sq2 of esquemedia.com. Cheers for the permission, Rauri!

I've seen some impressive artistic results from people using limited media. One of the greatest and certainly an influential example in my life was ANSI art. ANSI is a joy I recall from BBSes, back in the day when my internal 14400 modem was hot and my computer's hard drive had less capacity than my current thumb drive.

ANSI was the basis for BBS interfaces, with a whole 16 foreground colours, 8 background colours and 256 characters. Shading was achieved using using combinations of foreground and background colours, a very small number of dithered blocks and the four half-filled blocks. That's it.

Big chunky blocks of colour couldn't possibly produce great art, right? Well no, actually here was an entire international art scene devoted to ANSI art. Plus if you ran a BBS, you had to have a great scroller for when you logged in. So people pushed the boundaries far beyond expectation, they took an incredibly limited medium and created rich artwork.

In a way, ANSI artists worked hard to produce great work because the medium was limited. It took skill to create a great ANSI artwork. You really couldn't fake it, although many people tried. So the greater the skill and the greater the kudos for producing an elite ANSI.

back to the present

I was reminded of ANSI art when I saw the results of The Man In Blue's blobular competition (the peacock is definitely my favourite).

The medium allows for blobs of colour. That's it. Did that create a limitation which prevented great work? No! Instead artists looked at the possibilities - the potential of the medium.

peacock - Blobular

I think the peacock demonstrates that well-executed artwork uses the given medium to the best advantage. For best results work with the medium, don't struggle against it.

The point? The limits of a medium simply define the creative space. They don't prevent people being creative within that space.

standards aren't limiting

Web standards just don't limit creativity the way people claim they do. You aren't prevented from producing great web pages just because you make them validate. Standards-based pages don't have to look like useit.com. CSS Zen Garden has proved this ad nauseum.

If you work in the web you have to accept the medium for what it is. You need to accept its limits, play to its strengths and try not to bring unrealistic expectations to the table. You have to accept that you need to make things validate and make them accessible, then add the funky design and behaviour over the top.

Sure, the web isn't a perfect medium. There's no such thing as a perfect medium! Print, photography, video, paint, music... they all have problems. Watercolours can run and ruin a wash; photos can get overexposed; printing presses can screw up colours; guitar strings can break during a gig.

Every medium has limitations. Part of creativity is getting around them and coping with the problems.

So anyway... that's my response to the claim that standards and accessibility mean you have to create boring pages. A canned answer to a canned question ;)

2007-05-12: what i want from a new markup spec

So it has come to pass that the W3C has decided to take the WHATWG's HTML5 on board. It will form the basis of the W3C's HTML5. The goal is to have a public draft by June - yes, this year. Given that the spec now has to endure the full process of the W3C we'll see how that goes.

Anyway, this got me to thinking: what do I really want from a new markup specification? I've talked about this before but I realised that there's a difference between what I want and what I actually hope for :)

Ultimately it comes down to quite a small subset of the overall picture - the things I genuinely wish for in daily life. There are a few elements I'd like to see created or simply supported consistently by browsers.

basics

These are the basics, the minimum additions to fill in some blanks left by HTML 4.01.

  • An extensible, contextual heading/section system
  • A way to associate a CAPTION (or LABEL) with images and lists
  • Footnotes (which are really endnotes on the web)

It's a short list, since the reality is that the lack of decent CSS support impacts on my daily life far more than the limitations of markup. Frankly most developers out there still haven't mastered the semantics of HTML 4.01 so it's not like adding more elements will stop people making tag soup.

Meanwhile, semantics geeks like me will keep searching for the secrets of semantic alchemy with compounds and microformats. Where the markup is deficient we have ways of adding more meaning.

Although this is not an addition to a spec... I'd like to see real support for OBJECT so (amongst other things) we can replace images with the complex explanatory content required for complex graphics. Since certain popular browsers can't cope with this element, we still essentially don't have it.

headings

On the topic of headings, HTML5 does not do what I want since it still relies on H1-H6. I gather the HEADER element is meant to do some kind of section marking but frankly on a first reading it doesn't make a heck of a lot of sense. It certainly doesn't introduce any obvious practical benefit.

XHTML2's H and SECTION system is exactly what I want. I regularly wish I could write a code fragment with a heading, without having to know the heading rank. With the H/SECTION system, I could just define the fragment as a section and know that the heading rank will be sorted out in-situ.

If you maintain a small, stable site, headings may not have ever been an issue. But if you have ever maintained the code base for a very large site, you're probably nodding your head ;)

Even for a small blog headings are a problem. In your average blog the top two heading ranks are probably handled by the site template and CMS; but subheadings in actual posts have to be written in directly with heading tags. So you're probably inserting H3 tags right into your content. Too bad if you later want to change the post pages to have the post title as the H1 - then you'd have a jump from H1 to H3. You either have to stick with the original structure; or you have what I consider an invalid heading rank jump.

Consider the same blog, with H/SECTION... you can adjust the structure around the post as much as you like - it doesn't matter. The sections and corresponding heading ranks take care of themselves.

Headings aren't glamorous. They're not uber-funky AJAX-friendly form inputs which will sparkle in the sun and inspire dancing in the street. They are bread and butter elements which we use every day. HTML has never made them easy to work with, so like it or not they would be a killer app for a markup spec.

exclusions

In addition to what I do want, I think it's important to think about what a spec excludes. I think it's high time for specs to stop weakly deprecating things and flat-out remove them. I'd kill off the semantically neutral and visual-design-based elements - FONT, B, I, S, U etc... and definitely no get-out-responsibility-free cards for WYSIWYG editors!

The spec should just have them treated and rendered the same as SPAN. They're all semantically meaningless and can be replaced either with CSS or semantically-meaningful elements.

I should note that by my reading, WHATWG's HTML5 deals with B and I by creating semantic meaning for them. While that approach has some merit, I doubt the majority of developers will alter their usage according to the new semantics so those elements' usage will just be incorrect for new reasons. If everyone out there was to adopt the new semantics, I'd probably support the approach :)

wish list

These are things I want, but in the balance of things they're not the first things I'd argue to have included. That's the basics list :)

  • A dedicated caption or group label for sets of radio buttons - FIELDSET and LEGEND don't really work for long descriptions.
  • A drag-and-drop form input which is also keyboard accessible - keystroke/click to pick and keystroke/click to drop. Drag and drop is a useful paradigm but the possible solutions at the moment are not much good for keyboard or screen reader users.
  • An element to enclose extra info for assistive technology users, something a little like NOSCRIPT. Having to use CSS tricks to hide assistive content creates a clash between content and style; not to mention putting your content at risk of Google blacklisting. An element named something like ASSIST could be ignored by search engines and enabled by assistive tech like screen readers. [Note - this is a pretty sketchy idea, no doubt there are all sorts of practical issues. I'm not saying it's perfect. It's just that we need some legit way to give extra info to users who need it, without getting blacklisted from Google. A dedicated element might be the way to go - although proper support for OBJECT would help an awful lot with accessibility it still won't help the search engine issues.]

Another short list. I wouldn't say no to specific elements for navigation, but I don't think they would really fix problems. Accessibility basics give way to usability issues - if your navigation is hard to distinguish from content, it's more of a usability issue than a markup issue.

HTML5 has elements for navigation, document content, header, footer etc... I'm not a huge fan of the naming system but I can see the potential benefits. Still, such elements aren't really priorities for me. I'm still going to give users skip links and Google has no plan to reward semantics anyway. If - and it's an if - screen readers were to make use of these new semantic elements then I'd probably use them. But screen readers lag behind and users often can't afford the latest versions anyway, so we're still going to be using skip links anyway.

all i want for christmas...

So basically what I want from a new spec is a few basics that were missed the last time around. I'm not actually hanging out for bells and whistles, although HTML 5 seems full of them and no doubt we'll happily use them.

Has reality lowered my expectations? Perhaps. Will I be glad of some kind of update - something, anything - after all these years? Almost certainly. Remember it has been more than seven years since XHTML 1.0 became a recommendation. That's 70 web years - a long time between updates.

After all that time it seems that most developers had lost faith in the W3C. Taking on HTML 5 seems like the only rational way forward and it was probably the only thing the W3C could do to regain a little bit of relevance in the world of markup. The browser makers certainly seemed to have jumped ship to WHATWG's HTML 5, or were quietly preparing to do so.

When I first heard of the WHATWG I thought it was unnecessary - maybe even a little irresponsible - to break away from the W3C. Many years later I'm glad they did.

So anyway with a June deadline, here's hoping we have a new HTML spec in time for Christmas. Santa... I'll be a good boy, I promise.

Blog Archive