Date: Thu, 30 Nov 2000 08:55:50 -0500
| From: | Paul Fernhout |
|
pdfernhout@kurtz-fernhout.com Organization: Kurtz-Fernhout Software |
| To: | unrev-II@egroups.com |
| Subject: | Digest Number 294: Augment Clone? |
|
Productivity v. Ease of Use |
John \"sb\" Werneken wrote:
With that said, Augment seems to me to be a stunning achievement for the pre-PC era, but not necessarily a model for the future. As I misunderstand it, the Augment pattern is strongly centralized and document-centric. Customizability and "ease of use" don't seem to be strengths. How autonomous user groups could focus the tools on the issues of interest to them, and still exchange with others, does not seem to be a factor.
The "design from first principles" thread seems, in my misunderstanding of it, to be less committed to centralized management/control, less document-centric, more customizable, focused on seamless integration of information exchange for autonomous user groups, and cognizant of "ease of use" considerations.
I'd generally agree with your and Eric's sentiment here.
I don't want to take away one iota from Augment's breakthrough concepts for its time -- or even for now compared to what is commonly used. Still, one of the first design issues I encountered when reviewing the OHS/Augment spec (back in January) was the decision to use the word "document" for the core of how knowledge was stored -- as opposed to thinking of documents as something produced on a temporary basis, or perhaps exchanged, or perhaps input, with knowledge being stored in a "fine-grained" fashion (or "relational" in the Kent sense of relations between concepts).
Also, as you point out, issues of communities sharing knowledge, perhaps in a peer-to-peer way, are also beyond the original Augment. Here is one ongoing project that addresses some of the community aspect of knowledge sharing:
I'd tend to disagree some on the ease-of-use issue (and also some on customizability which some studies show people do once at the beginning and then leave as is).
I'm more with Doug here -- systems should be designed to be "efficient to use" rather than "easy to use", given that it is worth the small investment to become productive (Example the time it takes to touch type). Also, they should be "expansive to use" rather than "limiting to use". However, splitting the difference, I think they should be easy to learn if possible to do common tasks, and also may have to cater to different types of users (casual vs. expert) perhaps with multiple task specific or user specific interfaces which are easier to understand for their isolated useage. And after all, you can still use a keyboard even when you can't touch type. (Keyboards are actually a bad example because they weren't designed for speed or ease of use or efficiency (other than avoiding key jams) -- people just invented ways to behave when using them to try to make them so.)
It will be interesting to see how this issue is further wrestled with.
Sincerely,
-Paul Fernhout
Kurtz-Fernhout Software