On 06/10/2011 08:06 PM, MÃirÃn Duffy wrote:
2 HIGH-LEVEL UI PLAN
====================
Secondly, the approach we're looking at is to swap Anaconda's current
wizard-style, linear screen-by-screen interface with a hub-and-spoke
model. (a lot of mobile devices have hub and spoke style settings
interfaces, more info on the model at [4]).
Here is the latest hub-and-spoke mockup - consider the storage portion
pretty much not started yet:
http://linuxgrrl.com/fedora-ux/Projects/Anaconda/Prototypes/hubandspoke-preview8.png
The kind of feedback that would be helpful, looking at this mockup:
- Do you think the hub& spoke model could work?
I like this approach and if we are able to go the way we want
- "First make all choices, then apply them" I think it can work
nice. Some notes regarding network configuration:
1) network in hub?
I'd consider adding network configuration to the hub - just a simple
status info that makes the configuration accessible from the hub. Note that
in http://linuxgrrl.com/fedora-ux/Projects/Anaconda/Flows/userflows-elad.svg
"Internet connection" should be linked also to "Install Destination"
or "Advanced Storage" (e.g. iSCSI).
Another option would be making network configuration spoke accessible
from spokes that may require it with a button/icon. Opening
network spoke based only on simple network status (up/down) and
action required (using netwok repo/network storage) as we do it now
is not sufficient because repositories and storage (or say kickstart) can be
served by different connections/devices. Plus, we see network as up
via NM also in case of wrong static configuration (e.g. bad nameserver).
There could be another configure network button in the action
failure dialog but it starts to seem too complicated compared to
just going back to hub and fixing network configuration there
(or adding a connection there prior to the action).
2) gnome-control-center network integration
I see three levels of network UI.
- simple status info (hub) - level of panel icon in Desktop
- status and control - level of gnome control center
(status, turn on/off, select access point, wifi authentication)
- device/connection configuration - level of nm-c-e called from g-c-c
This one seems to be pulled into g-c-c in the screenshots [1].
I am afraid we'll need to go with g-c-c as writing and maintaining
our own UI is not good. (Unlike with partitioning UI vs gparted.)
I was looking at possibility of integration of g-c-c into installer [2].
It would need to run as separate process (C app). I found some
UI issues, see: https://fedoraproject.org/wiki/Anaconda/Network#nmapplet
but it seems you are working on its UI redesign where they will be
addressed in thorough way. The one worrying me most is (5).
- Anything else you can think of, honestly.
3) askmethod
With stage 2 gone can't we dare to remove loader network
cofiguration TUI [3]?
- for ks, updates.img, ssh, gdb, dd let's require setting in boot
options or ks
- (ask)method is reduced to source selection in GUI, no?
(https://fedoraproject.org/wiki/Anaconda/UX_Redesign/Discussion#Add_askmethod_options_to_UI)
One note for
https://fedoraproject.org/wiki/Anaconda/UX_Redesign/Discussion#Install_updates_by_default
Network status as condition of default seems rather random to me
(e.g. network can be set up just for storage).
4) hostname
What about host name setting? I think this could be easy, we just
need to find proper place for it. If all the actions/commits are done
post UI we don't have to bear in mind storage dependencies
(software raid and volume group default names based on hostname)
Radek
[1]
http://linuxgrrl.com/fedora-ux/Projects/Anaconda/Screenshots/new-gnome_network-panel_mockup.png
[2]
https://www.redhat.com/archives/anaconda-devel-list/2011-May/msg00152.html
[3] http://fedoraproject.org/wiki/Anaconda/Network#Loader_text_UI
_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
