John \"sb\" Werneken wrote:
> Eric wrote:
>> My reactions to that are mixed. If this truly is
>> the OHS spec, then, in actuality, it is the Augment
>> spec. That is not necessarily a bad thing. But if
>> so, then I am somewhat chagrined at how much time
>> I (we) spent trying to work a process (any process)
>> to define a solution, when the result was
>> foreordained.
>
> 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.
John-
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:
http://www.canis.uiuc.edu/
> CANIS is a research laboratory at the University of
> Illinois with the mission of designing and implementing
> new models for the Future of the Net. CANIS is
> developing and deploying unique analysis
> environments for large-scale information retrieval
> applications based on discipline and community scale
> collections.
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.
-Paul Fernhout
Kurtz-Fernhout Software
=========================================================
Developers of custom software and educational simulations
Creators of the Garden with Insight(TM) garden simulator
http://www.kurtz-fernhout.com
-------------------------- eGroups Sponsor -------------------------~-~>
eGroups eLerts
It's Easy. It's Fun. Best of All, it's Free!
http://click.egroups.com/1/9698/0/_/444287/_/975595857/
---------------------------------------------------------------------_->
Community email addresses:
Post message: unrev-II@onelist.com
Subscribe: unrev-II-subscribe@onelist.com
Unsubscribe: unrev-II-unsubscribe@onelist.com
List owner: unrev-II-owner@onelist.com
Shortcut URL to this page:
http://www.onelist.com/community/unrev-II
This archive was generated by hypermail 2b29 : Thu Nov 30 2000 - 07:01:26 PST