checkbox tree behavior

6 Oct 2005 - 3:36pm
8 years ago
5 replies
1349 reads
jstanford
2003

Hello,

I am trying to spec the behavior of a tree selection mechanism that involves
checkboxes and have a question about standard behavior that I can't quite
find the answer to.

Here's a description of the interface:

- Tree of counties and cities with checkboxes at each
- User can select a county which selects all the cities under the county or
open the county node in the tree and select an individual city within that
county by clicking on its checkbox

My question:

When a user selects one of the cities within the county, the engineering
team is claiming that it is standard to display a greyed out checkbox next
to the associated county to indicate that there is something selected under
that node even though the whole county is not selected. I personally think
this is sort of confusing. This link shows a web implementation that has
this sort of functionality that the engineering team is describing:

http://www.blueshoes.org/_bsJavascript/components/tree/examples/example3.htm
l
<http://www.blueshoes.org/_bsJavascript/components/tree/examples/example3.ht
mldiscuss at ixdg.org> discuss at ixdg.org

What do ya'all think?

Julie
_____________________________________
Julie Stanford
Principal, Sliced Bread Design | www.slicedbreaddesign.com
<http://www.slicedbreaddesign.com/>
650-799-7225

Comments

6 Oct 2005 - 3:56pm
Dave Malouf
2005

Hi Julie,

Your engineers are close with some caveats.
First, to say that anything is standard w/ this behavior is a bit off. The
closest thing I have seen to a standard is some windows applications. I have
not come across the issue in Mac OS X, and when on the web, this is a recent
phenomena that I know I'm struggling to manage as well.

The Windows behavior when it comes to hierarchical checkbox selection.

A "parent" w/ a checkbox has 6 states at its most complex. I suggest using
Visio b/c visio actually can handle all 6 states. There are 3 per 2 groups:
enabled and disabled:
Checked, mixed, unchecked

Mixed is usually represented as a box inside the checkbox. Making it grayed
out would be wrong b/c that would make it "disabled" and would tell the user
NOT to click on it.

Checked in this case for a parent means that all the items in it are
checked. Now the real hoot comes when you have nested hierarchy (more than 1
level). If the grandparent's children are all checked except for one parent
w/ grandchildren is mixed, does the grandparent show itself as mixed? I
would think yes, but I have seen it as no.

Anyway, Good luck!

-- dave

On 10/6/05 4:36 PM, "Julie Stanford" <julie at slicedbreaddesign.com> wrote:

> When a user selects one of the cities within the county, the engineering
> team is claiming that it is standard to display a greyed out checkbox next
> to the associated county to indicate that there is something selected under
> that node even though the whole county is not selected. I personally think
> this is sort of confusing. This link shows a web implementation that has
> this sort of functionality that the engineering team is describing:

-- dave

David Heller
http://synapticburn.com/
http://ixdg.org/
Dave (at) ixdg (dot) org
Dave (at) synapticburn (dot) com
AIM: bolinhanyc || Y!: dave_ux || MSN: hippiefunk at hotmail.com

6 Oct 2005 - 4:44pm
Todd Warfel
2003

This model exists in OS X.

Checking the parent selects all children
If nothing is selected, neither the parent nor any children are selected
If some children are selected, but not the parent, then the parent
has a [-] (which is a check with a minus in it to represent mixed).

This model is in OS X, it's also in several other applications that
have parent/child relationships (e.g. users/groups, font management
applications (LinoType FontExplorer, FontAgent Pro).

Greying an item out indicates that the item is disabled. So, the
engineers are incorrect in that.

On Oct 6, 2005, at 4:56 PM, David Heller wrote:

> A "parent" w/ a checkbox has 6 states at its most complex. I
> suggest using Visio b/c visio actually can handle all 6 states.
> There are 3 per 2 groups:
> enabled and disabled:
> Checked, mixed, unchecked

Cheers!

Todd R. Warfel
Design & Usability Specialist
--------------------------------------
Contact Info
Email: twarfel at mac.com
AIM: twarfel at mac.com
Blog: http://toddwarfel.com
--------------------------------------

7 Oct 2005 - 2:01pm
Jim Griffin
2005

Hey Julie. I ran into the same issue with my developers "graying out"
mixed checkbox selectors. This is how Windows displayed "some are
checked; some are not" up until Windows XP (Windows 95-ME). This made
sense to them - since the checkmark was still black, not gray - and
even some Excel powerusers I tested understood this, because again -
Microsoft used this convention across a lot of apps.

This symbolism broke down when I tested it with the non-powerusers.
One way we got around it so that everyone can understand it, was to
write inline "(Some checked)" in a slightly grayed out font, next to
the parent node that had mixed children selected. Not the most
elegant solution, but one where you say" well, you know, if it
works..."

This worked well - until we used that convention on 10 parent nodes,
with 6 children under them, each of those with 5 or 6 children. It
became "wordy," as one tester described it. But I agree with Todd and
Dave - grayed out to the majority of users means "I can't select
this," which is not what you're going for. And to Dave's point, I
haven't seen many Tree-like "standards" so if you can find a solution
that works for you, congrats.

- Jim Griffin

On 10/6/05, Todd Warfel <lists at toddwarfel.com> wrote:
> [Please voluntarily trim replies to include only relevant quoted material.]
>
> This model exists in OS X.
>
> Checking the parent selects all children
> If nothing is selected, neither the parent nor any children are selected
> If some children are selected, but not the parent, then the parent
> has a [-] (which is a check with a minus in it to represent mixed).
>
> This model is in OS X, it's also in several other applications that
> have parent/child relationships (e.g. users/groups, font management
> applications (LinoType FontExplorer, FontAgent Pro).
>
> Greying an item out indicates that the item is disabled. So, the
> engineers are incorrect in that.
>
> On Oct 6, 2005, at 4:56 PM, David Heller wrote:
>
> > A "parent" w/ a checkbox has 6 states at its most complex. I
> > suggest using Visio b/c visio actually can handle all 6 states.
> > There are 3 per 2 groups:
> > enabled and disabled:
> > Checked, mixed, unchecked
>
>
> Cheers!
>
> Todd R. Warfel
> Design & Usability Specialist
> --------------------------------------
> Contact Info
> Email: twarfel at mac.com
> AIM: twarfel at mac.com
> Blog: http://toddwarfel.com
> --------------------------------------
>
>
> _______________________________________________
> Welcome to the Interaction Design Group!
> To post to this list ....... discuss at ixdg.org
> (Un)Subscription Options ... http://discuss.ixdg.org/
> Announcements List ......... http://subscribe-announce.ixdg.org/
> Questions .................. lists at ixdg.org
> Home ....................... http://ixdg.org/
>

7 Oct 2005 - 3:28pm
natekendrick
2005

On Oct 6, 2005, at 4:36 PM, Julie Stanford wrote:

> Here's a description of the interface:
>
> - Tree of counties and cities with checkboxes at each
> - User can select a county which selects all the cities under the
> county or
> open the county node in the tree and select an individual city
> within that
> county by clicking on its checkbox
>

In this specific use case, and assuming this Tree component is not
used elsewhere:

The folder and page icons are not really appropriate for this case.
I'd suggest to simply use the "+/-" icons: using folders and such
mean a strict container. If you move or select the folder, all its
children/grandchildren are selected as well. Even remove the dotted
line that connects them to reduce the visual noise. The indentations
are sufficient to understand parent/child relationships.

The checkbox at the county level is (and I am assuming here) only
used as an interaction shortcut to either select all or none of its
children (and subsequent grandchildren and so on). If the checkbox
serves a dual purpose of selecting the county itself as an item (is
if the county itself is an entity and not simply an enclosing
container) AND selecting all its children -- then the interaction is
sufficiently complicated to merit a much more in depth analysis.

Assuming the checkbox only selects its children/grandchildren - then
it is convention to have a third state of the checkbox when the user
manually deselects one or more children of a checked parent
(confusing yet?), you'll need three states:

[ x ] = Checked state of a parent, and denotes the selected state of
ALL children.

[ ] = Unchecked state of a parent, and denotes the unselected state
of ALL children.

[ * ] = Bulleted state of parent, and denotes the selected state of
SOME but not ALL children.

This third state is described in the linked example by being grayed
out. It could be convention somewhere to do this, but certainly has
unavoidable problems with being interpreted as "inactive" or
otherwise being unavailable to interact with. An icon, such as a
simple bullet would do the job.

Additionally, and a little beyond the scope of this Tree component:
mixing read-only widgets such as tree views, with form elements
utilized for selection such as checkboxes or radio buttons rarely
works out well in the end. Either from a usability standpoint or
elegance in design.

This is decidedly different in stable (well, relative to the web) UI
environment such as in Windows or the Mac OS: tree views in Windows
Explorer or the Finder allow for selection without the need for form
elements.

But, on the web, interaction behavior for trees is unsure - through
usability it has proven that many users consistently do not know that
tree views can be used for selection purposes, and are usually
thought to be navigational.

What have others found for solving the "select not navigate" use case
of trees in a web page? This scenario should be considered outside of
a web app, where the user is a frequent or at least semi-frequent
user that learns the interface over multiple usages.

7 Oct 2005 - 3:35pm
Ted Boren
2005

I agree with David: "Mixed is usually represented as a box inside the checkbox. Making it grayed out would be wrong b/c that would make it "disabled" and would tell the user NOT to click on it."

But the color of that "box" may be an issue adding to the confusion. In Excel (on XP), the checkmark is green and so is the "mixed selection" box is also green. But I think I've seen UI's where the "mixed selection" box was greyish... which might connote "disabled." So * yes, the box-within-a-checkbox works, but it should probably not be a grey box.

Ted

>>> "David Heller" <dave at ixdg.org> 10/6/2005 2:56:24 PM >>>
Hi Julie,

Your engineers are close with some caveats.
First, to say that anything is standard w/ this behavior is a bit off. The
closest thing I have seen to a standard is some windows applications. I have
not come across the issue in Mac OS X, and when on the web, this is a recent
phenomena that I know I'm struggling to manage as well.

The Windows behavior when it comes to hierarchical checkbox selection.

A "parent" w/ a checkbox has 6 states at its most complex. I suggest using
Visio b/c visio actually can handle all 6 states. There are 3 per 2 groups:
enabled and disabled:
Checked, mixed, unchecked

Mixed is usually represented as a box inside the checkbox. Making it grayed
out would be wrong b/c that would make it "disabled" and would tell the user
NOT to click on it.

Checked in this case for a parent means that all the items in it are
checked. Now the real hoot comes when you have nested hierarchy (more than 1
level). If the grandparent's children are all checked except for one parent
w/ grandchildren is mixed, does the grandparent show itself as mixed? I
would think yes, but I have seen it as no.

Anyway, Good luck!

-- dave

On 10/6/05 4:36 PM, "Julie Stanford" < julie at slicedbreaddesign.com > wrote:

> When a user selects one of the cities within the county, the engineering
> team is claiming that it is standard to display a greyed out checkbox next
> to the associated county to indicate that there is something selected under
> that node even though the whole county is not selected. I personally think
> this is sort of confusing. This link shows a web implementation that has
> this sort of functionality that the engineering team is describing:

-- dave

David Heller
http://synapticburn.com/
http://ixdg.org/
Dave (at) ixdg (dot) org
Dave (at) synapticburn (dot) com
AIM: bolinhanyc || Y!: dave_ux || MSN: hippiefunk at hotmail.com

------------------------------------------------------------------------------
This message may contain confidential information, and is
intended only for the use of the individual(s) to whom it
is addressed.
------------------------------------------------------------------------------

Syndicate content Get the feed