Comments on: WebYaST Status Module https://lizards.opensuse.org/2009/12/15/2827/ Blogs and Ramblings of the openSUSE Members Fri, 06 Mar 2020 17:50:09 +0000 hourly 1 By: Josef Reidinger https://lizards.opensuse.org/2009/12/15/2827/#comment-1400 Fri, 18 Dec 2009 12:23:34 +0000 http://lizards.opensuse.org/?p=2827#comment-1400 Hi, I personally prefer hiding of options instead using tabs. If user starts with configuration and see that there is four tabs he could be scared. If he see easy to understand general settings and three details link (which show details on request ( using +/- to show/hide)) then he know what is important to set and what is just for experts. (just my opinion as non-usability-expert)

]]>
By: Martin Schmidkunz https://lizards.opensuse.org/2009/12/15/2827/#comment-1399 Thu, 17 Dec 2009 14:02:50 +0000 http://lizards.opensuse.org/?p=2827#comment-1399 Thanks for bringing up this topic!

As discussed my proposals are:
For the overview of system status
The main idea was to show an overview of system component status (e.g. CPU) indicated e.g. by a green dot (or something)
After clicking on the section an accordion opens with detailled information and a graph.

The limits are edited via >Settings. The settings are organized in tabs.
The user selects
and
For system specific limits the user selects whether he wants to be informed if a certain value is either undercut or exceeded.

]]>
By: Garrett LeSage https://lizards.opensuse.org/2009/12/15/2827/#comment-1398 Tue, 15 Dec 2009 13:40:45 +0000 http://lizards.opensuse.org/?p=2827#comment-1398 Hi Stefan,

It’s great that you’re looking into changing the status information page of webyast!

However, you should think about presenting the most important information quickly and clearly. It’s far more important than configurability.

Taking as much information as possible, throwing it at a person using your software, and forcing them to decide what to do is a HUGE disservice to the person who uses the software. As developers, we need to do the hard work of thinking of what is important, and presenting it in a nice, coherent, understandable way.

In addition, adding configurability means adding much more complication, including odd interactions, and more code to support.

Of course, at some point in time, some ability to customize the view may be nice, but it could possibly be integrated, or might scale with what other options are selected in webyast. (Such as seeing webserver health only if a webserver is installed and configured, for example.)

Errors, warnings, and notifications should take center stage. They should be the first thing you see, at the top. If there’s a problem with the system, or there is some vital information, you need to know what it is. There should also be some way to easily fix the error too — it would be best if it was a one-click option to fix the issue, but even providing human-friendly text about what is going on and a link to easy-to-read documentation on how to fix it would be decent.

Charts and graphs are nice, but there shouldn’t be too many, for a few different reasons: First of all, they add clutter to the page, making it harder to find a tiny needle of important information in a huge haystack of information noise. Secondly, since this is browser based, it’s important to note that you should consider certain browsers which will take a performance hit by having so many rich graph elements on one page. (Sure there are ways to optimize, and designs shouldn’t necessarily be limited by technical issues, but should drive solutions… but the reality is that if you’re supporting Internet Explorer, it’s a known issue. Again, there are some workarounds, but since the easy solution (have fewer graphs in total, such as combining multiple CPU cores into one graph instead of one per core) would help out with performance AND understandability… it’s a clear win.)

Also consider the colors. You should use pleasing colors (such as the Tango palette), and make sure you test it with colorblind people too.

Overall, remember that there is a TON of information you can show here — but you have to ask yourself, “What is the goal of this page?” Simply put, the goal is to have a clear overview of the most important, relevant system events. Anything that doesn’t fit into that goal (such as if it is not actually useful information, or the configuration of mountains of amounts of data, as shown in the screenshots) should not be part of the interface. Often, I find it helpful to step away from the computer and do things like think about the interface, brainstorm, take notes, talk with others, and try to really think about the problems. It’s fine to sketch out the important parts on paper; you can make a really rough outline of the important information, and feel free to make many sketches… You can use the sketches to talk with others to find out what they think too. (And you can even sketch with others as well.) Iterating with quick sketches on paper is almost always quicker & easier than doing it in code.

Simplicity has many benefits. Not only does it make things easier to understand for those using the software, it makes it easier to develop, test, bugfix, and maintain. It also allows you to spend more time on making sure the implementation is good and solid.

I’m really happy that you are excited about making webyast better. It’s also good that you’re looking for help to improve it. I hope that this input that I’ve provided has been insightful in some way. Webyast has a really promising future, and I think we’re all looking forward to it! Thanks for all your effort in helping to build it. (:

]]>
By: Josef Reidinger https://lizards.opensuse.org/2009/12/15/2827/#comment-1397 Tue, 15 Dec 2009 13:22:28 +0000 http://lizards.opensuse.org/?p=2827#comment-1397 If I have server (or appliance which is used as server) then I want to see disc usage, peeks in memory and CPU (to see if new memory is required or when schedule regular tasks), statisics about used software (I know that it is hard…e.g. database, apache etc) (I am not admin, so I don’t know what is interesting thing in that statictics).
so to summary:
disc usage – showed graph is good
cpu and memory peeks – showed graph is good, but maybe more scaling should be available (to see changes during one day, one week and maybe also during one year)
software statistics – no idea how it should look like (at least a downtime or average response should be good)
hardware vitality – don’t show by default, but if go near critical value show it ( e.g. if you have 4disc raid and one disc fail, or if SMART report problem, or critical temperature etc.)..but don’t show status by default – you don’t care if everything work as expected 😉

]]>
By: Stefan Schubert https://lizards.opensuse.org/2009/12/15/2827/#comment-1396 Tue, 15 Dec 2009 13:02:49 +0000 http://lizards.opensuse.org/?p=2827#comment-1396 Thanks for the reply. But more interesting would be which data has to be shown in the graphs (CPU, DF,…) and how this data should be shown.
Do you have some opinions here too ?
The configuration is more or less a second issue. Thats my fault I should have made this more clear.

]]>
By: Josef Reidinger https://lizards.opensuse.org/2009/12/15/2827/#comment-1395 Tue, 15 Dec 2009 12:36:01 +0000 http://lizards.opensuse.org/?p=2827#comment-1395 Hi, few notes (just how I see it).

1) try avoid showing implementation details or unnecessary details this is:
a) showed timeframe – it is not clear for me, if this mean how often check system or how much data is shown in graph ( of course I know right answer, but it is confusing)
b) Y-axis-legend – too much technical, I think that it doesn’t change units, so simple checkbox show axis units is enough
c) Y-axis-scale – again too much technical or mathematics. simple values range is enough (and allow easy to enable automatic range, which is what almost everyone want)
d) limits part is completely confusing – Status path – who care about collectd path? I think it need some user friendly transformation like “free space on disc-schubi”. Missing units at minimal and maximal value (also helper to specify easy big values should be useful). Legend row is confusing for me, what legend it is and also initial values doesn’t look like good one for me (better is same as I recommend in status path replace). Color is which color? Also cumulative value looks little magic for me. I also don’t understand what mean row graphic? What happen if I specify cpu usage for free space on schubi? that lead to second note.

2) try decrease complexity of configuration. If this whole page is showed to me I can choose two things – read manual or go away, because it is too complex. I recommend to have each part hidden except general. So when page is open you have simple three options and if you want more tune status, then you can click on tittle and finer tunning is showed. Also show only reasonable options. Less options is better 😉

3) icon for delete is not sufficient. I think that simple red X is better.

4) instead combobox of names of color place few squares in line and click on square with color choose color, it is more user friendly.

It improves status page, but there is still space to improve it.

]]>