Hi Ken,
On 06/17/2015 01:57 PM, Kenneth Wimer wrote:
Hi,
I am trying to understand the user path in this use case. If a user
wants to migrate a system which part of a given migration target is of
most importance to the user? For example, if the target is:
SLE-12.1-x86_64, SLE-SDK-12.1-x86_64, SLE-HA-12.1-x86_64,
SLE-HA-GEO-12.1-x86_64
I would assume that the last entry in that list is probably the most
important. If that is always the case we should optimize the ui for the
user to identify that information.
I would not say so - this is simply list of products which will be
installed after the migration is done. I cannot say whether SCC delivers
the list in any particular order or it is more or less random...
If however, there is, as you mention, a long list of possible
combinations perhaps it would be best to allow the user to select each
part of that list with hierarchical group of pull-downs. That would
certainly simplify the ui space-wise.
My guess is that the number of options will be rather limited - if you
stick with the SLE product family, I don't think that there will be more
than two, maybe three (depending on how many service packs we want to
allow to skip). There may be more when products, which are not released
in sync with SLES, come to the game - however, I still don't think that
the number of options will be any significantly higher.
Jiri
If the above is interesting I can make a mockup.
On 16/06/15 23:48, Ladislav Slezak wrote:
Hi all,
I'm implementing a new online migration dialog for selecting the
migration target.
(This tool is will be available only for SLE12, for openSUSE it does
not make sense
as the product cannot be registered in the SUSE Customer Center (SCC).)
The new online migration tool will find all installed products in the
system and ask
the registration server for possible migrations to new service pack(s).
The response from the server will contain all allowed combinations to
all available
products and extensions. E.g. [ SLES-12-SP1 + Extension-Foo-SP1,
SLES-12-SP1 +
Extension-Foo-GA (if the GA version is supported on SLES SP1), ...]
That means there could be potentially quite a lot of possible
migration targets.
User can select just one migration target in the dialog which will be
applied to the
system.
The problem is how to design the UI. Here are some my ideas with
screenshots
(mockups). The screenshots were taken in the minimal supported
resolution (800x600 in
GUI, 80x25 chars in text mode) to see the minimal available space for
widgets.
RadioButtons
------------
Qt: http://paste.opensuse.org/3268571
ncurses: http://paste.opensuse.org/65912174
This was the initial design as the RadioButton is the usual widget
used for selecting
a single option from many possibilities.
+ (IMO) clear meaning for the users (one from many selection).
- It's not possible to scroll the list if it is longer than the
available space,
in that case some RadioButtons will be missing. That's clearly
visible in the
ncurses screenshot, if there was one more installed product (or one
more migration
target) then the UI would break...
SelectionBox (with multi-line values)
------------------------------------
Qt: http://paste.opensuse.org/34590676
ncurses: http://paste.opensuse.org/65761791
+ Scrollable list, no problem with many migration targets.
- There is no separator in the list, it's not clear how many
migrations are there
and what each migration includes unless you click on some line.
- Ncurses UI does not support multi-line values (only the first line
is displayed).
SelectionBox (with single line values) + RichText (with details)
----------------------------------------------------------------
Qt: http://paste.opensuse.org/45144130
ncurses: http://paste.opensuse.org/56893356
Similar to the previous one, but there are short product names used on
a single
line in the SelectionBox. Additionally there is a RichText with
details of the
selected migration target. (The screenshot shows just the full product
names, but we
could simply add more details like the list of the migration
repositories, the
repository URLs, whatever...)
+ Both widgets are scrollable.
+ Works in both Qt and Ncurses UI properly.
- More complicated for users, not obvious how the dialog works and
what is expected
from the user.
So far the last solution looks the best for me. What do you think
about it?
Any suggestions or ideas how to improve it? Or even a completely
different design?
[Adding Ken to CC...]
--
Best Regards
Ladislav Slezák
Yast Developer
------------------------------------------------------------------------
SUSE LINUX, s.r.o. e-mail: [email protected]
Lihovarská 1060/12 tel: +420 284 028 960
190 00 Prague 9 fax: +420 284 028 951
Czech Republic http://www.suse.cz/
--
Regards,
Jiri Srain
Project Manager
---------------------------------------------------------------------
SUSE LINUX, s.r.o. e-mail: [email protected]
Lihovarska 1060/12 tel: +420 284 084 659
190 00 Praha 9 fax: +420 284 084 001
Czech Republic http://www.suse.com
--
To unsubscribe, e-mail: [email protected]
To contact the owner, e-mail: [email protected]
