Date: December 2, 1997 Time: 3:51 PM
From: Jerry Lawson
The Hartford Insurance Group
(860) 547-2960 jlawson AT thehartford DOT com
-----------------------------------------------------------------------------
The results are in - Thanks to all of you who responded - all 24 of you.
The results are in - Thanks to all of you who responded - all 24 of you.
When you think that there are over 1000 list members, and this is an issue
that should be of interest to the majority, I was disappointed. But then
again, maybe the questions could have been a little better designed..... or
perhaps the issues are not really a big deal.
Enough moralizing. Here are the results:
Question 1 - which level should the backup presentation start at?
A - All addressable files 4
B - Network or PC (including CD) 4
C - Individual Drive 14
D - All Local DASD 1
Note - D was not one of the options - but the person was voting for a way
that is consistent with how it worked in V2. A few comments were received;
all were along the line that it was dangerous to allow users to have the
ability to backup more than their own DASD - especially the Network.
Question 2
A. 7
B. 13
C. 4 (no opinion)
This question brought a lot of confusion; I think in retrospect, there was
not a lot of difference, and you had to understand the subtlety before you
could answer. That means I didn't write a very good question. If you have
installed the client, you may recognize "A" as the way it works with the new
system. Not everyone answered this question.
Question 3
The responses are below. There are some very good points in them, both for
and against. As one person puts it, it is almost a philosophical/religious
issue - similar to "my word processor is the best......" Not everyone
responded, so there are not 24 answers. If you don't want to read the
essays, you can hit delete now!
I will summarize my comments first; all others are included without names.
I believe that while consistency with an OS is important, consistency with
previous releases should not be lost. This aids in ease of use - why do we
always have to retrain our staff when a new version of a product is released.
Productivity is maintained if I can draw on previous knowledge about how to
use the product. Change for the sake of change is never a good idea.
Lastly; one of the important positives to us is that the interfaces a
customer sees with ADSM (in the past) has always been consistent with the
operating system it ran on. Don't loose this - in other words - don't make
the Mac client look like the Win32 client, or the Unix client, or the OS/2
client.
***** Other responses - each is separated by *****
I am accustomed to work with products that come with more or less changes in
their user interface for every new release. I think, that is not bad per se,
as long as it is easy for existing users to grasp the changes fast (one
example where this goal was clearly missed was the addition of a close box in
Windows 95, which was located in the place where the maximize box in Windows
3.1 used to be).
Products evolve, as they get new features, ... , and knowledge regarding what
works in an user interface and what does not advances. Why shouldn't these
changes be reflected in the user interface? As long as interface design is as
regular as possible (which also helps new users), I see no reasons why it
should cause problems.
*****
Match the OS
Ease of use has more to do with training than with an excellent user
interface. By keeping the application interface similar to other products on
an OS most people will be comfortable, and find the product easy to use.
*****
I think it should match the presentation of the products provided by the
operating system. There may be a slight learning curve, but, once the new
ideas are learned, they can be incorporated with everything in the OS.
*****
In this case, the new interface was long overdue. I wouldn't want frequent
major changes to the interface, but in this case, ADSM is just catching up
with the times. With the dominance of NT and Win95 in our organization,
maintaining "consistency with the presentation of the interface" would mean
that ADSM interface is "inconsistent with our applications," and
"inconsistent with our operating system" I let 4 different people who have
been using the old interface for 6 months or more try out the new interface.
As soon as they started clicking, they all agreed that the new interface is
much better and easier than the old. If we insist on "consistency with the
presentation of the interface", we'd still be running everything from the
command line, or keystroke commands. It may be tough getting the old-timers
used to the change, but new users should require a lot less instruction.
*****
I think it should be similar to the operating system, especially for the
users (the backup clients). Those of us switching between platforms can
probably just deal with the differences.
*****
As the MS-Windows is so much used, I think the new GUI is much better than
the older one. It is worth to forget about compatibility with older version
of ADSM and be consistent with the Explorer of Windows.
*****
Do you think that a new design should strive to match the presentation of
similar structures and products provided by the operating system, or do you
think he should maintain compatibility with previous releases. Where in this
decision should "ease of use" be measured against "consistency with the
presentation of the interface"?
Whew! I'm not a .EDU person looking for extra credit, but for today's PC
user this is almost the kind of religious/spiritual/philosophical type of
topic we were raised not to bring up at parties.
My feeling is that if the new presentation really IS easier to use and more
robust in its functionality, then compatibility runs a far distant second.
The increased ease-of-use should help reduce the learning curve and in a
not-too-long-run should compensate for any learning time lost. However, it
MUST be an improvement and not just prettier, flashier and more colorful. A
backup tool is just that as far as our workstation end users are concerned .
. . a tool. They just want it to work and work well, and they don't want to
be bothered learning any more than they absolutely have to in order to use
it. One of the biggest selling points for ADSM with my workstation clients
IS it's simple, straight-forward ease-of-use.
*******
For ease of propagating the client across the campus, a single ------
user interface would be preferable. At least our Help Desk would only have
to learn one interface. The greatest number of desktops here at McGill
University consist of Intel based products (read Microsoft OS) but we have
numerous other platforms, not unlike many other schools. One user interface
would be a boon.
*****
There's nothing I dislike more than trying to "be like the other kids on the
block". That limits innovation. "Ease of use" means that ADSM needs to have
features as in #2 above. "Consistency with the presentation of the
interface" means it looks and works the same for ALL its' clients, regardless
of platform. I have seen many a product with consistent presentation which
are a major pain in the butt to use.
*****
I think that software design should match the presentation provided the OS.
This is of benefit to users and trainers. But, I like to have the option to
use older methods of running the software. As much as possible, the
designers should make available these other functions in the interest of
consistency.
*****
I would say that the consistency is vary important, to change users (and in
some cases we a talking a lot of users) will have to be retrain. Each user
who sees the new presentation will call to see what it means or how to use
it, this will put a burden on the ADSM support personnel which in most cases
is very limited.
*****
One of the joys of ADSM is the multi-platform, common support and whilst the
best of modern interfaces should be exploited it is more important to retain
a common look and feel. There is (to me) no ambiguity in the visual display
of the current W32 V3 client gui. A half-yellow display clearly indicated
that not all is backed up below and it doesn't take too much effort to work
it out and I like the checks - they are very easy to interpret. It would be
more dangerous to have a full-yellow which may mislead folks into thinking
everything was taken care of.
On the whole I quite like the new GUI (although I am a unix-command-line
person primarily). I did install/play with the W32 (and AIX) backup/archive
GUI quite a lot. What annoyed me most was the poor use of space within the
GUI and the resizing options
*****
The answer to your question depends on who you are. A hotline person will
certainly prefer consistency both across releases and across platforms. A
user who needs to work with different systems will prefer consistency across
platforms. A user who is married to e.g. Win95/NT will prefer an Explorer
look/feel.
Another issue is consistency of user interface structure across presentation
mechanisms (command line vs. GUI).
Consistency with previous releases should never be at the cost of
functionality and clarity. On the other hand, change for change's sake is a
practice that I clearly disapprove of. An example is the unnecessary change
in terminology that was discussed in the List.
*****
For ADSM development, for systems admin and for the help desk, 1 consistent
interface would be best. As for an individual end user, an interface that
matches their system os would be best. As a compromise, a single interface
based on the most common os interface (NT/Win95) could be used.
*****
I think that a new design should strive to match the presentation of similar
structures and products provided by the operating system.
Consistency = familiarity = ease of use.
ie. make it resemble something the user is familiar with, and it WILL be
easier to use.
*****
I think that since most of the users probably have to deal with multiple
operating systems and their nuances anyways, ADSM should make the user
interface consistent with the particular client OS.
*****
New design should maintain compatibility with previous releases. I don't want
to have to keep relearning the same product.
*****
This is a case where you can achieve short term smart but create long term
stupid.
If you change the interface to be less ADSM V1-like, but more Windows-like,
it is true we will have to reeducate our current ADSM users now, which is a
burden. But if you keep the interface ADSM V1-like it means we will have to
provide special education for all FUTURE ADSM users FOREVER, which is a
bigger long-term burden. While the change is painful now, it is less of a
burden long-term to have the interface be more Windows-like than to try and
force compatibility with the old version.
(I would also like to add that when I say "ease of use" for Windows clients,
I want a format that is natural in the WINDOWS environment, not a ported OS/2
interface!)
*****
Most of my users do not like the current gui, so any change in any direction
will be good. Speaking for myself, I still use a 3270, so any gui is
impressive to me. Plus, I have worked with IBM software for 20+ years, so I
have a low level of expectation.
As far as the current v3 clients go, I think that the top 2 levels should
simply be done away with. Having answered 'c', what use are the levels then?
Just take them out and start the display with all the drives shown. It may
make it easier to put back the domain function. I can imagine that it was
left out because if it were implemented, the gui would start out with the
node box half yellow, the local drives box half yellow and the network drives
blank, and that would certainly cause confusion and questions. But by
starting out with an all-drives display, you will have some drives all yellow
and the others blank, and this will be understandable and explainable to end
users.
*****
End of Essays :-)
-----------------------------------------------------------------------------
Jerry
Jerry
Insanity is doing the same thing over and over..and expecting the results to
be different - Anon.
|
