row selection and interaction in a table or list

27 Feb 2008 - 11:27am
6 years ago
2 replies
1417 reads
Anna Ma
2007

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.

Comments

27 Feb 2008 - 3:26pm
jrrogan
2005

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 <Kun.Ma at redprairie.com> 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

27 Feb 2008 - 3:36pm
AlokJain
2006

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 ....... discuss at ixda.org
> Unsubscribe ................ http://www.ixda.org/unsubscribe
> List Guidelines ............ http://www.ixda.org/guidelines
> List Help .................. http://www.ixda.org/help

Syndicate content Get the feed