new UI in yast2-printer
Hi people, I'd like to announce improved (I hope ;-)) UI in yast2-printer module. You probably know old interface. Many options was accessible via several clicks and for new users some of them wasn't easy to understand. I wrote some screenshots here: http://en.opensuse.org/YaST/Printer and now is mostly implemented in yast2-printer version >= 2.16.4 So this mail is a "call for testing", but also your comments or other kind of feedback is important for me. When you check rpm from factory does it work for you with all functionality? Do you like this UI or would you like to change something? Bye, Michal -- Best Regards, Michal Zugec Software developer --------------------------------------------------------------------- SuSE CR, s.r.o. e-mail: mzugec@suse.cz Lihovarska 1060/12 tel: +420 284 028 960 190 00 Praha 9 fax: +420 296 542 374 Czech Republic http://www.suse.cz/ -- To unsubscribe, e-mail: opensuse-ux+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-ux+help@opensuse.org
Hi Michal, Wow! The current mockups are a huge improvement in usability and simplicity compared to the existing module! Based on your ideas I generated another mockup, which is visible and open for discussion on http://en.opensuse.org/YaST/Printer as well. The main changes are: * Remote access settings were moved to the basic settings * Network interfaces summary was skipped because this information should either be shown in the network interface module or in the firewall module (as internal zone) As I am no expert in printing I would like to ask: Global Settings * Is it really necessary to test the remote IPP access? * Isn't the default queue selected as well when the user chooses to use the settings of the remote CUPS server? CUPS server settings * Which kind of "default" would be restored? * Is it really necessary to edit the CUPS config file via GUI? Cu, Martin -- Martin Schmidkunz User Experience Specialist martin.schmidkunz@novell.com +49 (0) 911 740 53-346 ------------------------------------- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) ------------------------------------- Novell, Inc. SUSE® Linux Enterprise 10 Your Linux is ready http://www.novell.com/linux -- To unsubscribe, e-mail: opensuse-ux+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-ux+help@opensuse.org
Hi! On Donnerstag, 8. November 2007, Martin Schmidkunz wrote:
As I am no expert in printing I would like to ask: Global Settings
* Is it really necessary to test the remote IPP access? * Isn't the default queue selected as well when the user chooses to use the settings of the remote CUPS server?
Which user that is new to Linux knows what CUPS is or why "server" has anything to do with printing. Since both options include "CUPS" anyway it is not really important and should hence either vanish or put at the end in brackets for those users who are interested. The term "server" is only confusing as well, as for most users a server and printing have nothing to do with each other. So I would suggest to simply put: Print via: ( ) Printer attached to this computer ( ) Printer attached to a remote computer Further the term "queue" might also be replaced by printer, even if that simplifies it a bit but for most people the printer is what queue means. For those that have more than one queue and only one printer it will still make sense since a queue is just the same printer with different settings. The "Save debugging information..." should state where it is saved, because new to Linux users don't know where the logs are or how to access them. One could for example give a hint to YaST > Other > Logs. Sven -- To unsubscribe, e-mail: opensuse-ux+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-ux+help@opensuse.org
Hello, On Nov 8 16:21 Sven Burmeister wrote (shortened):
Which user that is new to Linux knows what CUPS is or why "server" has anything to do with printing.
Yes!
Since both options include "CUPS" anyway it is not really important and should hence either vanish or put at the end in brackets for those users who are interested.
Exactly!
The term "server" is only confusing as well, as for most users a server and printing have nothing to do with each other.
Right! What we must somehow make clear to the user is that under certain circumstances (see my other mail) there is no need to run the cupsd on his local system but he should use a "client-only setup". The reason is that a "client-only setup" provides direct communication with the remote CUPS server which usually works better than when there is a local running cupsd in between (e.g. much easier to query and cancel print jobs on the server). Since CUPS 1.2 (i.e. since openSUSE 1.2) there is by default not much more security when there is no local running cupsd because since CUPS 1.2 the cupsd listens only on localhost via TCP (via UDP it still listens also on external interfces because otherwise "Browsing" cannot work).
So I would suggest to simply put:
Print via: ( ) Printer attached to this computer ( ) Printer attached to a remote computer
( ) Printer attached directly to the network But now I don't understand what I should choose when there is a network printer but I know that there is a print server in my network which is resposible for all network printers. Note that usually one cannot send data to a network printer in a company because the company admin has set up the network printer to accept only data from the company print server. Perhaps "Printer accessible via a remote computer" would be the right wording but now it may look strange for an unexperienced user. It seems we still need to find out which questions we must ask the user so that he understands what we like to know and so that we understand what there really is in his network.
Further the term "queue" might also be replaced by printer, even if that simplifies it a bit but for most people the printer is what queue means. For those that have more than one queue and only one printer it will still make sense since a queue is just the same printer with different settings.
I agree and I disagree. On the one hand all other printer setup tools mix up "queue" with "printer" so that users are used to have this confusion in their minds and for compatibliliy reasons we could simply also use "printer" when we mean "queue". This results nice wording like: "Set up one more printer for the same printer?" ;-) But so many problems exist because users think the "printer" inside their computer is equivalent to the piece of hardware outside of their computer. This leads to wrong assumtions in the user's mind how the printing system works and the consequence are problems. E.g. when users query the queue and get a good result but the actual printer prints crap or when the queue is "ready" but the actual printer is e.g. "offline". In the past we tried to make the user aware that it is actually a "queue" what is set up in their system but the longer I watch to where we move, the more I don't care if it is really correct what we show to them as long as our users like it. Actually queues and printers are very different things. A printer is a piece of hardware. A queue is basically a named output channel which (hopefully) results correct output on a printer. One can have printers but no queues. One can have queues but no printers. One can have anything else in between. The basic reason of all this confusion is: ------------------------------------------------- | There is no printer in the printing system. | ------------------------------------------------- What I mean is that there is no software representation of the real piece of hardware in the printing system. The kernel or whatever low-level system has a software representation of a printer, for example the USB device IDs which "lsusb" shows or what a kernel module gets during autoprobing of the parallel port or what an SNMP tool may detect in the network and so on, basically what the CUPS backends show when they run in device discovery mode. But once a queue was set up, the printing system does not remember the software representation of the real piece of hardware for which the queue was set up. All what is done is that from the software representation of the real piece of hardware a more or less abstract description is derived (the so called DeviceURI) which describes only how the the piece of hardware is connected to the computer so that the printing system (the CUPS backend) can send its data out of the computer. But nothing in the printing system knows what there is really at the end of the "named output channel" - i.e. the "queue". Some examples of bad consequences: What happens if a printer is disconnected from the parallel port and replaced by a different model? Nothing happens. The printing system would not notice that a different piece of hardware is now at the end of the connection. The printing systen still sends the same kind of data out of the computer and in the best case the new piece of hardware doesn't print anything but in the worst case it prints tons of sheets with meaningless nonsense characters. The same bad consequence if a network printer is replaced by a different model (with same IP). What could be done if a user likes to find out for which printers in his environment (in particular think about a bigger networked environment in a company) there exists already a queue and for which printers not? Nothing can be done by software. It is up to the imagination of the user to check the info strings of the queues which he might see by luck on his local system to find out which queue matches to which printer. Furthermore a reliable printer autoconfig tool cannot exist because in general it is not possible to find out for an autodetected printer if there exists already a queue for it. One can do some "best guess" based on the usb DeviceURI but there is not only the usb backend for USB printers. Perhaps this is also the reason for https://bugzilla.novell.com/show_bug.cgi?id=334166
The "Save debugging information..." should state where it is saved, because new to Linux users don't know where the logs are or how to access them. One could for example give a hint to YaST > Other > Logs.
Or even better provide also a "View debugging information" (of course with a [Search] option ;-) I think it doesn't make much sense to offer only half of whatever nice-to-have functionality - then better no such nice-to-have functionality at all (e.g. when there is not enough manpower to implement and maintain the complete nice-to-have functionality). Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany AG Nuernberg, HRB 16746, GF: Markus Rex -- To unsubscribe, e-mail: opensuse-ux+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-ux+help@opensuse.org
Hi everybody,
Perhaps "Printer accessible via a remote computer" would be the right wording but now it may look strange for an unexperienced user.
Sounds good to me :-)
On the one hand all other printer setup tools mix up "queue" with "printer" so that users are used to have this confusion in their minds and for compatibliliy reasons we could simply also use "printer" when we mean "queue".
This results nice wording like: "Set up one more printer for the same printer?" ;-)
:-) But seriously: we should make a module that is consistent with the mental model of an unexperienced user (and the experienced as well). So what about explaining the underlying structure to the unexperienced user by using some kind of wizard-like dialog (as Johannes suggested in his previous e-mail) when the user e.g. adds a new queue?
The "Save debugging information..." should state where it is saved, because new to Linux users don't know where the logs are or how to access them. One could for example give a hint to YaST > Other > Logs.
Or even better provide also a "View debugging information" (of course with a [Search] option ;-)
I agree, that the place, where the log is saved, is a vital piece of information. We should make that clear to the user. But I would not provide a "view debugging information" int the printer module because the information belongs the logs module. Best regards, Martin -- Martin Schmidkunz User Experience Specialist martin.schmidkunz@novell.com +49 (0) 911 740 53-346 ----------------------------------------------------------------- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) ----------------------------------------------------------------- Novell, Inc. SUSE® Linux Enterprise 10 Your Linux is ready http://www.novell.com/linux -- To unsubscribe, e-mail: opensuse-ux+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-ux+help@opensuse.org
Hello, On Nov 12 16:24 Martin Schmidkunz wrote (shortened):
On the one hand all other printer setup tools mix up "queue" with "printer" so that users are used to have this confusion in their minds and for compatibliliy reasons we could simply also use "printer" when we mean "queue".
...
... we should make a module that is consistent with the mental model of an unexperienced user (and the experienced as well).
I assume I misunderstand something but if you really mean that we should make software consistent with the mental model of the user even if the mental model of the user is plain wrong, then I would strongly disagree ;-) As far as I know, good usability is when the software creates the right mental model in the user's mind i.e. a mental model which matches reasonably to what there actually is in the system (which does of course not mean an exact match). Therefore the question is if the mental model of a "printer in the printing system" matches reasonably to what there actually is in the printing system: "there is no printer in the printing system".
So what about explaining the underlying structure to the unexperienced user by using some kind of wizard-like dialog (as Johannes suggested in his previous e-mail) when the user e.g. adds a new queue?
It seems we come again back to the wizard-style. Yes, perhaps the step-by-step wizard-style is really better here than the all-at-once tab-style. Furthermore I would like to present a queue overview to the user so that he can for example see remote queues immediately so that he knows which printers in his network can be used out-of-the-box without any need to set up a local queue for them. But how make it clear to the user that there can be several remote queues (perhaps on several remote CUPS servers) for the same printer? If the user has the mental model of "printer in the printing system" in his mind, he might be confused to see more "printers" than real printers exist? Or how make it clear to the user the differnce when he uses a remote queue in contrast to when he uses a remote printer? Or are perhaps the limitations of the mental model of "printer in the printing system" so well known that it is clear what more "printers" than real printers means? I think that wording like "printers/queues" or "printers (print queues)" or "configured printers (print queues)" could hopefully match to the existing "printer in the printing system" mental model of the user and at the same time it should hopefully make the user aware that it is queues and furthermore it would better match to the mental model of an experienced user. Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany AG Nuernberg, HRB 16746, GF: Markus Rex -- To unsubscribe, e-mail: opensuse-ux+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-ux+help@opensuse.org
On Wednesday 14 November 2007 05:31:46 am Johannes Meixner wrote:
I think that wording like "printers/queues" or "printers (print queues)" or "configured printers (print queues)" could hopefully match to the existing "printer in the printing system" mental model of the user and at the same time it should hopefully make the user aware that it is queues and furthermore it would better match to the mental model of an experienced user.
I agree with idea to explain what is printing queue and use that term without mixing printer/printing queue/queue. There is more queues than printing, so queue alone will make confusion. I'm not far from inexperienced user when comes to printing, so for me it would be easy to understand that printing queue is software black box that takes my text do whatever is necessary to give appropriate printout and sends to printer. It is also easy to swallow that each computer has one such black box and also that such boxes can be reached over the network, so I can send text to any of them and they will find a way to printer. I agree that the worst thing is to mix expressions, use them interchangeably like they are synonyms. Martin: The terminology used in Windows can't be used here, as they make presumption that only one physical printer is attached to computer. So when I see printing queue on the network there is exactly one printer behind that queue. CUPS servers can run on every computer advertising single physical computer that can be attached to any of them or hanging somewhere it the network. This must be made clear to any user, new and old. The other option to limit explanation and printing system setup to Windows compatible mode is cutting the wings to openSUSE. -- Regards, Rajko. -- To unsubscribe, e-mail: opensuse-ux+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-ux+help@opensuse.org
Rajko M. wrote:
Martin: The terminology used in Windows can't be used here,
Mhm.. I can't remember I suggested something like that... Anyway, I also want to answer Johannes` mail:
As far as I know, good usability is when the software creates the right mental model in the user's mind i.e. a mental model which matches reasonably to what there actually is in the system (which does of course not mean an exact match).
That is correct, but good usability takes also care of the existing mental model of the user. That doesn't mean that it should be implemented, but if you are doing something that doesn't meet the user's expectations you have to explain that to him (by e.g. using tutorials, explanatory text, new metaphores (like the trashbin). And we should really, really focus on bringing the printing model to the user. That means of course that it is not enough to hide the explanation in the help text :-)
It seems we come again back to the wizard-style.
Michal: do you already have some drafts on that or would you like some support? Cu, Martin -- Martin Schmidkunz User Experience Specialist martin.schmidkunz@novell.com +49 (0) 911 740 53-346 ----------------------------------------------------------------- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) ----------------------------------------------------------------- Novell, Inc. SUSE® Linux Enterprise 10 Your Linux is ready http://www.novell.com/linux -- To unsubscribe, e-mail: opensuse-ux+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-ux+help@opensuse.org
Hello, On Nov 15 10:58 Martin Schmidkunz wrote (shortened):
... if you are doing something that doesn't meet the user's expectations you have to explain that to him ...
Exactly! This is what I like to get all the time. I think a YaST setup module should be better than just show choices to the user but leave him (mostly) alone what to choose. I think a YaST setup module should establish some kind of communication or dialog with the user to find out what he wants and then guide him to a reasonably good possible setup (in particular when what he wants is not exactly possible) or be brave and tell him frankly when what he wants is impossible (e.g. configure an unsupported printer).
And we should really, really focus on bringing the printing model to the user. That means of course that it is not enough to hide the explanation in the help text :-)
YES! I think this is our key problem: How to display the basics of the real printing model to the user so that he gets a basic understanding what the heck this weird and confusing printing config stuff is all about. I think Rajko's understanding is perfectly sufficient: A queue is a software black box that does whatever is necessary to give appropriate printout and sends it to the printer. The exact right point in his understanding is "queue is software". I assume when he does "lpstat/lpq" or whatever graphical stuff to query the printing system, then his understanding helps him to be aware that he gets only the state of a piece of software and not necessarily the state of a piece of hardware (the printer). Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany AG Nuernberg, HRB 16746, GF: Markus Rex -- To unsubscribe, e-mail: opensuse-ux+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-ux+help@opensuse.org
On Thursday 15 November 2007 03:58:01 am Martin Schmidkunz wrote:
Rajko M. wrote:
Martin: The terminology used in Windows can't be used here,
Mhm.. I can't remember I suggested something like that...
Talking about existing mental model, implicitly set this to existing experience of majority and that is Windows.
Anyway, I also want to answer Johannes` mail:
As far as I know, good usability is when the software creates the right mental model in the user's mind i.e. a mental model which matches reasonably to what there actually is in the system (which does of course not mean an exact match).
That is correct, but good usability takes also care of the existing mental model of the user. That doesn't mean that it should be implemented, but if you are doing something that doesn't meet the user's expectations you have to explain that to him (by e.g. using tutorials, explanatory text, new metaphores (like the trashbin). And we should really, really focus on bringing the printing model to the user. That means of course that it is not enough to hide the explanation in the help text :-)
That is major problem in YaST. It gives help text that is in front of user eyes and anyway user comes on mail list to ask a question.
It seems we come again back to the wizard-style.
This is for sure good idea for new users. In wizard you get step by step guide, with one question at the time and options to answer. It is hard to ignore help text if it is given as explanation of options that one has to select. Experienced users should have large blocks of options that could be filled in at once. I really hate, when I forget default gateway, and have to repeat network configuration, and that would not happen if I would have all fields in front of me at once. Also it would be good to have option to save (export) configuration for future reuse so that one can skip manual configuration on system reinstallation.
Michal: do you already have some drafts on that or would you like some support?
Cu,
Martin
-- Martin Schmidkunz User Experience Specialist martin.schmidkunz@novell.com +49 (0) 911 740 53-346 ----------------------------------------------------------------- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -----------------------------------------------------------------
Novell, Inc. SUSE® Linux Enterprise 10 Your Linux is ready http://www.novell.com/linux
-- Regards, Rajko. -- To unsubscribe, e-mail: opensuse-ux+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-ux+help@opensuse.org
Hello, On Nov 8 14:19 Martin Schmidkunz wrote (shortened):
Based on your ideas I generated another mockup, which is visible and open for discussion on http://en.opensuse.org/YaST/Printer as well.
The main changes are: * Remote access settings were moved to the basic settings
* Network interfaces summary was skipped because this information should either be shown in the network interface module or in the firewall module (as internal zone)
I wonder what the purpose is. I guess it is only to remind the user about the basics of his network settings?
As I am no expert in printing I would like to ask: Global Settings
* Is it really necessary to test the remote IPP access? * Isn't the default queue selected as well when the user chooses to use the settings of the remote CUPS server?
CUPS server settings
* Which kind of "default" would be restored? * Is it really necessary to edit the CUPS config file via GUI?
I have the general problem that I do not understand the meaning of "remote CUPS server" in this dialogs. I guess what there is behind the "remote CUPS server" is a so called "client-only setup", see http://en.opensuse.org/SDB:CUPS_in_a_Nutshell If "remote CUPS server" means "client-only setup", then the organization under the "CUPS server settings" tab is wrong because "basic settings" and "listen to IPP broadcasts" belong to the local CUPS server which should be totally and strictly separated from any "remote CUPS server" stuff. If one has at least one local queue, one must run a local CUPS server (i.e. a local cupsd), otherwise the local queue doesn't work. I.e. if one has at least one local queue, and if "remote CUPS server" means "client-only setup", then "remote CUPS server" should be deactivated. If one has no local queue, but there is one single remote CUPS server which broadcasts his remote queues for printing, the user can choose either if he likes to run a local CUPS server and use the broadcasted remote queues via the so called "Browsing", see http://en.opensuse.org/SDB:CUPS_in_a_Nutshell or if he likes to do a "client-only setup" so that no longer a local CUPS server runs but the one single remote CUPS server is used directly. If there are more than one single remote CUPS server which broadcast their remote queues for printing, the "client-only setup" doesn't work well because only one single remote CUPS server can be configured for a "client-only setup". Here it is recommended to run a local CUPS server and use "Browsing". If there is no local queue and there is one single remote CUPS server with remote queues which are accessible from the local host but the remote CUPS server doesn't broadcast his remote queues, then a "client-only setup" is recommended because otherwise the remote queues are not "seen" on the local host. If there are one or more remote CUPS servers (more precisely whatever hosts which listen at port 631 - e.g. network printers) but their queues are not accessible from the local host, then any kind of "use remote CUPS server" is nonsense. There are more and more nice looking design ideas but there is almost no progress how to make the underlying structures, dependencies, and relationships clear to the user. I think dialogs with all theoretically possible choices available don't help. We must much more guide the user in a step-by-step process to what he finally wants to get. Basically tabs offer all possible choices. All what could be done is gray-out something which looks ugly because any user would like to know why something is grayed-out. Even worse is to hide something because then we may get maximum confusion when something is there for one user but not for another user and again any user would like to know why this "something" is not in his dialog. Wizard-style can much better guide the user. Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany AG Nuernberg, HRB 16746, GF: Markus Rex -- To unsubscribe, e-mail: opensuse-ux+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-ux+help@opensuse.org
Hi all, new yast2-printer is available in FACTORY, so you can test it now. Michal -- To unsubscribe, e-mail: opensuse-ux+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-ux+help@opensuse.org
Hello, On Nov 23 12:24 miso zugec wrote (shortened):
new yast2-printer is available in FACTORY, so you can test it now.
I dare to introduce competition ;-) I made an experimental YaST printer setup module, see http://idea.opensuse.org/content/ideas/usable-printer-setup-tool Currently idea.opensuse.org is in read-only mode so that I cannot update the info there and therefore some details are outdated. It is is a completely new design from scratch. To avoid misunderstandings: I make it only to get something which is executable instead of tons of ideas in tons of mails or tons of nice graphical "mockups" which nobody can really verify if any of those ideas does actually work and/or could actually be implemented. A printer setup tool depends on what the printing system supports. For example "there is no printer in the printing system", see http://lists.opensuse.org/opensuse-ux/2007-11/msg00005.html so that a design based upon printers instead of based upon queues (which would of course be a better design) cannot be implemented. I provide it for testing and only for testing for the released openSUSE 10.3, openSUSE 10.2, and for the openSUSE development version openSUSE "factory" in the "noarch" sub-directory at http://software.opensuse.org/download/home:/jsmeix/ Its version number is intentionally less than the version of our official yast2-printer RPM so that you cannot install the experimental YaST printer setup module by accident (e.g. via whatever automated package installation tool). If you like to test it, first of all make sure that you have our official yast2-printer RPM available so that you can go back to the official package. Then download yast2-printer-2.1.0-1.1.noarch.rpm and install it as root with this command: rpm -Uhv --force yast2-printer-2.1.0-1.1.noarch.rpm Currently only the "Configure a Printer (i.e. Set Up a Print Queue)" dialog is of interest for me. Neither the "Connecion Wizard" nor the "Driver Wizard" is implemented. A simple queue deletion is possible but it is mainly intended for more convenient testing. Nothing is implemented regarding the CUPS server. A default CUPS 1.2 setup (i.e. a local running cupsd) is required, preferably listening to incomming CUPS browsing information from other CUPS servers in the network (which is the default). Nothing is implemented regarding "printing in the network" which is the real problem. Some background information what I had in mind when I made the new design: 1) First of all an "Overview of Already Configured Printers (so called 'Print Queues')" is shown to the user which lists also remote queues. The intention is that the user can directly check if there exists already a queue for a particular printers. 2) Set up a new queue happens in one single dialog, the "Configure a Printer (i.e. Set Up a Print Queue)" dialog. There is no three-step wizard-like sequence (first select the connection, then the driver, then specify a queue name). All three mandatory steps happen in one single dialog from the top down to the bottom. See http://lists.opensuse.org/opensuse-ux/2007-11/msg00017.html "Creating a (usual) local queue requires three mandatory parameters ... One parameter describes how the printer is connected ... One parameter describes which driver is to be used ... One parameter is a name for the queue" Anything else which can be set for a queue is not mandatory and should therefore be in an [Additional settings] sub-dialog to make it clear for the user what the crucial stuff is and what is only optional where is is usually best to leave the defaults. 2a) 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 (hopefully) more obvious to the user if there is more than one driver available and which one actually is auto-selected. If a driver can be auto-selected, it does not require one more click for the user - it is just that the user can see that a driver-auto-selection happens. 2b) More descriptive text directly in the dialogs, see http://lists.opensuse.org/opensuse-ux/2007-05/msg00087.html For example: No longer plain buttons [More Drives] [All Drivers] [Driver Wizard] but now enriched with some text: If no suitable driver is shown, try [More Drives] or [All Drivers] or use the [Driver Wizard] 2c) Stretchable empty space instead of nested frames. I used stretchable empty space to separate the connection selection from the driver selection and from the queue name setting instead of having a frame around each of them. Now the 80x24-text-only-mode advocates may complain because my design seems to need more space. Of course I tested my design in 80x24-text-only-mode (call "yast printer" from a terminal emulation like "xterm") and it works but of course it doesn't look really nice there. Stretchable empty space works even better than frames in 80x24-text-only-mode because stretchable empty space can be condensed to nothing if there is no free space on the screen so that there is more space on a small screen for real content. Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany AG Nuernberg, HRB 16746, GF: Markus Rex -- To unsubscribe, e-mail: opensuse-ux+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-ux+help@opensuse.org
participants (6)
-
Johannes Meixner -
Martin Schmidkunz -
Michal Zugec -
miso zugec
-
Rajko M. -
Sven Burmeister