Experiments with record listings / action links improvements - part 2

Publicat
2009-03-19 14:23
Written by
Dave Greenberg - member of the CiviCRM community - view blog guidelines
There are many places in CiviCRM where lists of records are presented... when you search for contacts, you get a list of contact records; when you go to manage events, you get a list of events; etc. Kurund blogged recently about prototypes for improving usability for these record listings (we call them "selectors" internally)... and we got a lot of good feedback from that post. Kurund and Amit on our team have now put up another iteration - which we'd love to have folks look at and comment on: » Contact Listing The new version incorporates these changes: * The listing now has "sticky column headers" - so when you scroll down the page "past the fold", the column header moves down with you. This feature seems like a no-brainer good thing to do - so the plan is to use that for all listings. * Context menu "actions" are now accessed BOTH via right click anywhere on the row AND via clicking the "more actions" link on the right side of each row. We're still wavering on whether over-riding 'normal' right-click browser behavior is legitimate for this - but thought we have folks test out both approaches. Right now only the new shortcut actions are included - "Record Contribution", Register for Event", etc. We're thinking of adding in any actions from the ' more actions ' dropdown which would also make sense at the row level. For example: Add to Group, Send Email, etc. However, that will make for a very long list. :-( There was another suggestion to use the "Gmail model", where all actions are only selected from the drop-down at the top of the page. This is pretty much what we have now - except all action links would be removed from the rows. If you want to act on a single row, you "check" it and then pick the action above. This seems fine in Gmail - but not sure it's right for Civi .... ??
Filed under

Comments

This is great news Dave! Both of those features are very handy!

I think in the world of Web 2.0 web-apps, you no longer need worry about "normal" right-click behaviour within the area of the window that is clearly part of the application rather than just a web page.

I think having the "Gmail model" actions at the top is still important for accessibility, as I am not sure how well some of these newer functionalities translate to screen readers.

Andrew

1) The action area is now too big to fit on my screen, so the lines are twice as hight, loosing valuable space and defying the purpose.

2) You should add the Edit as the first action, that's likely the one most commonly used, so you don't have to reach the right action column

I think focusing on usability is an excellent idea. It's been CiviCRM's most serious shortcoming up to this point.

However I think accessibility has to remain in our minds. We can't sacrifice accessibility of the few for usability of the majority.

About the right-click, I think it's a bad idea to override the browser menu. Doing so means that the user can't cut / copy / paste / open in a new tab/window or whatever other menu customizations that they need.

I've also got a screengrab with several other annotations here:
http://communit.ca/civcrm_selectors.png

I acknowledge that there are some right click features that would ideally be maintained, like open in a new tab, but I don't think that should prevent the traditional right click being replaced with a custom option.

The scrolling headers didn't scroll in Safari. They split into three as they neared the top of the window and then disappeared. Worked fine in Firefox though. Good idea!

I often view a single contact via "open in another tab" if I plan to use the search results to do that more than once - it's faster than re-executing the query.

I like where this UI is going, but I share concerns about choosing which actions to expose: there are a lot of things that users might do. It's hard to choose an optimal list of actions without knowing the use-case/end-user better.

The profile (ufgroup) mechanism is an interesting model. An administrator can currently define a new profile, flag it for use in "Search Results", and then hand-pick the list of columns (fields). Similarly, an administrator might hand-pick a list of actions.

Another possibility -- in the style of hook_civicrm_searchTasks, create a hook_civcrm_searchRowTasks which allows implementers to customize the list of actions displayed on each row. Implementers might add logic like: "If the current user has role 'Fundraising Volunteer', then display the "Add Contribution" action by default."

It is not clear what screen width is the minimum screen width. With FireFox 3, sometimes the search button is off the screen to the right without a scroll bar. I recommend that a minimum screen width functionality be 1024 x 768 or at least have an option to accommodate that a certain screen width.