Archive for February, 2009

Lipstick on an Aardvark

After our first round of product testing, we decided to make big changes in the look of our Infovark product. This is the first of an occasional series of posts about the design of the Infovark Beta.

We use the Infovark mascot — we call him “the Vark” — to represent our company. We use his head for our avatar in twitter and as the favorite icon for web bookmarks.

varkhead_original

I like the simplicity and abstract look of the icon. It has a certain Scott McCloud less-is-more aesthetic to it. As Scott explained in his book Understanding Comics, the less detailed an illustration is, the more it invites the viewer to use their imagination to fill in the gaps. The more detailed a drawing, the more it represents a particular thing. We wanted Infovark to be about you, the knowledge worker, and not about us, Gordon and Dean, two guys making software.

We also chose an animal mascot for a reason. The Infovark name was partly an accident, but it stuck because it was a useful metaphor for us. Infovark does a lot of work in the background for you. It watches files, catalogs email, indexes content, and other useful things automatically. We liked the image of an animal digging through your information, trying to find interesting items and making associations between files, contacts, and email. It made our software feel friendly and helpful, like an enthusiastic pet you’ve taught to do neat tricks.

For round two of our product design, we wanted to try giving the Infovark just a little more personality. But not too much personality. Ever since Microsoft introduced Clippy to the world — and to much popular scorn — software developers are mindful about overeager assistants. Does anyone remember these guys? It’s a fine line that we’re walking here… 

So after much consultation, this is our attempt at something a little cuter, with a touch more detail.

varkhead_cartoon

What do you think? We’ll use this new character on our redesigned blog theme, and possibly in the product itself. Leave a comment and let us know your thoughts!

Review: Keeping Found Things Found

kftf_cover I recently finished Keeping Found Things Found by William Jones. It’s subtitled “The Study and Practice of Personal Information Management” but I think it ought to read “The Study of a Practice…”

The book is intended as a broad survey of information management practices and principles that individuals use to manage information. This is not a how-to manual or a self-help guide. It’s written in the style of an introductory textbook, which is not surprising given that much of the content was developed as part of the Keeping Found Things Found Project, run by the Information School at the University of Washington.

The academic style of the writing might appeal to some, but I found it a slow read. The footnotes and citations often got in my way as I was trying to absorb the material. Each chapter begins with a lengthy introduction and ends with a point-by-point recapitulation of key messages. These are probably useful for a semester-long course, but it’s overkill for anyone wanting tips and tricks.

Your mileage may vary, of course. I’m not the target audience for a book like this. If you want a primer on the personal information management field, Keeping Found Things Found is a decent place to start.

Key messages

We live in a world awash with information. Some of it is useful to us, but much of it isn’t. The point of information management is to keep the useful information easily accessible while ignoring the unhelpful bits.

This is an extremely challenging task, because we use information in a variety of different ways depending on our current situation. It also requires us to make some guesses about the future. How likely is it that we will need to recall or retrieve the information again? Is it worth memorizing it? Writing it down? Saving a hyperlink or adding a bookmark to our browser? We can’t predict our future needs exactly, so we often wind up storing more information than we need.

And that leads us to develop strategies for organizing it, indexing it, and searching it. And because we’re all different, there are almost as many different methods for keeping found things found as there are people. Some of the strategies — like the post-it notes stuck to your monitor — are obvious. Others are subtle, like keeping a mental list of go-to people that are experts in a particular topic so that you can ask questions as needed.

How this relates to Infovark

Having recently worked at a firm making records management software, I was familiar with much of the material in the book. The main reason for reading it was that records management focuses on large-scale organizational methods used by government and corporations to store, track, manage and dispose of information. I wanted to find out whether there were specific strategies that work well for individuals or small teams. Were there methods or tools that might help us refine Infovark’s design?

Well, I didn’t spot any, though some of the sources cited in the book might be worth checking out.

One of the book’s themes that connected with me was that we are really operating in a different age. The amount of information available to people is orders of magnitude greater today than in the past. Many of us now have music collections on our iPods that would have put independent record shops a few decades ago to shame. We have vast amounts of movies, television, and other video available to us on DVDs and streamed across the Internet. And then there’s the mountains of text and reams of financial data. All this content means that we’ve outgrown many of the concepts that guided us and tools we used in the past.

Gordon and I saw this clearly in our old job. It seemed silly — ridiculous, even — to expect a large organization to get a handle on its information when most of its employees have difficulty dealing with their own email inboxes. And companies can’t afford to train all their staff in the ways of research librarians so that they can manage the stuff on the corporate intranet. We need new approaches.

And we’ll keep reading, and talking with people, and attending conferences, and scouring the Internet, until we find them.

The Perfect Process

Somewhere, there’s a dusty old librarian who thinks Google is a messy and irresponsible way to find things, and gets very annoyed when you  don’t put the index cards back in the right place in the catalog. I found this one under ‘P’ for Process…

I spent some time with a client the other day who was trying to determine the best way to manage how information flowed in their organization. They were having a difficult time, because they had laid out a series of discrete steps that needed to be followed by every person in the organization — first the document arrives, then the document is entered into a tracking system, then it is registered as a case in the case management system, and so on. There are thousands of these kind of processes being discussed in meetings all over the world while we drink our morning coffee. I must have sat in on hundreds of meetings like this. 

The problem within  this organization was equally commonplace. The staff weren’t following the process. The software was too weird/hard to use, and it forced them into working in a way that they weren’t used to working. So, because they wanted to get on with their work, they were going around it. Composing documents outside of the system, and saving them on their local machine or network share. Getting things done despite the fact that they were aware it was ‘the wrong way’.

Typically the way these meetings go is like this: Once it’s determined that people are doing it wrong, somebody insists that they need to start doing it right. And that it’s “Their Job” and they should “Do what they’re told” and then the meeting usually decays into “Change Management” and how best to force acceptance of a system that nobody really wants.

There are numerous problems at work here. The centralization of authority forces people to rebel. That happens all the time. There are probably other leadership issues, and poor planning, and issues of control. There’s a lack of willingness to admit defeat, or worse, good money thrown after bad. There are loads of other subtle personal and political issues that are also affecting the outcome. But you know what? The work is actually still being done. And it’s not like the workplace is ever going to be free of these problems — they’re part of human social behavior.

Process is not our only product

The whole time, while this conversation was playing out, I was thinking about Infovark, and how we are trying to solve this problem in such a completely different way.

Infovark encourages the user to do whatever works for them, and then publishes all the output (or lack of output) to their team. We don’t control “the process” at all. We simply measure the output and let folks figure out what works and what doesn’t. With an open and transparent system, the best methods ought to rise to the top. Why not let the best processes emerge as memes within an idea economy?

Is this irresponsible? Perhaps. Bad eggs could try to game the system. Clueless bosses could incentivize perverse behavior. And certainly, in some businesses, overall consistency might be more valuable than quality or efficiency.

But frankly, rigorous approaches to process control aren’t common in most businesses. It requires discipline and training to enforce strict guidelines. It costs time and money.

The Strict Process Control approach to productivity and efficiency might make sense from an academic or manufacturing perspective. But nothing pollutes a good process like a bunch of humans. Now, where do I put this index card again?

Ideas and Forms

Here’s a philosophical topic to start the week. Information Aesthetics, a blog about design and data visualization, posted two videos from Maya Design. The first discusses the term information, the second architecture. As a software developer, these are terms I use all the time, but I often have a hard time defining precisely what they mean.

It’s a bit of a challenge for our marketing and communications strategy. The core API for Infovark, our product, is fundamentally nothing more than an information architecture. We use this core to create solutions that help knowledge workers get stuff done. But if information and architecture are tricky to define, you can imagine the confusion involved in combining the two! But where was I?

The two videos do a great job describing the terms information and architecture from the classical point of view.

  • Information is the essential message being communicated. It is separate from the form the communication takes.
  • A design is a plan for making a thing. An architecture is a design for making plans.

These definitions are classical in the sense that they rely on Plato’s concept of an idea being separate from a particular physical representation. There are other approaches. For example, Marshall McLuhan believed that “the medium is the message” — that you can’t separate the meaning from the representation that conveys it.

Did I mention this was going to be a philosophical post? I did warn you…

Getting real

Even though the topic is a bit academic, there are real-world debates going on about representations and forms right now.

How many differrent representations of you can be found on the web? There’s your LinkedIn profile, your Facebook page, your  StackOverflow account…
Much of the buzz surrounding the open stack technologies is due to there being a way to finally associate a person with all the stuff about that person on the web. Wikipedians talk about having “canonical URIs” — a web page address that points to the master record for an article, rather than a particular translation of an article. And if you support or build software that uses the REST pattern, you’ll face this issue. What is the base address for this web page? How do I get to the HTML version, the XML version, the PDF version, or the MP3 audio version of the page?

There’s not a “right” answer to any of these questions, but we usually adopt certain conventions for dealing with them. Libraries had to figure out whether to keep Braille editions of books together with the print editions, for example. After all, they’re the same book — they contain the same message — but the format is different.

We’re working out those same conventions on the Internet right now with regard to privacy, data portability, text translations, podcasts vs. screencasts vs. print, etc.