[rfc][icedtea-web][itweb-settings] Improve Icedtea-Web cache disk space

[Jie Kang]

Hello,

My two cents:

In terms of this particular patch I believe that compared to hiding/showing UI elements, disabling UI elements is slightly more user-friendly and much more developer-friendly (in regards to Swing and Java). There are numerous other tasks that need to be done and I think we should consider pushing a working version of this improvement quickly, and then updating over that if necessary.

In regards to UI design philosophy and KISS (keep it simple stupid), I think we can argue over it all day long but rather than point to basic design guidelines or philosophies (since it all comes down to opinion), I think there are some simple rules that we can state and agree on such as, but not limited to:

UI must work : There are a set of actions that can be performed and the UI must support these actions.
UI must be simple : There are a set of actions that must be supported and the UI should support said actions with minimal effort on the part of the developer in creating this support, and on the user in accessing these actions.

When it comes to minimal effort for the user, hiding/showing versus disabling to me is a neutral difference. It is not harder for the user to perform all actions when UI is shown/hidden based on when an action can be performed, but it is also not harder for the user to perform all actions when the UI is disabled/enabled based on when an action can be performed. However I think that hidden UI is more difficult for a user to learn about than disabled UI which is why I prefer enabling/disabling if necessary.


Regards,


----- Original Message -----
> I'll wait for a hidding patch then.
> 
> On Wed, Sep 3, 2014 at 3:41 PM, Jacob Wisor <gitne at gmx.de> wrote:
> 
> > On 09/01/2014 at 02:59 PM, helpcrypto helpcrypto wrote:
> >
> >> On Sat, Aug 30, 2014 at 9:44 AM, Jacob Wisor <gitne at gmx.de> wrote:
> >>
> >>  No no, do not start playing around with visible and hidden UI components.
> >>> It is even worse when they change their layout or start jumping around
> >>> like
> >>> it is now. Generally, there is never any need to hide UI components. If
> >>> there seems to be, then either there is something wrong with the basic
> >>> design of a window or dialog, or you should have very good reasons to do
> >>> so. And, in this case there is surely *no* reason to hide any components
> >>> dynamically at all. Again, stick to disabling components. This should be
> >>> enough.
> >>>
> >>> @helpcrypto
> >>> Yes, it is against basic UI design principles to have hiding UI
> >>> components, unless there are really good reasons to do so.
> >>>
> >>
> >> Can you point a style guide, or a gui-best-practices which advices on
> >> that?
> >>
> >
> > Well, there are multiple guidelines available, depending on OS, window
> > managers and/or desktop managers. It is difficult to point to a specific
> > one in the case of SWT and Java because it is platform independent. But, I
> > suppose one could take Microsoft's UI guidelines as a basis because of it's
> > undeniable bread adoption. It also shares a large set of rules with other
> > UI guidelines form other vendors.
> >
> >
> >  I have seen several GUIs wich only show the user what he needs to see, and
> >> I found them KISS-compliant
> >>
> >
> > I think you are mixing to concepts here. KISS is about technical
> > solutions, that is how things should be solved in order for other engineers
> > to comprehend the work of the original authors, and generally assumes that
> > simple technical solutions are usually the most effective or efficient
> > ones.
> >
> > UI design guidelines employ a similar concept but not exactly KISS. Good
> > UI designs should not be overloaded with UI components and only display the
> > right amount of components required to accomplish the current task at hand.
> > Hence, users should not be overburdened with overloaded UIs. But, most
> > importantly UIs must not be confusing to users, and their behavior must be
> > intuitively and naturally predictable. Hiding and jumping UI controls feel
> > absolutely unnatural and inorganic. This is indeed bad behavior for UI
> > controls.
> >
> > I will give you a simple example why your way of thinking is flawed here.
> > Take for example a dialog with a list view and an edit button to edit the
> > list view items. Now, if no list view item would be selected then according
> > to your reasoning the edit button should be hidden because the user can
> > take no editing action while no list view item is selected. This is
> > absolutely confusing to the user. The user is supposed to be able to see
> > and know all the possible actions he can take at all times but should not
> > be able to take invalid actions. This is why the edit button in this
> > example has to stay always visible but not always enabled. Think about it.
> > ;-)
> >
> >  Unfortunately, because of your attempt to play around with hiding UI
> >>> components you have introduced a new bug. When "Limit cache size" is
> >>> checked and the spinner is 0 then all components for setting up the cache
> >>> location suddenly disappear.
> >>>
> >>
> >> Limit checked, value=0->no cache, hence no need of location, compression
> >>
> >> level or anything. It's not a bug.
> >> The warning under spinner informs about that.
> >>
> >
> > This is logically correct but it is against basic UI design guidelines. It
> > is inorganic.
> >
> >
> >  And, as soon as the value becomes greater than 1, they become visible
> >>> again. This is very odd, weird, and confusing. Again, do not play around
> >>> with hiding UI components.
> >>>
> >>>  The reason why i suggested "no caché" instead of 0.
> >>
> >
> > As mentioned before, the UI components handling the cache's location
> > should simply be disabled in this case. No real reason to hide them.
> >
> > Jacob
> >
> 

-- 

Jie Kang