Noise Between Stations

Category: Information Architecture

  • Information per Screen

    I’d like to develop a finite, coherent set of attributes that determine how much information to put on a page (a virtual, scrolling page that is) and that size of that page. It seems like a small enough scope to get scientific about it.

    The bookseller site analysis I did was informative (long pages seem to be OK in some contexts, density of text and links are something to look closer at). Some other relevant issues might be:

    1. Cooper, who says navigation isn’t fun, so make fewer pages with more to do (my personal take here is that interaction design is harder than your usual layout-content-and-links design, so only use interaction design if you can nail the interaction, otherwise keep it simple
    2. factor in page weight of course (which in turn factors in download speed)
    3. factor in the time it takes for elements to display (since stuff loading in over time is actually what people experience)

  • Reedy Site Summary

    I’m following the RSS auto-this and aggregate-that discussions, and it’s all fascinating and sure to lead to some good blog browsing. But I’m not so sure what’s so rich about rich site summary. RSS is essentially headlines, links, and text. It’s ain’t rich media. Heck, it’s not even layout or visual design (don’t get me started about auditory design). But as a standard it’s taking off, and maybe we have to start somewhere.

    When it comes to syndicating blogs, presentation might not make much difference for most. But for some it does. How much do we lose when we strip a blog down to RSS? I submit for your approval:

    1. Webseitz, who can intersperse weblog and wiki entries like nobody’s business
    2. Harrumph, whose design is part of the story
    3. Textism, whose small caps and text figures would be trampled underfoot by insensitive, unthinking aggregators everywhere

    And that’s just layout, there’s functionality lost as well: email php thingies and open-links-in-a-new-window javascript thingies. All lovingly handcrafted and left behind in the rush.

    Why must Victor whine endlessly you ask? Why can’t he just get back to [ insert favorite topic ]? I see a lot of momentum here I can’t ignore. I think we’re seeing the challenges of designing for web services, which I pondered recently. RSS might be the relatively tame and simple predecessor to Web Services Experience Language (WXSL) or its equivalent. For designers this could be another hump like 1994 with a long learning curve but also a wide horizon of possibilities.

  • Library Science + Computer Science

    The current social networks thinking is fascinating, and will only get better once more people dig into web services, and then the semantic web. It’s a little disconcerting, embarrasing even, that no IAs are at the forefront of these discussions. Isn’t that what we do, find interesting patterns in information and present them to people? It’s high time we start balancing our focus on library science with some attention to computer science. Or better yet combining the two to result in information architecture designs that haven’t been imagined yet.

    When it comes to taxonomies/thesauri vs. ontologies as the organization scheme of the future, ontologies will win out because that’s what the computer science people are using. They control the implementation and therefore innovation on the Internet. IAs will just keep using what software is offered to us, unless we reduce our navel gazing and get into the programmer’s clubs. At least we can take encouragement in the fact that their interfaces still suck.

    Kudos to Eric for outlining an implementation of social networks.

    Update: Michael takes notice, and I hit on what Matt’s been thinking.

  • Mozilla

    Mozilla reaches 1.0. It looks like it was four years in the making. That says something about the speed of open source development, or the project management, or the scope.

    Maybe scope. I like Bill’s description: The OpenSource version of the NetScape Navigator browser. Or, a RichClient development platform.

    So far I’ve tried the Windows version and I’m pretty happy. The default theme, or whatever the skin is called, resembles good ol’ Netscape 4. Pages load fast and, my biggest problem with IE/Win, it knows that when I type Google into the URL box that I want to go to www.google.com. The page up and down keys don’t work like I expect (read: like they’re supposed to), but that’s a small price to pay. It’s a good first impression.

  • Stupid Visio Tricks

    I usually abhore keyboard shortcuts, since everyone knows mousing is faster. But for zooming and moving in Visio, this rocks…

    hold down Shift + Control, then:


    – Left click zooms in
    – Right click zooms out
    – Hold right button to drag page (Adobe-style)

    thanks to Brett for the tip.

  • A-Z Indexes

    The good folks at the Montague Institute posted a collection of A-Z Indexes on the web. These can be incredibly useful in the right circumstances. What I’d like to connect to these are both a method for choosing the terms and usability guidelines for when they make sense.

  • Word, Covering Its Ass

    character count

  • Crosswalk

    Once we build all these taxonomies, thesauri, ontologies, etc. we’ll run into situations where we’ll have applications that need to access more than one of these simultaneously. Throw in organizational issues like different departments ‘owning’ their favorite organization scheme and it all gets rather messy. We’ll either need to combine them or ‘crosswalk’ them, that is, mapping them so we know how they interrelate. I started a crosswalk page on the IAWiki to start tracking the issue.

  • XFML

    http://xfml.org

    ‘An open XML format to publish and share faceted metadata for websites.’ Could allow us to link among sites with more than just links, we could link by way of categories for example.

    But the low barrier of entry to blogging is what has made it so popular, so I hope tools for using XFML make publishing and receiving easy.

  • User Interfaces and Metadata Schemes

    I’ve seen a few projects now, mostly big ones, where we’re trying to create generic metadata behind a website, the idea being you can then use that information for other applications (an example of an application being a portal that uses a person’s customized preferences to filter a set of documents using metadata associated with the documents). But there always comes a point when we have to put a stake in the sand and accommodate the application at hand. Eventually the metadata ends up being customized to work for specific applications and not just any old application. So my current thinking is that we should ignore all but the applications at hand. Metadata can be massaged and schemes can be morphed later to accommodate other applications, or at least that’s the assumption I’m going on for now (please tell me if you know better).

    So, rather than start with a metadata scheme, it makes more sense to work backwards starting from the user interface…


    • do all your up front user-research
    • determine what information will populate the user interface
    • determine what kinds of metadata will be necessary to pair that information with those users (or uses)
    • given the metadata needed, devise the metadata scheme to organize it all

  • Convention vs. Innovation

  • Software

  • Zeldman on Rules

    Zeldman, refuting design knowledge mistakenly distilled into slop by the drunk and dogmatic: ‘If users don’t click, scroll and read on the Web, I don’t know what they’re doing.‘

  • Search

  • Omnigraffle Site Map Generation

    James is experimenting with Omnigraffle site maps.