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@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org