weiner@novavax.UUCP (Bob Weiner) (06/08/89)
In article <43acb00f.1b147@apollo.COM> nazgul@apollo.COM (Kee Hinckley) writes: In article <1314@novavax.UUCP> weiner@novavax.UUCP (Bob Weiner) writes: >In article <43657eac.1b147@apollo.COM> nazgul@apollo.COM (Kee Hinckley) writes: > Apollo's policy has always been, right or wrong, not to ship things that > we don't have the resources to support. We are fully aware that there are > *lots* of utilities, tools, etc. that we should ship and support. But > we can't do them all, so the best we can do is make them available via > ADUS for those people who are willing to work with unsupported software. Did I say that I agreed with that policy? I spent three years trying to get my keydefs shipped as unsupported products. I gave up trying to ship my mkmodel script for DSEE, and sent it to this list instead (anyone interested in the SR10 version?). I'd fully like to see Apollo ship unsupported software as a separate piece of the releases. Thanks for the very clear headed and enlightening answer, Kee. I understand what you have been up against with Apollo in the past on these issues and I do believe that the merger with HP will help in a number of these areas. >4. Not providing a simple way of writing programs to access the high >performance features of Apollo systems. Something along the lines of >the NeXTStep programming environment is what I have in mind. We have >100's of Apollos down here used by software engineers (mostly >cross-compiling for other platforms) and I don't know one who is fluent >in Apollo's large set of system calls. Hence no one can write an >application that makes good use of the graphics, network communication, >or other powerful parts of Apollos systems. Open Dialogue is a step in that direction. We have a problem here. Apollo has concentrated on getting out base technology that provides you with the means to deal with a lot of hard problems. In the process we have *not* had time to provide the higher level tools which make it *easy* to deal with easy problems. This means that we have tools like DSEE and DDE which are capable of doing very complex things, but which you have to learn in depth before you can even do easy things. Most of this is very true, except all of the Open Dialogue applications I have seen including Apollo's own have user interfaces that even novice users tire of in less than a day. Much work has to be done in this area; I know the OSF is helping. This discussion points out to a large extent why Sun surpassed Apollo in market share a long time ago. They decided to pursue technology that would make people more productive in quickly and easily grasped ways. Apollo chose to produce better technology that virtually no management can understand and few engineering environments can fully benefit from. HP, at least in divisions besides computers, has a lot of experience in making complex technology eminently usable, especially in engineering circles. I hope this will also apply in the computer realm. Should we have done the sexy stuff first and then worried about the hard things? Maybe so. It's pretty hard to sell a system when it answers problems people don't know they have. Marketing should have told you this. >5. Not educating vendors as to the current state of Apollos system. >Most software vendors I speak to have not ported their software to >Domain/OS (SR10) and truly believe in their hearts that Apollo's OS is >Aegis and Aegis alone. That's an interesting one. How do you recommend that we do it? (I'm very serious here. I know we haven't suceeded, I don't know why.) This I think is an easy one. Mail to all your third party vendors and major users a one or two page, easy to read memo describing the state of your UNIX environments today (no marketing input allowed). Then do like everyone else and put an 'icks' sound in your OS name (Ultrix, Xenix, HP-UX. SUN gets away with SunOS since they get every one in the world to run on their platform and since UNIX is all they ever speak.) The sound helps people realize that your talking about a UNIX derivative. What does Domain/OS and SR10 conjure up? Confusion, basically. I definitely understand, and I agree. From my standpoint in the trenches I have two choices - put out as much functionality as possible to keep ahead of the competition, or put out very little functionality, but make it easy to use. I truly believe that sharp designers can do both for true functionality assumes usability as a prerequisite. You may be able to rocket me to Mars but if I burn up in the process, I definitely won't be impressed. Good luck. -- Bob Weiner, Motorola, Inc., USENET: ...!gatech!uflorida!novavax!weiner (407) 738-2087
conliffe@caen.engin.umich.edu (Darryl C. Conliffe) (06/10/89)
In article <1340@novavax.UUCP>, weiner@novavax.UUCP (Bob Weiner) writes: > In article <43acb00f.1b147@apollo.COM> nazgul@apollo.COM (Kee Hinckley) writes: > In article <1314@novavax.UUCP> weiner@novavax.UUCP (Bob Weiner) writes: > >In article <43657eac.1b147@apollo.COM> nazgul@apollo.COM (Kee Hinckley) writes: > > Apollo's policy has always been, right or wrong, not to ship things that > > we don't have the resources to support. We are fully aware that there are > > *lots* of utilities, tools, etc. that we should ship and support. But > > we can't do them all, so the best we can do is make them available via > > ADUS for those people who are willing to work with unsupported software. > [STUFF DELETED] > > >4. Not providing a simple way of writing programs to access the high > >performance features of Apollo systems. Something along the lines of > >the NeXTStep programming environment is what I have in mind. We have > >100's of Apollos down here used by software engineers (mostly > >cross-compiling for other platforms) and I don't know one who is fluent > >in Apollo's large set of system calls. Hence no one can write an > >application that makes good use of the graphics, network communication, > >or other powerful parts of Apollos systems. > > Open Dialogue is a step in that direction. We have a problem here. Apollo > has concentrated on getting out base technology that provides you with the > means to deal with a lot of hard problems. In the process we have *not* > had time to provide the higher level tools which make it *easy* to deal with > easy problems. This means that we have tools like DSEE and DDE which are > capable of doing very complex things, but which you have to learn in depth > before you can even do easy things. > > Most of this is very true, except all of the Open Dialogue applications > I have seen including Apollo's own have user interfaces that even novice > users tire of in less than a day. Much work has to be done in this > area; I know the OSF is helping. > > This discussion points out to a large extent why Sun surpassed Apollo in > market share a long time ago. They decided to pursue technology that > would make people more productive in quickly and easily grasped ways. > Apollo chose to produce better technology that virtually no management > can understand and few engineering environments can fully benefit from. > HP, at least in divisions besides computers, has a lot of experience in > making complex technology eminently usable, especially in engineering > circles. I hope this will also apply in the computer realm. > Bob, I cannot agree with you at all on this point. Apollo's networking is much simpler. Most systems people agree that it requires less attention to manage an Apollo network. Therefore, I believe the advantage has not been in "ease of use" features, but in the representation of broad choice of application programs. The edge to success for Sun and its workstations was the same as it was for IBM: they permitted application designers to add things to the basic unit. Sun took technology that was not cost effectively available at the time Apollo came out and began design on that platform. Apollo started earlier and choose to support upward compatibility. Any two hardware competitors who start at different times will experience the same type of disparity. Being second, after the market had been legitimized and hardware component prices have dropped, is definately an advantage. From my experience, Apollo's initial competition was with the sense that the workstation was equivalent to an IBM-PC, and the IBM-PC cost less. Then, most managers could not make the technological differentiation. Technological prowess was the thing being requested by those in the know, and was the justification of the purchase. The seamless interconnectivity of the token ring was also a key advantage. This, remember, was before UNIX was licensed, hence Aegis. It is true, however, that Apollo didn't see the uncovered check it found itself in by being effective in the workstation concept - Sun snuck in behind the IBM-PC attack. > Should we have done the sexy stuff first and then worried about the > hard things? Maybe so. It's pretty hard to sell a system when it > answers problems people don't know they have. > > Marketing should have told you this. > Again, given the history, they did the right thing at the time; they just didn't change strategy soon enough. > >5. Not educating vendors as to the current state of Apollos system. > >Most software vendors I speak to have not ported their software to > >Domain/OS (SR10) and truly believe in their hearts that Apollo's OS is > >Aegis and Aegis alone. > > That's an interesting one. How do you recommend that we do it? (I'm very > serious here. I know we haven't suceeded, I don't know why.) > > This I think is an easy one. Mail to all your third party vendors and > major users a one or two page, easy to read memo describing the state of > your UNIX environments today (no marketing input allowed). > AMEN > Then do like everyone else and put an 'icks' sound in your OS name > (Ultrix, Xenix, HP-UX. SUN gets away with SunOS since they get every > one in the world to run on their platform and since UNIX is all they > ever speak.) The sound helps people realize that your talking about a > UNIX derivative. What does Domain/OS and SR10 conjure up? Confusion, > basically. I do not think tricks like "icks" are the answer. Currently, those of the religion UNIX demand UNIX with the bugs. I'd rather buy for improved functionality. In either case, anyone with enough money to spend has enough time to spend to learn what Domain/OS is - IF APOLLO WOULD TELL THEM! Where are the writers? Where is the magazine? I realize Apollo found it hard to compete in a marketplace that was not demanding improved functionality, but mediocrity (be like every one else), but they could have helped their cause by a vigorous public education campaign on what it and other vendors have out there. > > I definitely understand, and I agree. From my standpoint in the trenches > I have two choices - put out as much functionality as possible to keep > ahead of the competition, or put out very little functionality, but make > it easy to use. > > I truly believe that sharp designers can do both for true functionality > assumes usability as a prerequisite. You may be able to rocket me to > Mars but if I burn up in the process, I definitely won't be impressed. > > Good luck. I don't find things hard to use on Apollo systems. Unless the application package is broken (has bugs, just like all vendors are subject to), the complaints I hear are that others find it hard to port code to Apollo platforms that was developed on other, frequently less robust, systems. There are ways to fix this, if Apollo wants to. > -- > Bob Weiner, Motorola, Inc., USENET: ...!gatech!uflorida!novavax!weiner > (407) 738-2087 Good, constructive comments, Bob. They started me thinking. I am sure we both hope they started others, too. -- ___________________ Darryl C. Conliffe conliffe@caen.engin.umich.edu (313) 721-6069 -------------------