Bug 310518

I am the assignee...

...but I need info from Jiri.

It is possible to extend the dialog, however, I don't think this is to be done for 10.3 (RC2). But I can do it for 11.0.

Therefore this is intentionally an enhancement request for openSUSE 11.0 ;-)

Jiri,
can you tell me if you have time to extend the dialog soon
so that I could use it for testing for 11.0 (i.e. so that we
have it really ready before the first 11.0 beta).

Currently I don't have an ideal place in mind where optional
additional buttons should appear.

I contrast to my initial comment #0 I think now it is perhaps
not good to have additional buttons between the table and the
rich-text because table and rich-text should always look
concatenated.
Therefore optional additional buttons should be placed over the
table or below the rich-text.
I don't know which place is better.
I think the place depends on the meaning of the additional button.

For example if an additional button changes the content or the
meaning of the table+rich-text (like in this enhancement request),
it might be best placed above the table+rich-text?

In contrast if an additional button offers an additional functionality
which should be directly accessible (and not hidden under [other])
e.g. something like [autodetect parallel port scanners], it might be
best placed below the table+rich-text?

By the way:
Another example of optional additional stuff which should be
placed over the table+rich-text would be a text-entry together
with a [search] button which would be useful if there are tons
of entries in the table.
Therefore it might be a good idea when the dialog could be
extended not only with buttons?

don't abuse NEEDINFO for actual work assignments - NEEDINFO is for log files and similiars

Now you abused this bug (enhancement in yast2-scanner)
for an enhancement in the underlying YaST wizard/widget (WizardHW).

Johannes, I've been looking at the dialog and really don't know where to put any additional button. Considering the space between [Delete] and [Other], it may not be suffucient. Putting a ReplaceBox anywhere in the dialog is technically not a problem, but I'd like to be carful, since the same dialog is used in many other modules.

Another idea is to put another item to the selection box (something like "Show all scanners"), but this is not extra usable either.

Martin, do you think you could give us a hint from the usability point of view?

Sorry for replying that late!

My initial thoughts about that are:
* Rename [Other] to [Detection], which will make the purpose of the button clearer to the user
* Add [All USB Devices] to that selection box
* Move [Test] to [Edit]

I tried to add a scanner to my computer today, but unfortunately I couldn`t install a needed package, so I will be able to take a closer look at it tomorrow.

What do you think about that?

Rename [Other] to [Detection] is not possible
because the meaning of the [Other] button is "everything else".
What there actually is varies for each hardware module.
E.g. the scanner module has also "Scanning via Network" there.

Move [Test] to [Edit] is not ideal because one can test
without editing.
Strictly speaking [Test] is only possible after [Edit] was finished,
i.e. after the new configuration was committed to the system
because one cannot test something which is not actually set up.

Have an additional [Test] under [Edit] and then also
an additional [Test] under [Add] would be possible
but because of the above logic, I think it is better
to have [Test] separated from [Edit] and [Add].

Mhm...

In general: [Other] is a pretty meaningless label for the user and maybe we should discuss if it wouldn't be better to introduce more meaningful button labels in YaST. 

But that is not really the topic of this bug :-)

Under the current circumstances I would suggest to add the entry [Detect All USB Devices] into the [Other] combo box.
Although the user has to find out that this functionality is hidden there it is a least grouped with other detection functionalities (Restart Detection, Scanning via Network).
If [Detect All USB Devices] would be an extra button the detection functionalities would be separated which would be much worse from the usability point of view.

Just some text to remove the NEEDINFO status :-)

O.k.
I will add the entry [Detect All USB Devices] into the [Other] combo box.

Now it is again my bug.

I think I found a simpler and better way how to implement it:
Use the existing "Restart Detection".

Initially yast2-scanner shows only known USB scanners.
When the user selected "Other" -> "Restart Detection"
it shows even unknown USB devices which might be a scanner.

Reasoning:
The help text already describes what to do when a scanner
is not detected (i.e. use "Other" -> "Restart Detection").
For the user it makes no difference if his scanner was actually
detected but just not shown (because it is an unknown USB scanner)
or if it was really not detected (e.g. because it was switched off).

By the way:
Again a nice example how difficult it is to come from the technical
point of view (two buttons for two technically different issues)
to the user's point of view (one button for both issues because
both issues are indistinguishable for the user).

Implemented it so that "Restart Detection" toggles
whether or not unknown USB scanners are shown.

Initially only scanners for which the USB IDs are
known by SANE are shown.

It changes to show all USB devices with the device class 255
as possible USB scanners when the user explicitely requests
a "Restart Detection" in the OverviewDialog.

A second "Restart Detection" changes it back
so that "Restart Detection" toggles the autodetection behaviour.

The idea behind is that the user can simply "Restart Detection"
as often as he likes until the result is o.k. for him
because "Restart Detection" does not cause harm and
it avoids a separated button or check-box to determine
the autodetection behaviour which would require additional
explanatory (complicated) help text about the whole stuff.

Examples:

Assume there is a known powered-off USB scanner and
another USB device with class 255:
Initially nothing is shown.
After the first "Restart Detection" only the other USB device
with class 255 is shown.
This unexpected result makes the user think about what is wrong
and he powers-on the scanner.
After the second "Restart Detection" only the USB scanner is shown.

Assume there is an unknown powered-off USB scanner and
another USB device with class 255.
Initially nothing is shown.
After the first "Restart Detection" only the other USB device
with class 255 is shown.
This unexpected result makes the user think about what is wrong
and he powers-on the scanner.
After the second "Restart Detection" nothing is shown.
A third "Restart Detection" shows both the USB scanner
and the other USB device with class 255.
This is the best possible result because it is not possible
to show only the unknown USB scanner.