By Todd Patrick on Nov 09, 2008
Caveat: my blog is in a hurty place as of our launch date, so I'm unable to post screenshots (how unfair is that for a graphic designer?). Hopefully you get a decent view of the interface from the rest of the team's blog posts until I get my pixels back.
The task wasn't exactly straightforward: Provide easy access to an administrative control point, enabling users to group together chunks of shared storage with common attributes, without getting in the way. However, once the concept was explained to me by the engineers, I had a hard time understanding why anyone wouldn't want to make strong use of projects\*. They held an important key to scalability and efficiency, and just seemed so obviously useful. And yet, surveying the competitive landscape, this clearly wasn't an obvious solution, because no one else was doing it. Other vendors wanted to limit administrators to setting policies for each share individually (and painfully), which I suppose makes a certain amount of sense, until you scale above even a few dozen shares. One could alternatively set policy for an entire set of shares, if one size fit all.
The ability to manipulate a group of shares by simply setting the properties of their governing project is clearly a usability win for the browser UI. My hunch is that without projects, scripting such a task within the traditional gateway for batch functions (the command line) would require admins to create these groupings on their own, by naming shares with similar properties alike, and operating on them as a group (student-tmp417, faculty-spp209). Instead we make one change to that group of shares by setting the attributes of their project, and it's propagated throughout. Naturally admins need, and we allow, exceptions these rules by deselecting the default "Inherit from project" checkbox for subsets of attributes.
Now, how to stay out of the way for users who have no need for more than a few dozen shares? Again, once the design is implemented, it seems obvious: hide the interface unless and until it's needed. Of course, this isn't exactly second-nature when the objective is normally to make everything immediately obvious to the user. However we confirmed our intuition through user testing that most administrative tasks would focus first on the creation of shares, and subsequently, setting properties. We therefore allowed users to create shares without a thought to grouping: all shares would be put into the default project, and they could be characterized individually.
How then do users discover and learn this abstraction? Here the concept of progressively revealing advanced functionality comes into play. First hint: the breadcrumb title bar that reads: "Projects > default > sharename." Second hint: the aforementioned "Inherit from project" checkbox. Third hint: revealed when interacting with the Shares list. Looking at the list of all shares doesn't immediately clue users in, until they mouseover a share and see the four-arrows move icon. The user clicks on this icon, and the side panel slides out from the left margin, revealing a menu of projects that serve as drag targets for shares. When a user drags a share into this menu onto a new project, inherited properties are adopted by the share. The user can also open the panel "manually" by clicking on the title bar heading, but automatically revealing the menu when dragging a share serves to inform the user of its purpose. Abort the drag, and the panel recedes, or rather, it gets out of the user's way.
\*Nomenclature is admittedly a bit tricky in this case. The natural instinct is to call it like you see it, but "group" carries baggage from other closely-related areas (like access control permissions), and is just generic enough to be meaningless. Instead, we settled on describing how it behaves, or how we expect it might behave for a large set of users: distinguishing between activities within an organization.