Archive for February, 2005

Phones and Annoyances…

Monday, February 14th, 2005

My mobile phone died recently, it was old, it was falling apart, and it had finally given up the ghost and just crackled at the poor person I was talking too at the other end. This was a great shame, It’d been dieing for a long time and I’ve spent lots of time looking for a replacement, playing with the phones in the shops, playing with other peoples phones but not one came close to being as usable as my trusty old Nokia 5210.

The features I want are very simple - I want to be able to phone people up, getting their numbers from some sort of directory thing. I want to be able to be able to send and recieve SMS messages - without having to decide if I want to send an email, or an MMS, or some other irrelevant thing. I want it fast, a UI that doesn’t respond instantly is useless to me. I’ve got a Nokia 3650, it’s way too slow (but great for wireless IRC), it’s an old processor I know, but even with the shiny speed of the 6630’s processor sending an SMS still takes about 5 times longer than it should - or indeed does on a 5210.

The Nokia 1100, is pretty good, the UI is fast, it does the jobs well, it has one problem, can I really use it in company? It’s the cheapest phone Nokia does, it’s got big wipe down kid friendly buttons, it’s hardly a fashion item, but I think I’m going to get one, and I’ll just have to live with the sniggers. It doesn’t have the one premium feature that would be useful - bluetooth - but that’s not important enough to compromise every single other feature.

For me, all the mobile phone makers have got it wrong, they’re only interested in the “large screen multimedia device” market, I don’t want a large screen that just makes the phone wide - it doesn’t matter how thin it is, if it’s wider than a credit card, it still doesn’t fit conveniently in the pocket. I don’t want a colour screen, it just makes the UI slow and the battery drain faster, I don’t want a camera, what’s the point in having crappy photos from crap lenses without a real flash. I don’t want calendars and note taking abilities and … the UI is way too slow and the input methods too impractical to even begin thinking about these. All I want is a communication device, but all the companies just want to fight over the teenage coolness market, I think that’s silly, there’s a large market out there of people who are simply not upgrading, because there’s nothing out there to upgrade too.

Of course, phones aren’t the things that really annoyed me this weekend, that was the Pigeon that decided to break into my flat on saturday morning and proceed to shit all over it, it took me all weekend to scrub down all the surfaces of the many places it had shat - I’d never have believed one pigeon could do so much. I have to say though if you ever need to get pigeon shit out of a carpet, I can certainly recommend “Vanish Carpet Cleaner” which did a great job, even if I did use the whole can. So despite having lots to do this weekend, it all got wasted as cleaning took over my life.

Javascript Triggers

Tuesday, February 1st, 2005

PPK has written up an article on alistapart about javascript triggers, it’s interesting, unlikely to be new to many, but that’s alistapart generally. The general idea is that you should include custom attributes or use ID in your HTML to allow you to add scripted behaviour to the document.

However there are a number of important problems not mentioned. If you add behaviour to your document outside of the HTML, there’s a time period where the user can interact with the HTML elements without the proper behaviour, either they’ll trigger the no script fallback - which could be annoying they get a much worse user experience, and you’ve wasted your time writing the script. Or as is more likely for the majority of script developers these days, they’ll end up with nothing happening.

The delay in behaviour loses one of the key elements of UI that of consistency.

You can of course author your script in such a way that this isn’t a problem, however to do that you can’t abstract out your scripts, they have to be inline next to the elements and immediately follow the HTML elements they’re modifying, the onload event is much too late. There is another alternative, that of hiding your content until such time as everything’s been rendered and the behaviour attached, this is far from trivial - how can you be sure you can show it again in a degradable manner? - and of course it makes your site seemingly much less responsive, so I think that is worse.

Seperating script and HTML simply isn’t practical in todays mark-up languages, even if it’s desirable. Simple onsubmit form validation might cut it, just about, because the user is unlikely to interact with the form enough until after the behaviour has been attached, but the more complicated validation that provides real-time feedback, that’ll be down the same problem of “onload=’someformelement.focus()’” where most users are well into the field before being viciously snapped back to the first.

Techniques like XBL, or HTC’s are practical future ideas of how proper seperation of behaviour can be achieved, but I don’t think a retrofit onto HTML is a good idea yet.