Making Web Log Analysis Tools Better
design, information, internet
March 05, 2004, 12:22 AM
We're starting our final project in Mapping and Diagramming, which is self-defined. I've decided to focus on designing visualizations of web log data (not to be confused with weblogs, although webloggers are my primary user group), since I've always been of the opinion that the visualizations generated by most current tools tend to suck. So far I've come up with a few sketches and a description of the project.
Some things I want to explore include:
- Better maps of what paths people took through the website (including most frequented paths).
- Information on how long people spent on each page.
- New ways to diagram other important web issues, like page bandwidth consumption, where people come from (referrers), etc.
- Interaction designs for mechanisms to show how these usage trends change over time.
And possibly others as well. I'd like to check out more existing web analysis tools as well as look over some of the relevant research that's been done on the subject, so if anyone has some good pointers, let me know.
Oh, and Dan is doing something wacky with linking together the music people buy, or something.
IBM's Social Computing
information, society & sociology
February 29, 2004, 11:26 AM
Wendy Kellog from the IBM T.J. Watson research center, gave a talk at the HCII seminar series last Wednesday on research directions in social computing. It was one of those "look at all the cool stuff we did" talks, but there were some fairly interesting ideas underlying the mishmash of technologies.
IBM research have moved from developing funky visualizations of social phenomenon to emphasizing technologies that universally represent users in the computing environment. They call them "people proxies", but they are essentially a form of digital identity. For instance, one of these technologies, Grapevine, was an intelligent electronic business card that allows recipients to contact you via multiple mediums (phone, email, IM, etc.) without disclosing your actual phone number, email address, etc. Another, Rendezvous, aimed to make conference calling more transparent by making it easier to bring in more people without hassling with special phone numbers and the like. IBM are also interested in personal middleware, the idea that individuals should be able to create and manage personal web services which rove inter- and intranets to locate information and perform other tasks for them, and that these services (dare I say "agents"?) should be sharable (although the really hard question, how everyday users are supposed to create these services, was completely skirted by Wendy). The theory behind all these approaches is that the vast majority of a company's information assets exists in employees' heads, whereas only 4% exists in enterprise database systems. So currently, 80% of a company's IT budget is spent managing that 4%. These technologies aim to facilitate sharing the remaining information.
I ran into my friend Cristen Torrey in the hall last Friday and we had a short discussion about the talk. She was concerned about privacy issues, which always rear their heads when the subject of consolidated online identities comes up. IBM assumes that making certain information transparent will improve productivity and enhance communication, but it could also increase the power of those on top of the management (or government) chain, encourage micromanagement, strip us of the right to choose what details of our lives are public and which are not, as well as a host of other unintended consequences. Where are the guarantees that we will have control over our digital selves? Where are the researchers that are bringing these issues to the table? I have yet to see them.
Email Rob:
Information Design In Practice: Agnew Moyer Smith
design, information
February 25, 2004, 11:57 PM
Karen, our Mapping and Diagramming teacher, took us on a field trip yesterday to Agnew Moyer Smith, an information design consultancy in Pittsburgh's Southside. Don Moyer, Karen's husband and a partner in the firm, gave us a tour of the facilities and talked to us about a few of his current projects as examples of how he practices information design. Agnew Moyer Smith specializes in making complex technical topics clear and accessible to non-experts, something I'm particularly interested in.
Don spent the most time on a project he'd been working on to develop an information design piece that clearly explains how RFID tags can be used to improve supply chain management. He started out by reviewing an existing piece on supply chain management that AMS had produced for a previous client. This enabled him to set the stage for his own research by working from a similar document whose quality he trusted. He also began to look for sources of information on the domain, investigating a technical paper on RFID, some articles about it in the popular press, and his client's own initial attempts at explaining the process. Don warned against gettting caught up in too much research; he could have probably found hundreds of articles on the subject and although he may have learned a little bit of important information from every one of them, he would have spent days and days going through them all. It's best, he said, to find the book on the topic written for 8-year-olds; that way someone else has already done all the hard work of pulling all the information together and making it understandable. If such a book doesn't exist, however, then you'll have to make do with the most clear and comprehensive sources you can find.
Next, he started collecting together a list of all the nouns (things, actors, etc.) that existed in his problem domain. Then he started listing all the verbs that each of these actors could perform. Interestingly enough, this is the same approach software engineers take when modeling a problem domain for developing an object-oriented software design.
Don prepared a brief of the project for his client to ensure that they were both on the same page as far as the project's requirements went (in theory a brief like this is prepared by the client, but Don says that has never happened in all the years he's been working. The brief, if one exists, is prepared by the designer, just as requirements are developed by software engineers and not handed to them by clients). This brief contained:
- A short objective for the project.
- A description of the intended audience of the communication piece.
- The information that the client wants to know before completing the communication piece.
- The information the client already knows (or thinks he knows) about the subject.
- A list of the main messages or "story elements" that the final communication piece must clearly portray.
After getting the client's approval on the brief, Don started developing sketches of the process as well as a notation language for the nouns and verbs he had identified earlier. He then started assembling the spread itself. Don prefers to develop information spreads before powerpoint presentations or other types of information design; he finds that the page works well to force constraints on the design project that ensure clarity and effectiveness of results that might be lacking in a more permissive medium like a presentation or video. This is very much in line with my own rants on the value of constraints.
Once Don reached a solution he was happy with, he moved the project along. Although he would have liked to explore more solution possibilities, he recognizes that making a decision in the development phase early enough to leave room for sufficient refinement is important.
Next, Don wrote the prose for the piece in the form of numbered steps; he believes that it's important for designers to be able to write their own clear, concise copy. He then merged the text with his sketches, and called in a colleague to conduct a critique of his work. His colleage came into the crit cold and played at being a user, pointing out areas where he didn't understand what was being communicated. Don remarked that its common practice in AMS to post designs up in the kitchen or on boards around the space to get comments from the other employees as they wander around the floor.
Finally Don handed off his project to an illustrator to come up with some final iterations. Don described the finished project as "not just a picture, but a story". Thus the need for spending eight weeks on it.
Afterwards, Don showed us around the very impressive AMS space, which completely blows anything at CMU out of the water. The space was very much tailored to the work; projectors were configured to be easily connected to any laptop, bookshelves with design-related books abounded, small workspaces could be reserved by teams so they'd have a permanent location to store work relating to their project. Interestingly, there were no personal private spaces at AMS; everyone had an open desk. Even more interestingly, Don himself had the same setup; his desk didn't really look much different from that of any other employee. No clearly visible hierarchy in this organization. There were also many common areas to encourage conversation and collaboration, although the atmosphere also created enough quiet in the working areas for employees to get things accomplished without interruption. There were closed off conference rooms as well as small booths for private meetings and telephone calls.
Finally, Karen showed us some small booklets that Don produced apparently just for fun about a variety of topics that he wanted to know more about. Don's motives were mixed, however, since he also sent copies of these booklets around to important contacts in the hope that they would bring more work. In many respects, this reminded me of the motivations of open source software contributors.
It was a great experience to see a practicing designer at work. I wish we got more field trips in this graduate school thing.
Dan went along as well; his commentary is also available.
Email Rob:
A Map of my Daily Walk
design, information
January 28, 2004, 10:58 PM
For my Mapping and Diagramming class I created a map of my walking route from the front door of my house to Margaret Morrison A11, the room where our class is held. Karen asked us to imagine that an old friend (and not just any friend, a particular friend) had come into town to visit and we needed to leave directions at our house so that they could find their way to CMU to have lunch with us. I chose to design my map for my friends Kim and Alaina.
I'm fairly pleased with the results. The form of my walking route in this schematic line representation is interesting and the elements of the piece fit together rather nicely. I tend to favor a minimalist approach to visual design perhaps because I still have too little confidence in my instincts to add much "decoration". But I think it worked for me with this piece; the simplicity made it easier to focus on attractiveness and understandability.
It struck me that this piece came together fairly easily because the users and their tasks were so focused and narrow. We were designing for one person, and all we had to do was get them from our houses to school. The design solution flowed almost naturally. This leads me to believe that one approach worth trying with more complex problems is to split them up into their component tasks and then design solutions for each task. You can then integrate the "sub-designs" into a larger metaphor that satisfies all tasks, taking into account the relevant tradeoffs and priorities. This has the side benefit of creating easily dividable work for the members of a design team.
Email Rob:
Of Maps and Diagrams
design, information
January 24, 2004, 11:45 PM
I'm taking a course called "Mapping and Diagramming" this semester from the Design department, taught by Karen Moyer, whom some may remember from my postings on CDF. This time, however, I'm learning about the design of (you guessed it) maps and diagrams, which Karen describes as essentially that subset of information design that deals with high-density information artifacts. I've always found maps and diagrams fascinating in and of themselves, quite apart from any information they convey, so this is a neat course to have the opportunity to take.
So far we've talked a lot about analyzing maps as information objects, and the field is more complex than you may think. Many think of maps as merely representing factual information. The design of a map doesn't seem quite so hard since the information already exists in the world; all the designer must do is record it accurately and in a reasonably aesthetic representation. But nothing could be further from the truth. All maps are selective in the information they represent, whether that information is geographical, political, or something else. Many maps outright lie with respect to certain kinds of information to more accurately or prominently display others (Karen showed us a geodesic dome of the world where all the continents were accurately sized, but the oceans were completely off; the purpose of the map was to allow comparison of the continent sizes while retaining the spherical form of the earth). Some maps may even make a political argument through the information they choose to analyze; Charles Minard's famous map of Napolean's Russian campaign is an example.
The definition of a "map" we're using is also broader than one may think; kayaking eskimos use a piece of wood carved in the shape of the coastline to navigate by. A series of photographs of the intersections of a highway is another example.
The essential goal of a well-designed map is (usually) to present a large amount of information that is intuitively understandable to its audience at a glance. Richard Saul Wurman's book Understanding is a nice collection of year 2000 statistics on the USA presented with this design goal in mind. Information design of this quality should be regularly produced by the government in a healthy democracy rather than relying on the good will of a cabal of famous designers (Wurman and his compatriots lost money on the project).
A final note: Karen mentioned a group of urban planners who had members of the community they were seeking to redesign draw maps of the areas in which they lived to find out what places were most important, dangerous, etc. to the inhabitants. An interesting user-research technique.
Posted by Andyed on January 25, 2004 at 09:49 AM
There's some seminal work from a couple of other CMU'ers, Larkin & Simon, that provides compelling a cognitive psych account of how diagrams an serve as a very rich form of external memory, extending the reach of computation:
Email Rob:
The Case of Powerpoint
design, information
January 06, 2004, 12:02 AM
Kevin has a nice summary of several of the Powerpoint-is-bad memes that are out there on the internet. Going over these again got me thinking about how one cause of this problem might not be any particular design flaw of Powerpoint's, but rather an extension of the tool into areas it was never meant to enter. Powerpoint is reasonably good at putting together visual aids for lectures and talks, and as long as it's kept to that purpose it tends to shine (Neema, who is an ardent defender of Powerpoint, proved this with his excellent presentation, "A Spiritual Journey", on his 9-month adventure across Europe/Asia/Africa). The problem arises when people use Powerpoint as their sole venue for information presentation. As Tufte points out, the slideshow format is inappropriate for many communication purposes.
However, there are many who use Powerpoint not only as a means of presenting visuals for a talk, but also as a way of publishing take-away materials for the audience and even for storing databases of information so that it can be quickly pulled together into a presentation format. On the one hand, this is a perfectly reasonable strategy for busy people who don't have the time to maintain their information in a more appropriate tool, then convert all the relevant bits into Powerpoint slides. On the other, this leads to all the problems Tufte rails against for the reasons he defends far more eloquently than I can hope to do here.
Perhaps the answer lies in developing tools that support more robust single-sourcing techniques, both for authoring and publication. Such tools should not only make it easy to store content generically and squish it into a variety of presentation templates, but should afford using the appropriate templates for each information presentation purpose. But who will provide us with a vision of what such a tool might look like? It'd be an interesting challenge to take on.
Email Rob:
Metacrap and Categories Revisited
information
October 04, 2003, 03:12 PM
I came across (Micah -> The Midnight Blog -> The Well) Cory Doctorow's essay on Metadata, entitled "Metacrap", where he outlines the reasons why the sort of universal metadata-enhanced world that information storage and retrieval experts dream of (he calls it meta-utopia) is practically impossible. Of special interest is his section on why schemas aren't natural, where he basically makes the same point I did in my post on why categories don't work so well (in brief: they are too hard to get right). He makes some interesting, true, and slightly scary points, since XML as a mechanism for universal information storage basically relies on bringing about the meta-utopia he pans.
Posted by Jordan on October 04, 2003 at 04:21 PM
Metacrap is a great essay -- makes one think about leveraging the power of groups to get to accurate metadeta -- I don't know exactly how to do this -- maybe we can learn something from wikipedia, etc.
Posted by Rob on October 05, 2003 at 10:12 AM
You might be interested in some of the things we're studying in CSCW. Unfortunately Bob axed all the readings on Recommender Systems in the interests of time, but much of the other things we're learning might also apply to ideas like this one.
Dana and I are planning to try to distill as much of the readings as we can into digestible design principles. I'll post more about that when there is more to post about.
Email Rob:
Newsable: Ready to Rock!
information, internet, software development, usability
October 04, 2003, 01:14 PM
It is, after all, Rocktober.
I've just unveiled Newsable 0.8 beta to a breathlessly-awaiting public (this public, in case you were curious, consists of Kerry and Jordan), thus marking the first release of my web-based news aggregator / modest experiment in merging open source and usability. The low-down on the current status follows.
First off, go ahead and create an account to take Newsable for a test drive. No, I really mean it. Go do that now.
Ok, now that you're back, let me confess that a few things still need work in the current release:
- The interface is ugly as all hell. Jordan is kindly lending me some of his awesome graphic design skills to help fix that. Additional help would of course be greatly appreciated.
- There are still known bugs. Namely, the harvester isn't entirely behaving itself, and the RSS autodetection algorithm needs a bit of improvement to handle the real web. I'll try to get these cleared up ASAP, but the system should be usable in the mean time.
- The help system isn't available yet. If you get confused about something, feel free to email me. This will help me know what needs documentation / usability improvements as well.
- Some of the interaction design decisions are tentative. The "Archived Stories" tab exemplifies this best. I don't yet have enough user data to make guided design decisions about these features. The personas still need some refinement.
- Some more advanced features aren't yet available. OPML import / export support is one of these. I hope to have these in place before 1.0
As you can see, there are many opportunities to get involved with improving Newsable even if you aren't interested in writing Perl code (unlike the majority of open source projects). Please email me if you have any ideas for improvements in the aforementioned areas. I may try to set up a mailing list soon to create a central place for discussion.
Happy reading!
Posted by Mathilde on October 04, 2003 at 01:21 PM
The release also consists of myself. :-) I volunteer to help Jordan with the visual design. I *need* to fix it if I am going to use it. It's *soooo* ugly right now. :-P
Posted by Rob on October 04, 2003 at 03:28 PM
Huzzah! There is benefit in doing a crappy job; it convinces others they need to give you a hand ;).
If anyone else has any interest in helping with the design or implementation of Newsable, do speak up! It doesn't even have to be anything significant; every little bit helps.
Posted by Mathilde on October 05, 2003 at 02:03 PM
Oh no! You started saying "Huzzah!" too! Curt has corrupted you. ;-)
Posted by jeff on October 05, 2003 at 07:44 PM
Congrats on the launch Rob.
Now for some constructive criticism. One long page of feed seems very hard to scan. I especially have trouble seeing the breaks between the sites.
When I order by newest, I see the newest post of the newest feed, then scroll through the entirety of the older posts of that feed before hitting the newest post of the second-newest feed. Repeat.
Since every ordering scheme except alphabetical seems to aggregate by feed, seeing breaks between feeds could significantly assist scanning.
A potential solution would be to remove the feed title from every post, and use it instead as a header that separates one feed from the previous feed. This has the added benefit of saving one line per post. Many lines over the course of the page.
Posted by Rob on October 05, 2003 at 08:16 PM
Oldest-to-newest and Newest-to-oldest actually interleave feeds, ordering entirely by Posted Time. What's probably throwing you off is that some RSS feeds don't contain Posted Time information, so Newsable has to substitute the time that it harvested the feed for the Posted Time (RSS 0.91 feeds are the offenders, in case you are curious). This means that when you first add a feed, all the posts in it are assigned the same Posted Time (the time you added it) which has the effect of aggregating them by site initially (this will change as Newsable harvests new content, though). Of course, there might also be a few bugs in Newsable at the moment that are exacerbating this problem. I'm looking into it.
Your point about site-separation is well-taken for the by-site ordering. I have an initial design idea (alternate the background gray-and-white by site, instead of by story) that should go into 0.8.1 or .2, but I like your "pull out the feed title" suggestion as well (although that'll be a bit harder to program).
Thanks for the great comments!
Posted by Jeff on October 07, 2003 at 04:27 PM
The more I understand how Newsable scrapes sites for feeds, the more impressed I become. It seems very much in the spirit of Mark Pilgrim's Ultra-liberal RSS Locator. Nice work.
Posted by Rob on October 07, 2003 at 07:56 PM
Thanks, Jeff. It turned out to be a much harder programming problem that I originally thought it'd be, given the mess that is the current state of real RSS feeds out on the real web. Conflicting standards and incorrect implementations galore.
I just came across Mark's RSS locator as well. He also has an ultra-liberal feed parser available; both of these projects are open source. Sadly, Newsable is written in Perl and thus can't take advantage of these excellent resources. Had I known Mark had done all this work for me three months ago I would have written the damn thing in Python. I hear its a cleaner language anyway.
The good news, though is that I found a Perl port of Mark's ultra-liberal RSS locator yesterday and plan to integrate it into Newsable in the next release. This should greatly improve the "Add to Newsable" functionality.
Posted by Kevin Fox on October 17, 2003 at 12:50 AM
Oooh... OPML support... I can't wait! (and I'm *not* being sarcastic!)
Email Rob:
On the Inadequacy of Categories
design, information
August 24, 2003, 10:11 PM
As I just mentioned yesterday, a common technique for organizing information is to put this information into categories, thus making it easier for users to locate specific information as well as search for types of information based on predefined properties. Generally speaking, this works pretty well; libraries and other information-rich environments have always lived by their categorization schemes.
But then someone got the bright idea to allow ordinary users to define their own categories for their own information. This, I'd argue, doesn't work so well.
A case in point is the very weblog you're currently reading. Shortly after starting roBlog, I went through a fairly rigorous process to develop categories for my current and future posts. I was hoping these categories would be fairly exhaustive (most every future post would fall into one or more of them), fairly meaningful to my readers, fairly few (I didn't want a huge list of categories that was hard to scan), and fairly balanced (I didn't want all my posts clustered into one category).
I'm becoming more and more dissatisfied with the results. I'm finding that most of the posts are clustering into a few categories and even I can't always tell what category a particular post should fall under, so I can't imagine its intuitive for you guys and gals. One option is to simply create more specific and a wider variety of categories, but I'm concerned that this will soon cause the number of categories to balloon into something unmanagable.
In "Inmates", Cooper complains about file systems (which are generally hierarchical, but hierarchies are essentially nested categories); he feels it is unrealistic to expect users to effectively organize all their personal information through this paradigm. And I can certainly relate to this; I know many people, all of whom are highly intelligent and very computer-saavy, who constantly lose track of where they put things in the file system. But even more specialized applications have this problem; I've given up on trying to categorize my MP3s by genre; I'm never able to remember what I filed a particular song under and I rarely want to hear all songs in a given genre.
The basic problem, I believe, is the user-built categorization schemes expect users to know what kinds of questions they're going to want to ask when searching for their information before they actually need to ask them. Most users don't have sufficient experience in the domain to know their own behavior patterns. And most of those users that do won't have reflected sufficiently on their own practices to design effective categorization schemes anyway.
The upshot is that designing good categorization schemes often requires extensive training. Library Science is an entire field that focuses mainly on solving this very problem. For those of us that lack such training, its difficult to know how to categorize the information we work with for maximum productivity.
For my own categorization problem with roBlog, I'm considering taking a suggestion Micah made; he thought I should group posts by certain interesting topics (such as some of my professor's names) since this would gather information on those topics in one location for Google searchers and the like. I'm thinking that these topics wouldn't be exhaustive; they'd be more like the "features" sections that Micah has on his own weblog.
Posted by Dan on August 25, 2003 at 07:28 AM
Micah made the same suggestion to me. I've considered making a MT category for each professor, but, over the course of a semester, since I'm trying to write about each class, the prof would have dozens of entries. Plus, I worry about stealing a prof's mojo in my blog. :)
As far as your categorizations, you took a "top-down" approach to creating them: trying to create broad categories to contain everything. That approach usually means some things will be odd fits. The other approach, "bottom-up," is the opposite: the content's characteristics create the categories or, in other words, the information architecture. As you pointed out, this can be too specific. This is why IAs get paid money.
An IA would probably do a card sorting exercise with your users, having them arrange your entries (one per card) into piles, then having them name the piles. Do that with several groups users and you some semblance of a navigation scheme. You've also spent several days and many thousands of dollars. :)
Have you looked at your logs to see how much your categories are even used? In six months of reading, I've never used them, but perhaps I am an atypical user. Search seems to fit the content of your blog much better.
Dan
Posted by Rob on August 26, 2003 at 11:15 PM
Yeah, I made a conscious decision to take a top-down approach to developing the categories; I didn't want to make them up as needed for each post since I was afraid of winding up with the "category soup" that lots of weblogs suffer from. I wanted the number to be short, sweet, and managable. Plus coming up with categories on the spot may wind up with lots of categories at wildly different levels of generality.
I agree with your assessment of the "correct" approach to take in this situation, but as you implied, I can't spend several thousand dollars on this weblog. I think this lends credence to my claim in the post that developing effective categories requires training and most ordinary users (even fairly design-saavy ones like me) can't do it effectively.
I have checked my logs, actually, and surprisingly categories are accessed fairly frequently. Much less so than the main page, of course, and less so than some of the more popular individual entries, but still a respectable amount and much more than the search url. Which surprises me too; I certainly search my weblog much more than I browse categories. But then I'm as far from a "typical" user as you can get (or maybe not; I have a sneaky suspicion that I use this weblog much more than anyone else does ;)
Email Rob:
Info Design's LATCH
design, information
August 23, 2003, 07:22 PM
This one's gonna be a quickie, but I wanted to throw it up while I was thinking about it.
During the last week of CDF on information design, our instructor, Bob Swineheart, remarked that there were five ways of organizing information items. The mneumonic is "LATCH":
- Location
- Alphabetical
- Time
- Category
- Hierarchy
I've been thinking it over, and so far I haven't come up with organization scheme that doesn't in some way fit into one of the above. Thoughts?
Ok, now I'm heading over to Walnut Street to drink and party with the new MHCI students. Less bloggin', more boozin'! :)
Posted by Jeff on August 23, 2003 at 08:01 PM
Richard Saul Wurman covers LATCH in Information Anxiety 2. He describes it as a finite list of organizational possibilities. I think this is largely because Category is such a catch-all scheme.
The choice of how to organize infomation isn't always obvious, since more than one scheme can apply, either exclusively or in tandem. Case in point is the Vietnam Memorial Wall, first approached as an alphabetical listing, and then refined as chronological, or the yellow pages, both categorical and alphabetical.
Posted by Rob on August 24, 2003 at 05:44 PM
Thanks for the reference; I knew Bob said he'd heard of LATCH from somewhere else, but I'd forgotten the name of the guy. Here's the book on Amazon.com, for posterity.
I thought about this a little more, though, and realized this list doesn't cover a "network" as a means of organizing information. Granted, networks are rarely useful as organizational schemes because they tend to get confusing quickly, but I'd imagine they are appropriate (or perhaps unavoidable) for at least some types of information organization.
Posted by Jeff on August 24, 2003 at 06:36 PM
Isn't the concept of "network" an offshoot of the location principle? Maybe I'm not understanding exactly how you mean. In any event, network seems too much like a "thing", sort of like saying that a bookcase is an organizational principle.
Posted by Vishi on August 25, 2003 at 12:20 AM
Hierarchys are basicly trees structures. Categories make hierarchies. Location, alphabet and time are types of categories. There may be lots of other types of categories like author, application used, etc which are the meta data of the object being described.
Now, a network or a semi-latice is made up of hierarchies or trees. More info on this is here (http://www.rudi.net/bookshelf/classics/city/alexander/alexander1.shtml).
Posted by Rob on August 25, 2003 at 01:09 AM
By a network, I mean an organizational structure where each information item is organized by its association with some subset of the other information items in the structure. Maybe "graph" would be a better term. Mathematicians define hierarchies as special cases of graphs (hierarchies usually have a single root and every child element has only one parent, whereas graphs have no root and every element can be associated with an arbitrary number of other elements). Friendster's mechanism for organizing your personal network would be an example (although maybe not the best one).
I suppose this could be considered an offshoot of "location". I was thinking that part of the definition of "location" was that each information item had some absolute position in space, independent of the positions of other information items, whereas in a graph information items are ordered purely with respect to one another.
Vishi: It's true that in some sense location, lexical order, and time are all categories; philosophers would say that all these things are properties of the information item. But to an information designer, thinking at this level of abstraction is rarely useful since good design is very much about staying concrete. Most users don't see lexical ordering and chronological ordering as the same thing. Remember, we're trying not to be astronauts here. :)
Posted by Vishi on August 25, 2003 at 12:34 PM
The lesson of the architecture astronauts is that, it makes it easier for the designers/programmers to work with abstract patterns, but they should not loose focus of the user. Task based interfaces help in working with abstract patterns while keeping the user in focus. So, what is important to an information designer is which categories are important to people while doing a task. The importance of the Location, alphabetical , time or something else depends on the task the user is doing and cannot be generalized.
Posted by Jeff on August 26, 2003 at 10:10 AM
We talked about LATCH in studio yesterday. Cheryl brought up the possibility that a sixth organizational scheme was "Random." This caused much discussion, including the possiblity that the acronym could be LARTCH. I prefer L'CHART.
Posted by Rob on August 26, 2003 at 12:26 PM
"Random"... That's a good one. Almost always a bad organizational scheme, but unfortunately also often the easiest to program. Until last weekend, my "Friends" sidebar was organized using that scheme, as you may have noticed. Then I learned more Perl...
Posted by Rob on August 27, 2003 at 11:39 AM
Just wanted to point out that Micah has more on this, including some interesting analysis of LATCH by Ryan.
Posted by Jeff on August 31, 2003 at 12:18 AM
In the first edition of Information Anxiety, Wurman hadn't yet come up with the clever acronym and was referring to "hierarchy" as "continuum". There's a subtle difference, but maybe not enough to justify a sixth method.
Posted by Rob on January 21, 2004 at 09:10 AM
As a quick follow-up: Jeff had it right when he noted that "hierarchy" was originally called "continuum", which is really a more accurate name. "Hierarchy" implies some sort of tree structure to many people, which is really just categories of categories. But the hierarchy in LATCH refers to a continuum organization where each information item is organized in relation to the other items based on some property; e.g. widget A is bigger that widget B which is bigger than widget C, etc.
Email Rob:
On the Properties of Links
information, internet
June 22, 2003, 11:40 PM
I've recently become peripherally aware of a discussion that's going on among the widely-read webloggers on what makes a weblog a weblog (as opposed to a normal website). This reminded me of a discussion I had with Micah after his CHI Weblogs BOF. At the session, Micah gave a quick definition of a weblog entry, which he described as necessarily having four components: a main link, some commentary on the link, a "posted at" date by which the entries are ordered, and a permalink. At the time, I took issue with the "main link" idea; I felt that this assumed a certain type of weblog, namely the "MLP-style weblog" that tends to be centered around spreading links to interesting content. Kevin, who was also participating in the discussion, remarked that he frequently posts entries that are spawned by his own thoughts and not directly from something he read on the web, a sentiment that I echoed (to be fair, Micah emphasized that he wasn't trying to present a rigorous definition so much as he was trying to give an idea of what a weblog is).
Since then, however, I've been thinking a lot about links and how they are used in weblogs. There's been a call recently for more expressive links on the web. Right now, all an <a> tag can really say is "this text refers to this other document". As a human, you may be able to infer the author's purpose in linking that particular text to that particular document, but a machine cannot do so, limiting the analysis capabilities of web robots. But what if you could, through a more powerful <a> tag, say things like "this text is rejecting the argument presented in this other document" or "this text refers to the person who wrote this other document". This is in line with the "semantic web" concept: Berners-Lee's vision of a more meaning-driven web that internalizes the separation of content and presentation. I find this idea quite intriguing; I have a strong intuition that there are lots of interesting things we could do with the web if links could express why they were made. Merely knowing whether the author agrees or disagrees with the documents he links to could open up whole new dimensions for social network analysis tools, for instance.
This lead me to reflect on my linking habits for these weblog entries I write every now and again. I realized that I have several types of links:
- Inspiration Link: I read this document, and it directly spawned this post. This is in line with Micah's "main link" concept. If you take a look at my post about Kevin's Fury redesign project, you'll note the link to his post that reads "a project to redesign Fury" is of this category.
- More Information Link: This document contains more information about the object or concept that the text refers to. The "eat your own dog food" link in my Natural Programming and Open Source post is an example of this type.
- Definitive Referent Link: This type links to a definitive depiction of the thing the text refers to, perhaps a picture of a person or their homepage (the links to people like Micah, Kevin, and Tim Berners-Lee in this post are examples) or a book's listing on Amazon. In the most direct case, the text names a specific HTML document and the link takes you there (an example is the "Natural Programming and Open Source post" link just above).
- Supporting Document Link: This document supports the point made by the link text. The "by his own admission" link in the Fury redesign post is an example of this type.
- Source Link: This document is where I got this information from. Basically the equivalent of a reference in an academic paper. In the Corporations are Plural Nouns post, the "Center for Auto Safety article" link is an example of this type (it doesn't look like I make extensive use of the Source Link type on this weblog, at least not in its pure form).
- Related Post Link: The document I'm linking to is related to the current weblog entry. Usually I use this to connect two posts on my site that are part of the same train of thought. The reference to the CHI BOF post and the Justifying My Existence post in the first paragraph are both examples. My "Threads of Thinking" idea (whoops, I just did it again :) is intended to help visualize the structure created by these types of links. Sometimes, these also seem to double-up as a Supporting Document or Source Link.
This is not meant to be an exhaustive list of the purposes of links; I can think of many more. But I think this post demonstrates that even within the limits of roBlog, the diversity of purpose that lies behind those little blue words is astounding.
Email Rob:
Email Rob: