[yast-devel] On WebYaST design
Hi all, today we (me, jsrain, jreidinger) had a small chat about what we'd like to change in webyast from the appliance users POV. This is the result. We think that these changes really should get into appliance toolkit 1.1. == Name the appliance == The "My appliance" string in header does not give any information to the user. Let's put there something useful - like the appliance name defined in Studio. == Don't mention localhost == In appliance toolkit 1.1, let's specialize the WebYaST interface for appliance use. The webyast-UI is always connected to the localhost webyast-WS (webservice, restful). We should hide this information from the user. == Move System Actions == System actions on the main controlpanel screen is a control, which will not be used very often. Let's make it a separate UI module. == Status into header == The status control in controlpanel is taking a lot of space and distracts from the module links/icons. Let's make it as small as possible (icons only or just a short text) and move it to the header. == Reuse status and updates == Display the old status (and updates) information immediately and exchange it for the new one when the new one is loaded. Don't use the waiting animations, they make the user wait and he should not be kept waiting in this situation. The ajax must not block the other use of the page, of course. == Categories of modules == By making the list of modules the main (only) part of the controlpanel page, we can use this to separate the modules into several categories (system, networking, users & groups, webyast settings, ...). == Show only usable modules == Currently an icon for module is shown the same way whether the user has permission to work with it or not. Let's hide (or display differently) those, which the user doesn't have full permissions for. == Speed up == Currently too many http requests to webyast-WS happen before a single page is displayed. Page loads are very slow. Josef (jreidinger) offered himself to work on this issue. == Send js and css together == We have many separate js and css files. Let's implement some system (or process) to collects them and send them in a single request. == Get rid of jquery styles == Currently we use many css files, but most of the useful definitions are in a few of them. For example we don't use much of the original jquery styles. Let's redefine what is left and use only our styles. Let's also gather them into 1 file using sass. == Remake selection controls == Our selection controls in Firewall, Users and Groups module uses 2 separate lists of items. User can click the items to switch between the 2 lists (selected items/unselected items). The original motivation was to have the selected items easily distinguished from the unselected items. But the 2 lists change often (layout moves) and the movements are confusing. Let's use a non- moving list of checkboxes with labels. Labels of checked checkboxes will be highlighted, so the user can quickly overview, which items are selected. == Popup notes == Let's start to use popup notes to give user more information when he hovers over a control. Let's use it in controlpanel for each module icon, in selection controls to say, what's going to happen, in navigation buttons to say, what's going to be saved or lost. Let's give user this additional information in a way which doesn't clutter the page. == You can change this later == When using Studio, I really liked that I was informed that the name of appliance was not fixed (and could be changed later). We should tell the user during Firstboot (basesystem setup) that the chosen values can be changed later. == Headline whitespace == We use too much whitespace around our module headlines (those with the module icon). We can move the whole headline into header, or just save the space around it. == Show unsaved changes == The user can forget or not feel the need to save his changes. This can happen in a multi-tab form for example. We should inform the user that he is leaving some changes unsaved. We can do it by giving a special highlight to the Save button (with a corresponding popup note) when user makes the first change. We can treat the Back link in a similar way. == Use headline as breadcrumbs == In some modules there are more than 1 page and the user often wants to go to the root page of the module. The Back link in navigation buttons can be at the bottom of the page (which means scrolling). Let's use the module headline as breadcrumbs - by clicking pieces of the headline user can go up in the module. == Highlight active controls == Whenever some control is changeable, it should react on hover. This applies particularly to accordions. == Reduce the frames == There are many border frames on a single page. Let's reduce it (ultimately to 0). There is no need to have them other that they sometimes look nice. == All status graphs at once == To get a specific status information it takes several clicks with long page/partial loads between them. An 1 page overview of all status graphs would be really helpful. The graphs would have to be returned fast. This calls for asynchronous generation of the status data. Let's generate them regularly, show user the old ones immediately and then exchange them when the new ones are generated. == Separate logs view == System logs does not fit well with the other parts of status. They should be viewed separately. Either in a different tab or in a different UI module. == Waiting animations == Use of waiting/hourglass animations is inconsistent between webyast modules. Let's unify it in a similar way to how we prevent Submit button doubleclick. Congratulations if you actually read all this list. We really think these changes are important. After some brief discussion, I'll file individual bugreports for all the items. Please comment! Martin Kudlvasr -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
participants (5)
-
Jiří Suchomel
-
Josef Reidinger
-
Klaus Kaempf
-
Martin Kudlvasr
-
Vladislav Gorobets