Also in Cooper's book (see last post), is a discussion of some significant improvements that can be made in the way the operating system handles file names and versions. While he has some interesting ideas, I prefer to use the idea of tagging that has become so popular with Flickr, Digg, etc. Instead of storing files in a folder hierarchy, why not have a save dialog the allows users to include tags that could be used for future retrieval? It could also store some faceted attributes such as data created, date last edited, size, etc. Then, when the user wants to open the file it becomes really easy and fast to find. A search interface could allow the user to type in a few tags and the file would be recovered. The user would not have to remember where it is in any hierarchy. A browsing interface would also allow a file to be in many places at once - corresponding to all of the tags and faceted attributes.
Another improvement would be to allow renaming in a simple fashion. Now, the user needs to close the file, go to explorer, change the name, and then reopen it. Why not allow renaming in the same way Excel allows sheets within a file to be named - a simple select and type.
And the operating system could also save previous versions so that if the user wants to go find an old version, it would easy to do. Now, the user needs to recognize the need in advance and save them along the way. But given the huge storage available, the system could store versions according to the date they were made and have several available. If the user wants to revert to an old version, it could be easy to find. If the user modifies an older version, it could either be renamed to establish a new stack of versions, or a tree could be created.
Rich annotations could be used to assist users in finding older versions. Rather than just a number (filename.txt v1), it could be tagged with date (filename.txt 08/22/07) or even more richly (filename.txt 08/22/07 5 pages with three embedded pictures) or something like that.
The book brings up lots of limitations of standard productivity software and operating systems. I am not sure they present the best solutions, but they bring up lots of ideas. It gets the juices flowing.
Sunday, August 26, 2007
Better design of undo
I was reading the latest edition of Alan Cooper's book on Interaction Design. While I tend to disagree with many of the solutions proposed in the book, he and his coauthors do a fantastic job of highlighting some of the major limitations of current interaction design in operating systems, software apps, and web sites.
My thoughts today are his ideas on the limitations of undo. How many times has the undo function failed to do what you wanted it to do? One of the problems is the LIFO and stack design. In order to undo a past action, you have to undo everything that happened since. And if you do, you can't redo them if you make any changes. What if the system stored the past actions in an independent list that could be independently applied? Perhaps it maintained a clipboard-like buffer where the user could see text (in the case of Word) that had previously been deleted and access it however he/she wants?
Or perhaps the user actions can be stored along with the file. So when you save or close a file, they are not lost. The user could reopen the file and still undo. As Cooper wisely notes - the extra storage required to do this would not be a significant constraint given the large hard drives we all have now.
Another idea they propose is to have different categories of undo. Currently, one can undo text edits, but not document formats. Why not have separate lists so that users can choose to undo recent text changes, formatting changes, or other types of user actions?
I recommend the book. Just this chapter alone highlights many ideas for improving the design of common office productivity suites. I hope the folks at Microsoft read it too.
My thoughts today are his ideas on the limitations of undo. How many times has the undo function failed to do what you wanted it to do? One of the problems is the LIFO and stack design. In order to undo a past action, you have to undo everything that happened since. And if you do, you can't redo them if you make any changes. What if the system stored the past actions in an independent list that could be independently applied? Perhaps it maintained a clipboard-like buffer where the user could see text (in the case of Word) that had previously been deleted and access it however he/she wants?
Or perhaps the user actions can be stored along with the file. So when you save or close a file, they are not lost. The user could reopen the file and still undo. As Cooper wisely notes - the extra storage required to do this would not be a significant constraint given the large hard drives we all have now.
Another idea they propose is to have different categories of undo. Currently, one can undo text edits, but not document formats. Why not have separate lists so that users can choose to undo recent text changes, formatting changes, or other types of user actions?
I recommend the book. Just this chapter alone highlights many ideas for improving the design of common office productivity suites. I hope the folks at Microsoft read it too.
Subscribe to:
Posts (Atom)