YaST/Development/Printer Enhancement

From openSUSE

YaST2 Printer UI enhancement

This is page with some suggestions how to improve usability of yast2-printer module
Benchmarks of other printer modules and their workflows can be viewed here

The experimental YaST printer module

Not just nice looking design ideas but something which is really implemented so that one can test how its usability is "out there in the real world" ;-)

Basic Design Ideas:

"Exchange Dungeons with Trees!"

What does this mean?

The usual wizard style with a sequence of dialogs looks like a dungeon from the user's point of view - in particular if the issue is not ridiculous simple.

Like a hero in a dungeon equipped only with a faint torch, the user moves from dialog to dialog, only knowing the past where he comes from but never knowing what there will happen after the [Next] button, never having an overview of the environment, always in terrible fear what there might lurk when opening the [Next] door.

In contrast a tree widget keeps the user continuously informed where he comes from, where he currently is, and what the alternatives are.

Obscure widely ramified dialog sequences were condensed into visible tree structures (for example the "Connection Wizard") to keep the user continuously informed where he is and what the alternatives are.

But here "tree" does not only mean the explicite tree widget. With "tree" I mean anything which provides this kind of information to the user.

In particular when sequences of dialogs were condensed into one single dialog, there is no need to provide an additional information how the parts are connected/related to each other because all is visible at a glance so that a derivative design idea is:

"All-in-one Dialogs"

For example the "Overview": It shows all avaialble queues - both local and remote queues - at a glance and it shows also all possible config tasks so that there is nothing which is hidden somewhere.

Or the "Add" sequence (first select the connection, then the driver, then specify a queue name): This three mandatory steps happen now in one single dialog from the top down to the bottom.

If the desired connection is not shown in the "Add" dialog, a "Connection Wizard" is available but even this is no longer a widely ramified dialog sequence but just one single dialog which returns to the one single "Add" dialog when the connection is specified.

Another design idea how to get rid of the dungeon feeling where the hero with his faint torch cannot know what is happening behind the walls (i.e. what the tool actually does behind the surface) is:

"Animated Automatisms"

The driver is visible auto-selected. There is no longer a hidden automatism which results whatever driver it thinks is best. The new design makes it much more obvious to the user if there is more than one driver available and which one actually is auto-selected.

The driver is automatically visible auto-selected so that there is no single click more needed by the user. The crucial point is that there is visible feeback from the automatism to keep the user informed what is happening.

Basic Implementation Principles:

Transaction Semantics For Each "One Setup"

This means: Either the YaST module does one setup completely or not at all (i.e. "transaction semantics") and it writes each "one setup" as soon as possible to the system (i.e. "for each").

"One setup" means the smallest amount of setup actions which lead from one consistent state in the system to another consistent state.

"Consistent state" is meant from the user's point of view regarding the particular kind of setup (e.g. set up one print queue or set up one service) and not from a low-level (e.g. filesystem or kernel) point of view.

If the user does malicious stuff (e.g. killing YaST) or if the user ignores warning messages then it is possible and it is accepted that the user can force YaST to set up even an inconsistent state (e.g. activate one service but do not activate another required service).

The current scanner module implements already this semantics.

Reasoning:

The current usual YaST module behavior is that all settings while the module runs are kept internally and all of them are written to the system only when finishing the module.

An argument for the current behavior is that this way the user would be able to experiment with the settings and having them applied only at the end.

For me this seems to be a contradiction in itself.

I think it is not possible to "experiment with the settings" without actually set up something. I think "experiment with the settings" requires to test them and to test something it must be set up (i.e. the settings must be applied). Without a possibility to do a real test it does not make sense to "experiment with the settings".

One may think that for "test" it can be set up temporarily but "set up temporarily" does not make sense too because what exactly should it mean to "set up temporarily"?

Either it is actually set up for a real test in the real system or something else is done to fake a test to make it look as if a real test happens but in fact nothing is changed in the system.

If it is actually set up for a real test in the real system then the test can have two kind of results:

• It leads to a partially or full destroyed system.
• It leaves the system intact.

For the YaST module it doesn't matter whether or not the test was "successful" regarding what the user intended with his settings.

All what matters is whether or not the system still works correctly after the test because:

If the test destroyed the system, how should YaST go back to the state before the test? I think we would not like to make a complete system shapshot before starting any YaST config module.

If the system still works correctly after the test, the user can decide as he likes:

• Either to edit or delete what was set up
• or to keep what was set up.

If the user wants to keep what was set up, it does not make sense to delete it after the test and set it up again when finishing.

If the user does not want to keep what was set up, he can edit or delete it.

Furthermore it may happen that one setup conflicts with another setup but if each setup was deleted after the test both setups could be tested "successfully" but when setting up both at the end it would not work.

I think "changes get written only when finishing yast" is wrong because the "only" forbids any real test without gaining any other benefit.

Strict Compliance With CUPS

How to set up a queue in full compliance to CUPS:

• Autodetect printers and retrieve the correct matching DeviceURIs from the cupsd: Run "lpinfo -l -v" (or get the exact same information via appropriate CUPS library calls).
• Retrieve the available printer driver descriptions from the cupsd: Run "lpinfo -l -m" (or get the exact same information via appropriate CUPS library calls).
• Let the user select a printer/DeviceURI from the first list and a printer driver from the second list and let the user supply an arbitrary queue name.
• Set up the queue: Run "lpadmin -p queue_name -v DeviceURI -m printer_driver -E" (or do exactly the same via appropriate CUPS library calls). There is no re-start of the cupsd needed to add, modify, or delete print queues (only a config change of the cupsd requires it to be re-started).

The current YaST printer module (i.e. the "official" one, not my experimental module which is already in full compliance with CUPS) does not work in full compliance with the CUPS printing system.

• It uses additional stuff to autodetect printers (e.g. "hwinfo") which leads to problems when it is a device which the cupsd does not know or knows under a different DeviceURI (the setup may fail or the queue may not work).
• It does not retrieve the printer driver information from the cupsd but inspects the PPD files in the /usr/share/cups/model directory directly which was sufficient up to CUPS 1.1 but nowadays PPD files can be also generated on the fly via programs in the /usr/lib[64]/cups/driver directory (e.g. /usr/lib/cups/driver/gutenprint.5.0), see "man cups-driverd".
• It re-starts the cupsd much too often (each time when it finishes) which disrupts actively printing jobs on all queues (really bad on a server under high load).

Screenshots

Overview (local and remote queues and their matching buttons are separated)	Overview (local and remote queues in one list)	Overview (only local queues)	Overview (only remote queues, the modify and delete button line is disabled)
Add a new queue	Modify existing queue	Modify existing queue in 82x28 text mode (horrible)	Modify driver options
Driver options with combo boxes (squashed)	Printing via network	Sharing and publishing local print queues via the network

Overview

Overview with two lists:
Local and remote queues and their matching buttons are well separated shown to the user in two lists.

Overview with one list:
All available queues are shown in one list and all buttons are shown below this list. The user can filter out remote or local queues. In this case the buttons change accordingly (i.e. disabled modify and delete buttons for a remote queue).

Comparison:

Remote queues are shown in the overview in any case by default to make the user aware when there are already queues to print in the network (e.g. via the default CUPS Browsing) so that the user knows when he can just print in the network without the need to set up anything. This default cannot confuse a home-user without a network because when there are no remote queues none are shown so that the home-user has implicitely a "local-only" view.

Having local and remote queues and their matching buttons well separated has the advantage that it is obvious that there are two kind of queues which look the same but which are actually different regarding how they can be configured (remote queues not via [Modify]/[Delete] but via [Printing in the Network]).

Disadvantages:

• For a stand-alone system without network (e.g. a home-user system) the remote queues list is useless (always empty) and might even confuse the user.
• For a personal workstation in the network without a locally attached printer the local queues list is usually useless (usually empty - in particular when there is a CUPS server in the network).
• For a big print server in the network with many local queues the remote queues list is usually useless (usually empty) and wastes space to show more of the local queues.

Because of the disadvantages I think that it is better to have local and remote queues mixed up in one list and accept that then all buttons are also mixed up.

Add a new queue

Adding a queue happens now in three basic and mandatory steps in one single dialog:

• Select the printer device via its connection
• Find and assign a suitable driver
• Name queue

This and only this items are mandatory to set up a new queue. Anything else is optionally and must not appear in this dialog.

Local connections (USB, parallel port, ...) are shown per default.
Users who wish can get a list of more available connections.
Users who wish to make detailed/special/sophisticated settings can use the connection wizard or the driver wizard.

Modify existing queue

The modification dialog is similar to the add dialog regarding the basic settings (the queue name cannot be changed in CUPS):

• Modify the printer device and/or its connection
• Exchange the driver

Plus additional stuff like

• Change the option settings of the currently used driver
• Modify the description string
• Add or modify a location string

Plus special stuff like

• Enable/Disable the queue
• Banner settings
• Access settings

It seems there is currently too much in one dialog here because it looks horrible (and is practically unusable) in a usual small text mode window.
This causes the question what is better:
Split stuff which actually belongs together and spread it over several small dialogs in any case or do the work twice and implement two kind of dialogs: one big dialog for the GUI and several splitted small dialogs only for text mode?

Perhaps it helps to use tabs for

• Basic settings which are
  • Modify the printer device and/or its connection
  • Exchange the driver
• Driver settings (i.e. change the option settings of the currently used driver) like
  • Paper size
  • Resolution
  • other driver settings...
• Description and Location settings
• Enable/Disable
• Banners
• Access control

Another issue is that the YaST GUI system does not support scroll bars when there is more content than what fits into the current window of a dialog.

See how "nicely" the combo boxes get squashed if driver options are implemented with combo boxes. Therefore the driver options must be implemented with a widget which supports scroll bars. I think combo boxes are the native way to set the driver options but I cannot use them. I don't want to have driver options artificially split over several dialogs with awkward additional "forward/more" and "backward/less" buttons as a workaround for the missing functionality of a scroll bar in the dialog.

Note the subtle difference: YaST widgets do support scroll bars but the dialog window which contains all the widgets does not. The astounding reason is that this is no bug but intentionally to make sure that dialogs are not overcrowded with too many widgets. It seems to be "better" when the GUI destroys the content than having scroll bars to provide the full content. Personally I think it is in any case a major bug when the GUI destroys the content.

Even if a dialog is overcrowded with widgets and scroll bars result a dizzying feeling as if one uses a magnifying glass to view the dialog, the dialog would be still usable (not nice to use but usable) in contrast to now where the dialog becomes unusable.

By the way 1:
Perhaps the missing scroll bars for dialog windows is the underlying reason why the modify dialog in 82x28 text mode becomes also unusable destroyed?

By the way 2 - regarding "magnifying glass":
I don't know if the YaST GUI supports to increase and/or decrease the size of the elements in a dialog (i.e. something like web browsers support for the font size)?

Where to get packages for testing

See http://download.opensuse.org/repositories/home:/jsmeix/

Release Candidate 2

In contrast to the YaST printer module in 10.3 the redesign shows a tremendous simplification:

• depth of workflow was reduced from 9 levels to 3
• overall number of screens was reduced from over 30 to 10
• technical short wording was replaced by explanatory wording, which is easy to comprehend
• dialog layout which also confused expert users was replaced by simple, meaningful layout

The first feedbacks revealed a great sense of confusion about the amount and design of information presented in the overview. So there is a redesign then :-) The space acquired by help was used for an overview. Help as such will not be dropped it will move to a button within the navigation area. One thought was to hide "print via network", "sharing" and "CUPS autoconfig" under a "Settings" category, but this idea was dropped as the word "Settings" as such is quite meaningless.

The crucial points are:

• By starting the module per default with the "Show All" settings it is avoided that e.g. a desktop user in the network environment doesn't realize that there are already existing queues and starts to add a new queue.
• "Print Via Network" should be very prominent because that is the point users should go to, when they want/are only able to use printers in a network.

Note: The screenshots below have some minor errors (e.g. missing icon, correct navigation button order, correct help display). Additionally, we all know, when you make selection with radio buttons the are below the unselected radio button is usually disabled. I left it enabled on purpose because I want to improve the readability of the mock ups.

Workflow

Workflow of YaST printer module after redesign according to RC 2.

Overview

Printer overview with remote and local queues (Default View: "Show All")	Printer overview with remote Queues filteres	How do I print in the network?	Who is allowed to access my printer configurations and whom do I publish them?
Settings for automatic CUPS configuration

Add New Queue

Add new queue

Modify Printing Queue

Basic settings

Printer options

Status

Sharing

Connection Wizard

Connection wizard for SMB

Connection wizard for TCP

"Connection Wizard" dialog after user selects "Use a Network Printer Directly" in the "Print Via Network" dialog

Connection Wizard If a connection is not detected automatically the user can add it manually with this dialog.
The tree view on the left provides an overview of all available connection types. The corresponding settings for each connection type are displayed in the right window pane.

Add Driver

Add a driver

"Add driver" dialog with shipped packages already installed by user

"Add driver" dialog with "Download Driver or PPD" activated

Add Driver If a driver is not available within the list of the add/modify dialog the user can add an additional driver within this dialog.
He can do it either by browsing his computer (or accessible computers within a network) or by downloading a driver from openprinting.org.

More Driver Options

More driver options