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: lslezak@suse.cz 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: jsrain@suse.com 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: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org