YaST/Development/UI Future

From openSUSE

Debating the future of YaST's interface... Add your thoughts of what you feel is wrong about it along with possible solutions, or simply what could be improved. Try to think globally across modules, but feel free to talk about specific ones. Do mockups if you can. Comment on other people's thoughts. Whatever. Let's make YaST rock. ;-) Of course, we depend on people to actually implement it; but this is a good step in that direction.

You may want to get registered on the development mailing list.

Help

Currently, help is presented in a persistent box on the side of the interface. Such help is being used for (quotes from the users tool):

• busy messages -- “Initializing User Management\Please wait... ”
• interface usage -- “To shift to the group dialog, select Groups. To create a new user, click Add.”
• system information -- “Each user is known to the system by a unique number, the user ID.”

The help box approach forces help to be short, not allocating space for some information on how the system works and problems resolution, so you get broad “information” like “press button X to do task X”. Its quite ironic that Suse is known for the good printed documentation it is shipped with, while the adminitration tools have poor online help (maybe the goal here is to get people to buy the package? ;)).

So what we want here is probably to adopt the docbook help format. We can use the desktops' help viewers, which the user is already familarly with, and is a rich format that support sections, search, links, images, etc.

Now, we can still keep interface elements descriptions, while for the most cases that's either bad documentation or a bad interface, there may be good uses for it. Tool tips allow the user to get prompt help on that specific entry, while What's This help can give extended help. Qt and Gtk+ support both these types of contextual help. Of course, YaST interfaces are usually very light, because they need to fit on the text console interface, so just having the manual opening on the current interface section should be enough for the user to get help fast.

Mockup:

Main Window morphing

In most YaST modules, the work flow goes always in the same window. So, you open the networks module, select a network card, press the Edit button, and now you proceed to setup it until the next step, until you're back to the original window. So, there are two different work flows involved: the main one where you get a overview of the system setup and then a wizard flow for the specifics. (Btw, the Delete button label doesn't makes any sense on hardware modules, should have been spelled as Disable, especially because they aren't even removed from the list.) Besides the awkwardness of the interface, it is annoying that you have to close the printers module so that the printer you just added is really added. Instead what we probably want is to have an initial window with the hardware listing, and open a dialog to edit some settings; possibly, a dialog with a wizard look.

When possible, the user should be allowed to have more than one subwindow – for instance, let him compare definitions between two printers setups.

The text interface and the installer should of course behave the same.

Partitioner Widget

Partitioning a disk is not a trivial task, but it sure could have been made simpler than what YaST offers. Most users would feel more confortable dealing with a bar graph because it gives a much better sense of size to each partition and allows the user to work better on the setup, as if they were physical items. The table could still be useful since it could display more information on-screen, and, in fact, there is no reason why both elements cannot co-operate; when you select a partition in one, it gets selected in the other as well. (ncurses would only show the table, as of now.)

To reduce the complexity of the task, only one disk should be displayed at each time. The user can switch disks by choosing it from a list of radio buttons.

With the same goal in mind, extended partitions should be created automatically. As the partition gets full of primary partitions, the user should be asked if he wants an extended partition to fill the rest of the disk, rather than just popping an error message, and expect the user to create such a partition by himself (of course, that could still be an option).

Mockup:

While this may work nicely for simple cases (a simple PC with one or two hard disks), what should that look like with RAID and/or LVM and/or EVMS -- or even with a combination of these? This becomes an n-dimensional problem pretty quickly. We'd need a much more generic concept here. Those simple bars are much too simplistic.

Formatted Entries

In a few instances, the user must set an entry in a given format (e.g. ???.???.???.??? for an IP 4 address). Such entries could have already fixed characters in them, so the user would insert values more comfortably as he has visual guides, and would avoid the annoyances of when you make a mistake. Of course, modules like the software sources should be worked to not have so picky entries rather than relying on this.

Progress Bar text

Associated with a progress bar there is generally some text telling you what is going on. But it is either what is being done overall or at the moment. For example: “Probing hardware: |---|” vs “Sound Card detected\|---|”, “Printer detected\|--|”, and it keeps changing.

The overall information should always be there as a label on the side, while specific progress should be set as a label of the progress bar itself, replacing the percentage points, when possible. The reasoning is that the progress information may change rapidly, which is an annoyance. And the user should be told what is going on rather than deducting from the progress text. At the same time, it's sensible to show the progress text to give more information than some percentage and it may help in some troubleshooting if the progress gets stuck while doing some operation.

Hardware Listing

In hardware setup modules (say the printers), the hardware is displayed in a table with a bunch of information with no graphical distinction which makes the listing harder to see than it could. Furthermore, some more information is shown in a box at the bottom.

A clearer interface may be to show the hardware in a list, rather than a table, and use visual hints like markup text and line breaks to distinguish the information. Together with the Add, Edit, Delete buttons (btw, the Delete should be spelled Disable in some hardware modules), we could have a Details buttons to show the information currently at the bottom box.

Mockup:

Expander

Some dialogs, in order to show extra information, either use a radio button or an ordinary buttons labeled “Show details” or something that automagically replaces the dialog with another with some extra information. Since GTK+ and Qt (at least version 4) offer an expand widget, we should make use of it. It would make the consequence expected and thus remove the annoyance of dynamic content.

Installer Game

What about letting people play a puzzle/card game while packages are being installed on the installer? Not extremely useful, but extremely cool, no? ;) People might install Suse just to check the game out. :) Probably a puzzle game, with simple instructions; I would suggest a NetWalk game. eg: http://rooster.stanford.edu/~ben/netwalk/

Educating the user

It would be good if ther could be a notification listing all changed files as each Yast module complets. This wuold be a great benefit for users and admins new to a specific functionality. It would also be good to get a delta of what has been changed to further enhance the educational effect.

Package Selection Widget

The software management is a vital part for a user to extend and update his system. The GTK+ package manager offers a new split two pane package list view unlike the Qt version. It targets to simplify the overall process for unexperienced users, to provide sane defaults and hide away advanced functionality. However it is not perfect and it is hard for users to understand what -devel/-debuginfo or even certain packagenames mean when they really just look for a list of "web browsers" to install.

The mockup below adds icons for packages in order to add more visual appeal and moves action buttons to the top in order to gain space between both panes. Of course this is just a temporary change and further investigation should lead to an approach which offers the best usability for novice users while still providing advanced but initially hidden features.

Mockup: