TreeViews

8 Jun 2005 - 2:43am
9 years ago
15 replies
727 reads
Tricia (Bluesky...
2005

Does anyone know of any studies or guidelines on Tree Views?

The only stuff I've seen has been for them being bad ways of displaying
information hierarchies.

I'm in the unfortunate position where I have a client that absolutely
wants a Tree View.

Thanks
Tricia

Comments

8 Jun 2005 - 5:47am
Tadej Maligoj
2004

I post quite the same question on March 22 and get some responses (I
was not quite satisfied with - unfortunately treeviews are still in
use ...).

If you cannot find this post on the forum, send me a note.

Tadej

On 6/8/05, Tricia (Bluesky Consult) <tricia at blueskyconsult.com> wrote:
> [Please voluntarily trim replies to include only relevant quoted material.]
>
> Does anyone know of any studies or guidelines on Tree Views?
>
> The only stuff I've seen has been for them being bad ways of displaying
> information hierarchies.
>
> I'm in the unfortunate position where I have a client that absolutely
> wants a Tree View.
>
> Thanks
> Tricia
>
> _______________________________________________
> 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/
>

--
_______________________________
Tadej Maligoj, Information Architect
e1: tadej.maligoj at gmail.com
e2: studio at maligoj.com
m: 031 306 986
w: www.maligoj.com

8 Jun 2005 - 6:22am
Tadej Maligoj
2004

That's what I meant. Unfortunately I definitely need it when you
design document management software or archiving software, because
there is no better solution yet.

I don't think treevies are bad. I just see how much trouble they make
for both sides - the designers and the users.

Tadej

On 6/8/05, Hegle Sarapuu <hegle at interinx.com> wrote:
> ? Unfortunately ? It just a same like unfortunately are data grids still in use or tables still in use - these are all software components which have their purpose of use one or another case. Sometimes you need tree view for better understanding and reading different information. It has special place in information architecture. But sometimes it is misused (like someone has found some kind of coded part from web and so on). That's true that you don't usually need tree view in webpage design (only site index can use it). But you definitely need it when you design document management software or archiving software.
>
> Hegle
>
> -----Original Message-----
> From: discuss-interactiondesigners.com-bounces at lists.interactiondesigners.com [mailto:discuss-interactiondesigners.com-bounces at lists.interactiondesigners.com] On Behalf Of Tadej Maligoj
> Sent: Wednesday, June 08, 2005 1:48 PM
> To: Tricia (Bluesky Consult)
> Cc: IxD Discussion
> Subject: Re: [ID Discuss] TreeViews
>
> [Please voluntarily trim replies to include only relevant quoted material.]
>
> I post quite the same question on March 22 and get some responses (I
> was not quite satisfied with - unfortunately treeviews are still in
> use ...).
>
> If you cannot find this post on the forum, send me a note.
>
> Tadej
>
>
>
>

--
_______________________________
Tadej Maligoj, Information Architect
e1: tadej.maligoj at gmail.com
e2: studio at maligoj.com
m: 031 306 986
w: www.maligoj.com

8 Jun 2005 - 6:49am
Hegle Sarapuu
2005

Well I agree in that matter. Well there is a way how can be avoided tree view.

If you design software what users use only process base. Like sales process is to insert contact info -> make/insert price offer -> make/insert contract. If you can set system up when you define process and what system have to do in any task, you can avoid views where are lots of objects. That means software has to have process design feature (very advanced one) And if you make processes even to find something or get report you don’t have to find things from tree view. It's hard to explain :) but I'm working with that kind of solution right now.

Best,
Hegle

-----Original Message-----
From: Tadej Maligoj [mailto:tadej.maligoj atgmail.com]
Sent: Wednesday, June 08, 2005 2:22 PM
To: Hegle Sarapuu; IxD Discussion
Subject: Re: [ID Discuss] TreeViews

That's what I meant. Unfortunately I definitely need it when you
design document management software or archiving software, because
there is no better solution yet.

I don't think treevies are bad. I just see how much trouble they make
for both sides - the designers and the users.

Tadej

On 6/8/05, Hegle Sarapuu <hegle atinterinx.com> wrote:
> ? Unfortunately ? It just a same like unfortunately are data grids still in use or tables still in use - these are all software components which have their purpose of use one or another case. Sometimes you need tree view for better understanding and reading different information. It has special place in information architecture. But sometimes it is misused (like someone has found some kind of coded part from web and so on). That's true that you don't usually need tree view in webpage design (only site index can use it). But you definitely need it when you design document management software or archiving software.
>
> Hegle
>
> -----Original Message-----
> From: discuss-interactiondesigners.com-bounces atlists.interactiondesigners.com [mailto:discuss-interactiondesigners.com-bounces atlists.interactiondesigners.com] On Behalf Of Tadej Maligoj
> Sent: Wednesday, June 08, 2005 1:48 PM
> To: Tricia (Bluesky Consult)
> Cc: IxD Discussion
> Subject: Re: [ID Discuss] TreeViews
>
> [Please voluntarily trim replies to include only relevant quoted material.]
>
> I post quite the same question on March 22 and get some responses (I
> was not quite satisfied with - unfortunately treeviews are still in
> use ...).
>
> If you cannot find this post on the forum, send me a note.
>
> Tadej
>
>
>
>

--
_______________________________
Tadej Maligoj, Information Architect
e1: tadej.maligoj atgmail.com
e2: studio atmaligoj.com
m: 031 306 986
w: www.maligoj.com

--
No virus found in this incoming message.
Checked by AVG Anti-Virus.
Version: 7.0.323 / Virus Database: 267.6.5 - Release Date: 7.06.2005

9 Jun 2005 - 2:09am
Hegle Sarapuu
2005

Hi Deepak,

If you insert to google 'tree view problem' you will find a lots of them :). But mostly these problems are programmer's problems. How to put it work in different languages? When our company made first tree view, we fixed so many bugs that I lost counting. Tree view is complicate thing to program but it seems very easy. And it is hard to design, because mostly tree view size is changing a lot during use period. It is almost impossible to predict how long and wide it will be. So there has been lots of thinking how to avoid using it in programs, because it is easier to us when client don’t want that. I never heard that any of my software users had any problems with using tree view. Only problems have been that tree view is too narrow or too slow, too many postbacks to server and so on these all have been mine as designer or developers fault. When we solved these problems clients were happy to use these features. I have to admit that tree views can't be avoided in our software. That process based system will be only as bonus (or tree view as a bonus) because users don’t like strict features. They like when they have choice how they use software. I have nothing against using tree views but there will be always complaining from developers when I design it. Most of the time it is the most expensive feature in software. Just because it takes so much time to create it.

Best,
Hegle

-----Original Message-----
From: Deepak Pakhare [mailto:deepux atgmail.com]
Sent: Thursday, June 09, 2005 6:25 AM
To: Hegle Sarapuu
Cc: IxD Discussion
Subject: Re: [ID Discuss] TreeViews

Hi,
I have recently joined the list and have been mostly lurking and
reading some interesting posts. :) In the discussion about treeviews,
I notice there seems to be near-unanimous opinion that an alternative
is required for treeviews although we feel they are not so bad. It
makes me wonder what's really wrong with using treeviews. Does anybody
have some more material on the pros and cons of using treeviews?

Cheers!
Deepak

8 Jun 2005 - 10:24pm
Deepak Pakhare
2005

Hi,
I have recently joined the list and have been mostly lurking and
reading some interesting posts. :) In the discussion about treeviews,
I notice there seems to be near-unanimous opinion that an alternative
is required for treeviews although we feel they are not so bad. It
makes me wonder what's really wrong with using treeviews. Does anybody
have some more material on the pros and cons of using treeviews?

Cheers!
Deepak

On 6/8/05, Hegle Sarapuu <hegle at interinx.com> wrote:
> [Please voluntarily trim replies to include only relevant quoted material.]
>
> Well I agree in that matter. Well there is a way how can be avoided tree view.
>
> If you design software what users use only process base. Like sales process is to insert contact info -> make/insert price offer -> make/insert contract. If you can set system up when you define process and what system have to do in any task, you can avoid views where are lots of objects. That means software has to have process design feature (very advanced one) And if you make processes even to find something or get report you don't have to find things from tree view. It's hard to explain :) but I'm working with that kind of solution right now.
>
> Best,
> Hegle

11 Jun 2005 - 8:23am
milan
2005

Hi!

I am working on a online help system for a large enterprise app, and
there also is no alternative to treeviews - because they have become an
industry-standard in online help. We are publishing 3 versions of the
help system: pdf, ms help (chm) and an software-integrated web version,
and in all of these users have to use treeviews - but that's not what
they're complaining about, because they know it from all the other help
applications they use.

milan
-- ||  | | | ||||| || ||| ||  |
| barbarossaplatz 5 | 40545 düsseldorf | germany
phone +49 (0)211 5863 701 | www.guenther.cx

On 9 juin 05, at 09:09, Hegle Sarapuu wrote:

> [Please voluntarily trim replies to include only relevant quoted
> material.]
>
> Hi Deepak,
>
> If you insert to google 'tree view problem' you will find a lots of
> them :). But mostly these problems are programmer's problems. How to
> put it work in different languages? When our company made first tree
> view, we fixed so many bugs that I lost counting. Tree view is
> complicate thing to program but it seems very easy. And it is hard to
> design, because mostly tree view size is changing a lot during use
> period. It is almost impossible to predict how long and wide it will
> be. So there has been lots of thinking how to avoid using it in
> programs, because it is easier to us when client don’t want that. I
> never heard that any of my software users had any problems with using
> tree view. Only problems have been that tree view is too narrow or too
> slow, too many postbacks to server and so on these all have been mine
> as designer or developers fault. When we solved these problems clients
> were happy to use these features. I have to admit that tree views
> can't be avoided in our software. That process based system will be
> only as bonus (or tree view as a bonus) because users don’t like
> strict features. They like when they have choice how they use
> software. I have nothing against using tree views but there will be
> always complaining from developers when I design it. Most of the time
> it is the most expensive feature in software. Just because it takes so
> much time to create it.
>
> Best,
> Hegle
>
>
> -----Original Message-----
> From: Deepak Pakhare [mailto:deepux at gmail.com]
> Sent: Thursday, June 09, 2005 6:25 AM
> To: Hegle Sarapuu
> Cc: IxD Discussion
> Subject: Re: [ID Discuss] TreeViews
>
> Hi,
> I have recently joined the list and have been mostly lurking and
> reading some interesting posts. :) In the discussion about treeviews,
> I notice there seems to be near-unanimous opinion that an alternative
> is required for treeviews although we feel they are not so bad. It
> makes me wonder what's really wrong with using treeviews. Does anybody
> have some more material on the pros and cons of using treeviews?
>
> Cheers!
> Deepak
>
>
>
> _______________________________________________
> 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/
>

30 Jun 2005 - 4:27am
Tricia (Bluesky...
2005

Firstly, I must apologize for taking so long to reply to my original post.

I am not yet finished with my analysis so your comments are still helpful.

Regarding some info. on pro's and con's of Tree Views. I do remember the late Jef Raskin saying that user's cognitive preference for organizing information is spatially and not laterally, his argument was specifically against tree views. He said that even though users could use them when they were very well designed the cognitive pressure placed on the users was unnecessary and that other alternative navigation solutions like spatial and depth arrangements always superseded them in testing. One of the pro's is that users can see the relative groupings clearly and where objects come from and how they're owned, but this isn't as helpful to the user as we sometimes think, it just requires too much cognitive work to learn and to remember.

Thanks again
Tricia

-----Original Message-----
From: discuss-interactiondesigners.com-bounces at lists.interactiondesigners.com [mailto:discuss-interactiondesigners.com-bounces at lists.interactiondesigners.com] On Behalf Of Milan Guenther
Sent: Saturday, June 11, 2005 3:24 PM
To: discuss at ixdg.org
Subject: Re: [ID Discuss] TreeViews

[Please voluntarily trim replies to include only relevant quoted material.]

Hi!

I am working on a online help system for a large enterprise app, and
there also is no alternative to treeviews - because they have become an
industry-standard in online help. We are publishing 3 versions of the
help system: pdf, ms help (chm) and an software-integrated web version,
and in all of these users have to use treeviews - but that's not what
they're complaining about, because they know it from all the other help
applications they use.

milan
-- ||  | | | ||||| || ||| ||  |
| barbarossaplatz 5 | 40545 düsseldorf | germany
phone +49 (0)211 5863 701 | www.guenther.cx

On 9 juin 05, at 09:09, Hegle Sarapuu wrote:

> [Please voluntarily trim replies to include only relevant quoted
> material.]
>
> Hi Deepak,
>
> If you insert to google 'tree view problem' you will find a lots of
> them :). But mostly these problems are programmer's problems. How to
> put it work in different languages? When our company made first tree
> view, we fixed so many bugs that I lost counting. Tree view is
> complicate thing to program but it seems very easy. And it is hard to
> design, because mostly tree view size is changing a lot during use
> period. It is almost impossible to predict how long and wide it will
> be. So there has been lots of thinking how to avoid using it in
> programs, because it is easier to us when client don't want that. I
> never heard that any of my software users had any problems with using
> tree view. Only problems have been that tree view is too narrow or too
> slow, too many postbacks to server and so on these all have been mine
> as designer or developers fault. When we solved these problems clients
> were happy to use these features. I have to admit that tree views
> can't be avoided in our software. That process based system will be
> only as bonus (or tree view as a bonus) because users don't like
> strict features. They like when they have choice how they use
> software. I have nothing against using tree views but there will be
> always complaining from developers when I design it. Most of the time
> it is the most expensive feature in software. Just because it takes so
> much time to create it.
>
> Best,
> Hegle
>
>
> -----Original Message-----
> From: Deepak Pakhare [mailto:deepux at gmail.com]
> Sent: Thursday, June 09, 2005 6:25 AM
> To: Hegle Sarapuu
> Cc: IxD Discussion
> Subject: Re: [ID Discuss] TreeViews
>
> Hi,
> I have recently joined the list and have been mostly lurking and
> reading some interesting posts. :) In the discussion about treeviews,
> I notice there seems to be near-unanimous opinion that an alternative
> is required for treeviews although we feel they are not so bad. It
> makes me wonder what's really wrong with using treeviews. Does anybody
> have some more material on the pros and cons of using treeviews?
>
> Cheers!
> Deepak
>
>
>
> _______________________________________________
> 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/
>

_______________________________________________
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/

30 Jun 2005 - 11:57am
Tom Ollar
2005

Excellent post!

Technically any TreeView can be reduced to a ListView by placing a drop down
list above it. But that's pretty much a band-aid too.

The real breakthroughs in productivity seem to come from persona/goal-based
looks into the larger problem. Isolating a user goal just seems to eliminate
complexity, streamline design and increase the perceived "power" of the
resulting app almost every time.

Tom

----- Original Message -----
From: "Tricia (Bluesky Consult)" <tricia at blueskyconsult.com>
To: "Milan Guenther" <milan at guenther.cx>; <discuss at ixdg.org>
Sent: Thursday, June 30, 2005 3:27 AM
Subject: RE: [ID Discuss] TreeViews

[Please voluntarily trim replies to include only relevant quoted material.]

Firstly, I must apologize for taking so long to reply to my original post.

I am not yet finished with my analysis so your comments are still helpful.

Regarding some info. on pro's and con's of Tree Views. I do remember the
late Jef Raskin saying that user's cognitive preference for organizing
information is spatially and not laterally, his argument was specifically
against tree views. He said that even though users could use them when they
were very well designed the cognitive pressure placed on the users was
unnecessary and that other alternative navigation solutions like spatial and
depth arrangements always superseded them in testing. One of the pro's is
that users can see the relative groupings clearly and where objects come
from and how they're owned, but this isn't as helpful to the user as we
sometimes think, it just requires too much cognitive work to learn and to
remember.

Thanks again
Tricia

-----Original Message-----
From:
discuss-interactiondesigners.com-bounces at lists.interactiondesigners.com
[mailto:discuss-interactiondesigners.com-bounces at lists.interactiondesigners.com]
On Behalf Of Milan Guenther
Sent: Saturday, June 11, 2005 3:24 PM
To: discuss at ixdg.org
Subject: Re: [ID Discuss] TreeViews

[Please voluntarily trim replies to include only relevant quoted material.]

Hi!

I am working on a online help system for a large enterprise app, and
there also is no alternative to treeviews - because they have become an
industry-standard in online help. We are publishing 3 versions of the
help system: pdf, ms help (chm) and an software-integrated web version,
and in all of these users have to use treeviews - but that's not what
they're complaining about, because they know it from all the other help
applications they use.

milan
-- || | | | ||||| || ||| || |
| barbarossaplatz 5 | 40545 düsseldorf | germany
phone +49 (0)211 5863 701 | www.guenther.cx

On 9 juin 05, at 09:09, Hegle Sarapuu wrote:

> [Please voluntarily trim replies to include only relevant quoted
> material.]
>
> Hi Deepak,
>
> If you insert to google 'tree view problem' you will find a lots of
> them :). But mostly these problems are programmer's problems. How to
> put it work in different languages? When our company made first tree
> view, we fixed so many bugs that I lost counting. Tree view is
> complicate thing to program but it seems very easy. And it is hard to
> design, because mostly tree view size is changing a lot during use
> period. It is almost impossible to predict how long and wide it will
> be. So there has been lots of thinking how to avoid using it in
> programs, because it is easier to us when client don't want that. I
> never heard that any of my software users had any problems with using
> tree view. Only problems have been that tree view is too narrow or too
> slow, too many postbacks to server and so on these all have been mine
> as designer or developers fault. When we solved these problems clients
> were happy to use these features. I have to admit that tree views
> can't be avoided in our software. That process based system will be
> only as bonus (or tree view as a bonus) because users don't like
> strict features. They like when they have choice how they use
> software. I have nothing against using tree views but there will be
> always complaining from developers when I design it. Most of the time
> it is the most expensive feature in software. Just because it takes so
> much time to create it.
>
> Best,
> Hegle
>
>
> -----Original Message-----
> From: Deepak Pakhare [mailto:deepux at gmail.com]
> Sent: Thursday, June 09, 2005 6:25 AM
> To: Hegle Sarapuu
> Cc: IxD Discussion
> Subject: Re: [ID Discuss] TreeViews
>
> Hi,
> I have recently joined the list and have been mostly lurking and
> reading some interesting posts. :) In the discussion about treeviews,
> I notice there seems to be near-unanimous opinion that an alternative
> is required for treeviews although we feel they are not so bad. It
> makes me wonder what's really wrong with using treeviews. Does anybody
> have some more material on the pros and cons of using treeviews?
>
> Cheers!
> Deepak
>
>
>
> _______________________________________________
> 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/
>

_______________________________________________
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/

_______________________________________________
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/

1 Jul 2005 - 1:18am
Ripul Kumar
2005

My apologies for posting this so late. However, I feel this may benefit our collective understanding. I had written a couple of blog entries some months back about the usability of tree views. These are my deductions after many years of testing software products with tree views.

Tree on the Left
Recently I found myself staring at another Enterprise Software Application (ESA) that uses a tree structure as primary navigation. A tree structure on the left is usually not the right choice for navigation in such applications.

1. Typically in ESAs, the tree is composed of artifacts like actions, files, and tasks. This type of hybrid scheme is confusing as it makes it difficult for users to form a consistent mental model. A non-consistent mental model increases memory load and makes learning difficult.

2. To find any action, file, or a task, a user usually take many points and clicks.

3. Though pointing and clicking seems lightning fast, but remember Fitt's Law - each point and click takes a whooping 1 to 1.5 seconds!

4. A tree structure offers poor help to find and select next logical task after completing the current one. It forces users to learn the next logical step.

5. People use spatial memory to find artifacts on a screen. However, the tree structure does not support spatial memory - makes it harder to find artifacts. It also increases the time to find artifacts.

6. A tree typically provides poor navigational clues - does not tell where the user is now, what is clicked, and what is open. To provide all these clues, a software developer spends a lot of energy.

7. A tree helps software developers put artifacts as in the systems model. This model is usually very different from the user's mental model.

8. The tree typically takes more than 20% of screen space. This amount of space for navigating from one point to another is a waste of precious screen area.

9. Software developers believe that each "leaf node" in the tree must be associated with a corresponding screen. These corresponding screens typically don't contain any content and are shown blank or with content that users never need.

Original entries are at:
1. http://ripul.blogspot.com/2004/05/tree-on-left.html
2. http://ripul.blogspot.com/2005/05/tree-on-left-2.html

Tricia, in a mail to me talked about "smaller something is harder to click on." I don't know how I missed that! Tricia is absolutely correct, small target acquisition is harder to click on.

- Ripul Kumar

1 Jul 2005 - 8:47am
Tom Ollar
2005

Excellent.

It would be interesting to see some step-by-step TreeView removal surgery.
In other words, pick a publicly available app that uses a TreeView (Outlook
Express for example), and come up with something better that does not use a
TreeView...

This could have more impact than just breaking down current UI...

1 Jul 2005 - 11:17am
Richard Czerwonka
2005

This is a great thread. First I would like to declare that I am not a designer. I'm just a
humble programmer. I joined this list in order to get ideas so I can become a better
programmer.

Everybody knows that tree lists are only good for computer geeks. The average man in
the street has all kinds of problems with them.

I wish I could find an alternative. I am working on an application in which the end user
can create a database with a group type structure. For example, they could create a
Hospital group. Within that group they create a sub group for each hospital. Within that
group they can create a sub group for a department. WIthin that group they can create a
subgroup for a ward. They can then assign clients to one or more of these groups.

Using a dreaded tree list, it would look something like this:

Hospitals
East Side Hospital
Cardiology Department
East Ward
Dr Fred Smith
Nurse Joy Roberts
South Ward
North Ward

North Shore Hospital
Oncology Department
Ward 1
Ward 2
Theatre

Royal Adelaide
Emergency
Radiology

I have yet to find a way of displaying this structure, without the use of a treeview.

On 1 Jul 2005 at 11:48, Ripul Kumar wrote:

> [Please voluntarily trim replies to include only relevant quoted
> material.]
>
> My apologies for posting this so late. However, I feel this may
> benefit our collective understanding. I had written a couple of blog
> entries some months back about the usability of tree views. These are
> my deductions after many years of testing software products with tree
> views.

=================
Richard Czerwonka,
Delphi Programmer
ENT Technologies
Mob: 0412 104 042
=================

1 Jul 2005 - 1:50pm
Tom Ollar
2005

Who is setting up these categories and why? What are they really trying to
accomplish when doing so?

Also, if the categories truly follow the physical layout of the hospital,
then you could use a map...

1 Jul 2005 - 3:06pm
Jim Kauffman
2004

Richard,

First of all, you need to find out the purpose of this hierarchy. Is it for
navigation, so someone can see the doctors and nurses assigned to East Ward?
Is it to enter information that can be rolled up to higher levels (like a
spreadsheet)? Is it a map? Is it a user-level database that will be used to
enter and maintain information?

Trees are so versatile that you need to be very sure of its underlying
purpose. Then, you can choose alternatives that suit that purpose better than
a tree.

Hope this helps.

Jim K.

> -----Original Message-----
> From:
> discuss-interactiondesigners.com-bounces at lists.interactiondesi
gners.com [mailto:discuss-interactiondesigners.com->
bounces at lists.interactiondesigners.com] On Behalf Of Richard
> (ENT Technologies)
> Sent: Friday, July 01, 2005 12:17 PM
> To: discuss at ixdg.org
> Subject: Re: [ID Discuss] TreeViews
>
> [Please voluntarily trim replies to include only relevant
> quoted material.]
>
> Using a dreaded tree list, it would look something like this:
>
> Hospitals
> East Side Hospital
> Cardiology Department
> East Ward
> Dr Fred Smith
> Nurse Joy Roberts
> South Ward
> North Ward
>
> North Shore Hospital
> Oncology Department
> Ward 1
> Ward 2
> Theatre
>
> Royal Adelaide
> Emergency
> Radiology
>
>
> I have yet to find a way of displaying this structure,
> without the use of a treeview.

5 Jul 2005 - 8:58am
Patrick Hunt
2005

On Jul 1, 2005, at 4:06 PM, Jim Kauffman wrote:

>
> First of all, you need to find out the purpose of this hierarchy.
>
> Trees are so versatile that you need to be very sure of its underlying
> purpose. Then, you can choose alternatives that suit that purpose
> better than
> a tree.

I'm also currently designing an interface and examining alternatives
to tree structures. In this instance, end users can create various
hierarchical organization schemes for files and certain other system
objects. The objects and hierarchies in which they are categorized
could number in the hundreds. They can also move objects from any
place in the object-type hierarchy to any other place. This is where
the tree structure has come into play.

My current design for "Move" invokes a pop-up with a tree-structure
of the hierarchy. Users traverse the hierarchy by collapsing and
expanding items (using either right/down arrows, plus/minus symbols,
or some other device), then select the target destination by clicking
it or a "select" button (or some other device).

I don't love this, but I'm not thrilled with other options either.
Showing the entire hierarchy on page load could be a tad overwhelming
(but better than a tree structure?). Using cascading drop-down menus
are a hierarchical browsing structure (with breadcrumbs) could create
too many barriers to efficiency.

Does anyone have any thoughts on the relative merit of these
approaches, or ideas for alternatives?

Thanks!

Patrick

5 Jul 2005 - 4:26pm
Tom Ollar
2005

>
> In this instance, end users can create various hierarchical organization
> schemes for files and certain other system objects. The objects and
> hierarchies in which they are categorized could number in the hundreds.
>
This is a technical summary of a completed implementation. To get better
ideas you need to start thinking about user goals. Is it true that
"end-users" want to create a hierarchical set of objects, or is that what
the system is going to force them to do to reach a
real goal?

Syndicate content Get the feed