Monday Sep 18, 2006

Reading at work: Rosenfeld and Morville's Information Architecture for the World Wide Web, 2e

My flight to Seattle's TechDays a couple of weeks ago ended up being delayed by about an hour, so I had enough reading time to finish the second edition of Louis Rosenfeld and Peter Morville's Information Architecture for the World Wide Web.

Because the book's publication date is 2002, the various dynamic elements of AJAX-style interactions are touched upon very lightly. The book ends up arguing along the lines of "designing for the lowest fidelity is safest", but I'm not sure that browser expectations can be traded away so quickly today. Certainly some of the example websites cited in the text now use a substantial amount of AJAX enhancements that improve site interaction.

Rosenfeld and Morville's main point is that information architecture—the organization of information so that that information can be successfully retrieved by the various individuals that interact with a site—is hard. Having spent some time worrying about how to publish the engineering workflow around ON (and, I believe, OpenSolaris more widely) open software development, and to make sure that that publication is navigable and meaningful over time, I can only agree. The book presents a medium-scale overview of information architecture: there are "basic principles" chapters on organization, labelling, navigation, and search, as well as case studies and thoughts about practice. Various classic tradeoffs, simple usability tests, and kinds of site prototypes are concisely introduced and then expanded upon, leading to more advanced considerations.

Beyond the illustrative examples from a wide set of websites, one thing that was of particular value to me was learning about the potential role of thesauruses as a specific form of metadata, and how that metadata can be used to make search-based navigation capture a larger set of related documents. We're also outgrowing the initial design for the site, so we'll use some of the ideas presented in the "Process and Methodology" section. The example strategy document is also a useful case study—we probably need to develop a similar document for in a collaborative fashion in the website project.

The authors also identify some of the potential career forms an information architectural role might take, as well as how information architecture's shared boundaries with implementation and graphic design are fuzzy. It seems to me that every substantial open development community needs some kind of information architecture, if only to support the classic user/developer audience split, so some of the credentials they suggest might be necessary for a corporate information architect appear elite, or unusual, for a community effort.


Available via Sun's subscription to the O'Reilly Safari online library.

[ T: ]

Wednesday Dec 14, 2005

Reading at work: Sturgis, Standard code of parliamentary procedure

[ Alice Sturgis, The Standard Code of Parliamentary Procedure, 4e., Mc Graw-Hill, 2000. ]

As I mentioned, I wanted to make sure the team gave some additional support to the governance work being done for OpenSolaris. When I thought about it for a little bit, I realized that, while we have recent and valuable experiences from the open source communities that have established organizational structures and codes, setting up societies and deliberative bodies and their rules is something that's been going on for a while. So, on a late night dealing with a disk problem at home, I read most of the transcripts from the U. S. Senate's Oral History Program's interviews of Floyd M. Riddick, who was Senate Parliamentarian from 1964 – 1974. (There were a number of reasons I ended up here, but one was to determine what lessons bodies like the Senate might have for a fledgling organization.)

The fact that a word like "parliamentarian" exists means you have a solid angle for searching, as well as a hint that you might not need to reinvent everything. If you search, you'll find there are two U. S. national organizations for parliamentarians, and that the two primary rulesets are Robert's Rules of Order, Newly Revised and The Standard Code of Parliamentary Procedure. There's a whole industry around RONR and much information online; the SCPP is a complete procedure, simplified to remove some of the more unusual parts of RONR, so I thought I would work through that. (So more reading at work.)

One of the first quotations in the book, in Chapter One, is in turn a quotation from Clarence Cannon, who was Parliamentarian of the U. S. House of Representatives (and subsequently a Representative), which reads:

These rules of Parliament and Congress are designed for bicameral bodies, generally with paid memberships, meeting in continuous session, requiring a majority for a quorum, and delegating their duties largely to committees. Their special requirements . . . have produced highly complex and remarkably efficient systems of rules peculiar to their bodies, but which are, as a whole, unsuited to the needs of the ordinary assembly.

— Clarence Cannon, "Rules of Order", Encyclopædia Britannica, 1964.

I interpret this paragraph as "imitate us at your own risk".

But SCPP does identify when reasonable alternatives to its formulation might be considered, and how they may or may not lead to distortion of the principles of majority-based decision making or the silencing of minority viewpoints. For instance, the idea of requiring a unanimous result for a particular vote means that a minority of one can block resolution of the motion being voted upon. Similarly, a supermajority voting requirement means that a smaller minority can block that action. (Perhaps I'm just pleased that the reference frame that's being taken is similar to an engineering frame: "how do we construct an assembly so that it can make progress on difficult issues?".)

I'm still reading SCPP, mostly with an eye to being ready to design's support for various kinds of voting, but feel free to recommend you have a look at it now.

[ T: ]

Friday Jul 01, 2005

Reading at work: Lencioni's Death by Meeting

One of the nice aspects of working at Sun is that the company subscribes to a number of online libraries. Usually I consult these for overviews and introductions to technologies I use rarely or need to put into context. But occassionally, I'll read a business book.

This past week, I took two chunks of time out—an evening at home, and a half hour this afternoon—to read Patrick M. Lencioni's Death by Meeting : A Leadership Fable... About Solving the Most Painful Problem in Business. The title is melodramatic from every possible angle, and the main argument is targeted much more to executives and general management teams, but I can see a few aspects that will help in our own technical meetings. The point about the hidden cost of "sneaker networking" as opposed to having an effective meeting hits close to home.

This text is in Sun's available collection at NetLibrary.




« July 2016
External blogs