Mailinglist Archive: yast-devel (34 mails)

< Previous Next >
Re: [yast-devel] On WebYaST design
  • From: Josef Reidinger <jreidinger@xxxxxxx>
  • Date: Wed, 30 Jun 2010 16:19:44 +0200
  • Message-id: <201006301619.44628.jreidinger@xxxxxxx>
Martin Kudlvasr write:
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.

My idea is to have configuration for such thing and when you build appliance in
studio with webyast, studio automatic replace string with studio name of
appliance during build.



== 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.

Agree, but put it in separate sass file so we can easily recognize which
changes is just for appliances release.


== 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.

I personally instead of displaying old status prefer at first look how we can
speed up status., so we get actual status.


== 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, ...).


agree

== 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.

No full permission but at least read permissions.


== 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.

see my another mail.



== 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.

there is tools to decrease size of js and to put it in one file. Also sass
should know it. In general it takes around 0.3 second for each file when I try
it (of course it is then cached in browser, but first load makes bad impact if
it is too slow).


== 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.

agree. or create more then one sass, but split it to logical parts.


== 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.

agree


== 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


--
Josef Reidinger
YaST team
maintainer of perl-Bootloader, YaST2-Repair, parts of webyast
--
To unsubscribe, e-mail: yast-devel+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: yast-devel+help@xxxxxxxxxxxx

< Previous Next >
List Navigation
References