Table Row Interactions and .ico files

12 Mar 2008 - 9:03am
6 years ago
10 replies
460 reads
Margeaux Mann
2008

"I'm working on an internal application where users need to add, edit,
delete and cancel rows in a table. In this case, the items are names of
salespeople, however, this pattern of adding and editing rows is used"

David,

Now knowing what kind of a product this is, who is using it, or the style you are using.
Many fun ways to design this.

You could have wheel that lights up one of the choices as the mouse passes over.
Edit could be the single choice next to the line, because you are in fact editing it.
The add, cancel, delete could be built into a circle with buttons, or a square grid with
four icon choices.
or
It could be a fun simulation of a game thumb hand held device nintendo game boy.
or ( never played? : )
it could a zillion ways to skin this cat.

Get creative. I guess "you re fired" would be kind of harsh for delete?

Margeaux Mann
Manndesign
Voice
408 439 3379

-----Original Message-----

David B. Fine

Bowne Technology Enterprise

Bowne & Co.

55 Water Street

New York, NY 10041-0006

212-924-5500

email: david.fine at bowne.com <mailto:david.fine at bowne.com>

phone: 212-658-5694

mobile: 914-671-5939

CONFIDENTIALITY NOTICE: The information in this Internet email is confidential
and may be legally privileged. It is intended solely for the addressee. Access
to this email by anyone else is unauthorized.

________________________________________________________________
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

Comments

12 Mar 2008 - 9:35am
Dennis Williams
2008

Not sure if I'm following this correctly - but there's a couple of
ways you can solve this:

Have 1 icon set at the top of the table (in the title bar - right -
almost like your windows close and minimise actions) which is
relevant to the selected row you're in.

Another option would be to reduce the icons to one icon (action icon)
from Which you can:

pop up a small window with actions once you hover over the "action"
icon.
Or..

Have one of those "more" arrows at the bottom of the icon - meaning
that once you click the more actions icon - a list of other options
appear.

The same action can be done by simply making the name of the sales
person a link which triggers the same actions as mentioned above.

This making sense? I do have an example of the first option also done
in .net - but not sure how to send it to the group.

Good luck. Don't you have a good team backing you up on the UX? I
also found that light greys work better than yellow. Use primaries on
activated rows only.

DON'T LET DEVELOPERS MAKE UX DECISIONS. I LOVE THEM WITH EVERY LAST
BONE IN MY BODY BUT THEY SIMPLY CANNOT MAKE VISUAL DECISIONS WHEN
THEIR BIGGEST CONCERNS ARE DEADLINES AND HOW TO IMPLEMENT DIFFICULT
LOGIC AND REQUIREMENTS. THEY LITERALLY THINK IN CODE - NOT IN ICONS.

Hope it helps

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=26984

12 Mar 2008 - 10:23am
Michael Micheletti
2006

On Wed, Mar 12, 2008 at 6:04 AM, Fine, David <David.Fine at bowne.com> wrote:

> PS Does anyone have any good suggestions or software for converting
> .ico to gifs?
>

Hi David,

Give IcoFX a try. It's an excellent free icon editor that can export an icon
in several different image formats. File | Export Image | Gif will do it. I
run it on Windows, not sure if there's a Mac equivalent. Obtain it here:

http://icofx.xhost.ro/

I use IcoFX mostly for packaging all the different image resolutions
together for a final .ico file. I'm more comfortable editing the original
source graphics at their various sizes in Photoshop, so I haven't spent much
time with the IcoFX editing or scaling tools. Good luck,

Michael Micheletti

12 Mar 2008 - 10:29am
Jack L. Moffett
2005

On Mar 12, 2008, at 9:04 AM, Fine, David wrote:

> Can anyone point me to some good examples where this pattern is
> implemented? I'm trying to get out of listing the four actions icons
> (add, edit, delete and cancel) next to each row.

I work with lists of editable items a lot. There are a number of
patterns you could follow, each with their own strengths and weaknesses.

1. Buttons on every row
As you have already mentioned, one option is to include all of the
relevant actions as icons/buttons on every row. The available actions
may differ based on object type or status. The benefit of doing this
is two-fold: the UI presents the available actions to the user in
direct relation to the object they will act upon, and it provides one-
click access to those actions. The problem is visual clutter. The
sheer number of icons on the screen, and the repetitiveness of them,
does not result in the most elegant UI.

2. Buttons on mouseover
This is set up the same as option 1. However, you only show the
buttons when the cursor moves over a row, so only one row shows
buttons at a time. Benefits: Removes the clutter, and highlighting
the row makes it apparent that you are acting on the correct item. It
is still single-click access. Drawback: It is not immediately
apparent that the actions are available. Once the user knows that
they are there, it shouldn't be a problem.

3. Row selection
In this pattern, the user selects a row (or multiple rows) and then
presses a button found on a toolbar above the list. Buttons should
enable and disable based on the selection. Benefits: removes screen
clutter, allows for actions on multiple items. Drawbacks: two-click
interaction, actions and items are not directly connected.

4. Checkboxes
This is similar to option 3, but easier to implement. Checkboxes are
placed in every row. Actions are provided elsewhere on the screen.
The user clicks checkboxes for items they want to act upon. Benefits:
removes screen clutter, allows for actions on multiple items.
Drawbacks: two-click interaction, actions and items are not directly
connected, doesn't completely remove screen clutter. Note: this can
be used in combination with options 1 and 2.

> PS Does anyone have any good suggestions or software for converting
> .ico to gifs?

Graphic Converter
http://www.lemkesoft.com/xd/public/content/index._cGlkPTE5Mw_.html

Jack L. Moffett
Interaction Designer
inmedius
412.459.0310 x219
http://www.inmedius.com

If there's anything more annoying
than a machine that won't do what you want,
it's a machine that won't do what you want
and has been programmed to behave
as though it likes you.

- Don Norman

12 Mar 2008 - 10:43am
Matt Nish-Lapidus
2007

This is similar to a question I asked a little while ago, the solution
I decided upon is #2 and #4 from Jack's list, and it's working very
well.

Matt.

On Wed, Mar 12, 2008 at 12:29 PM, Jack Moffett <jmoffett at inmedius.com> wrote:
>
> On Mar 12, 2008, at 9:04 AM, Fine, David wrote:
>
> > Can anyone point me to some good examples where this pattern is
> > implemented? I'm trying to get out of listing the four actions icons
> > (add, edit, delete and cancel) next to each row.
>
> I work with lists of editable items a lot. There are a number of
> patterns you could follow, each with their own strengths and weaknesses.
>
> 1. Buttons on every row
> As you have already mentioned, one option is to include all of the
> relevant actions as icons/buttons on every row. The available actions
> may differ based on object type or status. The benefit of doing this
> is two-fold: the UI presents the available actions to the user in
> direct relation to the object they will act upon, and it provides one-
> click access to those actions. The problem is visual clutter. The
> sheer number of icons on the screen, and the repetitiveness of them,
> does not result in the most elegant UI.
>
> 2. Buttons on mouseover
> This is set up the same as option 1. However, you only show the
> buttons when the cursor moves over a row, so only one row shows
> buttons at a time. Benefits: Removes the clutter, and highlighting
> the row makes it apparent that you are acting on the correct item. It
> is still single-click access. Drawback: It is not immediately
> apparent that the actions are available. Once the user knows that
> they are there, it shouldn't be a problem.
>
> 3. Row selection
> In this pattern, the user selects a row (or multiple rows) and then
> presses a button found on a toolbar above the list. Buttons should
> enable and disable based on the selection. Benefits: removes screen
> clutter, allows for actions on multiple items. Drawbacks: two-click
> interaction, actions and items are not directly connected.
>
> 4. Checkboxes
> This is similar to option 3, but easier to implement. Checkboxes are
> placed in every row. Actions are provided elsewhere on the screen.
> The user clicks checkboxes for items they want to act upon. Benefits:
> removes screen clutter, allows for actions on multiple items.
> Drawbacks: two-click interaction, actions and items are not directly
> connected, doesn't completely remove screen clutter. Note: this can
> be used in combination with options 1 and 2.
>
>
>
>
>
>
> > PS Does anyone have any good suggestions or software for converting
> > .ico to gifs?
>
>
> Graphic Converter
> http://www.lemkesoft.com/xd/public/content/index._cGlkPTE5Mw_.html
>
>
>
>
> Jack L. Moffett
> Interaction Designer
> inmedius
> 412.459.0310 x219
> http://www.inmedius.com
>
> If there's anything more annoying
> than a machine that won't do what you want,
> it's a machine that won't do what you want
> and has been programmed to behave
> as though it likes you.
>
> - Don Norman
>
>
>
>
> ________________________________________________________________
> 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
>

--
Matt Nish-Lapidus
work: matt at bibliocommons.com / www.bibliocommons.com
--
personal: mattnl at gmail.com

12 Mar 2008 - 12:06pm
dmitryn
2004

Two small additions to Jack's list:

1) The Tool Tip Invitation pattern
(http://developer.yahoo.com/ypatterns/pattern.php?pattern=tooltipinvitation)
could be helpful to address the drawback with Jack's option 2.

2) If your application is designed for frequent use, and editing
specific items is more important/frequently used than the other
actions, you may want to provide double-click to edit as a shortcut
for power users.

Dmitry

On Wed, Mar 12, 2008 at 9:29 AM, Jack Moffett <jmoffett at inmedius.com> wrote:
>
> I work with lists of editable items a lot. There are a number of
> patterns you could follow, each with their own strengths and weaknesses.

<snip>

12 Mar 2008 - 12:35pm
Meredith Noble
2010

> 3. Row selection
> In this pattern, the user selects a row (or multiple rows) and then
> presses a button found on a toolbar above the list. Buttons should
> enable and disable based on the selection. Benefits: removes screen
> clutter, allows for actions on multiple items. Drawbacks: two-click
> interaction, actions and items are not directly connected.

Jack, you mention "buttons should enable and disable based on the
selection". Have you had success with this in the past? I am worried
about randomly disabling buttons -- what if the user doesn't understand
why it's happening?

(In my situation, I'd be disabling certain items when the user selects
multiples -- because some actions can't be done to more than one item at
a time.)

I just imagine this would be confusing to users and I can't find any
decent examples. I'm wondering if someone has come up with some elegant
feedback mechanism -- like a button greys out and next to it is
something saying "some actions can only be performed on one item at a
time" -- but ugh, this seems so ugly!

Meredith

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Meredith Noble
Information Architect, Usability Matters Inc.
416.598.7770 x6
meredith at usabilitymatters.com
http://www.usabilitymatters.com

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

12 Mar 2008 - 1:50pm
Jack L. Moffett
2005

On Mar 12, 2008, at 2:35 PM, Meredith Noble wrote:

>> 3. Row selection
>> In this pattern, the user selects a row (or multiple rows) and then
>> presses a button found on a toolbar above the list. Buttons should
>> enable and disable based on the selection. Benefits: removes screen
>> clutter, allows for actions on multiple items. Drawbacks: two-click
>> interaction, actions and items are not directly connected.
>
> Jack, you mention "buttons should enable and disable based on the
> selection". Have you had success with this in the past? I am worried
> about randomly disabling buttons -- what if the user doesn't
> understand
> why it's happening?

My philosophy is that it would be more confusing to allow them to
press a button that won't work because of the selection. I have also
used tooltips on disabled buttons that indicate why they are disabled.

> (In my situation, I'd be disabling certain items when the user selects
> multiples -- because some actions can't be done to more than one
> item at
> a time.)

Yes, I'm working on an app that does this right now. If I remember,
I'll post the results of our user trials, but they are a month away.

Best,
Jack

Jack L. Moffett
Interaction Designer
inmedius
412.459.0310 x219
http://www.inmedius.com

First, recognize that the ‘right’ requirements
are in principle unknowable by users, customers
and designers at the start.

Devise the design process, and the formal
agreement between designers and customers and users,
to be sensitive to what is learnt by any of the
parties as the design evolves.

- J.C. Jones

12 Mar 2008 - 2:29pm
Meredith Noble
2010

> > Jack, you mention "buttons should enable and disable based on the
> > selection". Have you had success with this in the past? I am worried
> > about randomly disabling buttons -- what if the user doesn't
> > understand
> > why it's happening?
>
> My philosophy is that it would be more confusing to allow them to
> press a button that won't work because of the selection. I have also
> used tooltips on disabled buttons that indicate why they are disabled.

Oh, absolutely, I agree, better to prevent the error in the first place
than to have to explain it after it happens!

We actually dismissed both these approaches.

Instead, our solution has been to move any "single item actions" down to
the "item detail page" only. An example of this is "Edit". Because we
can't let people edit two items at the same time, we don't include that
option on the List Page. Instead, people click on one item in the list,
go to the Item Detail Page, and then click the "Edit" button there.

So we have:

List Page (list of all items, with buttons allowing the user to perform
any actions that can be applied to any combination of items in the list,
including multiples)

Item Detail Pages (what you get when you click on an item, with all of
the same buttons as the list page, PLUS any buttons for actions that you
can only perform on one item at a time)

I don't know if that explanation makes any sense -- hope so :)

Anyway, we're about to test this in a few weeks and I'm quite worried
about it. We dismissed your proposed solution in favour of this, so I
was just curious how your solution tests. Would love to hear your
results after you're done!

Thanks,
Meredith

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Meredith Noble
Information Architect, Usability Matters Inc.
416.598.7770 x6
meredith at usabilitymatters.com
http://www.usabilitymatters.com

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

12 Mar 2008 - 10:53pm
Jack L. Moffett
2005

On Mar 12, 2008, at 4:29 PM, Meredith Noble wrote:

> So we have:
>
> List Page (list of all items, with buttons allowing the user to
> perform
> any actions that can be applied to any combination of items in the
> list,
> including multiples)
>
> Item Detail Pages (what you get when you click on an item, with all of
> the same buttons as the list page, PLUS any buttons for actions that
> you
> can only perform on one item at a time)
>
> I don't know if that explanation makes any sense -- hope so :)

Yep, I get it. That makes sense, but I could see two cases in which it
could be problematic:

1. The single-item actions are the ones that people use most often. It
would be frustrating to have to navigate an extra screen to get to the
functions you typically need when other, less useful functions are
immediately available.

2. They need to perform the single-item actions on several items in
sequence. This would require "yo-yo" navigation, bouncing in and out
of details screens to accomplish their task.

Let's take "edit" for example. I'm going to assume that pressing the
edit button changes the detail screen from a read-only mode to an
editable mode. This cognitively makes sense, and may test okay, but it
does add a click to get to the edit state. Do they often view item
details without editing? If so, your solution seems appropriate. If
not, you might consider displaying the edit state automatically.

Best,
Jack

Jack L. Moffett
Interaction Designer
inmedius
412.459.0310 x219
http://www.inmedius.com

In our society,
the scarce factor is not information,
it is time to attend to information.

- Herb Simon

13 Mar 2008 - 1:38am
Rony Philip
2007

The Google approach...

http://specials.rediff.com/money/2008/mar/11google1.htm

Cheers
Rony

Syndicate content Get the feed