Selling equipment that is easy to learn improves earnings of equipment
manufacturers and vendors in the near-term. Buyers, who enjoy favorable market
conditions, will initially favor tools that are easy to learn, until the rash of
errors caused by the inability to keep up on the Information Highway, eventually
leads to reduced earnings and stock prices. At that point, people will look for
productivity, and will invest an extra hour or so to learn how to convert
information into knowledge in order to improve earnings.
So far, the connection between income and the productivity of knowledge tools
has not gained wide currency, because the transition from IT to KM has not yet
begun in earnest. As we move forward toward a culture of knowledge, the force
of public attention that drives markets will turn from viewing computers as a
novelty, to an instrument of productivity.
Generally, productivity of knowledge work is directly dependent on the
ergonomics of the total work environment, including tools for rendering in
objective form the constant stream of impressions that flow through the mind
during a busy day. Knowledge, considered in that context, leads to the idea
that, overtime, it can be crafted, shaped and improved; whereas, information
exists in the moment based on what we see, hear and feel. Therefore, design and
manufacture of tools for knowledge work must eventually pay attention to the
speed and accuracy, i.e., efficiency, of converting information into knowledge.
The simple fact is that more efficient tools lead to more knowledge, which is
the foundation of civilization, as well as personal and organizational
From a manufacturing perspective, so long as customers view the keyboard as an
incidental component, manufacturers are free to short-change quality in order to
compete by reducing costs. Over the past 20 years attention has been diverted
by the growth of processing power, memory, viewing screens and GUI, ignoring
that civilization took a giant step by moving from pictures on the walls of
caves, to the connectionist theory of knowledge endemic to alphabet technology.
Until and unless a stronger technology emerges for accommodating human
architecture, the ergonomics of the keyboard will be critical to KM, because
human biology cannot be changed. Some hope for voice data entry to save the
day, so-to-speak, and there is progress in this area. While that will be
helpful, it cannot replace the role of the keyboard for empowering people to
increase their craftsmanship in constructing knowledge and ideas, just as a
sculptor, carpenter or piano player draws on the powerful interplay between the
hands and the mind to improve critical skills.
I guess this means I vote for Doug's idea on favoring productivity.
Paul Fernhout wrote:
> 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.
> 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
> > 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
> eGroups Sponsor
> [click here]
> Community email addresses:
> Post message: unrev-II@onelist.com
> Subscribe: unrev-IIemail@example.com
> Unsubscribe: unrev-IIfirstname.lastname@example.org
> List owner: unrev-IIemail@example.com
> Shortcut URL to this page:
-------------------------- eGroups Sponsor -------------------------~-~>
It's Easy. It's Fun. Best of All, it's Free!
Community email addresses:
Post message: unrev-II@onelist.com
List owner: unrev-IIfirstname.lastname@example.org
Shortcut URL to this page:
This archive was generated by hypermail 2b29 : Wed Dec 06 2000 - 20:09:35 PST