Boxes and Arrows: Comments by Scott Germaise

Scott Germaise — Fri, 26 Jan 2007 14:52:48 GMT

Regarding Mike’s comment… For large sites, some text labels or clear abbreviations may be appropriate for specifying levels/hierarchies and numbering pages. It can certainly take up a little more space, but offer clarity in a large structure. Especially if there’s tons of tree/flow pages and you’re sharing docs withn non-IA types who might be more likely to be easily lost in a structure. Plus, assuming this is used only at a 2nd tier category level, if you have cause to move the 2nd tier boxes around, you don’t have to re-number everything. Face it, you move stuff when you can’t fit things below, to express the order of menu items, (even if it doesn’t really matter because you’re not really reflecting the design at this point). And you certainly can’t have 1.3 showing up to the left of 1.2.

For example, you might have 1.0 as the home page, then 1.abt for the About Us section, which would subsequently have 1.abt.1.x and so on. (Or whatever works for you.) Personally, I like the numbers better, but I’ve found the text method useful on a few occasions.

The thing is, even with some small abbreviated text, if you have a textual outline or page list with page requirements, (for example, using MS-Word and tagging the page names with a heading), you can still easily outline/sort the page requirements and automatically create index/tables of contents.

Scott Germaise — Fri, 26 Jan 2007 14:52:48 GMT

“Working with a small set of real data lets you find out about the real state of the data.”

True. But a warning… acquring truly real data may actually violate privacy provisions of a client. And even if it doesn’t, you just never know where some presentations may end up. Is this a big problem? Probably not. Still, the wrong stuff in the wrong place and you could have a crazy large liability problem that started with a totally innocent and well-meaning plan. I’d suggest if you pull real data, you switch about the fields from record to record so nothing represents a real record.

Scott Germaise — Fri, 26 Jan 2007 14:52:48 GMT

“When is a true, live accessibility strategy going to matter to enterprise software companies?”

Right, wrong or grey area, the answer to this one, with regards to resource efficiency obsessed commercial business, is simple. Companies will more fully embrace accessibility when embracing such a strategy has some clear gain or not doing so has a real risk of loss.

In the case of loss, companies that want to develop for the U.S. govenment may risk some contracts for non-compliance. In the case of gain, clearly niche products that serve a particular market in need is one obvious area. More generally, it’s conceiveable that sites designed for accessibility may be more portable by their nature, hence easier, (meaning less expensive), to port to multiple user-agents.

Scott Germaise — Fri, 26 Jan 2007 14:52:50 GMT

“In my experience, accessibility is about making sure that people with disabilities can interface with the product and ingest the information. But making a site accessible does not necessarily make it useful or user-friendly.”

Maybe true. Are you sure? What are we really talking about here in terms of accessibility? Chances are we’re really mostly talking about sight-impaired or wholly non-sighted users. And it does seem true that making sites more accessible in this regard does involve some overhead. (Using image/text hiding/visibility techniques with CSS and so on.) As to your comment about accessiblity not necessarily being useful or friendly… Using CSS and truly structured content the way it’s supposed to be, making an accessible site shouldn’t HURT the primary design goals. Certainy accessibilty includes the simple reality of something like 100 million in the U.S. over age 40 and some vision degradation in large segments of the population. Glasses/contacts/laser notwithstanding, isn’t it best to not used fixed fonts that can’t be easily adjusted by a user? For that matter, you’re also concerned about users increasingly upgrading to higher res monitors who may also have problems with fixed fonts. (Due to how graphics adapters and operating systems end up rendering them.)

Beyond basic readability, deeper accessiblity in order to be readable by more esoteric user agents likely takes more effort. So how does expending this effort add enough value that development teams will expend the effort? Maybe… maybe it helps cut costs in an unknown future. (Which is admittedly a hard sell.) But think about it; accessiblity is essentially about making sure content elements are available to various user agents/devices that can in turn provide the content to people. (Or maybe meta data about elements to search tools.) In a world where new devices in all shapes and sizes are showing up every few months, you could make an argument that an accessible site is more likely to require less re-working to accommodate such devices. (Hey, I said it was a stretch. But at least you could argue – from a future cost/risk mitigation standpoint, that 1% – 3% more effort to achieve better accessiblity is a worthwhile upfront cost.)