Dec 22, 2008 / Observation: Lists in Web Applications
6 commentsI'm working on new lists in v.3.0 already and wondering how 37signals managed to create several web applications with no traditional lists. OK, there is one list that shows time records in Basecamp, but as far as I know there are no other such lists. All the other lists are very simple and well formatted. All 37signal's applications look simple, with fresh air and the first expression is very good.
Typical list in Basecamp:
The only traditional list I found in Basecamp:
Now I wonder why that happened. Maybe data volume in Basecamp is low? Maybe they are just super-smart folks (well, no doubt here)? Also I wonder whether it is possible to get rid of traditional lists in TargetProcess. Is it possible at all when people want to prioritize 300 user stories in the backlog (yes, we have such requests from customers!). Is it possible to get rid of usual lists when you receive dozens of support requests daily?
Labels: design, lists, usability, v3
posted by Michael Dubakov @ 6:09 AM
6 Comments:
300 user stories goes against the lean practice of short work queue. Do you really want to build your UI around such a use case? Wouldn't it be a better goal for your tool to encourage effective practices rather than bending the tool toward non-ideal situations?
Very good point! It may work for backlog, but still we have some places where we need to handle 1000+ records. For example, Requests list.
which "requests" do you mean? Customer requests? Perhaps i'd have to see an example screen. What's the workflow for processing these requests? It sounds like another work queue to be processed rather than managed.
Yes, I mean a list of requests posted by customers. It has issues and ideas. For example currently we have more than 600 open ideas in the list.
Gotcha. So what are the end-user's goals when looking at this list? Why would someone bring up that web page? Most traditional lists are like big shoe boxes where you keep all your receipts for the year and then dread having to organize them before tax day. But in software we can just keep delaying and never organize it.
I was intrigued by you observations about basecamp's lists. These are good questions to ask. The answer, I think, is to focus on the end user's activities, rather than the structure of the data. As software engineers these two things get confused, because, for us, the data is the task, but for the people we server this is never the case.
-Evan
Shoe boxes... Nice :)
In fact several weeks ago I reviewed all that ideas and selected most interesting/demanding for v.3.0. It took about 2 days.
I agree that we often focus on data. If we have entity (like user story) we expect to have a list of entities. But is it always the best solution? I bet not. We are going to re-think this in TP v.3
Post a Comment
<< Home