flickr versions revisited: alpha, beta, gamma, loves you

  • 2007-06-03

A key point of ridicule for Web 2.0 is the endless use of non-final version releases - Perpetual Beta. As I've observed before, Flickr is a notable offender.

Now they have either done it again with the most ridiculous version yet; or maybe they've finally realised that they can call it whatever they want - they're taking money so it's bloody well final.

Flickr has gone through alpha, beta, gamma and now the logo just says "loves you" where it used to say gamma. It's certainly an odd version number. What comes next? Flickr "loves you more... no you hang up... no!... ok let's hang up together... 1, 2, 3... you didn't hang up!".

Sure, Flickr's a great service - I paid up after all - but their approach to version numbering is weird. Not to mention the fact that at this point, the numbers are only really useful internally. Marking a site as Beta just alerts people that the service is not finalised. Flickr really can't argue that point any more.

So anyway, Flickr loves us. Does that mean it's out of gamma? :) The logo's file name is flickr_logo_gamma.gif.v1.5.gif so who knows.

Update: Mystery solved! Turns out a couple got married after meeting on Flickr, so the crew at Flickr were having some fun marking the occasion. Awww ;)

user feedback you know you're going to get

  • 2007-06-02

Over the years I've noticed there are a few pieces of user feedback you can pretty much count on when you relaunch a website. Most developers are familiar with these comments and have learned to breathe deeply and not freak out.

However many of our clients have not seen it all before and do freak out. They'll read a few comments and start asking to change everything. It takes a lot of reassurance for them to leave the site alone for a while, to let users get a feel for the new site.

In any case, I thought it might be fun to run through the pearls of wisdom you will probably get once you open up for comments... and the people behind them :)

loyal fan: unconditional love

"New site is awesome!"

This is great, enjoy it. Just keep in mind that some people will love the new site purely because it has changed. You could produce something ten times worse and still get this feedback, since a change is as good as a holiday.

Should you pay attention? Well sure, since an improved site should attract nice comments. Just remember that it may not mean you've got everything right :)

curmudgeon: unconditional hate

"New site is shit! Why did you change? Put the old site back!"

No matter what you do, some people will hate the new site purely because it changed. They'll hate the colours, the fonts, the structure and navigation. They'll complain bitterly about people who don't know when to leave things alone and say 'if it ain't broke don't fix it'.

Sometimes they'll have a point about something which has actually changed for the worse. Other times they just fear change.

Should you pay attention? Not unless your entire user base complains. Otherwise just keep an eye out for any reasonable points which slipped in between the bile.

speed cop: has the stopwatch on the new colour scheme

"New site is so much faster!" and "New site is so much slower!"

You could produce a site which loads in precisely the same amount of time as the old one; and some users will still be convinced that it is faster or slower. I kid you not, this effect is amplified if the new site is red.

Should you pay attention? Yes and no. If users are reporting problems, you should investigate. But don't simply take their word for it - you should run some tests before and after launch and get some hard data. Load time can be measured, so measure it!

armchair expert: knows better than project staff

"You should use a serif font to make the body text more readable, duh! Don't you know anything about typography?"

"You are all morons. I could do better than this in my sleep. Send me a copy of the website and I'll rebuild it over dinner tonight."

This sort of feedback is a minefield. Sometimes they're spot on, other times they're miles off. When they're wrong it's really hard for staff to argue against it, since the user can sound so well informed. When they're right it can be embarrassing - someone missed something, or the client vetoed the developers who said the same thing.

Should you pay attention? You should definitely pay attention to the points they raise, but don't automatically assume their conclusions are right or think you are required to reinvestigate things you've already addressed. When it comes to the crunch you should trust the people who were actually hired to do the job. Plus, ideally you should also have user research and other data to back up the decisions that were made.

Remember: it's the net. You don't know who is on the other end. It might be a web professional giving you a little freebie consultation; but it might also be some freak reading Don't Make Me Think and smoking crack.

Evaluate carefully!

Comment spotters should keep their eyes peeled for the professor of irrelevant studies variation on this theme. Watch out for "I've been teaching programming/screen printing/comparative religion for fifteen years, so I am an expert on web design".

lazy navigator: can't find page x, didn't actually look

"I can't find the deciduous-tree-praising haiku section, I hate this site, you suck."

This feedback can mean one or more of several things. First, if you intentionally removed the content the user wants it back; no matter how obscure the page there was someone who adored it. Second, if it's still there, it might be hard to find. Third, the user may not have made any attempt to find it; and since it's not on the homepage they chose to complain instead of look. Fourth, the user may have simply looked at the old location; received a 404 and sent you a complaint. The list goes on.

Should you pay attention? Well if you misjudged the popularity of some removed content, you should evaluate the pros and cons of bringing it back. If there's a massive red button on every page, marked "deciduous-tree-praising haiku", then you might conclude the user hasn't really tried to get to grips with the new site. But if you get lots of people saying they can't find anything, you might need to change the site.

Just don't decide the entire navigation approach should be scrapped because one single user couldn't find something.

dismissive nitpicker: hates one detail, declares relaunch a failure

"The footer text should be one point larger. This entire site is terrible, what a waste of time."

Some people will hate your entire site because one specific feature ticks them off. There's not a lot you can do about this since you generally can't prompt them to comment on anything else.

Should you pay attention? Depends on the specific detail. If you only have one feature and everyone hates it, you've got a problem. If the detail is "I'm disabled and can't use this site" then you should find out where you went wrong. However if they're talking about the specific shade of blue you used for the bottom border of the navigation, you can probably let it go. Unless you get heaps of comments about the same thing.

how to deal with feedback

So anyway, you will get feedback. You'll like some comments and hate others; you'll find genuinely good ideas and totally ridiculous suggestions; you'll get warm glows and horrible lows. It is hard to read negative feedback.

Some thoughts to help you cope with user feedback:

  • You should seek user feedback! Put a call for feedback front and centre. This is a good thing to do.
  • For every person who comments, there are hundreds more who won't. Comments take time and people are busy.
  • People who are angry or don't like the site are far more likely to comment than people who are happy or unconcerned about the changes.
  • You can use the feedback point to gently point people towards the positive features of the site which address their concerns. But don't fall into angry rebuttals - save that for the pub afterwards, when users can't hear you.
  • You will get upset when you read the negative feedback. You've invested a lot of time/money/effort and it will feel very personal. So it's often a good idea to read it, say and do nothing, go for a walk and have another look tomorrow.
  • Look for common complaints, don't act on lone curmudgeon complaints.
  • Don't simply dismiss all complaints. We're not perfect, neither are our sites.
  • If you respond, don't do it when you're angry. Be calm and very plainly state your reasons for what you've done. If you do plan to take an idea on board and make a change, gracefully thank the user for their input.
  • Enjoy the praise! You've earned it.

We all have to deal with user feedback and the experience is a mixed bag. Take comments with a little dash of humility and humour, and a whole lot of grains of salt.

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.

Blog Archive