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

[Jacob Wisor]

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