Groups web interface: five simple suggestions for improvement
The user design of the Groups web interface is still underspecified and could be much improved. Here are some suggestions.
"Latest additions" on the Group's homepage is a nice idea, but if it lists attachments and top level items indiscriminately (as it still does) it is useless and messy.
Proposal: show only top level items in latest additions.
On that same page, the three columns Title, Added by, and Date all link to the same page. "Title" should naturally be a link. "Added by" should probably link to the user's profile if anywhere. "Date" doesn't need to be linked, unless the link would have to do something with the date specifically (such as displaying all items added around that time, which might not be useless).
Proposal: link only titles, and if you must link "added by", make the link go to the user profile.
There would be more useful things that could be listed on the the Group homepage. Basic stats like number of items and percentage that have attachments. A list of (top level) collections. Possibly a tag cloud (though given the persistent problem with personal and workflow tags being included I would advise against it until group tags are really group tags).
Proposal: Add basic stats: total items, % of total that has PDF attachments. Add a pretty list of collections.
On Group library pages, if you choose to display the "Added by" column, it has the same problem: the links in that column don't point to user profiles but (redundantly) to the item. Why?
Proposal: link to user profile.
A general annoyance to do with web libraries (personal and group) is the fact that attachment metadata is given more prominence than the attachment itself. You click on the title of a PDF and you think you're opening the PDF, but instead you go to a page of useless metadata about the PDF and you have to look for a link to the PDF. Going back, you see the link was there, but not at all prominent.
Proposal: make attachment links go where users expect them to go: directly to the attachment itself. For the few gnomes that want to study the attachment metadata, add "(metadata)".
"Latest additions" on the Group's homepage is a nice idea, but if it lists attachments and top level items indiscriminately (as it still does) it is useless and messy.
Proposal: show only top level items in latest additions.
On that same page, the three columns Title, Added by, and Date all link to the same page. "Title" should naturally be a link. "Added by" should probably link to the user's profile if anywhere. "Date" doesn't need to be linked, unless the link would have to do something with the date specifically (such as displaying all items added around that time, which might not be useless).
Proposal: link only titles, and if you must link "added by", make the link go to the user profile.
There would be more useful things that could be listed on the the Group homepage. Basic stats like number of items and percentage that have attachments. A list of (top level) collections. Possibly a tag cloud (though given the persistent problem with personal and workflow tags being included I would advise against it until group tags are really group tags).
Proposal: Add basic stats: total items, % of total that has PDF attachments. Add a pretty list of collections.
On Group library pages, if you choose to display the "Added by" column, it has the same problem: the links in that column don't point to user profiles but (redundantly) to the item. Why?
Proposal: link to user profile.
A general annoyance to do with web libraries (personal and group) is the fact that attachment metadata is given more prominence than the attachment itself. You click on the title of a PDF and you think you're opening the PDF, but instead you go to a page of useless metadata about the PDF and you have to look for a link to the PDF. Going back, you see the link was there, but not at all prominent.
Proposal: make attachment links go where users expect them to go: directly to the attachment itself. For the few gnomes that want to study the attachment metadata, add "(metadata)".
2. the recent items widget was just a modified piece of the library and was intended to behave the same way. That means mimicking the client as closely as possible, so the whole row should actually the click target, and only be links to fall back if javascript is disabled. Obviously that's not happening, and again the need for it may be obsolete by now with your proposed behaviour being more desirable.
3. These would be nice to have, but at the moment the only one that is easy to get is total items. The pretty list of collections is obviously also available, but can take several requests to fill out, so I'm not sure it's worth the loading time. We could of course cache those closer to the website, but I suspect that would cause many more problems than it's worth.
I can't say for sure, but more aggregated statistics may be doable in the nearish future.
4. Same as #2, but this is where the entire row is in fact the click target and mimicking the client, so I think leaving it as is makes sense.
5. That change is in place and will roll out with the next website update.
With that in mind, consider the following: the logic of the client (an entire row is a link) is adapted to the reality of the three-pane design of the local client. A click on the row brings up metadata on the right while the item list remains in sight. The web doesn't work like that: people are used to opening things in new tabs and expect different linked pieces of information to lead to different places. And especially when the pieces are not only informationally different but also visually presented as distinct, it runs counter good UI design practices to point them to the same place.
Regarding the more specific points:
#1: What are your sources for getting this kind of information and when do you allow yourself to be overruled? Considering that we know that the bulk of users won't speak their mind here on the forums, it seems important to have reliable ways of identifying how people work with the Groups web interface. I am reporting not just for myself by the way but also for colleagues who have expressed some mystification about that page and generally avoid it.
Also, the fact that you're torn by it doesn't mean that if you include both, they should look the same (as they do now). I have often noticed that the web interface is very underspecified when it comes to distinguishing types of information that are in fact very different both conceptually and in the way users handle them. That contributes to the feeling of "underdesignedness". But anyway, my position is that only top-level items should be listed on this home-page. A separate way to keep track of recent "notes" activity would be cool, but I think "notes" activity and "recently added items" are two very distinct things worth keeping separate.
#2, #4: Why a linked "added by", which identifies a user account, should ever be anything else than a link to that user's profile, is mysterious to me.
#3: Well, anything that's easy to get is already an improvement. Right now the page is underdesigned and not information-rich -- very much unexpected for a page that is the number one place where users end up when they (1) double-click group name in their library or (2) search for groups. Right now sending them straight to the library would be more useful (I see people doing that all the time, indicating that the homepage is experienced as a stumbling block rather than a helpful first stop).
#5: Great!
The same holds for the giant table that is the library display: the title TD is at least given the item type, but Author, Year and Added By are not given their own CSS classes, placing them effectively out of reach of styling.)
The logic of the website library is the same as that of the client. Clicking a row brings up the full metadata for that item. In most cases it should happen nearly instantaneously. The table doesn't stay in view, but it maintains its state (and the page keeps all the library data it has loaded). The styling of the table is also intended to indicate that the entire row of data is the clickable element. The only reason the text is linked at all is semantic. You have brought to my attention that usernames are not linked to profiles in the item details, which I think was just an oversight on my part and will be fixed.
Note that this doesn't apply to the usernames on the recently added listing. I only said it was the same as the library interface to explain the current state, not argue that it needed to stay that way.
The idea of separating notes activity is interesting, but I'm not sure yet what that might look like in a way that accomodates the many different ways people use notes. It may be that a simple list of most recently modified notes (with indication of parents?) would be sufficient.
In any case, the group page is definitely less useful (and uglier, as it was not given as much attention as it deserves during the last redesign) than it could be. If you have more ideas for what you would find useful on there please do throw more suggestions out and we can see about how feasible they are.
(Nightmarish example which cost me a lot of time: my UI proposal for a better date field, which despite drawing agreement from key people devolved into a messy discussion about minor details. Ultimately nothing happened and we're still stuck with a fantastically inconsistent date field which is misunderstood and/or misparsed by most users.
And another example: my reasonably well thought-out proposal for better roles for group libraries), which didn't manage to attract contentful comments from devs. Sorry to be spamming my own proposals here but that's what the forums are for right? User questions and suggestions.)