From: Paul Fernhout <firstname.lastname@example.org>
Jeff Miller wrote:
> I'd have to agree with you that training is most important. The question
> is how much do we bend the human to the computer and the computer to the
> human. see the example of the apple newton and the palm pilot(from session
> 2). The failure of the newton though may not be due in total to it's poor
> hand regonition but also to it's large bulky size - not very portable. The
> point I'm trying to make is that the user interface is not limited to
> what's on the screen, but how the user interacts with the device
I agree with your general points.
There is much we could learn about group dynamics from considering the
Newton as an object lesson for the OHS/DKR group.
I did some Newton development, and when Apple finally officially pulled
the plug, I recall a drug company within one day or so bought all the
remaining stock for their own use. The remaining MP2000 stock had been
predicted to last for a year.
By coincidence, just yesterday in a doctor's office I saw two drug
company sales representatives each with a Newton MP2000. The fact they
were using a Newton would probably not have been apparent to anyone who
did not know Newton history -- it just looked like they were making some
notes on something that looked like a day-timer. I asked one sales rep
how he liked the MP2000 and whether it was reliable, and he said it was
great. He seemed to have high confidence in its reliability and
usefulness. It was in a sleak black fold open zippered case that slipped
right into a larger box for drug demo stuff.
So, given this continuing use, and the high level of happiness the rep
expressed with this product, in what sense then the Newton a failure?
The Newton was and still is a very advanced technology. It still the
best embedded processor (200 Mhz StrongArm) and still has the most
integrated OS, a really cool prototype based OO language (NewtonScript),
a well thought out paradigm and developer library for pen interaction on
a small screen, and the longest batter life for something in its size
class. The Newton's notion of a "soup" for data storage and retrieval by
any application was brilliant. Its size undoubtedly did play a role in
limiting acceptance, but it still worked for many applications, and
reduced size prototypes were made. Many people carry paper day-timers
the size of a Newton.
The Newton "failed in the market place" primarily for reasons that had
little to do with the advanced technology. These non-technology "human"
and "group" issues were in part:
* bad marketing, including poor in-store sales demos relying on
handwriting recognition and not what the device could do,
[the main Pilot in-store demos don't even mention graffiti]
* an overly closed underlying OS/VM which attempted to force all
developers to do deelopment in the same language (NewtonScript),
[The hardware could not easily be programmed in anything but
NewtonScript, which had certain limits. This is the same error much Java
hype makes. Widespread VMs are good (especially when integrated with
native code tools -- look at the success of the IBM 360 VM). Forcing use
of specific language is not so good. The two don't have to go together
-- for example on an IBM 360 VM you can run assembler, COBOL, FORTRAN,
etc. I don't think of this problem as a technological one, because the
issue of "closed systems" is more a political decision by Apple and lack
of trust in developers than a lack of technology]
* complex internal politics at Apple,
* the failure to rapidly deal with user feedback about handwriting, like
adopting graffiti as an alternative,
* Apple's initial (and later) policies of secrecy that led to only
allowing a few large or well connected developers to make application
for it before its release (and allowing no one to make low level
alternative OS's afterwards),
[I desperately wanted to make a collaborative note taking application
for the Newton (Scientist's or Engineer's Notebook) before it was
released, but I and thousands of other developers got ignored by Apple
and told to wait till it was out -- yet a good architecture should have
let them ship us an emulator like the PalmPilot has, especially given
the Newton's VM. I later wanted to put Squeak Smalltalk on the platform
and ran into a lack of documentation of the needed internals and the
bootup process to either replace or coexist with the Newton OS -- a far
cry from the total transparency of something like the Commodore 64, or
even to a lesser extent the Palm Pilot.]
* Lack of realizing how important an issue reliable connectivity was,
[something that given the resources that went into the Newton would have
taken a tiny, tiny fraction of that]
* Many issues related to group dynamics and group think (probably
affected significantly by the blow of a suicide on the project).
There is an entire book "Defying Gravity" about the development of the
Newton. It shows what a weird world high technology development can be.
Anyway, I bring this all up to point out that these are the human and
group dynamic issues that any technology project (including the OHS/DKR)
will have to wrestle with.
An integrated open source OHS/DKR as described by the Technology
is a superior concept to much or all of what is out there for knowledge
management. Its widespread adoption would have many significant benefits
to lowering IT costs and increasing individuals confidence in
maintaining their own data for the long term. (I'm about to loose access
to a generation of Mac documents and Commodore documents and Mainframe
and Unix documents on disk and tape. Even if I got them to a PC or Linux
box, translation is awkward).
Look for example at the problems being faced just today as two companies
with incompatible proprietary IT systems merge:
OHS/DKR still faces the same hurdles the Newton did.
Some lessons for OHS/DKR from the Newton "failure", put positively, are:
* do good marketing and good demos,
[whatever that means today for OHS/DKR]
* build on an open architecture,
[not just Java, although XML has the potential to be something good,
although it too is not a magic bullet]
* have relatively straightforward or transparent development group
politics, [if such is possible]
* provide acceptance of and accommodation of feedback from many sources,
[Such feedback is usually handled best by remembering the adage "listen
to your users, but ignore what they say". This means address the problem
they point to, but maybe not as they suggest since they are not
* make sure that whatever is produced can interoperate with other
systems easily and reliably,
* be open and inclusive, "release early, release often", and commit to a
specific open source license and put good stuff under it,
* be very aware of group dynamics and try to foster a productive
atmosphere (without too much pressure).
I'm sure there are many more lessons from the Newton (or any other
failed or succesful advanced technology) that could be applied to making
the open source OHS/DKR effort a success. A classic in this field is
"The Mythical Man-Month" by Frederick P. Brooks, Jr.
Perhaps someone could provide a list of what the Palm Pilot creators did
right as a group?
Developers of custom software and educational simulations
Creators of the open source Garden with Insight(TM) garden simulator
--------------------------- ONElist Sponsor ----------------------------
Independent contractors: Find your next project gig through JobSwarm!
You can even make money by referring friends.
<a href=" http://clickme.onelist.com/ad/jobswarm2 ">Click Here</a>
Community email addresses:
Post message: unrev-II@onelist.com
List owner: unrev-IIemail@example.com
Shortcut URL to this page:
This archive was generated by hypermail 2.0.0 : Tue Aug 21 2001 - 18:56:35 PDT