August 2008 in the Life of Ben (Blog)

  1. January
  2. February
  3. March
  4. April
  5. May
  6. June
  7. July
  8. August
  9. September
  10. October
  11. November
  12. December

Cycled Fleet Pond with Dad (30th August 2008)

Another glorious Summer evening. I convinced Dad to ride with me to Fleet Pond.

We took the Basingstoke Canal down to Pondtail, then joined the road by the bridge. We crossed the crossroad and used the residential street to cut out a big corner. We turned left at the end, staying on a road to cut out some more distance. It was muggy amongst the houses.

We considered cutting through the woods to the ford on the way down. I wasn’t certain which path it was and it would be a nicer highlight to visit on the way back. Something to look forwards to.

We continued clockwise around the pond, stopping at a few places to look across the water. It almost feels like looking over the sea. You can clear see the far bank but the wide expanse of water tricks the mind. There are a few islands which are each big enough for a copse of trees to grow on them!

While riding alongside the railway, dad noticed the row of narrow arches where water flows from one half of the pond to another. The railway built a giant causeway across the pond and these arches allow the water to stay level. Despite the causeway, it still took about half an hour to cycle around. Makes you realise how monumental a body of water it really is.

Riding parallel with the embankment, I tried riding up the tough route I conquered a few months ago. Dad watched and said it looked “tiring”.

Nearby we saw a group of Shetland Ponies, on the pond side of the fence. I guess they’ve been introduced to help graze the grass, similar to the giant cow-like things which have been introduced into other areas around here.

Eventually, our clockwise circumnavigation of the pond finished at the sandy beach opposite the railway causeway. It still had a miniature bay with a spit of land across it. There were some tree trunks laid from the beach to the spit, which stood clear the lowering Summer water level.

To avoid ending up on the route we had approached the Pond from, we left the beach the same way we had entered it. This leads to a track through the woods where we turned right, away from the pond. A narrow bridge cross a stream which I could tell led to the ford due to the orange stones in the bottom. The water was very clear.

A man was walking his dog, which promptly lay in the stream as I was about to ride through it. He called the dog away and it got up but choose to paddle further into the stream. I talked to it and it seemed calm, so I rode through.

On the way back, we exited the woods onto the same residential street we’d used on the way out. But this time we headed straight back to the main road, then went left, down to the crossroad. Instead of rejoining the canal we turned right, without cheating the corner by using the pavement…honest guv!

headers Issue “Resolved” (30th August 2008)

This message underwent some peer review before I sent it:

  1. #whatwg, 29th August 2008
  2. #whatwg, 30th August 2008

The reviewers felt it was comprehensive and contained useful stuff. I think it needs to be said, so I hope you’ll excuse the length.

Check the follow-up to this entry for more technical review and some example solutions.)

Overlooked Ideas

James Graham, Re: headers issue resolved - allowing a <td> to be referenced by a header to be in the HTML5 spec.

Indeed. Having read through that telecon’s IRC log, it seems the alternatives were either missed or were rejected with faulty reasoning. I appreciate these records are not exhuastive. But it’s not only the alternatives put forward by James and Lachy which were missed.

Contradictions

From the telecon minutes:

MS:part of discussion and solutions that have been advanced for some cases - don’t know if this table falls into that case - there are certain tables that are fundamentally badly designed - not fixing poor design by adding features for AT software - better solution is to redesign table
Laura:

“[...] That process is complicated and cumbersome. It basically requires rewriting the table.”

Jim Thatcher, forwarded by Laura Carlson, Re: headers attribute (was Re: Form elements)

Redesigning a table does indeed require altering the table. So does retrofitting headers+id. Is this an argument against doing so?

Any widespread improvement in table accessibility will require some changes to large numbers of existing data tables. In particular, those which use <td> for any header cell with neither scope nor headers+id, as these do not have the semantics of a header cell. <td>-only tables was the first obstacle I found to widespread table accessibility during my research just over a year ago.

Later on, the need to rewrite data tables is given as an argument for changing the specification:

Josh:@MS: The mark up should facilitate how authors will mark up tables, though I agree that tables are often very badly designed.

Needing to alter existing tables is used as an argument against redesigning, then used as an argument for retrofitting.

Redesigning versus Retrofitting

The retrofitting proposal favours adding complicated markup to badly designed tables. The alternative is redesigning (aka rewriting) bad tables into being good tables. Good tables are more usable for everyone, so I prefer the alternative wherever possible.

It’s worth mentioning that “Smart Headers” and similar approaches can sometimes get accessibility out of bad tables, with no changes to the underlying markup. (See below: “Research into Simplicity”.)

Factual Inaccuracies

Reasons were given to support the proposal which sometimes contradicted fact. One example of many (and not wishing to single out Josh):

Josh:Note that headers/id association are rather well supported by much current AT so Gez’s solution is rather simple and elegant.

It is true that headers+id enjoys some support. It is also true that this support is far from universal. For example, Firefox does not implement complex table markup.

I further disagree with the proposal being “simple and elegant” in more detail, below.

Simplicity

The proposal cites the Test Files from “TableHeadersTestingBug5822”. Specifically, Test File 3 is given as an example of why headers+id should be allowed to reference <td> as though it where a header cell.

Test File 3 requires the addition of:

In total, 47 attributes must be added to a table with only 50 cells for this proposal to work!

For the headers+id aspect to work, a total of 72 id names are listed in the 18 headers attributes. All of these must be perfectly accurate, in the perfect order and separated from each other in the correct manner. It’s a minefield for authoring error. (See below: Research into Simplicity.)

To put it another way, Test File 1 uses 1,704 bytes for the <table>. In contrast, Test File 3 uses 2,625 bytes for the <table>. That’s 54% more markup for the same data, presented the same way.

In this table of just 50 cells, there are 20 header cells. Bad design seems a contributing factor to the usability problems this table has.

I disagree on technical grounds with this example being in any way “simple”. Indeed, I would say of it: “That process is complicated and cumbersome.”

Research into Simplicity

Publically available research shows headers+id is used very rarely. When it is used, the permutations frequently result in mistakes.

James and I demonstrated a faulty use of headers+id at the W3C TPAC in November 2007, during an “unconference” session into data tables. We followed this with a demonstration of how James’s prototype of the “Smart Headers” algorithm associated the table correctly, despite the underlying markup errors.

Joshue O’Conner and Steve Faulkner were present and active at this demonstration. They seem to have forgotten the effectiveness of “Smart Headers” since then, which is quite understandable, since they are busy people and the demo was less than overwhelming!

Ironically, the present-day version of the demonstrated page no longer uses headers+id. It uses <th scope> exclusively and correctly for all but the top-left cell, afaict. There are a few id attributes on <th> elements but there are no headers attributes to use them. It also has several parse errors for using </th instead of </th>, among other things.

A further irony is the table was originally featured in a collection (part of the Complex Table Examples) intended to show headers+id being used correctly and helping users. I guess the various errors present in the table at that time were missed by the original collector. The table has since moved to a simpler approach with scope. It would work fine with plain <th> in the Smart Headers system.

Elegance

Test File 3 does not use headers+id for all associations:

Test File 3 is not testing headers+id in true isolation.

The cell using <th scope="col"> also uses colspan. For scope to work here under HTML4 (the DOCTYPE given by the test), scope="colgroup" must be used with appropriate <colgroup span> elements.

This cell uses colspan="6" when only 3 columns are being spanned. It should use colspan="3". The tests don’t even get colspan right…

2 of the cells using <td scope="row"> also use rowspan. For scope to work here under HTML4, scope="rowgroup" must be used with the appropriate use of <tbody>.

These same errors are also present in Test File 2. So the tests also get scope wrong.

Test File 2 found that scope did not work in the tested ATs. Perhaps the errors are just too grievous for ATs to make sense of it?

Either way, Test File 3 unfairly reduces the complexity of headers+id due to the 8 <th scope> cells which don’t participate in headers+id. These rely on either:

The cited Test Files uses a weird patchwork of techniques, with mistakes in the use of scope and colspan. I disagree with this being “elegant” on technical grounds.

Corrected Test Files

Test File 1 uses <td> for 11 of the 20 header cells. In the absence of scope or headers+id, these obviously require <th> to get header cell semantics. This is another error in the Test Files.

I have attempted a orrected version of each Test File without changing the arrangement of cells:

Feedback on these Corrected Test Files is welcome. Feel free to use them in documenting test results on the wiki or any other purpose.

Relevance of AT Testing

“Smart Headers” and so forth could be implemented by UAs. They would pass the information on via the accessibility APIs for that platform. In this way, it would work without ATs implementing a new association algorithm.

Testing my gez-1 example may reveal present-day algorithms of this sort in ATs. Such as those described by HTML4.

Either way, James Graham’s Table Inspector can be used to test the associations made with various algorithms. Ironically, this was in response to a request to enable testing Smart Headers in present-day ATs, which has still not been carried out. Again, the presence of this ability was mentioned by James during the demo at W3C TPAC in November 2007 and on-list in March 2008.

Process

I feel that the telecons should not be used for political power-plays to steamroller a previously declined proposal into the specification. Especially when it is being justified by such erroneous background work and false reasoning. This proposal ignores a great deal of work about solving the issue of table header association, all of which is publically available for review and hands-on testing.

Incidentally, I think headers+id fulfulls a useful role. I also think it is made more useful by letting the headers attribute point to <td id>. I’ve said as much on Public-HTML and elsewhere. Ian Hickson responded with a research-based rationale back in April 2008.

I have yet to see that reasoning contested by a new round of research. Even I haven’t got that far, yet.

I wouldn’t feel right about insisting that my or anyone else’s ideas get immediately adopted into the specification by beauracratic brute force. Especially after the Editor has made a research-based decision against them. Yet that is the situation here, as I see it.

Instead, accurate evidence should be collected to test the decision. This may well confirm it, of course. I’ll probably do this myself at some point. But the more the merrier. c{:¬)

Attending HTMLWG Meeting (26th August 2008)

Today my plans to attend the W3C TPAC 2008 solidified. Mozilla Foundation look like they’ll sponsor my travel and accomodation. After some confusion it looks like only single rooms are now available.

At the official hotel, anyway. Anne van Kesteren mentioned he stayed at a different hotel for substantially less. I ran this past Sean Medero and he liked the idea of paying less money (well, who wouldn’t?).

There are hundreds of hotels in the area. So I guess my answer to the registration question about hotels (restricted access) will be that I’ll stay elsewhere. My embryonic plan is to arrive Wednesday 22nd (afternoon?) and leave on Friday 25th (evening/night), flights permitting.

This will only work out if I can tag along with Shawn Medero (aka smedero) and Geoffrey Sneddon (aka gsnedders). Navigating around the real world genuine scares me. Gijs Kruitbosch was essential to me not getting lost at Sight City Along with being a nice guy to hang around with.

It looks like Ian Hickson might go after all. I suggested we could run through 2008 collection in person:

I would apply what we decide during November 2008.

Ian was keen on that, if he does go.

5th September 2008

The hotel has 2 rooms available from Sunday 19th October 2008 to Saturday 25th October 2008! This means I can have a room to myself for the whole event while Geoffery and Shawn share one.

The hotel are sending a confirmation thingy for me to finalise the booking.

Long Family Cycle (24th August 2008)

Glorious weather is less rare in this part of England than our culture would have you believe. Still, it’s true that we try and make the most of it whenever the sky brightens up. This seems to be a hardcoded feature.

This time I convinced my parents to take the other direction along the Basingstoke Canal towpath, though Fleet. Eventually, we ended up riding much of the long route I cycled with Dad earlier this year.

Through Fleet

We rode slowly in short sections, stopping at landmarks. There were many groups of ducks and pairs of swans on the canal. Also lots of people on the towpath. We stopped on the left and let them walk past, being thanked courteously by nearly all of them.

Houses line the far bank of the canal. Ranging from modest bungalows to picturesque city houses, many had a dingy or small narrowboat moored on the canal.

Pondtail

A bridge carries Kings Road over the canal and into the Pondtail area of Fleet, with an older bridge beside it. We passed under them and saw a boat turning around in the winding hole. The skipper really gassed up the long-stroke diesel engine to bring it around during the final movement!

This stretch of the canal is very open. I took the lead and rode really slowly so we could admire water lillies and let people pass. After a while, mum got impatient and overtook me!

We had almost caught the narrowboat when we stopped at the overflow. It was’t overflowing. In fact, the water level was several centimetres below the overflow point. There were a couple of leaks in the sluices where water was gushing through at a modest rate.

We trundled around to the pool which acts as a buffer between the overflow and the stream. We watched the water for a while and discussed a route back. Much to my surpise and delight, going back through the woods like dad and I had done was unanimously, if reluctantly, agreed on.

Diverge

We moved off towards the bridge. I darted ahead to swing left up the huge, steep, root-covered path up the embankment. Managed to get up it in one go, although I was knackered by the top! Looked around and couldn’t see my parents. Had they stopped? Had they taken a wrong turn?

I shouted down "“I MADE IT!” but got no response. Couldn’t hear anyone cycling. After a while I picked my way back down but nobody was there. Now I was getting a bit worried…where were they? Had they tricked me; turned around and gone back home on the towpath? Rode as fast as I could up the towpath to see if they were looking for an alternate way up. Got to the bridge but didn’t see or hear them, so I turned around and races back.

Eventually I figured if they had started home they wouldn’t turn around and come the long way with me, even if I found them. But if they were finding an alternate way up to the road, I might find them by waiting by the road for a while.

So I rode back up the hill, taking a different line which made the upper section a little longer but also a little shallower and smoother. This was an overall gain. Continued through to the road and waited.

Moving On

After quite some minutes, I eventually heard day shouting “Hello!” He was approaching from the far side of the road, so my gamble had paid off. Mum was following, a little way behind.

Apparently they had looked for an alternate route but not found it. So they climbed a track up the embankment. Mum said there was a shallower route but they should have gone further on, so I guess choosing the earlier path was dad’s idea.

We rode 3-wide along the pavement, over the high bridge. Crossed the road and dropped into the woodland area.

Uphill, Downhill

Dad and I pushed mum up the hill a little. Not sure it had much effect but it was quite funny. 3 routes were ahead of us; dad and I had taken the left one before. Since it went a long way, I suggested taking the middle route. I didn’t remember this route before but it seemed to be pointing in a better direction for a shorter route. So that’s what we took.

It immediately led into a long, steepening, downhill, gravel-covered access road with a right-hand corner. One of those corners which is tight enough to make you worried but which tempts you to try taking it at high speed. We all got around it and continued rolling down to where the track flattened.

The flat track went through an open heath, then stopped at the foot of a small hill. We stopped here to cool down and rest. A small formation of fast jets flew overhead, a little way off. I just managed to glimpse 2 of them.

The Foresters

After some debate about which gear to use, Low 3 was what mum and I were already in and we figure that would be fine. We got up the hill easily. In fact, mum accelerated away from dad and I, who were taking it easy.

Mum stopped for us to catch up, just past a gate which leads to The Foresters pub. We decided to go in for an orange juice. Dad led us to the beer garden at the back and, leaving me in charge of the bicycles, went with mum to buy an orange juice for each of us.

They returned with a bag of Kettle Chips which, after tasting one, I asked for as well. Mum offered to get them for me so I sat back down and enjoyed the orange juice.

It’s a lovely garden. Quite adequate in size and with bird feeders which were very effective at attracting a variety of small birds.

We chatted slowly and joked a bit for quite some time. We rarely do that these days (either part).

Homeward Bound

The journey home is fairly unremarkable. You go through another wooded area, over a cattle grid then it’s a series of long paths and quiet roads back to Basingbourne Park. Cut through the woods (yes, another wooded area!) and you arrive at the bottom of our road.

Mum and I took the longer, shallower route and rode really slow to cool down. Dad bombed it up the steep bit. I used to do that but the discomfort of overheating when back indoors make me favour a slower end. Like walking a horse to help it cool down after a hack through the countryside on holiday.

Family Cycle (23th August 2008)

Similar route to my birthday, although the towpath was noticably more overgrown this time. On the way back, mum zipped up onto the humpback bridge and we all freewheeled down the hill.

Mum and dad continued around the corner while I tore off through the woods. The track is just packed soil and varies in width from about 2m down to about 20cm.

It’s a long, gentle but steepening uphill route on the way in. It flattens out after a 90° right-hander although there are dips and camber changes across the path. Another 90° right-handed leads onto a lane. By this time I was quite worn out from sprinting the whole way, so I coasted down it.

My parents were waiting at the end. After a short pause we continued back to the canal, rejoining at the swingbridge and headed home. Did a cool-down lap around the estate with mum; dad pull straight into our driveway.

AT UI (22nd August 2008)

Aaron Leventhal and I were in Mozilla’s #accessibility channel this morning. We got to talking about how screen reader’s expose their features to end users. As their users normally cannot use a pointing device, their user interface is based on keyboard shortcuts.

Overcomplexity

There are typically 50+ commands in modern screen readers, several modes and other complexities. Consider a GUI with 50+ controls and all these complexities. I suggest this is too much.

Aaron has seen these features aid power users. He agrees it can be too much for new users. Horses for courses; there’s space for both models to compete.

Efficiency

Aaron described how having more commands reduces keystrokes. He gave specific examples of where modes in the screen reader disambiguate commands. Let’s say T is used as a shortcut to move to the next textbox. When focus is in a text input, should T move to next textbox or type T? By letting users switch in and out of a forms mode, what it does is always predictable.

You must know the shortcut to switch modes, been trained on how each mode differs and have months or years of experience to understand when each mode is of practical use. I suggest this is false economy.

Consistency

I suggest the same model for sighted keyboard users would work. So you’d use Tab and Shift+Tab to move between form controls, rather than having T and Shift+T for moving specifically between textboxes.

Aaron asks how I’d feel if I could only navigate with Tab and Shift+Tab. “My keyboard would get worn out,” I quip. “I wasn’t suggesting they go from 50+ commands to just 2.”

We go back and forth about more keystrokes versus more commands for a while.

Smart Minds

Screen readers have been around for a long time. The people who design their interfaces don’t do it in a vaccum. They have years or even decades of experience, observing tests and mailing lists and direct feedback from users over their careers. Aaron touches on this several times.

My objection is not to the overall design of screen readers. I am not questioning the expertise of the people who make them, either.

Winning Designs

The read-through toggle (aka pass-through mode) seems eminently sensible to me. From a simple one-touch shortcut, such as Ctrl, reading begins. It pauses if Ctrl is pressed once. It stops upon reaching the end of that window. This works in all modes, all contexts.

Convenient and dependable features like this are what I think enrich an interface.

A sighted keyboard user need not use a shortcut to change the input mode of their keyboard before they can put focus into a form control and interact with it. The application, the operating system and the specific control work together to make the interaction seamless.

Once in the control, a few keys change to operate within the control. For example, End now moves the input caret to the end of a textbox rather than scrolling to the bottom of a viewport. When interacting with forms, Enter submits the form. Whem focus is on a link, Enter activated the link. In a <textarea> it types a new line.

All this Just Works; the interface adapts seamlessly and intuitively to the user’s context.

Ideas

Modeless Interaction

Working with tables, lists and forms seamlessly should be the goal for screen readers. Just like sighted keyboard access disambiguates commands intuitively based on the user’s context. With enough imagination and sophistication, surely that’s possible?

List of Things

There are less dramatic ways which I think usability could be improved. I’ve seen ATs where several windows are available, each listing a different type of interesting structure. Each has a different shortcut and may work radically differently from each other.

I would just provide one window. A List of Things window, if you will. This immediately reduces the number of shortcuts which must be crammed into the ever-narrowing pallette of combinations available for ATs.

The window would provide one tab for each type of list. Each list would automatically select the item at or just before where the user’s focus was. Each list would work as similarly as possible. There would be a “find as you type” box for each one, so users could search within each list. Preferences for searching, sorting and filtering would be remembered.

Reliability

An often overlooked but frequent problem is features which don’t work quite perfectly in every possible scenario. Noticing when the off-screen buffer has got out of synchronisation with the screen and taking steps to compensate is something I might expect a tactical officer to notice during a battle on Star Trek. It’s not something a casual user should need to understand.

ATs are often hampered in this respect by other people’s mistakes. We’re all human but if an application is doing something wrong, an AT gets put in a difficult situation. Nobody wins and users lose out.

Imagine a concerted effort by the ICT industry to fix accessibility bugs wherever they are found. Imagine the productivity and happiness of users for whom everything works properly all of the time.

of course, this is a monumental and ongoing task which has been underway in one form or another for decades. But there are a finite number of variables. Each has a finite range. The task is not quite endless, afaict.

Old News

No doubt, Aaron and AT vendors have heard this all before. It’s probably been tried before, too.

Aaron points out that the design each product uses has evolved through feedback from its users. They continue to make changes but for the most part, what they’ve got is what works best. Hanging around in #accessibility, I see first-hand that identifying and fixing accessibility bugs is happening all the time.

I appreciate it’s a massive area. I appreciate there are many balance points. But my feeling is there remains room for great improvements. Things I can’t even imagine.

26th August 2008

Another aspect is what features an author makes available from their documents and in what way they do this. For example, a discussion about linking <video> to its transcripts revealed different ways (some hypothetical, for now) of doing this:

My preference would be an <a href> immediately after the <video>. Another possibility would be having the transcript on the same page the <video> is on.

Each technique would have a different user experience. Simple and reliable authoring is the key, imho. That’s the only way a feature can work for anyone. That’s the starting point to make it work for everyone.

HTML5 Research Midpoint (19th August 2008)

On 1st September 2008 I’ll reach the midpoint of my research. My progress gets reviewed and a 2nd payment is made, hopefully.

A little in advance of this, I’ve published my progress so far and notified:

Now I’ll e-mail some relevant Mozilla Foundation people:

Then I’ll log into Mozilla’s #accessibility channel and see what happens next.

21st August 2008

Marco has helped me draft an interim report. Aaron Leventhal also gave some review and help. He’s basically the 2nd mentor for this project. My funding proposal now reflects this and is integrated into the site’s templates.

The collection has had some updates:

22nd August 2008

This Week in HTML5 focuses on revisions to the HTML5 specification. So, naturally, Episode 3 doesn’t mention my progress. After discussing this on the #whatwg IRC channel, I wrote a comment

Blog Done (14th August 2008)

Today is the last time my rather weak VB6 build scripts should need to run.

Difficulties

With the change in URL level for the entries, I had to transform all relative href values. Internal links in /blog/ should now be absolute.

Spidering through the blog and then generating pages which span different areas was tricky. In the end, I settled on pre-spidering the blog to load each entry’s path into an array, nested 3 levels deep:

  1. Year numbers. Currently from 2004 to 2008 at the moment.
  2. Month numbers. Currently from 1 to 12 in 2004 to 2007, with 1 to 8 in 2008.
  3. Paths to entries.

The path to the blog is stored in a constant as the script is just for my use.

Script Steps

  1. Spider blog into nested array, counting total number of entries.
  2. Start the archive of entries.
  3. Start the archive of months.
  4. For each year:
    1. Write heading and list of months to archive of months.
    2. Write <div> and heading to archive of entries.
    3. Start this yearly index.
    4. Write list of months to this yearly index.
    5. For each month:
      1. Write subheading and list of entries to archive of entries.
      2. Write heading and list of entries to yearly index.
      3. Start monthly index.
      4. Write list of months to monthly index.
      5. Sort entries into reverse chronological order.
      6. For each entry:
        1. Write linked heading followed by date in parenthesese to monthly archive.
        2. Write entry text to monthly archive.
      7. End monthly index.
    6. End yearly index.
    7. Write </div> to end section in archive of entries.
  5. End archive of months.
  6. End archive of entries.
  7. Start blog homepage.
  8. Write most recent linked heading followed by date in parenthesese to blog homepage.
  9. Write most recent entry text to blog homepage.
  10. End blog homepage.

Timeline

2nd December 2006 Blog Rebuild
23rd March 2007 Blog Headings
28th August 2007 Blog Sidebar
22nd May 2008 Extinction of Stone Age Blog IA
23rd June 2008 New Blog for 2003
29th April 2008 Complete Archive now built by an update.php script checking files and folders.
17th May 2008 Completed blog about Sight City 2008 Notes & Experiences.
23th May 2008 One page create per entry for all of 2003.
27th May 2008 Page per entry for 2004 and 2005.
Markup of blog indices.
Automation of yearly blog indices.
Indices for 2003, 2004 and 2005.
29th May 2008 Yearly index ordered from oldest to newest.
Yearly index has horizontal list of months across top.
Yearly index has subheading per month.
Yearly index has list of blog entries with date as <li value>.
Page per entry for 2006.
30th May 2008 Blog sidebar starts with a list of all years.
Blog sidebar lists recent 5 months instead of 13.
Page per entry for 2007.
7th June 2008 Page per entry for entire /blog/ area.
24th June 2008 Went live with new IA for 2003 section of Blog.
Link checking all online blog indices.
25th June 2008 Went live with new IA for 2004 section of Blog.
27th June 2008 Created the Blog Organisation, Navigation and Information Architecture topic in Site Critiques of Accessify Forum.
29th June 2008 For bettor or worse, I’ve gone live with all the new IA.
Created 2 RedirectMatch rules which cover most changes.
14th August 2008 Raised subheading levels in entries as they were still at the level for monthly indices.
Reduction of subheading levels when entries get built into indices written, tested and run successfully.
Uploaded entire blog folder.

W3C Desktop Publishing (8th August 2008)

An idea popped into my head whilst pacing the downstairs rooms, waiting for my vegetables to boil. Actually, several did. But one of the more interesting ones was this:

Are widespread W3C formats adequate for use in desktop publishing?

This would involve some combination of the following:

This combination would replace a proliferation of formats, including:

The following are some quick scribbles about how it might work out.

Adaptable

PDF is sometimes used to share documents which must appear “pixel perfect” to everyone who views them.

Yet even this format is ever more permissive of zooming, colour changes, reflowing and other adaptations by end users to improve their experience. Primarily useful for disabled users, of course. But zooming technical diagrams and ferry timetables is something I’ve seen my dad do, without disabilities.

Office documents are usually editable by the end user. You can tweak font sizes, font styles, colours, anything you like. Even if edits have been disabled in some way, you can still zoom. The viewing application should inherit any special colours from the operating system, too.

W3C technologies are designed from the ground up to be adaptable for user needs, along with the limitations and innovations of devices. This is especially the case for HTML and CSS.

Given the adaptability which is creeping into even the most lock-down desktop formats, this seems like a bridge towards a W3C desktop rather than a barrier against it.

Cross-platform

PDF readers on mobiles. Microsoft Office formats supported by Linux and Apple systems. Maybe vendor lock-in is no longer the goal of proprietary formats? The biggest businesses want their format to work everywhere, it seems.

This is another area where the W3C process excels. Their formats are designed to be device independant, so the format can be shared between platforms without conversion by authors. The newer formats reduce or remove the always necessary but previously somewhat unacknowledged guesswork and reverse engineering required by new implementors.

So again, this is a key area were W3C formats would fit like a glove.

Author, Store, Publish, Share & Print

W3C formats cover all uses of your documents, without conversion or exporting different versions:

CSS can be embedded in a <style> element for a single HTML document. Images can’t really be embedded into HTML. Separate files will normally be used.

I guess you could wrap them up in a Gzip archive. Or you can just keep them close to each other when sharing.

Feasibility

With fewer formats to support, applications could concentrate on their user experience. Performance, interface, reliability, security and so forth. Ultimately there would be a tiny number of formats in use, creating a simpler ecosystem of products and content.

There will always be a legacy content problem, of course. Old documents can be supported by:

This is broadly what happens inside each proprietary ecosystem already. The big difference is a W3C desktop converges all applications and platformson one small set of carefully designed formats.

Cycled with Warren (5th August 2008)

Warren Brand is the Head of ICT at Calthorpe Park School, where I’m the Webmaster. We work together to provide the website:

Today he had the finalised version of the school calendar for 2008-2009. This document is a huge production each year considering the size of the school (about 1,000 students). So getting the final version online in advance of the new school year had turned into quite a mission.

He was going to cycle over and give the calendar to me. It was a lovely day so I suggested we go cycling together, which we’d talked about some months earlier. He recalled this and agree, so we planned an initial time. This turned out to be impossible due to his family commitments. After several reschedulings, we met up at my home and rode out at about 7:30pm.

To cut a long story short, he’s a hell of a lot faster than me. Still, he appreciated the company and I got a much harder workout than if I’d been riding alone.

Misplaced Sympathy (4th August 2008)

My programming ability leaves a lot to be desired. But when I write code, I worry about how hard it makes the machine work. If the machine has to work too hard, I feel guilty about this unfair burden.

Years ago I used to think everything was alive. If I slumped onto the sofa too strongly I’d apologise to it. Quietly, so nobody else would hear. These days I’ve grown past that. But maybe my sympathy for objects and machines is a relic of those childhood feelings?

The purpose of machines is to accurately carry out tedious and repetitive tasks for us. That’s why we create them. To feel guilty about making a machine work too hard makes no sense. Hard work is what machines are built for.

Making a CPU thrash a bit due to minutely inefficient redrawing of a control will cause a minimal increase in labour. In contrast, trying to boost my novice programming skill to overcome these slight inefficiencies causes a great deal of labour.

Of course, if code is so bad it makes an application hang for several seconds during simple operations, some changes are in order. But I should stop driving these out of misplaced sympathy. The users’ experience and the developer’s time are what matter, not the machinery’s labour.

Feature Proliferation (3rd August 2008)

An idea I often come across from people who make stuff with computers is that more features let users do more. It’s often motivated out of what the programmer finds easy or interesting to implement rather than what would help end users.

In practice, more features means users have a tougher time finding the one they need. Indeed, often the feature a user needs will be absent or won’t work properly. Often the cause is that the developers didn’t stop to think clearly about what users would actually need.

Sensible defaults can often preclude extra features. If the application works fine out of the box, you won’t need menus and windows and controls which let the user change how the application works. Users won’t need to tweak or babysit an application with sensible defaults.

A proliferation of customisations is as much an anti-pattern as a proliferation of features. Even if they are moved to an Advanced area or a settings file, too many will muddy the waters for expert users.

My thoughts about this have crystalised over the past month or so, while I’ve been using the essential GTA 2 Game Hunter. It’s built by a hobbyist in his spare time, which I think means good use of development time is all the more important.

There are lots of tweaks and refinements which would add up to a large and genuine improvement to the quite good usability it currently has. Yet the difficulty (or sheer tedium) of implementing them turns the developer off making these genuine improvements.