Bug 852850

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: YaST2Assignee: 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
This issue was reported to me by Christopher De Nicolo.

On his workstation the usually by default enabled SuSEfirewall2 is active
(probably because his network interface "enp4s0" belongs to the usual default
firewall zone "EXT" - i.e. the external zone).

Therefore the local running cupsd on his workstation cannot receive
the print queue information that get sent to his workstation
by the CUPS server in the network.

Accordingly the print dialogs in his application programs cannot
show any print queue so that Christopher "just cannot print".

Because for Christopher the active SuSEfirewall2 is not at all perceived
he launches the YaST printer module.

In the same way as any printing application also the YaST printer module
cannot show any print queue so that Christopher thinks he must "Add"
a new print queue.

If one knows what goes on behind one knows that this is the wrong way.
But for a normal user everything leads towards that wrong way.

All what Christopher would have to do to solve the issue correctly
is what is described at "Bottom Line" in
http://en.opensuse.org/SDB:CUPS_and_SANE_Firewall_settings
---------------------------------------------------------------------------
Only assign the network interface which belongs to the internal
network to the internal zone of the firewall.
---------------------------------------------------------------------------

Regardless that it is actually a firewall configuration issue
(compare https://features.opensuse.org/316708)
I would like if we could think about how to enhance yast2-printer
to better guide the user away from "Add" towards an actually right
solution (when "Add" is not the actually right solution).

The problem is how to find out when "Add" is not the right
solution for what the user actually wants to have.

I.e. how to autodetect what the user actually wants to have!
;-)

Or alternatively:
How to ask a few simple questions that are meaningful for the user
to find out what the user actually wants to have.

Or alternatively:
How to re-design the initial yast2-printer dialog to better guide
the user away from "Add" towards an actually right solution.

By the way,
Christopher told me that my very first proposal for the initial
yast2-printer dialog could have helped him because it separates
local printins stuff from network printing stuff, see
http://en.opensuse.org/File:Printer_jsmeix_overview.png
and for background information see
http://en.opensuse.org/Archive:YaST_Printer_redesign
Comment 1 Johannes Meixner 2013-11-29 13:25:08 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?
;-)
Comment 2 Johannes Meixner 2013-12-03 13:53:59 UTC
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".
Comment 3 Juergen Weigert 2013-12-03 19:59:11 UTC
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.
Comment 4 Johannes Meixner 2013-12-04 10:09:32 UTC
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"?
Comment 5 Johannes Meixner 2013-12-04 10:29:35 UTC
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.
Comment 6 Johannes Meixner 2013-12-04 10:48:08 UTC
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.
Comment 7 Christopher De Nicolo 2013-12-04 11:27:43 UTC
(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
Comment 8 Johannes Meixner 2013-12-04 11:35:53 UTC
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?
Comment 9 Juergen Weigert 2013-12-04 15:12:59 UTC
(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?
Comment 10 Johannes Meixner 2013-12-04 16:07:22 UTC
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.
Comment 11 Christopher De Nicolo 2013-12-04 19:20:33 UTC
is now public.
Comment 12 Johannes Meixner 2013-12-05 09:23:18 UTC
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).
Comment 13 Johannes Meixner 2013-12-05 09:46:32 UTC
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'.
Comment 14 Johannes Meixner 2013-12-05 12:13:22 UTC
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
Comment 15 Johannes Meixner 2013-12-05 13:20:18 UTC
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"
                                     ^^
Comment 16 Johannes Meixner 2013-12-11 09:48:11 UTC
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.
Comment 17 Johannes Meixner 2013-12-11 10:42:36 UTC
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.