Re: [yast-devel] printer module redesign
Michal Svec wrote:
On Mon, 4 Feb 2008, Martin Schmidkunz wrote: I'm confused, why I'm not able to delete a remote queue? Meaning, I must have added it before, right?
AFAIK a remote queue is only broadcasted by CUPS. So I add a local queue on my machine and share it with others. So they can see and use it but they are not allowed to modify it. This makes sense for me, as I don't want other users to screw up my settings.
* if you want to add a new queue you therefore would have click on a local queue to get an add button. This seemed quite unlogical to me.
Well, the current solution might be OK, having Add/Configure/Delete where Add would popup a list with possibilities.
To add a printer you need to determine at least: * Connection * Driver * Name for the queue We decided not to do that in a pop-up, but in one screen. The reason was that with the full screen wizards in YaST the user gets easily lost.
I might be insane but I'd like to have a possibility to see everything at once :-) Filters might help here ("limit view to only" Local etc), but it's just an idea, let's see what others think.
Well, you are the first to say that you like the overall overview :-) All the others said, that they were confused by it and liked the four tab layout best.
And in addition, I could then reasonably select the Default printer, which I'm not sure is easily doable in multi-list/tab design :) :-) Is it technically possible to select a remote queue as "default printer"? I believe yes.
Mhm. Then this would be something to be considered. Thanks for your comments, 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
On Monday 04 February 2008 09:25:07 am Martin Schmidkunz wrote:
Michal Svec wrote: .... I might be insane but I'd like to have a possibility to see everything at once :-) Filters might help here ("limit view to only" Local etc), but it's just an idea, let's see what others think.
Well, you are the first to say that you like the overall overview :-) All the others said, that they were confused by it and liked the four tab layout best.
I'm second :-) I think that one list is what one that has to setup many printers (many anything) is wanted feature. I'm trying to imagine it as YaST software installation module, that has layout that can accommodate a lot of buttons. Though when comes to change I guess it would have to use new window. ... -- Regards, Rajko. See http://en.opensuse.org/Portal -- To unsubscribe, e-mail: opensuse-ux+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-ux+help@opensuse.org
Rajko M. napsal(a):
On Monday 04 February 2008 09:25:07 am Martin Schmidkunz wrote:
Michal Svec wrote: .... I might be insane but I'd like to have a possibility to see everything at once :-) Filters might help here ("limit view to only" Local etc), but it's just an idea, let's see what others think. Well, you are the first to say that you like the overall overview :-) All the others said, that they were confused by it and liked the four tab layout best.
I'm second :-)
I think that one list is what one that has to setup many printers (many anything) is wanted feature. I'm trying to imagine it as YaST software installation module, that has layout that can accommodate a lot of buttons. Though when comes to change I guess it would have to use new window.
I'm afraid that there are more than just two people :) I also rather do like more in one dialog than four tabs. * Tabs make sense where user understands tab-labels for the first sight. * Tabs make sense for doing different tasks (configuring different things) on every single tab. * Unification is the way to go, if we have tabs there, user has to still click through every single one of them to be sure. L.
On Tuesday 05 February 2008 02:21:28 am Lukas Ocilka wrote:
I'm afraid that there are more than just two people :) I also rather do like more in one dialog than four tabs.
I know there is more, but someone has to say that :-)
* Tabs make sense where user understands tab-labels for the first sight. * Tabs make sense for doing different tasks (configuring different things) on every single tab. * Unification is the way to go, if we have tabs there, user has to still click through every single one of them to be sure.
Agree. The single list would be good for one printer and for 100. Same set of buttons. BTW, Johannes has some ideas that IMHO are more promissing, than currently discussed UI design. Look at one of threads "printer module". The text included in line with buttons can explain what buttons can't. List can be expanded to include all printers, so there is no need for 2 lists. Buttons can be grayed out (deactivated) if they don't fit printer setup. I started to dislike tabs after network setup got them and I had to go trough all of them to find what I need for static setup. -- Regards, Rajko. See http://en.opensuse.org/Portal -- To unsubscribe, e-mail: opensuse-ux+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-ux+help@opensuse.org
Hello, On Feb 5 21:29 Rajko M. wrote (shortened):
On Tuesday 05 February 2008 02:21:28 am Lukas Ocilka wrote:
I'm afraid that there are more than just two people :) I also rather do like more in one dialog than four tabs.
I know there is more, but someone has to say that :-)
Having both local queues and remote queues in one single overview and have them nevertheless strictly separated is the fundamental "message" which must be made obvious to the user because this tells him in one single overview what the printing stuff is all about. Mix up local queues and remote queues in one list might look better on the first glance for those who don't know what the printing stuff is all about but it doesn't help them to deal with it. It does even confuse them because they will not be made aware of the crucial distinction between local queues and remote queues and what one can do with each of them. Provide local queues and remote queues on two different screens (e.g. via two tabs or whatever the usability experts like) might look better on the first glance for those who don't know what the printing stuff is all about but it makes it harder for them to deal with it. When only the local queues are shown by default it is no longer obvious when there exist already remote queues which are ready to be used for printing in the network. Users might then start to set up local queues when they like to print in the network but the [Add] button is the wrong way for printing in the network with CUPS. By the way: The word "printer" becomes meaningless when "queue" is not used. When "printer" can mean both the device and its queue, the meaning of "printer" is degenerated to "thingy regarding printing". This does not provide real information so that it is meaningless. It does not mean that we must use "queue" in the dialogs. But it does mean that we can no longer use "printer" when we mean the device. Therefore we should use strictly "device" when we talk about the piece of hardware and we can use "printer" or "configuration" or whatever else fits - except "device" - when we mean the queue. The wording "printer" for queue and "device" for the hardware is even consistent with the wording in CUPS. As a small exercise think about the differences regarding the meaning behind the following terms: - local queue for a directly connected device - local queue for a local device - local queue for a remote device - remote queue for a directly connected device - remote queue for a local device - remote queue for a remote device
... Johannes has some ideas that IMHO are more promissing, than currently discussed UI design. Look at one of threads "printer module". The text included in line with buttons can explain what buttons can't.
http://lists.opensuse.org/opensuse-ux/2007-05/msg00075.html http://lists.opensuse.org/opensuse-ux/2007-05/msg00087.html Unfortunately any further discussion is futile because descriptive texts for buttons was already rejected. Instead we have exhaustive discussions about button names... 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
Johannes Meixner napsal(a):
Hello, On Feb 5 21:29 Rajko M. wrote (shortened):
On Tuesday 05 February 2008 02:21:28 am Lukas Ocilka wrote:
I'm afraid that there are more than just two people :) I also rather do like more in one dialog than four tabs. I know there is more, but someone has to say that :-)
Having both local queues and remote queues in one single overview and have them nevertheless strictly separated is the fundamental "message" which must be made obvious to the user because this tells him in one single overview what the printing stuff is all about.
It's all about printing, details might come when user wants to configure how to print (local printer, remote queue, local queue, ...). A simple overview can show already configured devices and queues at once.
Mix up local queues and remote queues in one list might look better on the first glance for those who don't know what the printing stuff is all about but it doesn't help them to deal with it. It does even confuse them because they will not be made aware of the crucial distinction between local queues and remote queues and what one can do with each of them.
I'm afraid that splitting into more and more tabs will help even less because users will never find what they are looking for, especially when they are unsure what *exactly* they are looking for. In my opinion, what users want is *to configure a printer or queue* to use them for printing. Additional sharing local printers to another clients can be done via per-device basis. User mustn't be scared with *so many options* we provide. Having four different tabs makes user run away, especially with terms they don't understand. Configuring a printer or print queue is nice example for Configuration wizard: YaST asks for simple questions, user selects from simple options.
Provide local queues and remote queues on two different screens (e.g. via two tabs or whatever the usability experts like) might look better on the first glance for those who don't know what the printing stuff is all about but it makes it harder for them to deal with it. When only the local queues are shown by default it is no longer obvious when there exist already remote queues which are ready to be used for printing in the network. Users might then start to set up local queues when they like to print in the network but the [Add] button is the wrong way for printing in the network with CUPS.
Almost nobody (except Johannes) exactly knows what all this stuff is really about :) ;) The only way is to provide a simple view to that problematics: * Newbie users would not run away because of thousands of check-boxes and other options. * Experienced users would almost know what is it about and where to find and tune details. * Experts would configure cups directly or know exactly where to find the options.
By the way:
The word "printer" becomes meaningless when "queue" is not used. When "printer" can mean both the device and its queue, the meaning of "printer" is degenerated to "thingy regarding printing". This does not provide real information so that it is meaningless.
It doesn't matter whether a printer is local or remote or how do you print with it (directly, cups). What matters it what users want to do: just print. It doesn't make sense to configure a printer (or queue) just to have it configured. Printing must be transparent: you have document and you want to have it printed. Philosophical questions can be reduced to simple human-understandable tasks. http://en.wikipedia.org/wiki/Printer * Printer (publisher), a company or person who operates a printing press * Computer printer, a computer peripheral that reproduces text and/or pictures * Optical printer, a device to copy and/or modify images on motion picture film http://en.wikipedia.org/wiki/Computer_printer A computer printer, or more commonly a printer, produces a hard copy (permanent human-readable text and/or graphics) of documents stored in electronic form, usually on physical print media such as paper or transparencies.
It does not mean that we must use "queue" in the dialogs. But it does mean that we can no longer use "printer" when we mean the device.
As well as I don't agree with the the argument, I don't agree with te conclusion.
Therefore we should use strictly "device" when we talk about the piece of hardware and we can use "printer" or "configuration" or whatever else fits - except "device" - when we mean the queue.
The device is called a "printer". And at the end, a printer prints the document. Exception: 'Virtual Printer' that creates and stores a Post Script or PDF document instead of printing it :)
The wording "printer" for queue and "device" for the hardware is even consistent with the wording in CUPS.
We should keep consistent with how humans understand it. Because our users are (mainly) humans :)
As a small exercise think about the differences regarding the meaning behind the following terms: - local queue for a directly connected device - local queue for a local device - local queue for a remote device - remote queue for a directly connected device - remote queue for a local device - remote queue for a remote device
Simple overview can show details for each configured printer (device) or queue. You can't have tabs for all possibilities.
... Johannes has some ideas that IMHO are more promissing, than currently discussed UI design. Look at one of threads "printer module". The text included in line with buttons can explain what buttons can't.
http://lists.opensuse.org/opensuse-ux/2007-05/msg00075.html http://lists.opensuse.org/opensuse-ux/2007-05/msg00087.html
Unfortunately any further discussion is futile because descriptive texts for buttons was already rejected. Instead we have exhaustive discussions about button names...
A style guide (haha) defines, that some buttons can have more informative label: [ Print ] [ Cancel ] [ Yes, Shut-Down ] [ Cancel ] ... But they are mostly used in pop-ups. Have a nice day Lukas -- Lukas Ocilka, YaST Developer (xn--luk-gla45d) ----------------------------------------------------------------- SUSE LINUX, s. r. o., Lihovarska 1060/12, Praha 9, Czech Republic
participants (4)
-
Johannes Meixner -
Lukas Ocilka -
Martin Schmidkunz -
Rajko M.