Kun, This is how we have solved it in past:
- On mouseover of the individual row, we display actions. - In addition there is a shortcut for edit - doubleclick - Multiple rows can be selected by just clicking on them , all shortcuts are supported - Ctrl + Click, Shif + Click - something like http://extjs.com/deploy/dev/examples/grid/xml-grid.html As multiple rows are selected, the actions appear on the last row - Right Click Menu and keyboard shortcut for each actions is also supported Please note, our entire application works this way.. - AJ On Feb 27, 2008, at 11:27 AM, Ma, Kun wrote: > Has anyone read or discussed about design patterns for selecting and/ > or > interact a record row in a table or list? I'm working on a project > that > a user needs to interact with single record (edit/view and delete) > in a > table most of the time. However once we get into the discussion of > interaction consistency, it gets more complicated. I would like to > know > if anyone has done any research in this area. > > We can generally categorize the interaction into 3 types: > > Case 1: A user needs to manipulate each record/row one at a time. The > action is limited to one thing (two at most) only. For example, a user > will select a row in master table to view/edit it in a detail panel. > In > our case, we have "edit" (or view depend on the status of the record > if > it is still editable) and "delete" actions. We are discussing a few > approaches: > a) a user can click anywhere on a row to view or edit the detail, a > trash can icon will be available on the same row for deleting the > record. The drawback for this option is that there's no direct link or > button to spell out "edit" action even though we can provide mouse > over > highlight to hint the rows can be clicked on. In our field studies and > usability tests, we have found that sometimes users didn't get the > clue > that they could interact with the grid. > b) provide edit/view and delete links on each row. The drawback for > this > approach is that some users may get used to click on the row from > other > application experience and expect the same here and also edit and > delete > links take more pixel real estate than option a. > > Case 2: A user needs to manipulate each record/row one at a time. > There > are more actions can be done for each record. Design approaches for > this > case are: > a) similar to option b in case 1, provide action icons/links on each > row. Other than the links, the row is not clickable. Links can take > too > much space in this case. > b) provide links on each row as option a, but the row is clickable as > well. In this case, a single click on anywhere on a row and load > detail > record immediately in detail panel can be problematic and slow down > performance. > c) Since there are more actions now, each row can get cluttered with > action icons/links, so move the actions to a top action bar may make > sense which is similar to outlook. The drawback on this approach is > that > each action takes two clicks now, select the row first, then click on > the action button. This approach makes more sense for aggregated or > batch editing as in the following case 3. > > Case 3: A user needs to do mass edit to multiple records at a time in > the grid. The solution seem to be more unified in this case: provide > checkbox on each row and allow user to select multiple items then > perform actions by click on actions on top or bottom of the grid. > > So is there a magic formula that provides intuitive yet consistent > user > experience for all 3 cases? Should the whole row be clickable? When > provide action buttons on each row, which way is better practice: to > put > the buttons on the far right or far left of the table? Will it cause > confusion if action buttons are on top for mass edit grid and then on > each row for other cases? > > By the way, lots of our end users are novice computer users, they > don't > use outlook or surf on web. And yes we are going to do usability test > eventually on this, but for this project we don't have time and budget > to do it with end users now, so I'm asking you interaction guru's > opinion now. J > > Thanks, > Kun > > > This e-mail is confidential and is intended solely for the use of > the addressee(s). Opinions expressed are solely those of the author > and may not be those of RedPrairie. Content is not to be relied upon > by any person other than the addressee(s), without prior written > approval of RedPrairie. If you are not the intended recipient, > please notify us immediately, destroy any copies and delete from > your computer systems. > If you have received this e-mail in error, any use, disclosure, > dissemination, forwarding, printing or copying is strictly prohibited. > Although this email and any attachments are believed to be free of > any virus or other defects which might affect any computer or IT > system into which they are received, no responsibility is accepted > by RedPrairie for any loss or damage arising in any way from the > receipt or use therein. > ________________________________________________________________ > Welcome to the Interaction Design Association (IxDA)! > To post to this list ....... [EMAIL PROTECTED] > Unsubscribe ................ http://www.ixda.org/unsubscribe > List Guidelines ............ http://www.ixda.org/guidelines > List Help .................. http://www.ixda.org/help ________________________________________________________________ Welcome to the Interaction Design Association (IxDA)! To post to this list ....... [EMAIL PROTECTED] Unsubscribe ................ http://www.ixda.org/unsubscribe List Guidelines ............ http://www.ixda.org/guidelines List Help .................. http://www.ixda.org/help
