widgets to the left, widgets to the right...

  • 2007-05-24

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...

limits vs. creativity

  • 2007-05-17

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 ;)

what i want from a new markup spec

  • 2007-05-12

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.

imagine there's no google

  • 2007-04-22

How would you find information if Google was down for a day? What if it was just gone?

"Google? Gone?" you say, "that's crazy talk, it's impossible!"

But it's not impossible. Google will only retain its market dominance until something better comes along. After that, it will be remembered but never used any more. Just ask Altavista, Lycos, or any other pre-Google search engine.

Now I don't for a moment wish bad things on Google, I just think people should be a little more aware of the fact they use Google without thinking. How else could "Google" become a verb?

Google has achieved ubiquity. Good for them! But is it good for us?

there can be...well lots, actually

Google is a brilliant general search engine, but it's not the only one out there. In fact, brute force searching isn't even the only way to look for information. In some cases, it's probably counter-productive.

Why counter productive? Well for a start people don't search widely. They just hit the first few results on Google and go with the first answer they find. Too bad if it's wrong, or there's relevant information that wasn't obvious from the first page of search results. So many people are getting bad information because they've developed bad search habits. Google's "I feel lucky" button probably didn't help!

You also have to consider that with systems like PageRank you're not necessarily getting accurate information. Millions of people linking to something doesn't mean that it's the best information, it just means it's popular.

You have to ask yourself, do I actually want the masses to filter information for me? What if I'd just prefer to know what my peers think? After all, I know and trust my peers (and their opinion).

trust and information retrieval

You do need to trust the people delivering search results and the people who influence those results. I don't actually know the people at Google so I have no real basis to trust them. I definitely don't know the masses of people whose links are indexed by the Googlebot. So, search in general does not score well on trust - I can only assume I can trust Google, which is a pretty thin level of trust for such a critical tool.

However, I do trust friends and colleagues... and the cool thing is that many of them use social bookmarking systems like del.ico.us and ma.gnolia. So I can actually search the links which they designate "Good Links". I can tap into the tribal hive mind.

besides that...

Besides questions of trust, accuracy or information gatekeeping... I just think people should ask the question: "why do I always use Google?".

I think that people should be reminded to question things, pure and simple. It's probably a hangover from my philosophy degree. Everyone should prove that they don't exist at least once ;)

I'm not saying you can't continue using Google - frankly I know we all will! But we should do so with the awareness that we are trusting a single pathway to information. We are putting all our eggs into the one proverbial basket.

a day without google

So why not try going a whole day without using Google. Where would you start?

  • Maybe you know a search engine or two off the top of your head (no Googling for search engines, you at the back). Try Teoma, Ask, etc.
  • Maybe you'd hit Technorati and search tagged info.
  • Maybe you'd hit a major single resource like Wikipedia.
  • Maybe you'd search Technorati and Wikipedia for search engines.
  • Maybe you'd hit del.ico.us or ma.gnolia and go the social bookmarks method.
  • Maybe you'd hit email, IM or Twitter and ask your friends for recommendations.
  • Maybe some people would be really freaky and go to the library. Before the web, there were Libraries; before Google there were librarians...

We don't actually need Google. We're just really used to it. It's good at what it does, but it's not the only one nor is it the only way to access data. Every once in a while, we should try some of the other ways. It's not good to be totally reliant on a single source or pathway to information.

There's every chance that one day, Google will fall. One day, it might not even be there. Stranger things have happened.

Until then, we can gleefully google to our hearts' content... but we shouldn't do it out of ignorance.

gettin' naked

  • 2007-04-05

It's CSS Naked day... basically a worldwide nudie run for websites! The idea is to show off the underlying structure of the page. This is what you see if you're, say, blind; using a mobile without CSS support; using a text browser or have CSS/images disabled; or if you're the Google bot.

For more info check out the Annual CSS Naked Day website.

user-generated concepts

  • 2007-03-26

User Generated Content (UGC) is a hot topic - it seems everyone wants it. A bit like everyone wanted Blogging. They weren't quite sure what it was but they were pretty much convinced that businesses should be Blogging, so they told their IT section to order in some Blogging.

Or something.

So anyway UGC is the new black (one of them anyway), which seems to translate to "comments" a lot of the time... but hey, that's a step forward in many cases. It all helps and paves the way for the next thing.

Once in a while though you see something which just sets a different standard. A SXSW attendee - a user, in other words - decided that mere note-taking didn't cut it. So they sketched the speakers: Crazy Characters at SXSW | In The Garage | The nGen Works Blog.

Now that is what user-generated content should be like! Compelling, unusual and link-worthy. It reminds me of John Allsopp's WE05 remixes (admittedly calling John a WE05 'user' is pushing it a bit ;)).

Of course it's not exactly UGC if it's hosted on the user's own blog, rather it's meta content... but I like to point out cool moments of user engagement, even if just to remind us all to keep an open mind. The best ideas are probably things we won't even think of ourselves - the users can and will outdo us.

So if you want UGC as part of your product or business, look to the users for ideas on what form the UGC should take. You may suggest or set directions, but you shoudl be willing to accept direction as well.

Maybe the buzzword should be User Generated Concepts.

disappearing content bug in opera 9

  • 2007-03-22

This is one for the "if you fix a problem, blog it" files.

I've been having a problem with a particular feature on a page I'm building at the moment. Basically I need to position a small div over the top of an image. The image can then change without needing to edit the content in the div.

To do it, I set the size of the container div then used absolute positioning to place the small div where I wanted it within those boundaries. To get it all to work the container is set to position: relative; and the small div is set to position: absolute; - something which is pretty common.

the problem

Screenshot of desired results
Screenshot 1: Desired result (and before scrolling in Opera 9).

Screenshot of problem after scrolling in Opera 9
Screenshot 2: After scrolling down and back in Opera, content disappears. The exact result varies; with other combinations of positioning the example div may also disappear immediately after the page loads (that is, it renders then disappears).

The problem occurs in Opera 9 on both PC and Mac. To see this in action, check out the example page.

the scenario

The large image and the red example div are enclosed in a container div. Initially, the container div was set to position: relative;; the red example div was set to position: absolute; and the large image had no specific setting.

the fix

To fix the problem in Opera, apply position: relative; to the large image as well. Some more testing is required to be sure, but I think the principle is to make sure there aren't any elements without explicitly handled positioning.

Again, see the example page for the real thing.

Update 2008.08.13: This bug does seem to be fixed in Opera 9.5x. Hurrah! :)

Blog Archive