Hmmmm I have been following this thread with a bit of interest and at
the risk of igniting someones flame switch, thought I might contribute a
few thoughts of my own... ;-) From my take on things, I gather that
there is an effort to reorganize the tools within Yast and the GUI
(Graphical User Interface) that is being used to present them to us
users. I am a long time programmer myself and have done a few GUI's so
been there and done it and I KNOW that philosophies on GUI design
borders on religion... I have not studied the internal code of Yast, so
am guessing, but I would surmise that it has a fairly lightweight MVC
architecture? (Model - View - Control for you non software engineers out
there...) Or does it predate structure architectures?
One of the first things that struck me about both the referenced
document and this follow up discussions is that the focus/purpose of
doing a new GUI and reorganizing Yast hasn't really jelled yet and that
probably needs to be tackled first. Is the development team proposing
that they just want a new look and feel? More features? Are they after
the holy grail of GUI's, one that will suit everyone (good luck!) If so,
it is a good goal but perhaps priorities/requirements first need to be
set and then the team can focus on the highest ones first. And while
free for all discussions such as this will help solidify those
requirements, it will be hard to keep everyone focused on the goal of a
redesign effort.. So IMHO it would be helpful to everyone if we were all
on the same page as to the purpose of redesigning the Yast UI (User
Interface) and/or its internal structure. To expand on this, for
example, is the purpose of providing a new Yast/GUI to help expand the
SuSE/Linux user base and make it easier for the mass hordes of
non-computer types to use SuSE? Or is the purpose to create a new
Yast/GUI that makes it easier for power users to build advance systems
and networks? Or for administrators to manage corporate workforce
computers? Or for intermediate users to set up SOHO (Small Office/Home
Office) or small business environments? Or for those who maintain
servers? Or for programmers and developers. Etc. etc... All of these
user bases will have quite a different set of needs and to provide a one
size fits all sort of solution will be incredibly challenging and
probably lead to a lot of in-fighting between these different user bases.
From my reading of the documentation and discussions another question
arises in my mind - Is this new Yast/GUI design to be a single point
solution or will it be something more elaborate like a pluggable
framework that allows for future expansion via the contributions from
the open source community? Something in-between? My initial impressions
lead me to believe the former, though I personally am hoping for the
later! ;-)
The main purpose of a GUI (which I will address from this point forward,
though changes in the GUI (View) of an application can imply similar
changes in the underlying architecture (Model and Control layers) as
well) is to provide an environment that will successfully guide its
users to an adequate solution to the problems they are trying to solve.
If IMHO I were to judge the current flavors of Yast I would have to
agree that for the most part it is poorly meeting this obligation for
many of its users, and doing exceedingly well for others.. Yast, like
much of the rest of Linux, is a collection of tools that have been
design to meet various needs and then, at least in Yast, loosely
organized into a set of related categories. Sort of like a tool box full
of both specialized and general purpose tools. I get the impression that
the idea behind what to put in Yast, was to throw in a bunch of tools
and hope they would cover the needs of most users.
But to effectively use such a tool box, it requires the user to be savoy
enough to understand which tools are useful and applicable to his/her
needs, how they work together, and which are clutter. Often, with such
tool boxes we will hear people say things like "If you don't understand
a particular tool that is being presented to you, then you have no
business tampering with it" Or "This tool box should only be used by
experts" That argument is OK IF the goal of a Yast/GUI redesign is to
make it into an experts only tool set but I don't get the impression
that it is.. So to present a tool set to a wide range of users, from
novices to power users, with a mixture of qualification requirements
(which are not well presented) will result in something that is very
intimidating to those who do not fully understand what they are being
presented with, and may or may not need, in order to help them solve
their particular problems.
I read a bit of an argument along these lines, about using an NIS
(Network Information Service) client/server, much to my dismay. To
counter such an argument, lets take for example a beginning user, who is
trying to use Yast to set up a network in his house, and failing. This
user does not have the knowledge base to make the distinction as to
whether something he/she sees, that appears to be network related, is
important or not in helping him/her to get a working network. And it
will overwhelm him/her to have to make the effort to learn what all
these network related tools are used for, so as to be able to sort out
what is useful. These users, when they encounter a technical geek term,
simply put, they do not know whether they should or should not learn
about it and may very well guess wrong and spend needless frustrating
hours trying to understand or else give up an walk away. Neither of
these responses would be hoped for! The problem is not in having the
luck to get something working, because a user happened to guess
correctly which tool to use, or how to set a particular configuration
parameter, because he/she just happens to have enough technical geek
speak savoy to make a good guess, but in the failures that occur and how
to guide those frustrated users to the correct tools to use and in turn
teach them how to use them or have the particular job done for them in a
way that makes using a tool such as Yast a joy rather than a painful
experience. A power user would have this knowledge base so to him it is
obvious whether setting up an NIS client for an NIS server is useful or
not. Therefore he/she is not going to be confused by having it presented
to him/her. And a great developer does not want to abandon either user!
IMHO not enough thought has been given towards how to *present* these
tools in a coordinated and integrated fashion that will provide us users
(with varying degrees of technical prowess) with good solutions, and
fulfill the requirement of being a helpful guide. A well thought out
presentation will have easily understood models behind it that provide
support for simple concepts that we can all easily understand and agree
on. Yast, in many ways, IMHO, is a little better than the /bin directory
of most Linux systems, but not much. As I said, it is still a collection
of loosely integrated tools that someone thought belong together there,
and made a bit of an effort to organize at a level that they were
comfortable with, but not with the intention of really addressing the
needs of a much wider audience.. So I will take exception to those who
have argued on this thread that Yast as it stands is a well designed GUI
and does not need further work. It most certainly does and I for one
welcome this effort to try and improve it.
Since examples are almost as good as pictures lets take a couple and I
think it will help many of you to understand what a well design GUI for
Yast might be capable of.. (As an aside, I recognize that the study
group did use a methodology to organize their thoughts on a GUI design.
However, in my experience with doing GUI designs, I prefer using, in our
vernacular, use cases, as that design process actually allows you to
test out different design strategies to see if they will meet various
user requirements. It also promotes a lot of brainstorming as you
creatively think up different types of use cases to work on. There are
other methodologies, and your mileage will vary.. At least this team
chose one to start with and that is far better than taking an ad-hoc
approach!)
So here is a use case example - Lets suppose we have a user who wants to
set up his/her computer to run a sound system or a home theater or
simply as a music server. How is Yast going to help guide this user to a
solution that will meet his/her needs. Has Yast even profiled the user
to determine what the goal is? What his/her level of expertise is? How
will the user be able to determine what software
applications/packages/modules are available and useful to meet this
goal? What services are appropriate and how will the user be guided in
setting them up? What system services, such as firewall settings are
needed or really necessary? If your goal is to guide a novice user, then
this GUI and Yast's underlying architecture is going to be far more
challenging to design than if you are going to guide a professional.
(With the current software manager in Yast, my mind boggles at how a
novice user will ever be able to manage things like dependencies....) To
carry this example a little bit further, IMHO Sax2 and X11 configuration
is weakly integrated into Yast at the moment. There is a lot more
capabilities hidden behind these tools (to include even the display
drivers), so how will (or will it?) the new Yast GUI present this wide
range of options, from a limited set for novices to a more complete set
for power users? How will Yast allow this user to grow and gain the
experiences needed to advance into ever more sophisticated systems
safely? Getting back to my earlier question, will the new GUI have a
scalable view? Perhaps a pluggable framework? Or will the new GUI be a
simple one size fits all sort of thing and have ALL options thrown at
the poor user and leave it up to him/her to try an comprehend?...
Another example might be - we have an administrator who needs to
maintain a bunch of Linux computers for users who must work
interactively together. Some requirements might be they need a data base
server, backup capabilities, common web interfaces to an application,
and general office tools such as spreadsheets, document generation etc.
This is probably a fairly typical small office scenario so again ask
yourselves how will the Yast GUI guide such an administrator (user) to a
solution that will meet his/her needs? For example, will this
administrator have to have detailed/pre-existing technical knowledge
such that if the answer he chooses for office software might be Open
Office, that it also requires technical knowledge about the management
and maintainance of a Java interpreter? Will the new GUI present the
administrator with this requirement in a way that a typical
administrator can understand? Will it present the trade offs between
using Open Office Writer or using KWord? What will happen when Sun
releases their next fancy version of Java? Will Yast help solve the
dependency issues surrounding such an upgrade in a way that is easy to
model and makes it easy for this administrator to understand the
consequences of applying or not applying such an upgrade? And how will
he/she manage the upgrade process and distribute this new environment to
all his/her users? Sometimes software dependencies get very obscure and
make it difficult to understand what is needed and how best to solve
various issues that arise during an upgrade effort... How will the new
Yast GUI help? What framework will it provide developers so that they
can present a better model of software dependencies, so that such issues
can be more easily resolved by an administrator?
And No, one does not have to develop a use case scenario for every
possible application, but if a lot of use case studies are done, what
will emerge is a model on how to organize the gui, an integrated view
that shows the relationship between various tools, a design path that
will guide the development of the tools, and an framework for
integration of the current and future tools with an organized focus
directed toward different user bases. And before anyone jumps to this
conclusion, I am not advocating the usage of wizards or specific point
solutions to guide the users to specific answers.... I am quite sure
this team will be able to come up with far better solutions than
Microsoft's wizards! ;-)
Next a word of caution - While getting input on the design of a new GUI
for Yast, from groups such as this, is fine and wonderful, the danger
lies in that fact that most of the clientèle of a news groups such as
this are going to be fairly advanced Linux users. IF you are trying to
make Yast easier for novices, then you must seek out engineers who have
had a LOT of experience developing such GUIs. Novices can rarely tell
you in engineering terms, or even in lay terms for that matter, what
they really want. Intermediate users and users with a limited experience
base will tend to focus on narrow issues that are currently bothering
them. Only engineers with a great deal of experience developing
applications for novices can really defend and champion their needs. It
takes engineers who have been through that grist mill a few times to
develop really good user interfaces, they are just about the hardest
ones to do a good design for! Trust me on this one, been there, done
it, and you will be really surprised at how novices (and even
intermediate and advance users) can so easily mis-interpret something
that we seasoned developers think should be intuitively obvious!
Here is a challenge and another use case, if you think otherwise - try
and teach a novice user how to configure his/her laptop to work in
several different wireless environments, with SuSEFirewall, so that
he/she can easily move his/her laptop from a safe secure home
environments into a hostile public coffee house with a public access
hotspot, and then integrate it into his office network seamlessly later
on! On this one, I would have to argue Microsoft Windows is way ahead of
Linux (but not truly there yet either, even though Linux is probably far
more secure and robust)... Although it is not so easily done right now,
(or if so then easily discoverable because I haven't found a way to have
my Linux laptop join different networks with different WEP keys, domain
controllers, SSIDs etc. while using different firewall settings for
each... easily that is - I had to write a bunch of scripts.... (sorry
about those geek acronyms but they are not all that important to
understand)) how will the GUI framework be designed so that, in the near
future when such tools become available, it will easily be integrated
into Yast, with common paradigms of usage, that allow the user to easily
discover the process and accomplish such a task, like finding and safely
joining a nearby wireless network. How could such a tool be integrated
into and with the rest of the Yast tools and its GUI? Will Yast provide
an API (Application Program Interface for you non software types) that
reflects its stated goals?
To try an make my point a bit clearer, the GUIs and usage of each of the
individual tools, their documentation, their models, etc., that is the
responsibility of that particular tools developers and yes a lot of
these tools need a lot of help also... But the INTEGRATION of these
tools into a single coherent framework, with common paradigms of usage,
guides, and levels of presentation tailored to the various user
audiences who have an interest in managing their SuSE systems, THAT is
the responsibility of the designers of YaST and its GUI. And from the
wide range of discussions so far it sure appears that there are a lot of
discontented users of Yast and its GUI as it currently exists... That is
a strong indication of a need for improvement!
And lastly, for those of you who might take exception to some of the
things I am trying to say.. Please don't try and defocus or deflect from
what I am trying to say by finding nits with what I said.. Good GUI
design is very hard and needs a lot of careful thinking. It is hard to
convey just how difficult in a few short paragraphs. Identifying who is
going to be using the GUI is the first step towards a good solution.
Defining the requirements is a long arduous process, and will take time.
Yast and its tool set is NOT simple and a LOT of complexity is buried
within it. Organizing and presenting models that are easy to understand
by all the various user bases of Yast will NOT be trivial and I wish
those of you who are undertaking this task lots of luck! ;-)
Before I close, I will throw in my own personal request.. ;-) One of my
biggest gripes about GUI's and applications in general is that many, if
not most, do not provide an easily reachable feedback mechanism. Without
good feedback developers cannot learn what worked and what is failing
that needs improvement with their users. Things like Bugzilla will only
reach intermediate to advance users. Forums such as this are also
difficult for many users to find and reach on their own. Put a mechanism
in where it it pretty easy to find, (Help menu is a good place IMHO)
make it easy and non -intimidating. Help guide the user to providing
feedback, that is just another job of a well designed GUI... Providing
feedback is different than a request for help though often the two will
overlap... (And speaking of help, never EVER tell a user to get help
from his/her administrator! In many cases that poor user IS his/her own
administrator.. If that is the only solution your new GUI provides, on
getting help, then it has failed its primary purpose! Give realistic
suggestions on where one can go to find a guru.. like to this newsgroup,
how to join etc. As for feedback, which does not expect a response,
perhaps a form could be provided for the user to fill out and
automatically sent somewhere?.... ) Having such built in features will
at least show your users that you care about their experiences and want
them to help you improve it for them...
>
> Marc Chamberlin...
--
To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse+help(a)opensuse.org
