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

2005-07-31: to patch or not to patch?

For years, Microsoft Internet Explorer has been criticised for its lack of security, high number of vulnerabilities and endless patching regime. With a cluster of Firefox updates in the last few weeks, it seems natural to ask the question: should Firefox be getting similar criticism? Why aren't people complaining about Firefox needing so many updates? So far it seems that Firefox's general goodwill has held out, but it's unlikely that people have just started to appreciate better security.

The average user really doesn't care much about their browser. Just as they like a car that goes from A to B and has a stereo, they want a browser that opens websites and doesn't bug them for updates too often. They've got net banking to do and stuff to buy on eBay - why should they mess around with updates?

everyone hates updates

A little while back, Microsoft was getting criticised particularly heavily for constantly releasing patches. Users felt like they were always being bugged by Windows Update and technical administrators were stuck in an endless cycle of testing and deploying patches. Microsoft's solution? Hold back all the patches and release them at the end of the month. Too bad if the latest hack is found the day after patch day.

Firefox clearly goes the other way: as soon as a patch is prepared, it's released. It looks like 1.0.5 was probably pushed out too fast, since 1.0.6 had to be released almost immediately to fix bugs in 1.0.5.

It's a classic case of tension between the best result for the user (being fully patched) and doing what the user wants (don't make them install patches). The Mozilla Foundation is taking the more responsible approach to patching while Microsoft sacrifices better security in favour of a "better" user experience.

The argument can't be solved, so we set it to one side and look for a less subjective way to compare browsers.

quality over quantity

If we ignore the number and frequency of patches, what's left is how well those patches performed. There are some major differences between IE, Firefox and Opera in terms of....

  1. How long it takes for a patch to come out for a security flaw
  2. Whether the patch actually fixes the problem
  3. Whether a patch is released at all

Secunia advisories show it pretty well. Opera is the clear winner on patching; Firefox isn't too bad; and IE is the clear loser.

Browser patch success rate (Feb 2003 to July 2005)
Browser IE 6 Firefox 1 Opera 7/8**
Number of advisories since Feb 2003* 83 21 42
Vendor patch 55% 81% 100%
Vendor workaround 1% 0 0
Partial fix 13% 5% 0
Unpatched 30% 14% 0

* Firefox advisories start from August 2004.
** Opera 7 and 8 are combined to create a better comparison in terms of the number of advisories.

Data source: Secunia Vulnerability Reports - Explorer 6.x, Firefox 1.x, Opera 7.x, Opera 8.x.

what about other gecko browsers?

You could compare based on rendering engine, since people have become aware of them lately; or at least they've heard of Gecko and perhaps understand that it's not a browser. That said, most people who can name Gecko (Mozilla, Firefox, Netscape) would have trouble naming Trident (IE) or Presto (Opera).

In any case, the problem is that the rendering engine is only part of a browser. Plenty of flaws are a result of the interface wrapped around the rendering engine, so you'll get skewed results combining all browsers with a common code base.

death, taxes and patches

To an extent, updates are just a fact of life. Even the least interested user has to be able to understand that occasionally they'll need to update their system. Mind you, some users resent more than one change in about three years... I can't help but wonder what state their cars are in.

At the end of the day, people complain less if they can see some benefit from the updates they carry out on their system. Virus definition updates help keep their machine working, new versions of applications should add useful features and software patches/updates should fix bugs and close security holes.

conclusion

So, back to the original question: should Firefox be getting the same criticism as IE? Well it would be fair to say that Firefox has probably rushed a patch or two; but it would also be fair to point out that some problems were actually related to extensions and not Firefox itself. We also have to remember that some level of patching is not just required, it's the mark of a responsible vendor. Based on whether identified problems have been fixed, Firefox is doing better than IE on the update stakes; but neither one is as good as Opera. So, no - Firefox does not deserve the same criticism as IE.

browser news

2005-07-28: &headache;

In short... character set encoding and special character display remain a pain in the butt.

Update: this t-shirt says it all (Mac version also available).

2005-07-27: firefox gets greased

open.itworld.com - Greasemonkey opens hole in Firefox: A serious security flaw has been discovered in Greasemonkey, a widely used extension to the Mozilla Firefox browser. An updated version of Greasemonkey has since been released, with Mark Pilgrim saying (on the mozdev greasemonkey list) that it closes all known security holes: mozdev.org - : /pipermail/greasemonkey/2005-July/004380. So, update your extensions (if you have Greasemonkey installed).

2005-07-26: successful != good

Amazon No Longer the Role Model for E-Commerce Design (Jakob Nielsen's Alertbox). Oddly enough, I never though Amazon's design was good. I think Amazon's success comes despite the terrible design - what they offer is just too good to pass up, so people tolerate the ten millions links per page and ever-shifting interface.

The same applies for eBay. Their site interface is awful, full of weird icons and odd navigation systems; not to mention their habit of sending 100% graphics email. But, the lure of snagging a bargain keeps people hooked long enough to learn how everything works. If that lure was any weaker, they'd give up. If you had to learn eBay's system just to pay your library fines, you'd probably give up and just drop in with some cash.

Basically, sales success does not equal good design. While a good design will definitely help sales, having good sales does not necessarily mean you have a good design. It could just mean you have a product people want or need enough put up with your design. I thought that was obvious, but since people continue aping Amazon, eBay etc, I guess it's not obvious.

Think of it another way. I've never encountered a VCR which had an easy, reliable timer record system; aka the "record the football while I'm at Grandma's birthday party" feature. There is no consistency - all VCRs are different, they label things in bizarre ways and for extra points some even make you swap between buttons on the machine and the remote during a simple process. Why do we put up with that? Because we really want to watch the football when we get home.

Motivated users will conquer bad usability, because they have to in order to fulfil their wants and needs. Give them a better option and they'll be off like a shot.

2005-07-21: zoom design is the new black

Joe Clark seems to have caught everyone's attention with his @media presentation Zoom the Web: The problem of giant fonts.

Just after the conference, I had several references go through my RSS reader; most notably references to:

Now Joe has followed up with Le blog personnel de Joe Clark | Zoom layouts - again.

If you are confused about where this is going, consider it this way... Users with no vision (or extremely low vision) generally use a screen reader, which makes the visual design more or less irrelevant to that user group (they can't see it). People with partial vision might use a page zoom tool, which is a completely different mode of use - they are still visual users. The way they interact with the web is entirely different from screen reader users, so we should not treat them as one group.

At least, that's how I read it :)

To a great degree this is a bit of a wakeup call for us all. We've got the technology but we're not making nearly enough use of it. It's a great stage where we can turn around on the mountaintop and give a thoughtful squint at the next one.

2005-07-20: dom scripting resources

I'm not a Javascript guy, but I am a Standards Guy. Every now and then someone asks me how they should learn DOM scripting. It doesn't look so good when I'm forced to do a Homer Simpson impression and mutter "uhhhidunno".

Apparently I'm not the only one however, since the question has just been asked on the WSG email list. This is nothing more than a collation of recommended resources, which is called "research" in academic circles ;)

Agree? Disagree? Feel free to comment. As I said, I'm not a script guy... I just need to be able to advise people anyway. Such is life as a standards advocate :)

2005-07-19: DOMSlides vs S5

A couple of people have sent me the link to DOMSlides - Yet another standards based presentation slide system. I'm already a fan of S5, so I figured I'd check this one out.

upsides of DOMSlides

  • Slightly lighter file weight than S5, fewer support files.
  • If you don't use graphics, you can embed the CSS and JavaScript and have a single, self-contained file.
    • This would allow a single file to be emailed to people, stored in repositories, etc.
    • To be fair, I haven't tried this in S5 yet.
  • Very neat layout/interface for the user who is browsing the document as a web page.
  • Doesn't take over all keypresses, S5 is a little bit over-enthusiastic on that count.
  • If Javascript is disabled or not available, the page degrades very nicely to styled content.

downsides/bugs of DOMSlides

  • User can't toggle between slide mode and linear page mode (not counting disabling javascript as a toggle)
  • TOC fails for long presentations (extends off cavas and doesn't scroll)
  • TOC does not number the slides
  • If more than one slide has the same title, they are collapsed into one TOC item. The DOMSlides presentation itself does this - it has five slides titled "How to style your slides". All five appear as one item in the TOC, so you can't jump straight to a specific slide.
  • Keyboard shortcuts don't work or aren't reliable
    • Keyboard shortcuts failed in Firefox if the focus is changed, or the presentation loads in a background window and you switch to it
    • Keyboard shortcuts also fail in IE if the focus changes, etc
    • Keyboard shortcuts failed in Opera in all circumstances
  • Default template doesn't allow for speaker notes, although you can probably add this with your own CSS..

other claims

The DOMSlides site does make some points/claims which I am not sure it actually follows up. Which is not to say that it doesn't, just that I can't see how it does.

  • DOMSlides suggests this advantage over S5: It is dependent on a height and will cut off presentations on smaller resolutions. I can't tell how DOMSlides is supposed to avoid this problem, other than the fact the default template is really small and fits in 800x600. I imagine a similar design for S5 would work just as well.
  • Enhance an HTML document with a proper structure instead of relying on markup created for the slide system Well actually DOMSlides requires specifically-named DIVs, so it does require markup specifically for the slideshow. It's no better or worse than S5 in that sense.

As I said, I may have simply missed something.

summary

I'm not ditching S5 just yet, but I'll be keeping an eye on DOMSlides. If the keyboard shortcuts and TOC issues are fixed, this will be a very nice alternative. The more standards-compliant alternatives we have to PowerPoint, the better!

2005-07-18: browser-based developer tools

I've discovered - to my surprise - that a lot of developers aren't aware of tools like the Firefox Web Developer Extension. I guess I was assuming knowledge, against my own advice :) So anyway, I thought I'd mention a few useful browser-based tools for a wide range of testing and development. Feel free to comment with your own recommendations!

  • Firefox Web Developer Extension (Firefox has a stack of developer extensions). Example features:
    • enable/disable scripting, style, images, caching, cookies, etc
    • resize window to 800x600 (or any other size)
    • send current page to validation tool
    • extract properties information about the page, image lists, links, etc
  • Patrick Lauke has written an entire article on using Firefox for accessbility testing: Get Tooled Up:'Evaluating Web Sites for Accessibility with Firefox', Ariadne Issue 44
  • NILS Web Accessibility Toolbar (for IE/Win). Example features:
    • enable/disable scripting, style, images, caching, cookies, etc
    • resize window to 800x600 (or any other size)
    • send current page to validation tool
    • colour contrast checker
  • Opera 8 (scroll down to Web Development). Opera natively includes many/most features included in other browsers' addons:
    • enable/disable scripting, style, images, cookies, etc (tip: use F12 - Quick Menu)
    • send current page to validation tool
    • linearise page (ie. disable tables etc)
    • small-screen testing mode
    • reload from cache: Edit the source of any open Web page and view the result instantly...great for debugging.

So, what tools do you use?

Update: there is a developer toolbar for Opera, check out nontroppo.org/wiki/Opera.

Update: The good people at Vision Australia have released a version of their toolbar for Opera, check it out - Resource Center - About: WAT for Opera.

opera development resources & the 'open the web' project

Someone recently suggested that Opera needed to provide developer resources, similar to Netcape in days gone by. Oddly enough, Opera already does; it's not that the resources aren't there, it's just that many developers are willing to bitch that their site broke in Opera but they're not willing to fix it.

While looking around at these resources, I noticed this: Open the Web: Have you had problems displaying a site in Opera or received a message saying that you are using an unsupported browser? In most cases, these problems occur on sites that use non-standard code or that fail to correctly recognize Opera.

Poor browser sniffing like that is really annoying. I frequently get told my browser is "old" and "not advanced enough for this site", when I know for certain Opera works just fine! Interestingly enough the same pages are often whitelisting IE and Netscape and excluding everything else. Not the end of the world if there's a "proceed anyway" link, but generally there isn't one.

2005-07-14: assuming knowledge hurts users

I was just reading How usable are university websites? A report on a study of the prospective student experience and found it struck a chord with my experience enrolling in a postgrad course a few days ago. From the abstract:

Only 62 percent of tasks were completed successfully. ...

The study highlighted five key usability problems that contributed to these results: poor information architecture, poor content, poor search results and/or search interface, a reliance on domain knowledge about the higher education sector that many prospective students do not have and negative reactions to or difficulty using PDF documents.

My postgrad experience aside, the most frustrating thing is how these issues are so common across the web. We go blue in the face telling people about these problems, but they persist. I tell people to "assume zero knowledge on the part of the user", I tell them not to use PDFs, I tell them to write simply and clearly with their audience in mind. Still we get confusing crap that assumes you know everything the author knows and you don't mind downloading Acrobat Reader just to get the next bit of information.

University websites are clearly still way behind the needs of prospective students (both undergrad and postgrad). I didn't know what a "Commonwealth Supported Student" is and I certainly wouldn't have thought the term applied to me. I didn't know whether I was doing a "degree", a "program" or a "course"; nor did I know if I was turning up for "courses", "subjects" or "units". To cap it off, the password they posted to me didn't work when I tried to log in for the first time.

No matter what your website contains or who it is for, you have to assume that users don't know anything at all about the topic. You also have to remember that the same acronym might mean something totally different in another industry. It doesn't hurt to assume the reader doesn't have time to read marketing spiel.

Just skip to the facts, thanks. But please, include all of the facts - even the ones you think everyone knows.

2005-07-11: accessible means you can access it even if you're not blind

mezzoblue | Made for All of Us:

Accessing any web site on the cell phone I'm cursed with is an exercise in frustration, however I had time one afternoon to make a determined attempt to use various sites. Those built with standards worked. Those built with accessibility in mind worked well. Those built by developers stuck in 1997-era development habits were completely useless.

Solving this problem would mean employing methods to make the site work without CSS, without script, and essentially allow unstyled and unscripted HTML to accomplish the same task. Funny enough, doing so would likely boost the overall accessibility of the site as well, allowing users with assistive devices to accomplish the same goals in a similar fashion.

Simple really. Standards compliance allows or helps other things to happen. Nobody said web standards were glamourous, if you want fame and fortune go be a rock star. If you want to be a web developer - and you want to be good at it - use standards. It won't solve all of your problems and yes, we know, CSS isn't properly supported yet. Again, go be a rock star.

Just because standards support is not yet perfect does not mean we shouldn't use them. Just because there's a learning curve doesn't mean you shouldn't learn it. If you're a developer you obviously know some amount... were you born with that knowledge? No. You learned, there was a learning curve, there is a learning curve for the next level.

Separating style, content/structural presentation, behaviour, application and data layers is a good idea. Websites should work with CSS, images and scripting turned off. Since nobody cares about the accessibility side I'll simply remind everyone that mobile phones and search engines have the same needs. So when your boss uses their Palm Pilot to Google for their own name, you'd better hope you didn't include it on your site by having JavaScript write in an image without an ALT attribute.

2005-07-09: it'll make coffee eventually, i'm sure

Faster, more efficient downloads in Opera technical preview with BitTorrent, which is a long way to say Opera 8 now has native support for BitTorrent in its current technical preview. Which is great, since it means I don't have to bother looking into this BitTorrent thing the cool kids keep talking about - it'll turn up in Opera soon enough. Just like the XML feed reader turned up... and tabbed browsing; popup blocking; the list goes on.

2005-07-04: wcag 2.0 call for review

As per W3C procedure, there is a call for comment on the latest working draft of Web Content Accessibility Guidelines 2.0 (WCAG 2.0). Call for Review: Working Draft of Web Content Accessibility Guidelines 2.0 from Wendy Chisholm on 2005-07-01 (w3c-wai-ig@w3.org from July to September 2005) : A new Working Draft of the Web Content Accessibility Guidelines 2.0 (WCAG 2.0) as well as five supporting documents were published 30 June 2005. The Web Content Accessibility Guidelines Working Group (WCAG WG) invites you to comment on these documents.

They include a (separate) call for comments on moving valid code to a level 2 checkpoint: Due to issues raised during a spirited discussion, no Success Criteria have been included in this Working Draft. Instead, the draft links to a summary of the issues, background, and discussion questions.

Unless we solemnly swear not to complain about things we don't like later on, we'd better take this chance to tell the W3C what we think! :)

2005-07-01: semantics, philosophy & dining hall arguments

A couple of pieces on semantics have crossed my path recently:

  • mezzoblue | Who Cares about Semantics Anyway? and the very neat, tidy and useful mezzoblue | Markup Guide
  • Le blog personnel de Joe Clark | Semantics: During the night-before dinner at the @media conference by the River Thames, I handed around an official @media pad of notepaper on which I had written the following: The Latest Exercise in Shutting WCAG Up Write down your own definition of "semantics" (or "document semantics") and passed it around the table. The results are amusing and insightful with a big dash of "too damn true" (Jeremy Keith nails that one). Ahh the problems of definition. Must have been one hell of a dinner party, too.
  • What's in a word? | clagnut/blog: However apt it may be, semantic is just one of those words that sounds too technical; try putting into conversation and peoples eyes will gloss over.

Now... we All Know™ semantic markup is fundamental to creating web documents which are standards-compliant, accessible, search engine friendly and so on. In fact, we probably learned the difference between <b> and <strong> so long ago that we forget there are plenty of people that don't even know there is a difference, let alone know what that difference might be.

Joe Clark's exercise got me wondering how on earth a newbie developer would approach semantics. I was comfortable with the concept as soon as it was explained, but I can appreciate that it wouldn't come naturally to some. It must seem like a lot of very high-level theory at first, really deep, meaningful...yawn...stuff. The kind of stuff people don't really want to know about, most of the time. Which is sad, because just about anyone in modern business would benefit if they really got their head around semantics (and separation of content from presentation).

too busy cutting wood to sharpen the saw

Your average office worker probably uses Microsoft Word constantly, yet most people don't use the style dropdown to mark up their documents. They just merrily set the font size and weight and occasionally wonder what that "Normal" dropdown is all about. Some people eventually learn (usually the hard way) that long documents should be formatted according to semantics, although they probably wouldn't use those words. The cause is not helped by the fact that Word is absolutely abysmal at semantic markup. I've found myself using XHTML documents instead, out of sheer frustration at Word's inability to mark up a nested list. But I digress.

Most people are blissfully unaware that "bold" expresses style, not meaning. In fact, I'd say most people probably don't care. They probably think you're a bit weird for thinking about it at all, let alone getting emotionally involved enough to get into arguments about it. It's a lot like philosophy, that way.

ignorance is bliss

One of my university majors was philosophy, so I explored concepts like the nature of reality: how do we know we exist? I find the topic highly stimulating and well worth the time and money to study it at length. Besides, it made a nice counterpoint to the journalism major.

The science and engineering students I lived with (at college) thought somewhat differently. Dining hall conversations would be joined by people who would contend that it was useless to discuss the topic. They know they exist, they're talking right now and eating this rather ordinary meatloaf. Questioning how they know just seemed stupid. They weren't interested in the idea that maybe we take a lot of things for granted.

Still others - including some fellow philosophy students - actually found it incredibly tough and even depressing to study philosophy. The more they realised that life can be proved meaningless and ethics are relative, the more they wished they'd never asked. It made me realise that the dumb jocks who couldn't grasp even the most basic premise of existentialism lived in a kind of happy void. Their world was complete without these 'higher' thoughts.

I came to realise that on a fundamental level, for daily life ignorance is bliss. People would rather live in happy ignorance than troubled intellectualism; and I guess who can blame them?

preaching to the hostile

The majority of the cut the crap people were doing degrees like engineering, business and science. People who like rules to follow and a bottom line to justify it. Interestingly enough, people doing medicine and basically any of the humanities were quite happy to discuss philosophy. Most people studying to be a doctor eventually discuss ethics, mortality and the meaning of life. IT students were split. Some got right into philosophy, some were scathing.

In a lot of ways, the people who discussed philosophy in the dining hall are the advocacy targets in my professional life (note to self: check for premature grey hairs again). A concept like semantics is no more palatable to them now than the nature of reality was to them back then.

Frankly I don't care if nobody else wants to explore the meaning of life, but I do care if people use semantic markup. Semantic markup is important; it has real, measurable benefits; it's as practical to web developers as a spanner is to a mechanic; and it really isn't hard. So how do we sell the concept to a hostile audience?

a spoonful of sugar

We need to make the idea of semantics a little more approachable and a lot more palatable. In some ways even the word itself doesn't help - it's a pedantic-sounding word. It might be a real nuts-and-bolts kind of practical tool, but it sounds like wishy-washy crap. In the context of web development, it sounds "too hard" for a lot of people. Just like some people buy a car "that goes from A to B", many people "just want a web page that works". They don't want to expend mental energy, they're "not a zealot, they're just doing a job".

As always, we have to talk up the practical benefits and forget about anything that sounds like the moral highground. As I have said before (during presentations), the moral highground doesn't work.

Perhaps we'd be better talking about "structural" markup, or "meaningful" markup. The name you give something shapes the way people react to it, so let's avoid making it sound intellectual. If we say structural it sounds like something that an engineer would design. If we say meaningful it appeals to the "call a spade a spade" types.

Plus, we need to spend a bit more time on teaching the non-technical sides of web standards. We get so caught up in talking about >abbr< and >acronym< that we forget to tell people why it's important not to just bang in the letters with no tag at all. We have to find ways to get a small amount of theory in before we start telling people the practical stuff.

That, or we should just tell the engineering students that it's really hard and take away their beer until they learn it. Beer and testosterone, works every time. You have to know how to motivate people, after all.

Blog Archive