Usability problem: inherited options

[rejetto]

This is something i'm writing for my thesis for graduating.
I'd like you folks to comment the thing and/or propose your solutions.

We have this nice file system, and it is hierarchic: we have folders, in folders, in folders, etc.

When i set an option on a folder, there is always a problem: will this option  be applied to this folder only or also to things inside it?

Options that are applied not only to the folder but also to all things that are inside that folder, are often called recursive, or heritable.

This may seem simple to someone, but it is very controversial and non-intuitive.

I see 4 usability problems for the user

Problem#1
understanding if the option you are setting is recursive or not.

Example#1
if i set a comment, it is only applied to the folder.
if i set user/pass, it is applied also to files in the folder.
it may need some experiment before i realize this, nothing in the GUI tells it.

Problem#2
know what options are actually operating on a file/folder.

Example#2
if i set a customized realm on the folder, when i move the mouse over it, a tip tells me the realm. But the realm is applied also to files in the folder, and the tip doesn't tell me about the realm for those files.

Problem#3
after you solved problem#2, distinguish options set locally and options inherited by an ancestor.

Example#3
using the "hide tree" on a folder, the folder gets hidden but also the file in it. If one of those files has its own "hide tree" option set, i will see no difference with other files. The only way is to go moving the options, so i will see the check mark.

Problem#4
understand how the option you are setting will behave added to inherited values for the same option.

Example#4
i set a default file mask for the root: index.html
then i set a default file mask for a folder: default.html
Will the folder accept only default.html as default file, or both default.html and index.hmtl ?

[rejetto]

here goes some proposal

Solution#1 for Problem#1
Append a label (recursive) to all recursive options.

Solution#2 for Problems#2
The tip for file/folder should show all options actually operating. Both inherited and local.

Solution#3 for Problem#3
The tip should show a label (inherited) for all options inherited by an ancestor. No label for options set locally.

[~GeeS~]

Finally, rejetto, the fundamental question:
Usability vs. Options or Design: What is wisdom ?
Before i try to comment on your questions or even give some valid answers, there should agreement on some definitions and prerequisits. Some of them are trivial, but others could have impact on possible solutions.
Definitions:
File system: it is hierarchic: we have folders, in folders, in folders, etc. Root is the begin folder.  Folders can contain items (files, links etc.)    
HFS admin: the user(group) of HFS who can build a folder/item tree for the HFS server using all options available in HFS.
Usability: refers to the usability of options for the HFS admin.
Client: the browser/application which puts request to the HFS server from localhost, LAN or the internet on behalf of a local/remote user
...
Prerequisites:  
1. The file system is strictly hierarchical for both virtual and real folders.
2. In case of options logical and intuitive defaults for all folders and files have to be defined.
3. The HFS admin only decides which options apply to all folders and/or files and what is served.
4. Clients never can change the authorization applied by the HFS admin for folders and files.
5. Clients never can change options applied by the HFS admin on the file system.
6. No exceptions.
...  
With this rule set an HFS admin should be able to construct a secure hfs server. (This is just a quick first shot, to be completed!)

But what is the relation with usability for the HFS admin or inherited properties on folders and files? Take example 4#:

Problem#4
understand how the option you are setting will behave added to inherited values for the same option.
Example#4
i set a default file mask for the root: index.html then i set a default file mask for a folder: default.html
Will the folder accept only default.html as default file, or both default.html and index.hmtl ?

Without definitions and prerequisites, problem and example 4# could lead to an indefinite discussion, so back to basics:
A filesystem by default displays all items and folders in a certain folder. That's intuitive, logical and easy to remember.
In order to display webpages, it's common practise (or rule?), that if and only if a file called "index.html" is present in a folder, the index.html file will be served instead of the content of the folder. Still logical, intuitive and easy to remember. A default "switch" for serving files or webpages.
But HFS can do more: instead of using "index.html", the HFS admin is allowed to choose any name for this default htmlpage: Any_file_inclusive_index.html with the "Default file" menu option.
Before i will give an answer to question 4#, i want to put another question before:
Do we really need all possible combinations? Why should we have different default files anyway or what is the real added value which would justify the additional effort in programming and a higher chance for misconfigurations by the HFS admin?
My answer to your example 4# is easy now:
index.html is the default, which can be overruled with the option, but apply it to all folders (recursive). It's simpler, more intuitive, logic and also increases usability, and -imho- non-controversial.

Note: Independently which approach is finally chosen, there's another issue with this index.html or default.html: An upload-enabled folder  will accept default.html and after upload switch the file system to webpage view. Because this is not intended and caused by the client, all upload enabled folders have to be disabled for the "Default file" option.  
 
Conclusion: Carefully chosen rules for design and cutting away some "fat" from the set of all possible combinations of options can avoid dilemmas and improve usability without loosing functionality. Even more, running the rules like a kind of checklist and asking which workarounds could clients apply, may reveal unrecognized incompatibilities like f.e. the upload of default.html.

Here is another example

Problem#5 (rejetto's problem#1, but with modified example#5)
understanding if the option you are setting is recursive or not.
Example#5
a) if i define users in the menu -> "Other options..." -> "Users ..." and then set "Restrict access to ..." , it is applied to the folder and all items in the folder.
b) if i "Set user/pass...", it is applied also to files in the folder.
c) if i apply both above methods a) and/or b) only to a file in a folder, only this file is protected. With method a) i can see the applied protection in the options user tab page, users added with method b) are not shown there.

I could not find the reason for having two different options for access restrictions and because authorization is about the crucial module of any server -security or access control to resources- i want to discuss this in some more detail.
Again, back to the basics and the prerequisites to find a solution to this problem:
First, to save some precious time, cut away the "waste": the "Set user/pass..." option b) can be discarded without loss of functionality (or convince me and show the added value).
But there is still some waste in the remaining option "Restrict access to ..."!
Why is it possible to protect individual items in a folder and keep some other items in the same folder with less restrictions, like:
Folder_ABCDE containing Subfolder_ABC & Item_AB & Item_AC & Item_B & Item_BCE & ...? (_ABCDE = Access for client A,B,C,D or E as defined in "Restrict access to ..." option) or "translated" ro real life :
Shared_Room_ABCDE containing Locker_ABC & Newspaper_AB & Magazine_B & Book_AC & ...
You cannot lock and restrict access to a newspaper or magazine, when it's in a shared room (folder), but you have to put it in a separate and locked container(restricted subfolder) in this shared room.
Ofcourse individual items have to be locked, because the filesystem is not hierarchical for access: even hierarchical filesystems allow to "fly" to an item: site/long_path/destination/item or C:\long_path\destination\file for ease of use.
An protected folder with unprotected subfolders and items, would be accessible for client X by the command URL/protected_folder_ABC/unprotected_item. Therefore all items have to inherite the protection of their folders by default. This would increase usability, is intuitive, saves alot of time not to check every individual file, and simpler without loss of functionality.
BTW, many misconfigured servers in the wild do not fulfill this reqirement and unwillingly leak information to clients.

From the above statements, a new definition/rule arises:
Definition:
Items are protected within containers (folders). An opened container (folder) does not give extra protection for an item. Root is a folder too.
Rule 7. Items are not protected individually, but the item- and subfolder-protection is always inherited from the folder they reside in.
This rule will save time: only check 1 folder instead of many individual files in the folder too. HFS admin friendly and less chances for mistakes.
 
Proposal for solution of the problem "Understanding if the option you are setting is recursive or not."
In this specific access control related case, first there should be a decision on what the default of the option is and how this options could be visualized for the HFS admin.
Logical choice would be "Nobody" at first run (fail safe state), then the HFS admin decides to give the keys of his facilities to all (Anybody) or to selected clients (Users) only.
Added new folders to an existing folder inherit their clients to the subfolder. The HFS admin can restrict from this set of inherited clients the newly created folder. Adding non-inherited clients is not possible, which complies with a strictly hierarchical filesystem.  Adding or removing folders is transparent, clients have to be added from root to the deepest  folder, so keep the "organisation" as flat as possible..  

BTW, i would like to see a more prominent location for the "User tab button", preferable next to the start/stop button. Clients are the most important part of our server: Without clients there would be no reason to start the server. Clients and their access rights should have our utmost attention. I check permissions even before i start the server.
I really like the implementation for visualization of the access control for each client in the small window. Maybe this window should have our attention for further future improvements.

Sorry for the long  :read: , but sometimes oneliners don't do the job. Maybe i've not even answered your questions or just touched them on their surface, anyway, then consider this still as a proposal.
Again: Many of the said is trivial, no critics, but to have a common base for discussion.
_______
~GeeS~