Magic Torch

Inspiration struck over the weekend for a wee web app to make life a big easier in a small way in the office. Going to thrash out the technical details tomorrow, hopefully, and then have a prototype up and running ASAP.

But this evening I’ve been working on the UI. I’ve got something going that I’m really happy with. And the closest I came to opening any kind of graphics software was resizing a couple of user avatar placeholders in Preview. Everything else was done in HTML and CSS, straight into the browser. I’ve never really got used to doing mockups in Photoshop or whatever. I don’t have the patience for it, and it’s not really my medium anyway. But cracking a tricky little layout problem by thinking laterally about how to style a span? Dynamite.

Now it feels like 2010.

We Interface Developers have been talking recently about the range of browsers we support and test our sites against. IE8 is threatening to be released any day now, and almost as importantly it is definitely not threatening to kill off substantial use of IE6 and/or IE7 anytime soon.

So we have a trilogy of different Internet Explorer browsers doing things their own, interesting ways. Plus the Webkit and Gecko-based alternatives, like Safari, Firefox, Camino and Chrome (I would call these necessities rather than alternatives, but I’m still in the minority according to the stats).

It means a lot more work for Interface Development. In the same amount of time. So instead we need be smart and not just keep the smartness to ourselves.

Up until now we’ve been able to support a fairly generous production process, in terms of what the client has been getting. That is, sites that work and present themselves pretty much identically in all the browsers we support, IE6 included. Working that way is the result of many things, not least the fact that our team really knows what it’s doing when it comes to wrangling angry browsers.

But a new perspective is needed. One that recognises that treating all browsers the same actually does more harm than good in the long run.

I’m a bit obsessed when it comes to clean, semantic markup. It’ll tend to the be the first thing I look at when studying a site. You may be rocking the best visual style the world has ever seen, but you’ll not get any opinion from me until I’ve hit “view source” or fired up Firebug and checked out the DOM. At which point it can all go horribly wrong.

Of course, being an inhabitant of the real world, an attitude like this is tough to maintain when you are actually making web stuff, and compromise is never a bad thing when a deadline is approaching or an extra bit of markup gives a more robust finish.

But priorities and expectations about the web have changed radically in the last couple of years, such that compromise on markup standards has become a luxury rather than a necessity. We don’t have time to keep hauling struggling browsers along at the same speed as the pack leaders. We have to accept what has always but which we’ve been able to ignore up until now: All browsers are not equal so they should not be treated as equal.

We need to adopt a approach of Progressive Enhancement and make this the core of our process. We need to allow flexibility in the user interface to give enhanced functionality across all browsers.

The best browsers today can do amazing stuff given the chance. The worst browsers today can provide better functionality and speed given the chance.

How to achieve this is simple: don’t try and apply a one-size-fits-all interface, because actually it doesn’t fit anybody. The old browser struggles with the extra markup, styling and images. The new browser is stuck handling a legacy implementation it could run rings around given something fresher to work with.

And then the future turns up and things really get bad.

Let’s go the other way. It has frickin’ lasers and everything.

John Gruber has an seriously exhaustive UI critique of the Safari 4 Beta over at Daring Fireball. I agree with most of it. I’ve recently moved back to using Safari as my main Mac browser after about 6 months of Firefox (I was in a forensic mood and Firebug kicks the Safari web inspector’s ass for hot code-perusing action).

But, Safari (3, at least) just feels part of the OS in a way Firefox doesn’t, and I was getting enough Firebug action at work so back I went.

But the nice feelings have pretty much evaporated with version 4. Mac UI conventions have been abandoned left, right and centre, and I’m having to exert substantial mental effort just to re-orientate myself with the bloody thing every time I use it.

Here’s one thing. A tiny, little thing that is driving me nuts.

I, like most people, love my browser tabs. I don’t go crazy, but I generally have 3 or 4 open at a minimum. With version 4, Safari has combined the tabs with the normally sacrosanct window toolbar. Many of the reasons why this is knob-headed are detailed over at the Fireball, but my one tiny thing is this:

When I click to switch tabs I clearly make some kind of a minute downward motion with the mouse. Previously this had no effect on the window as a whole. But now about 50% of the time, because tab and toolbar are one, the window gets dragged down a few pixels instead of the tab being switched.

I like my windows right up against the menu bar. Just how much is becoming clear to me, because I am starting to make strange moaning noises when the 3 pixel drag occurs.

UI anxiety is a laughably crap thing to have, so please stop giving it to me, Safari 4.

UPDATE: I gave in and changed the tabs back to the v3 configuration using the hidden preferences. The downside to this is that Safari no longer asks you the “Close multiple tabs?” question if you click the “close window” button. One thing replaces another.

ANOTHER UPDATE: Looks like the “Close multiple tabs?” warning does appear, after all. Must have unchecked the option at some point. Huzzah!