Hi Kun, We are dealing with very similar issues, and have come up with some interaction idioms and general rules, and base the overall design on assumptions which need to be tested.
Certain overarching design concepts dictate a higher level of interaction, such as: Which ever way we go, keep it consistent, for usability and learnability. Keep it as simple as possible, especially with interaction, (this is where it can get problematic). Design for the target user, (our target is the somewhat computer literate intermediate user, who uses the system 1 + hour every day). Regarding your case 1 - single action on single row: We have "row onfocus" bringing up the Detail, which can then be edited, no need for "edit" links at the end of row. Regarding your case 2 - multiple actions on one row: We use top buttons like Outlook. Originally we thought of going with an underlay, which opened with row "onfocus", but as these actions would be mostly hidden, we went with making the functioanlity more obvious by displaying persistent buttons at top of grid, (note actions placed at top of grid allow more horizontal real estate for row data, then putting all actions at end of rows). With edits, we have "edits" accessible by clicking at the cell level within a row, which opens the detail. Regarding your case 3 - one or more action(s) on one or more rows: This is a tricky one. We are using check boxes with the above interaction paradymes. This brings into question, what does "onfocus" mean, when. For example, when a user is prospecting rows for which row to select, we have designed the following "onfocus" interactions of an unchecked row: A: "Clicking" on a row does NOT select the row for the multiple row actions, (does not "auto" check the check box). B: "Clicking" on an unchecked row allows standard view/edit of that row, regardless if other rows have been checked for multi select or not. C: "Clicking" on an unchecked row does NOT uncheck other rows, which had been previously been checked. Regarding "Checked" rows: A: The only way to multi select a row is to "check" the check box, (we're also looking into key board short cuts such as "shift click"). B: "Checking" a checkbox does NOT place this row onfocus, only clicking on the row, outside the checkbox puts the row "onfocus". C: "Clicking" on one "checked" row puts all checked rows "onfocus", and allows aggregate edits with this "onfocus", (note this is still contraversial, any thoughts on this are appreciated). D: To view the details of a single "checked" row, the user must "uncheck" the row then click this row for "onfocus". This is as far as we got with the "single/multiple" row selection actions. OK so that's how we're looking to design tthis, any ideas/comments are welcome, Rich On 2/27/08, Ma, Kun <[EMAIL PROTECTED]> 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. > > -- > Joseph Rich Rogan > President UX/UI Inc. > http://www.jrrogan.com ________________________________________________________________ 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
