|
Bugzilla – Full Text Bug Listing |
| Summary: | yast2-printer: better guide the user away from "Add" towards an actually right solution (mainly towards "Print via Network") | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE 13.1 | Reporter: | Johannes Meixner <jsmeix> |
| Component: | YaST2 | Assignee: | Johannes Meixner <jsmeix> |
| Status: | RESOLVED FEATURE | QA Contact: | Jiri Srain <jsrain> |
| Severity: | Enhancement | ||
| Priority: | P5 - None | CC: | christopher.denicolo, froh, stefan.fent |
| Version: | Final | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | openSUSE 13.1 | ||
| Whiteboard: | |||
| Found By: | Development | Services Priority: | |
| Business Priority: | Blocker: | No | |
| Marketing QA Status: | --- | IT Deployment: | --- |
|
Description
Johannes Meixner
2013-11-28 15:16:20 UTC
yast2-maintainers@suse.de, it does not help to just assign an issue that is reported by me back to me (if I had an idea how to solve it I would have assigned it already to me). I need help how to solve issues like that. What do you usually do in the YaST team to solve issues like that? Do we have usability experts or similar who could help? The currrent yast2-printer dialogs - in particular its initial "Overview" dialog - was designed in a lenghty development process together with one from our former usability team, see http://en.opensuse.org/Archive:YaST_Printer_redesign in particular the "Release Candidate 2" section that reads: -------------------------------------------------------------------------- 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. -------------------------------------------------------------------------- Regardless that "Print Via Network" is shown "very prominent" Christopher did not perveive it and clicked "Add" instead. Should I make "Print Via Network" bright red blinking text? ;-) Christopher, could you provide background information so that I can imagine why you clicked "Add" instead of "Print via Network". Preferably I would like to understand what you had in mind (in particular your so called "focus of mind") when you looked at the initial "Overview" dialog why "Add" looked as if it was "the right thing" regardless that your actual issue was to use a printer in the network. I know that this happens often when users actually want to "Print via Network" but I need to understand what goes on behind in the user's mind that makes "Add" look like "the right thing". From a not 'printer-educated' point of view:
'Printer Configurations' starts with 'Sho [x] Loca [x] Remote', which I read as covering both, local and remote printers.
There is no strong motivation to click on 'Print via Network'. This reads like limiting the scope to 'only remote'.
When you say, you want to guide users away from pressing 'Add' for remote printers, does that mean, 'Add' can only add local printers? The onscreen instruction says "Try 'Detect More' or use the 'Connection Wizard'". The connection wizard lists many network related options, under the headings 'Access Network Printer or Printserver Box' and 'Print via Print Server Machine'
So chances are that I invest some time here trying to find out which protocol might work to access a new remote printer.
Choosing 'Print via Network', we first see a warning that a firewall may prevent CUPS servers to work properly, then we have three options all related to CUPS servers. In a more windows centric world (e.g. outside of SUSE), I would not expect to have any CUPS servers. Thus I am inclined to ignore the warning, and also dismiss 'Print via Network' as all this is CUPS Server specific.
In a windows world, I'd certainly also try 'Share Printers' to look for shared printers on the network. (I have seen missing letters before)
Sorry if most of my above logic appears foolish. I am trying not to be extra clever, maybe I overdo things.
I'd like to know if the following assumptions are safe (only the first few are printer specific, sorry for going off-topic):
1) 'Print via Network' already has a sane default, namely
'[x] Accept Printer announcements from CUPS Servers (all, any).'
Usually there is nothing to configure here.
2) When we have a Firewall and we try 'Print via Network', at least
one interface should be in the internal zone.
3) This reliably tells us which interface is where:
cd /var/run/SuSEfirewall2/status/interfaces
for i in *; do echo -n "$i "; cat $i/zone; done
4) If a machine has only one interface, switching this interface from
external zone to internal zone would normally have the same effect
as disabling the firewall.
5) FW_TRUSTED_NETS="192.168.0.0/16 10.0.0.0/8 172.16.0.0/12" expresses
trust in the local network. The outside world is still firewalled, as
we are within a private network. This setting should not be used
in a campus, an internet cafe, an open hotspot, or any other location
with potentially hostile users or machines.
Juergen Weigert, only some reply (I cannot fully answer firewall issues, a firewall expert should do that): a) It is correct that 'Print via Network' is limiting the scope to 'only remote'. b) Regarding 'Add' can only add local printers? see "The Printer Configurations Dialog" at http://en.opensuse.org/YaST_Printer that reads in particular: --------------------------------------------------------------------------- When the YaST printer module started, it shows the printer configurations. This dialog shows an overview of all available print queues - both local and remote queues - at a glance and it shows also all possible configuration tasks. There is a difference between "local/remote queue" and "local/remote printer": * "Local queue" means a print queue which is configured on the local computer (strictly speaking the computer where the YaST printer module runs) which is usually the computer where the user sits in front of. * "Remote queue" means a print queue which exists on whatever computer in the network or on whatever network printer. * "Local printer" means a printer device which is directly connected to the local computer (usually a USB printer). * "Remote printer" means a printer device which is not directly connected to the local computer (usually a printer with a built-in network interface). Only local print queues can be configured with the YaST printer module. But local print queues can be set up both for local printers and for remote printers. It does not matter how the printer device is connected but it does matter whether or not the print queue configuration exists on the computer where the YaST printer module runs. --------------------------------------------------------------------------- It is perfectly valid to set up a local queue for a remote printer. But when there is a CUPS server in the network and when you like to use a network printer for which there is already a print queue on that CUPS server (and when you are allowed to use that queue) then it is _the_recommended_way_ not to set up a local queue for that network printer but to use the remote queue on the CUPS server instead. To use a remote queue on a remote CUPS server it is again perfectly valid to set up a local queue that only forwards the printing data "as is" to the remote queue on the remote CUPS server. But when the remote CUPS server announces its queues in the network traditionally via CUPS Browsing up to CUPS 1.5 or since CUPS 1.6 via DNS-SD (Avahi) then it is _the_recommended_way_ not to set up a local (forwarding) queue for the remote queue but to accept the remote CUPS server's queue announcements instead. See also bnc#852842 If you now feel confused you are perfectly right. The whole 'Print via Network' is manifold and that makes it hard to design a good initial overview dialog in a printer setup tool. Cf. John Fitzgerald Kennedy: "We choose to go to the Moon in this decade and do the other things, not because they are easy, but because they are hard." c) Regarding a more windows centric world (e.g. outside of SUSE) where one canot expect to have any CUPS servers: The current YaST printer module does not specifically implement anything that guides the user in such a network environment towards an actually right solution. I.e. in a Windows network environment the user is currently on his own to "somehow know what he must set up" and then he can do this setup with the YaST printer module using the "Connection Wizard" - regarding that name see "Connection" at http://en.opensuse.org/YaST_Printer that reads in particular: --------------------------------------------------------------------------- If a network printer cannot be autodetected by CUPS or when you like to print via a print server machine (e.g. when printing via a Windows or Samba server or when printing via a traditional Unix server), you have to specify the connection manually via the "Connection Wizard". Unfortunately its name is somehow inappropriate because there are neither "wizards" nor any other kind of obscure "magic" in the YaST printer module, see http://en.opensuse.org/Archive:YaST_Printer_redesign --------------------------------------------------------------------------- In a network environment without a CUPS server usually the only way to use a remote printer is to set up a local queue for it. See "Differences in Printing between Windows and Linux" at http://en.opensuse.org/SDB:Printing_from_Windows_to_Linux and the help text for the "Connection Wizard" dialog and http://en.opensuse.org/SDB:Printing_via_TCP/IP_network http://en.opensuse.org/SDB:Printing_via_SMB_%28Samba%29_Share_or_Windows_Share My personal guess why users click "Add" instead of "Print via Network" when they like to print via network is that their experience comes from network environments without a CUPS server where they must "Add" a local queue to use any remote printer - i.e. I guess that somehow the "I must add something to use a printer" is more or less hardwired in user's minds so that they cannot perceive "Print via Network" - it is just "random noise" for them. If my personal guess is right, I wonder how we could disrupt a user's hardwired intention to click straight on "Add" when he actually wants to "Print via Network"? Regarding "if the following assumptions are safe" in comment#3: Accepting printer announcements from any CUPS servers is not safe. This is the CUPS default that can lead to "print job phishing" see http://en.opensuse.org/SDB:CUPS_and_SANE_Firewall_settings This is one reason why a firewall should by default protect the local system from arbitrary incoming print queue announcements. I think item 2) and 3) in comment#3 are possible enhancements for the 'Print via Network' dialog regarding better firewall status detection (the current firewall popup is really simple). But for now the topmost crucial point is to guide the user into the 'Print via Network' dialog when he likes to print via network. Only for my own information regarding item 3) in comment#3: /var/run/SuSEfirewall2 does not exist on SLE11 (the current YaST printer module also works on SLE11) On openSUSE 13.1 /var/run/SuSEfirewall2/ only exists when SuSEfirewall2 is active. Therefore a fail-safe implementation should be something like: When SuSEfirewall2 is active but there is no /var/run/SuSEfirewall2/status/interfaces/*/zone file, then assume the external zone is used. When SuSEfirewall2 is not active or when it cannot determine whether or not SuSEfirewall2 is active and when "iptables -n -L | egrep -q 'DROP|REJECT'" results exit code 0 then assume another firewall is active and assume the other firewall behaves as if the the external zone was used for SuSEfirewall2. (In reply to comment #2) > Christopher, > > could you provide background information so that I can imagine > why you clicked "Add" instead of "Print via Network". > > Preferably I would like to understand what you had in mind > (in particular your so called "focus of mind") when you > looked at the initial "Overview" dialog why "Add" looked > as if it was "the right thing" regardless that your > actual issue was to use a printer in the network. > > I know that this happens often when users actually want > to "Print via Network" but I need to understand what > goes on behind in the user's mind that makes "Add" look > like "the right thing". Opening the yast-printer-module I see an empty list of local and network printers. Why should I think the add-button has nothing to do with network printers when in addition on the next dialog (following the add button) I can choose a connection wizard? Following would have helped me: - Separating local and network printers: 2 lists side-by side, with an add-Button for local printers and a refresh-Button for network printers - Pressing a refresh-button giving me a warning about an activated firewall - A button named "Add a local printer" - A connection wizard in the "Print via network" dialog Since comment#2 all comments are marked "private". I wonder if there is really private information therein or what the reason is why openSUSE users are excluded? Juergen Weigert and Christopher De Nicolo, do you agree that I make comment#2 up to comment#7 public accessible? (In reply to comment #8) > Since comment#2 all comments are marked "private". > I wonder if there is really private information therein > or what the reason is why openSUSE users are excluded? > > Juergen Weigert and Christopher De Nicolo, > do you agree that I make comment#2 up to comment#7 public accessible? mine are public now. sorry. Regarding 'disrupt a user's hardwired intention to click straight on "Add" when he actually wants to "Print via Network"?': When a 'list of things' is empty or too short, and it offers an 'Add' button, then users will press that button. This logic is independant of any knowledge about queues and printers. If A user correctly understands that 'Printer Configurations' handles both, remote and local, and it is correct that 'Print via Network' is limiting the scope to 'only remote' -- then there is no reason to ever select 'Print via Network'. Logic: A includes B, so having A is sufficient. Probably wrong logic here? Juergen Weigert, regarding "remote and local" you mix up "Local queue", "Remote queue", "Local printer", and "Remote printer", see my comment#4. The user does not need to understand that differences. All he needs is to perceive that when he likes to print via network, then he should click "Print via Network" (and not anything else). Regarding "Empty list with 'Add' button => user clicks 'Add'.": I think this could be the actual root cause here. Many thanks for that idea what is going on behind! Now we have to think about how to re-desing it so that there is no such thing as an "Empty list with 'Add' button" when the user actually wants to "Print via Network". This seems to lead back to the inital problem in comment#0: "how to autodetect what the user actually wants to have!" because for a home user system where a local USB printer is not configured, the "Empty list with 'Add' button" is exactly the right thing and here the user must click the 'Add' button. Is the absence of a local USB printer (local USB printers can be autodetected) a sufficient indicator that the user actually wants to "Print via Network"? Probably a 100% excat solution is not needed. It may be perfectly sufficient if an automatism could distinguish the both cases "Add (a local queue for local or remote printer)" and "Print via Network" e.g. 90% correctly. is now public. Generalization of "Empty list with 'Add' button => user clicks 'Add'.": I thought I could use the case "Empty list" as indication that the user may actually wnat to print via network but this would be wrong. Rationale: Assume the user has a local USB printer set up and additionally he wants to print via network. This is the usual case for a mobile system (e.g. a laptop) where a local queue exists (e.g. for an USB printer at home) and when not at home the user wants to print via network (e.g. in the office). In this case the list of already available print queues would not be empty (the USB printer's queue exists). When the user is not at home (e.g. in the office with a CUPS server) and wants to print from an application, the application's print dialog only shows the queue for his USB printer at home because the firewall that must run on a mobile system must block CUPS server's queue announcements see in particular "print job phishing" at http://en.opensuse.org/SDB:CUPS_and_SANE_Firewall_settings The user misses queues to print via network. When the user is not aware of the firewall (cf. https://features.opensuse.org/316708), the user may launch yast2-printer to set up printing via network but for the same reason (firewall blocks CUPS queue announcements), the user would see only the queue for his USB printer at home in the overview dialog but no queues to print via network. The user misses queues to print via network in the list but there is that "Add" button next to that list so that it is totally obvious what to do next... Therefore from my point of view a generalization of "Empty list with 'Add' button => user clicks 'Add'." is the following finding: Usability hypothesis: "Missing entry in list with 'Add' button => user clicks 'Add'." To get at least some kind of evidencde (or even a proof) for that hypothesis: Christopher De Nicolo, Juergen Weigert, and whoever is listening here: please provide feedback whether or not you think my above analysis is correct. Outlook: If my hypothesis is right, the yast2-printer initial overview dialog needs a fundamental re-design. Basically (if my hypothesis is right), it means one cannot have two different buttons to set up printing (one via "Add" and one via "Printing via Network") which means the setup for printing via network must somehow be integrated with the setup for local print queues (the current "Add" setup). This would need a fundamental re-design of the whole workflows in yast2-printer. Retrospect: Setup for printing via network was not a major goal at the time when the YaST printer module was made anew. The main goal at that time was to clean up the mess of the old YaST printer module, see in particular "Basic Design Ideas" and "Strict Compliance With CUPS" at http://en.opensuse.org/Archive:YaST_Printer_redesign The current YaST printer module does not specifically implement anything that guides the user towards "Print via Network". The user is currently on his own to somehow know in advance that he must click "Print via Network" (but not "Add") when he wants to set up printing via network (cf. "Regarding a more windows centric world" in comment#4). I think Juergen Weigert already provided the feedback that I asked for in comment#12 in his comment#9: "When a 'list of things' is empty or too short, and it offers an 'Add' button, then users will press that button." One only needs to equate 'empty or too short' with 'missing entry'. I was wondering all the time how I could find out when the firewall is active whether or not there are print queue announcements from remote CUPS servers in the outer network beyond the firewall. yast2-printer nor any other application can look outside beyond the firewall - but the firewall itself knows what goes no in the outer network. If the firewall logged when it drops or rejects print queue announcements from remote CUPS servers (i.e. what gets sent to UDP port 631), yast2-printer could inspect the firewall's log file to find out and show meaningful information to the user so that the user could then decide if he trusts those remote hosts and likes to accept what they send to UDP port 631. See "A general idea for better firewall user experience:" at https://features.opensuse.org/316708 Typo correction:
"the firewall itself knows what goes no in the outer network"
should read
"the firewall itself knows what goes on in the outer network"
^^
Conclusion: Better guide the user away from "Add" towards an actually right solution (mainly towards "Print via Network") is not possible when there are different buttons (with different workflows) to set up printing (one via "Add", one via "Printing via Network", one via "Share Printers", ...). When there are several buttons (entry points) the software cannot guide the user to click the right button (choose the right entry). Therefore the initial dialog should show the list of currently available print queues plus one single button to "do whatever can be done" when something is not as expected (e.g. when something is missing) in that list. This means a fundamental re-design of the dialogs and workflows to set up the whole printing stuff is needed. This cannot be implemented as "bugfix" or "enhancement". I will file a FATE feature request. The FATE feature request is https://features.opensuse.org/316789 "Fundamental re-design how to set up the whole printing stuff" FYI: There is a related FATE feature request https://features.opensuse.org/316708 "simple laptop user firewall experience (e.g. printing)" If a fundamental re-design of the printing setup happens, then it would be the right time to also fundamentally improve how to deal in a ueser-friendly way with the case when a firewall blocks printing stuff. |