soft-eng@MITRE.ARPA (Alok Nigam) (10/01/88)
Soft-Eng Digest Sat, 1 Oct 88 V: Issue 33
Today's Topics:
Anyone using Cadre teamwork IM?
Cynic's Guide to SE #6: Forthcoming Revolt
Interface Standards (was OPEN LOOK) (5 msgs)
KEE, Knowledge Craft
OPEN LOOK
Tool evaluation
----------------------------------------------------------------------
Date: 21 Sep 88 12:00:39 GMT
From: mcvax!ukc!stl!stc!datlog!dlhpedg!cl@uunet.uu.net (Charles Lambert)
Subject: Anyone using Cadre teamwork IM?
The Cadre package is also marketed in the UK under Hewlett-Packard's
badge, by the name Teamwork.
------------------------------
Date: 29 Sep 88 21:29:05 GMT
From: neff%helens.Stanford.EDU@labrea.stanford.edu (Randall B. Neff)
Subject: Cynic's Guide to SE #6: Forthcoming Revolt
------ The Cynic's Guide to Software Engineering ------
------ an invitation to dialogue, starting with the personal view of ------
------ Randall Neff @ sierra.stanford.edu ------
------ Sept 29, 1988 part 6 ------
------------------------------------------------------------------------------
The Coming Revolt in CS Education and the CS Workplace
The incredible rate of innovation and product development in the personal
computer market has resulted in greatly improved user interfaces for
most home computers. These interfaces are available on operating
systems (Apple Mac and Microsoft Windows), application software
(spreadsheets, databases, and desktop publishing), programming
environments (Lightspeed languages and the Turbo languages), and hypertext
tools (Apple Hypercard). These user interfaces and programs are better and
more productive than the interfaces available on most undergraduate computer
systems and most computer systems in the workplace. The provided workplace
computers may have more raw cpu power and memory, but still be much harder
to use.
Aphorisms:
If your hardware does not support a mouse, then it is obsolete.
If your software does not support a mouse, then it, too, is obsolete.
If your hardware does not support color graphics, windows, menus, then it
is obsolete.
If your software does not support color graphics, windows, menus, then it,
too, is obsolete.
Batch processing: making people wait in order to minimize computer cycles.
Scenario 1:
An undergraduate student comes to Stanford to learn Computer Science,
paying $4,100 for the quarter. At home he has a typical personal computer
(say a Mac with standard software). For his CS homework he gets to use
a cheap glass teletype terminal connected to a DEC-20 running TOPS-20
using EMACS and batch compilers. For upper level courses he gets the
same terminal connected to an overloaded VAX running UNIX using vi and
batch compilers. Now, how can this student take Computer Science
seriously when the provided hardware and software is so old-fashioned?
Scenario 2:
A new grad joins a large, multi-billion dollar corporation as a programmer.
He gets a cheap glass teletype connected to a large mainframe running
an old operating system (VMS or CMS) using an awful editor (EDT) and
batch compilers. However, he is forced to do a lot of his work at home
(documentation, overhead slides, budgets) using his personal computer since
the provided hardware/software cannot perform those tasks. How can this
new employee believe the claims that company is a "world leader in the
research, development, manufacture, and delivery of..." or has "a
worldwide reputation for blending technological foresight and advanced
resources to..." or "reputation is that of a technology and industry
leader".
The absurdity of have a more useable, more likeable, more productive
computer at home compared to the provided computers at school or at work will
lead to dissatisfaction and frustration. The first solution will be using
the personal computers to solve educational and work problems. However, there
will still be the embarrassment and loss of confidence in the CS department
and CS work management that they are providing archaic, obsolete hardware and
software.
The forthcoming revolt is this: my own computer at home is better than the
computer at school or work.
------------------------------
Date: 23 Sep 88 15:19:07 GMT
From: ficc!peter@uunet.uu.net (Peter da Silva)
Subject: Interface Standards (was OPEN LOOK)
The problem I have with Open Look is that AT&T has done the easy part:
figuring out what should be done. But they haven't finished the job:
figuring out how to do it. Until there's a standard programmer interface
for multiple window systems, Open Look should be given no more credence
than GEM, Intuition, MS-Windows/New Wave, Macintosh, X-Windows, NeWS,
Sun Windows, or any other interface you might name.
Until I can write a program that works on all these systems that lets me
say "put a text pane here, a scroll bar there, and a row of buttons here."
standardising what they *look* like is highly premature. Stick to how
they work.
That said, there are some aspects to things like scroll bars that should
be standardised. Like, there's a thing in the middle: if you click on it
and hold the mouse button down it moves. If you click above or below it
it moves towards the point you clicked at.
Now, it might move at a set speed as long as you hold the button down,
or it might jump a certain amount every time you click, or it might go
right to that point. The knob that moves might be a square, a bitmap, a
sizable rectangle, a circle, or a stylised doorknob. It might move to a
fixed number of positions or it might slide. It doesn't matter.
The important thing is to at least make sure you can sit down in front
of it and use it.
Similar standards can be defined for other aspects of the interface, without
specifying it "almost down to the bitmap".
------------------------------
Date: 25 Sep 88 10:32:58 GMT
From: steinmetz!barnett%mozart.steinmetz.ge.com@uunet.uu.net (Bruce Barnett)
Subject: Interface Standards (was OPEN LOOK)
>The problem I have with Open Look is that AT&T has done the easy part:
>figuring out what should be done. But they haven't finished the job:
>figuring out how to do it.
Of course not. Only a fool would release a product. and THEN
invite comments on whether it was the right user interface.
Instead, they have given the public a change to REVIEW the specifications.
If you don't like it, and have valid reasons, they would LOVE to hear
from you.
The X-windows and NeWS versions of OPEN LOOK is being developed
as we speak. They are still open to suggestions if you don't like OPEN LOOK.
The specs did say PRELIMINARY.
>Until I can write a program that works on all these systems that lets me
>say "put a text pane here, a scroll bar there, and a row of buttons here."
>standardising what they *look* like is highly premature.
Most professional software programmers I know are given some sort of
user requirements before they are allowed to spend person-years
developing a large package. It is not usually productive to waste
years of effort. I also don't know many programmers who deliver
EXACTLY what a customer wants the very first time.
I think you are missing out on a point about OPEN LOOK.
The intention is to have a stand look and feel for ANY WINDOW SYSTEM
and ANY TOOL KIT.
If you want to write some software for a PC, Amiga. MAC, etc.
you could try to duplicate the style yourself.
As I said, there will be at least TWO toolkits available. I believe
they may be announced late this year, early next year. You might love
one toolkit, and hate the other. Your criticism on the toolkits have
no bearing on the goal of what they are trying to accomplish.
>Now, it might move at a set speed as long as you hold the button down,
>or it might jump a certain amount every time you click, or it might go
>right to that point. The knob that moves might be a square, a bitmap, a
>sizable rectangle, a circle, or a stylised doorknob. It might move to a
>fixed number of positions or it might slide. It doesn't matter.
I believe the specifications for OPEN LOOK cover this.
>The important thing is to at least make sure you can sit down in front
>of it and use it.
If you can't visualize the interaction from the specifications, I
suggest you wait until a real product comes out. But don't expect to
change anything because you missed your opportunity. AT&T and SUN are
very interested in inputs. There are forms that come with the
specification that they want you to fill in and return.
I don't mean to be offensive, but I have noticed a lot of criticisms
to OPEN LOOK that are without any substance. I have seen a lot of
criticisms "on general priciples" and few complaints about specific
features.
------------------------------
Date: 25 Sep 88 00:38:31 GMT
From: voder!pyramid!prls!philabs!gcm!dc@bloom-beacon.mit.edu (Dave Caswell)
Subject: Interface Standards (was OPEN LOOK)
There isn't anything wrong with "arbitrary choices". How would you
like it if every videocasette you bought was a different size? Or if every
traiffic light used a different color for "go"? Certain things are better
standardized for consistancies sake regardless of the number of equal
alternatives available.
------------------------------
Date: 28 Sep 88 14:11:06 GMT
From: tness7!tness1!uhnix1!sugar!ficc!peter@bellcore.bellcore.com (Peter da Silva)
Subject: Interface Standards (was OPEN LOOK)
> Of course not. Only a fool would release a product. and THEN
> invite comments on whether it was the right user interface.
You mean like UNIX, MS-DOS, Mac OS, etc... AT&T, IBM, Apple. Fools all.
Seriously, though. I don't care what the overall visuals of the system are.
Open Look is pretty but unless I can write an Open Look application and have
it run under various windowing systems why should I bother? It doesn't
increase my market any... if I have a Y-windows application I'm going to have
to go through the same effort to port the program to Z-windows whether or
not I use the look and feel of Z-windows, Y-windows, or Open Look. Look and
feel is a sucker game.
If you want to get vendors to standardize on something, define a programmer
interface standard that hides the ugly internals of the window system (and
they're all ugly) from them.
That's the biggest advantage to UNIX. Not that people love the shell. Some
people hate it (whichever shell you want). It's because it's based around a
set of simple and clear concepts that work well on a variety of machines.
Even machines that don't run UNIX... see the Software Tools effort, for
example. Or look at MS-DOS (CP/M trying to be UNIX).
> Instead, they have given the public a change to REVIEW the specifications.
> If you don't like it, and have valid reasons, they would LOVE to hear
> from you.
I haven't seen the specs, and I don't really care. The specs don't cover the
important part of any user interface... how I use it.
> >Until I can write a program that works on all these systems that lets me
> >say "put a text pane here, a scroll bar there, and a row of buttons here."
> >standardising what they *look* like is highly premature.
> Most professional software programmers I know are given some sort of
> user requirements before they are allowed to spend person-years
> developing a large package. It is not usually productive to waste
> years of effort. I also don't know many programmers who deliver
> EXACTLY what a customer wants the very first time.
I don't see the point of this paragraph. It's a non-sequiter. Your customers
are programmers. Their requirements are a uniform programmer-interface to
whatever window system and user-interface you want to push.
> The intention is to have a stand look and feel for ANY WINDOW SYSTEM
> and ANY TOOL KIT.
I don't see the point. The hard part is the toolkit. If there are different
toolkits for different window environments, why bother?
> If you want to write some software for a PC, Amiga. MAC, etc.
> you could try to duplicate the style yourself.
Why?
> As I said, there will be at least TWO toolkits available. I believe
> they may be announced late this year, early next year. You might love
> one toolkit, and hate the other. Your criticism on the toolkits have
> no bearing on the goal of what they are trying to accomplish.
I don't understand the goal.
> >Now, it might move at a set speed as long as you hold the button down,
> >or it might jump a certain amount every time you click, or it might go
> >right to that point. The knob that moves might be a square, a bitmap, a
> >sizable rectangle, a circle, or a stylised doorknob. It might move to a
> >fixed number of positions or it might slide. It doesn't matter.
> I believe the specifications for OPEN LOOK cover this.
I suspect you didn't read what I wrote. Now, I may not have phrased myself
clearly, or you might have jumped to conclusions, but this is my point:
Specifying this to any greater detail, at this point, is the wrong thing to do.
I, as a user, don't care which of these choices is provided. I don't care
that much how a slider works. I just want a certain amount of similarity
between sliders. One that goes up with one button, and down with another,
is just too weird. If I use a particular system much, I'd also like to be
able to customise it. Make it jump, or scroll, or whatever. But that's
a lesser problem, like customising your erase key in UNIX.
I, as a programmer, don't care which of these choices is provided. I just want
to say "put a slider here, and tell me when the user moves it". I don't
care whether this involves the toolkit blitting images in on mouse events,
or just sending a message to a display postscript program that manages the
slider and tells me when it moves, or what. I just want to write code and
have it do pretty much the same thing in X-Windows, Intuition, NeWS, Windows,
MacOS, and so on. I can call "gets(buffer)" in BSD, Amiga-DOS, SunOS, MS-DOS,
and MPW and have it work. I don't have to handle erase key processing on my
own.
> I don't mean to be offensive, but I have noticed a lot of criticisms
> to OPEN LOOK that are without any substance. I have seen a lot of
> criticisms "on general priciples" and few complaints about specific
> features.
That's because Open Look is style without substance. It's like going down
to your chevy dealer and filling out an order form for your car. They
hand you a plane ticket to Detroit and a hard hat and expect you to build
the damn thing.
------------------------------
Date: 29 Sep 88 18:13:18 GMT
From: steinmetz!vdsvax!barnett%vdsvax.steinmetz.ge.com@itsgw.rpi.edu (Bruce G. Barnett)
Subject: Interface Standards (was OPEN LOOK)
>Seriously, though. I don't care what the overall visuals of the system are.
>Open Look is pretty but unless I can write an Open Look application and have
>it run under various windowing systems why should I bother?
...
>I haven't seen the specs, and I don't really care. The specs don't cover the
>important part of any user interface... how I use it.
>> >Until I can write a program that works on all these systems that lets me
>> >say "put a text pane here, a scroll bar there, and a row of buttons here."
>> >standardising what they *look* like is highly premature.
>
I wrote:
Most professional software programmers I know are given some sort of
user requirements before they are allowed to spend person-years
developing a large package.
>I don't see the point of this paragraph. It's a non-sequiter.
The point of the paragraph is that before you write a toolkit, you have to
know what it will do.
>Your customers are programmers.
The style guide is trying to get responses from:
a) Users of the window system
b) developers of the toolkits
The style guide is NOT for programmers of *one* of the toolkits.
I wrote:
The intention is to have a stand[ard] look and feel for ANY WINDOW SYSTEM
and ANY TOOL KIT.
>I don't see the point. The hard part is the toolkit. If there are different
>toolkits for different window environments, why bother?
I wrote :
If you want to write some software for a PC, Amiga. MAC, etc.
you could try to duplicate the style yourself.
>Why?
Wouldn't it be nice if you, as a company selling software, could have the
same user interface on every machine? On every operating system?
Wouldn't it be nice as a user to be able to use your PC at home,
and have the same interface at work? The interface on your MiniCray IV
is the same as the interface on your Amiga 5000 at home?
You can get inside a car and drive away because there is a standard.
Why can't this goal be achived with computers?
>I don't understand the goal.
We are not talking on the same wavelength. I hope my examples
make this clearer. Please don't argue with ME if you think this is right.
I, for one, would like to customize the HECK out of my personal interface.
But I do understand what AT&T is trying to do.
>Specifying this to any greater detail, at this point, is the wrong thing
>to do.
>[...]Open Look is style without substance.
It seems obvious to me that the development of the toolkits are in parallel
with the Look and Feel specified by the Sytle Guide. AT&T could have
said:
Here is the toolkit.
and let people scream that the user interface is UUUUUGLY, wrong, sick, etc.
Then they could take the toolkit back and:
change the Look and Feel
possibly change the programmers interface, making all of the old
code incompatible at the source level.
Don't forget that the months of fine tuning the toolkits and doing a
quality assurance would be wasted, and the New and Improved Look and
Feel would therefore come out 6-12 months after the first release.
This is not something I would like to do, if I were developing a toolkit.
The second thing they could do is:
here are the User Level specs for our new toolkits.
We have implemented at least one toolkit in one language.
We are doing the final polishing AS WE SPEAK.
The toolkit will be available soon.
Any last minute changes? Do you see something that is brain-damaged?
We can make some changes now, if there are valid.
I am not privy to AT&T's strategy. But I would guess that the second
choice is the RIGHT thing to do. It certainly is the most efficient
with respect to resources.
------------------------------
Date: Mon, 26 Sep 88 16:32:38 BST
From: Carl Musson <cldlm%psychology.nottingham.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: KEE, Knowledge Craft
Both of these are programming environments for Artificial Intelligence,
specifically Expert Systems.
KEE (Knowledge Engineering Environment) is marketed by Intellicorp (I think).
I can't remember who produces Knowledge Craft. But to find out more I suggest
you write or email:
Ian Filby, Nang Chan & Paul Wai Hing Chung
AI Applications Institute, Edinburgh University
Phone: 031-225 4464 Ext 230
Ian Filby imf@aiai.edinburgh.ac.uk
They are compiling a bibliography of AI tools and suppliers that
is to be updated every three months or so. They hope to expand to include
Object-Oriented Programming environments and the like.
------------------------------
Date: 26 Sep 88 20:02:39 GMT
From: vsi!sullivan@uunet.uu.net (Michael T Sullivan)
Subject: OPEN LOOK
I keep hearing about the Open Look spec. Just how does one lay his or
her hands on this spec. Sounds like interesting reading.
------------------------------
Date: 28 Sep 88 19:03:20 GMT
From: mcvax!ukc!stc!root44!hrc63!cd@uunet.uu.net (Colin Denman "GECCL")
Subject: Tool evaluation
We are currently evaluating Teamwork and IDE (Software
through Pictures), primarily for use with Real Time SASD
(Yourdon).
Useful comments and observations would be appreciated over the
next few weeks (I can make my own subjective evaluations {:->).
------------------------------
End of Soft-Eng Digest
******************************