MikePadgett.com

I’d be among the first to admit that, despite being a stickler for standards, sometimes I like to do things my own way.

For use cases, I should be using UML but I take one look at the diagrams and I run for my life.

For preparing ontologies, I should be writing OWL, but I end up writing my own XML variant with (shhh!) no schema. This is (almost) inexcusable, so I’ve decided to try to jump on this particular train and start using a bit of software to get me started.

Introducing Cmap Tools COE OWL

I wanted to have my cake and eat it. I wanted the graphical modelling capabilities of Visio plus the OWL export and minus the Office 2007 interface. Enter Cmap Tools COE OWL: a JAVA-based concept mapping tool with OWL export.

And what better way to introduce an concept mapping product than to display a concept map in place of a homepage? Well, a normal web page would probably have been better in terms of usability but it was a good idea anyway!

Note that Cmap Tools COE OWL is a distinct variation of the standard CmapTools.

According Cmap Tools’ custodian, the Institute for Human and Machine Cognition, the software “empowers users to construct, navigate, share and criticize knowledge models represented as concept maps”.

It’s available in great-tasting flavours Windows, Mac OS-X, Linux, Solaris and the One Laptop Per Child machine XO. It’s also free for individual, non-commercial use.

Working with the software

At such a keen price, I decided to try it out! I installed version 4.11.01

I don’t personally know any JAVA developers, but my experience of JAVA software has often been that the user interface was an afterthought - it seems to be a feature of the platform!

Lest I protest too much, Cmap Tools turns out to be a pleasant exception to the rule.

The UI is relatively straightforward, echoing the product’s overall simplicity. A separate initial window entitled Views is for file management and collaboration. From there, we can start work on a new project.

Most of the donkey work gets done via standard drag-and-drop functionality, enabling rapid drawing from a standing start with no prior experience of the software.

Growing the concept map is dead easy. Users need simply select the parent of the intended new node and drag from the top of the label. Dragging from the top does feel slightly counter-intuitive if one intends to branch below the parent, but that’s a tiny (and probably entirely personal) niggle.

As the ontology spreads, there’s an absolutely essential Autolayout feature that helps the user to bring under control any concept map that starts to look like Phil Spector on a bad day in court.

If, like me, the user likes to see a simplified view of the strict hierarchical order of their taxonomies and ontologies, then to the right under Cmap Outline, he/she will find a more traditional tree layout. What I think is a minor shame here is that the list cannot be edited from Cmap Outline. The same can be achieved in the forms-based adjacent tabs.

Export

Now for the all-important test: how’s the OWL output?

From my very first attempt, I find that the XML result isn’t exactly as expected. I need to go back to the software and try to be more explicit in the relationships between objects before eventually I achieve more predictable output.

Conclusion

Cmap Tools is a great bit of software for simple rendering of taxonomies and ontologies in the form of concept maps.

It’s not a serious development tool but as an all-rounder starter kit that’s safe to put in front of clients (with a commercial licence of course), it’s usable enough to invite the uninitiated to participate.

I’ve also recently started to look at Protégé, maintained by Stanford University’s National Center for Biomedical Ontology. This is the serious tool which, along with the Protégé-Owl extension, takes advanced OWL-based ontology editing and visualisation to another level.

In this item, I will refer to “editorial design” as the refinement and optimisation content presentation for content-driven websites.

Of course, editorial design for print predates the Internet and web designers may even take some cues from it, but this item is concerned only with the digital domain.

Article continues after the jump…

A very public row broke out recently over a report concerning the results of a survey published by Socitm entitled Better Connected 2007, which surveyed the level of accessibility of 544 local authority websites.

The brouhaha centred upon the methods employed by Socitm to generate metrics amounting to a thumbs up or down.

The ink on the publication had barely dried when the influential PSF weighed in conspicuously with vocal criticism of “continued peddling of what can at best called ill-informed pontificating and at worst out and out drivel.”

Better Connected is one such example, and the Insight team behind it add insult to injury by clipping town halls for £395 a pop as they vacuum up cash like the most opportunistic of privateers while cowering behind and milking their quasi-official .gov.uk status for every penny they can. [1]

The methodology consisted of a programme of automated testing, followed by human testing conducted by the RNIB, an organisation which has been seen to take a leading role in the promotion of accessibility best practice in recent years.

Acrimony surrounds the report’s implication that sites that did not meet the W3C’s WCAG were deemed to have “failed”, contributing to a generally gloomy bigger picture in which the site of only one local authority was rated ‘excellent’, 64 others reached Level A Conformance (compared to 62 in 2006) and the rest presumably trailed even basic standards.

The overwhelming issue highlighted by PSF and others [2] is that reliance upon WCAG, automated testing and narrow criteria does not make for an accurate assessment of accessibility, generating instead sensational headlines and more spin based on a “dodgy methodology which fails (and therefore implies inacesssibility of) perfectly good websites … This is doing more harm than good” [3].

Are false impressions being created? Certainly a great deal of energy has been spent mooting just that, but away from the glowering flames, there’s also the year-on-year grinding negativity of Better Connected to worry about.

The RNIB’s Donna Smillie suggests that there’s something inherently wrong about seeing accessibility as a boolean [4], yet there can be little doubt that many do make that mistake.

Though the context of Smillie’s statements is intended to support Better Connected, doesn’t the report - and the study as a whole - encourage a pass/fail view of things, attempting as it does to generalise into a digestible format what is a wide-ranging and often laborious area of practice treated in varied meticulous ways by hundreds of different organisations?

This is after all a quantitative study, not a qualitative one.

I have arrived at a logical pause in my efforts to write an Information Design library, so in the current fashion I’m releasing it as a “beta”.

Some time ago, I wrote in a post entitled “21st Century Job” that an Information Designer …

“…makes sense of complex information and communicates it … so that information is converted to knowledge.”

Now since I’ve been a consultant in this capacity for some time, I’ve learned a couple of things that have prompted these recent efforts:

1. Clients need to have a better understanding of Information Design
2. The concepts and processes I use need to be documented

The library (working title “Insight”) attempts to address both these issues by describing the conceptual framework of Information Design. So far, I have only just begun to discuss the design disciplines involved, starting with web-based design, the area in which I’m most active.

So rather than bang on about how I’m trying to write more nowadays anyway (future career move in the offing?), I’ll just close there.

By way of a postscript, I might add that “writing the library has been a labour of love”, but there are problems with that soundbite:

1. I make it sound like I’ve finished writing it, which I haven’t;
2. I didn’t love the writing, it was a bit of a grind, but I hope reading it won’t be!

If you didn’t already spot the link above, you can find the library at: http://www.fincaso.com/work/insight. Enjoy!

Flash is ten years old, as the BBC reports, and for any Internet technology still around after a decade that’s a considerable achievement.

When I started out in web design, it was almost the only medium I worked in, reflecting the tastes of the time. That was before the Flash backlash, led by the arch-headline-grabber himself Jakob Nielsen’s vociferous take on the matter.

Since then, the paths of Flash and I have diverged considerably. I rarely work with it nowadays.

Inappropriate Flash harms user experience

I haven’t seen developers breaking new ground lately, in the way every week used to bring extensions of Flash’s seemingly limitless capabilities in two dimensions.

Just at the time when Flash was in the corner licking its wounds, good old HTML enjoyed a renaissance with the adoption of web standards and increased accessibility. Today, JavaScript has taken markup into orbit and in a curious irony, it has also saved Flash from a further beating from the Eolas patent mess.

A few major successes have been brought to us by Flash in recent times. Yahoo has finally done the obvious and released a Flash mapping interface and YouTube’s video relies totally upon Flash’s video capabilities, of course.

Indeed, it’s the video stuff that ensures Adobe’s trusty plug-in is still relevant today, since the tech corporate’s vision of an all-purpose application delivery medium still looks years away, with a muted response to Flex and Microsoft’s competing Avalon (now imaginatively retitled WPF) technology tied to the long-delayed Vista.

“It’s a bit chaotic. There’s lots of noise, lots of activity. That’s great; there’s a huge amount of innovation” said Adobe’s Kevin Lynch [1] when asked about the future of Flash. Not a straight (or strong) answer.

In times past, Macromedia always managed to brave the storms, so perhaps Adobe can keep the tide in its favour.

Remember when a job was something to be proud of? When a job was a job for life?

Before you complain and click “Back” dear reader, let me assure you that this is not an article about the long-term effects of Thatcherism.

No Sir/Madam, this is an article about breaking free from the strictures of bad jobs and worse job titles and proposing a new role for the 21st century. It’ll come as no surprise to you that I’m trying to occupy this role myself.

I’ll call the role Information Designer. This isn’t a new job title - it already means something in Designland, but that definition isn’t nearly enough. It’s also a very basic job title, because the job should come with a wide brief and enough autonomy for the individual to firm up that brief. Indeed, Information Design already exists as a body of disciplines, but the job specs are always highly fragmented.

The Information Designer that I envisage is someone who, in the simplest terms, makes sense of complex information and communicates it effectively so that information is converted to knowledge.

The work includes elements of:

• Business intelligence
• Data analysis
• Web design (plus usability and accessibility)
• Graphic design (plus typography)
• Training and presentation delivery
• [Insert relevant disciplines here]

There are quite a few skillsets here, including those of web designer, graphic designer and information architect. I think that, just as web people need to have a good grasp of several technologies, so too should the 21st century Information Designer be very capable in each of these disciplines, rather than having to outsource bits of it to freelancers.

The 21st century Information Designer role has precedents. While designers could still avoid being pigeonholed, the range of Otl Aicher’s work comes close to my concept, as does the utility of Harry Beck’s solution to the mapping of the London Underground in 1931.

The Information Designer is a designer since his/her work is all about finding solutions, but the information could be absolutely anything considered complex needing logical organisation and it’s this latter aspect that goes beyond visual design.

What AJAX isn’t, in this context

Over the last couple of years, we’ve seen a significant leap forward in computing technologies and on one side of the coin, for the first time the Internet looks capable of delivering on the promise it showed a decade ago.

The flipside is that, during this time, the detritus of the computing has also increased exponentially, with over 95% of emails classified as junk [1] and ever more vocal reports of shady behaviour on the part of software vendors [2,3].

Enter AJAX

Riding the crest of this digital wave, the web technology “warp drive” that brought us Basecamp, del.icio.us and GoogleMaps - defined and described ad nauseam as “Web 2.0″[4] - represents both sides of the coin.

The positives are well-documented, the negatives less so. I decided to zoom in on one particular aspect: the conflict between AJAX [5] and Accessibility. This is not an especially new area of concern, but recently I wanted to check what progress there had been.

AJAX vs. Accessibility: why is there a conflict?

The key front-end advantage of the AJAX programming technique is that data can be served to the client without a page refresh. Small amounts of data are requested and managed by using a powerful scripting language. This language is JavaScript, and the AJAX technique finally shows how powerful it really is.

But therein lies the problem. Assistive technologies such as text-only browsers and screenreader software step over JavaScript altogether. As Joe Clark rightly points out [6], the WCAG 1.0 checkpoints include that:

“if you use applets and scripts: Ensure that pages are usable when scripts, applets, or other programmatic objects are turned off or not supported. If this is not possible, provide equivalent information on an alternative accessible page.” [7]

So how do we use a web application like Google Maps if our assistive technology steps over or mauls the very JavaScript that brings us the functionality needed to navigate the interface and serve maps dynamically? And just what would an alternative accessible page for a map of your hometown contain? Could it be something like David Hawgood’s map of Kent [8]?

Here’s another example: if we choose to validate a form with AJAX, so it’s possible to check for data entry errors in real time as the user fills out the form [9], then isn’t an assistive technology user at risk of entering invalid data?

One step forward, two steps back?

If, like me, you consult on web accessibility issues, then AJAX is a major concern: procurers see the power of an AJAX-ified application but none of the fallout.

People seemed to be all too willing to put aside the years of building awareness, interpreting and implementing standards and complying with the law just as soon as the jaw-dropping cleverness of this powerful (and discriminatory?) approach to web development became clear.

AJAX became a saleable “feature” of web applications, moulded into a point of difference that could be touted by salespeople who very likely had no idea what software had to do with the Achaean strongman.

The sad truth on this angle is that, as Clark succinctly points out, accessibility is also just a product feature.

For procurers whose personal experience of assistive technology amounts to little more than the wearing of spectacles, and whose personal knowledge of the law is as blurry as not wearing those spectacles, accessibility just ain’t sexy.

The response: silence!

One answer to all this might be: change the assistive technology software, not the development techniques. Another might be to simplify the complexity of the offering (often wrongly interpreted as “dumbing down”). In the best tradition of human interaction, the best response is probably to meet somewhere in the middle.

The product of research conducted by James Edwards et al on screenreader reactions to AJAX is predictable: the reactions are unpredictable. [10]

The key finding, for screenreaders at least, seems to be that the whole process of updating content inline, which is what AJAX facilitates, is not picked up at all. This acts out as “I select a button or a link and nothing happens“. Not good.

If AJAX is used almost totally to improve user interaction, Edwards makes a typically valid point: “[i]nteractions are just details, and perhaps what we’ve really been doing is projecting our own desires and preferences onto users for whom they’re not really relevant”.

Rolling with the punches

Imagine a boxing match attended by politicians. If you asked a cross-section of the attendees about the result of the bout, all that you’d learn is that the red corner and the blue corner both won.

Similarly, both of these are true: accessibility best practice is totally on the ropes and AJAX is seeing stars.

On the one hand, progress is both inevitable and inexorable, but on the other, we have come too far towards a best practice for accessibility to lose out now.

Seconds away, round two?

The old RouteOne website

A new website for RouteOne, the leading publication in the Coach and Bus industry, is set to go live shortly.

My job was to turn the old offering - primarily a storefront for new registrations - into an accessible, readable editorial site to reflect the investment in design.

RouteOne was a great opportunity for me to follow up on my recent interest in the area of editorial design and I did a lot of research into what works.

The business of designing for a readership turned out to be a process of experimenting with subtlety, since content and continuity are the most important factors in getting the site to sit well with users. I think we’ve certainly achieved this, based on the results of the testing I did.

The new RouteOne website homepage

As ever, the site is put together with a CSS-based layout and on this project, a full stylesheet was devoted to the provision of the numerous editorial styles that should make RouteOne distinctive and highly readable.

I really enjoyed working on the new site, my first under the banner of our new business. I look forward to the desired results being achieved!

Designers generally accept the HCI suggestion that human analogies can be useful in creating effective UI solutions. This is especially important when looking at graphical data overviews, or ‘dashboards’.

Using a human analogy in UI design is to cross the bridge between two and three dimensions. We only need to look at icons to see how useful human analogies can be: waste paper baskets, card folders, notebooks, keys, stamps. Tactile objects. I mean to say, how last century. But that’s the level of meaning we’re hanging onto in this (sort of) unfamiliar era, sick/excited about the future and digging retro like it’s going out of fashion.

The cover of the Adam Beyer / Jesper Dahlback CD here at my desk shows a Space Invaders type of arcade console. The kind of big unit you can now buy on eBay for an achingly cool six hundred quid, rehabilitated after serving 25 years-to-life in a Croydon pub.

Handsome retro like this makes me wonder if, on the desktops of the future, we’ll be seeing an iPod icon that represents music. Of course we won’t, the machine will understand what we’re after by electrotelepathy. It’ll retire all the HCI bods because there’ll be no interaction. Just in time to avoid the next age and draw on their comfortable (private) pensions like a hamster on its water bottle.

My father has been given a laptop at work. He’s sixty years old and he’s never used a computer in his life. Now he’s got to learn. I’m a bit sad, because he didn’t quite make it to retirement without being sucked into computers. He’s done a manual job (very well) his whole working life. So he’s going to need all the human analogies he can get when he comes up against the dreaded desktop.

Er, back to the point. Data overviews, otherwise known as dashboards.

As Alex Kirtland points out however, designers need to avoid excess “chartjunk”.

In other words, users want to see the data, not the graphical approach used to render it. And since we’re talking about analogies, let’s draw one with typography: the best type is that which readers don’t notice. Or in cinema, literate critics will reject a movie where overt, self-conscious styling makes the piece superficial.

It’s bad design that draws this parallel…

Then takes it as literally as this…

In the first two instances, the “soft” graphics absolutely own the layout. The data is crammed into ridiculous little dials around - and this is a triumph of banality - an array of extruded plastic “upholstery”.

In the third, an aberration against the usual trend of Mac excellence, we are looking at dials with an apparent scale of zero to one hundred. Zero to one hundred what, exactly? Well sure, but who cares with bevelling as fine as that?

The Apple approach to UI design has always been a bit of a tightrope walk between form and function, at least since the advent of more than 256 colours, anyway. It’s a tightrope walk that Apple tends to do rather well, but when we want data, it doesn’t need to be tactile.

For, as Kirtland states with admirable bluntness, “For the busy executive, quick comprehension outweighs a pretty picture every time”.

Quite.

And anyway, who says human analogies are always right?