[unrev-II] Productivity v. Ease of Learning

From: Rod Welch (rowelch@attglobal.net)
Date: Wed Dec 06 2000 - 20:07:42 PST

  • Next message: Henry van Eyken: "Re: [unrev-II] You'll see ..."

    Selling equipment that is easy to learn, discussed by Paul and John, below,
    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 demand productivity, and will further demand
    the right to 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. The DKR team can greatly aid this

    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 basic truth that more efficient tools produce more knowledge, and knowledge
    is the foundation of civilization, is deeply ingrained in the culture under the
    homilie: time is money, knowledge is power.

    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.
    > 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
    > [click here]
    > 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

    -------------------------- eGroups Sponsor -------------------------~-~>
    It's Easy. It's Fun. Best of All, it's Free!

    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:

    This archive was generated by hypermail 2b29 : Wed Dec 06 2000 - 20:17:46 PST