Fog Creek Software
Discussion Board




UI Suggestions

I have just developed this picklist ( http://www.aws.com.au/ddd.jpg ).

The way it works is a sort of "categorised picklist", so the item you select in pickbox 1 affects the options available in pickbox 2 and so-on down the chain.

2 Questions:

1. Is the UI I have chosen for this ideal ? (i.e. can you all understand how it works just by looking at the screenshot and reading my short description) Any suggestions for improvements?

2. I am completely stumped as to how I might have the UI for what should come up when they click "Click Here" to edit the items without confusing the heck out of them. Any ideas?

Chris
Thursday, June 26, 2003

It looks like you're trying to model a hierarchy, so perhaps an expanding tree would be useful here (c.f. Explorer).

I know some people don't like tree controls, but I think Users do understand them, especially if they're used in an appropriate context, i.e. representing a hierarchy.

On the other hand, there's nothing particularly wrong with the design you have. Only problem would occur if you had cases where there were more than four levels of selection. Less than four might be bad too, as you'd have to disable the last control somehow, which might be confusing.

One final note. What happens when you click that link at the bottom on the dialog ? It's not at all clear to me, but maybe I'm just being stupid.

Steve Jones (UK)
Thursday, June 26, 2003

Yeah, I don't think it's ideal ...

The first problem is that this won't extend to situations where the heirarchy is less than or greater than four levels deep ...

Treeviews are a bit confusing, but they are also are more common.

I'd try an inductive user interface (i.e., a wizard).  On the first page, the user would choose the overall category, on the second they would get more specific (or would have the option to go back), and so on to the end ...

Not sure if this is ideal, but it's a thought.

Alyosha`
Thursday, June 26, 2003

> Any suggestions for improvements?

One way is to have a treeview (where you can see all top-level nodes, and expand any node to see its sub-nodes). Another way is to have a 'Wizard', where you pick the top-level item on screen 1, and then click "Next" to see the corresponding level 2 items on screen 2. Another way is a popup menu (like a right-mouse context menu or the Windows "Start" menu) when you click on text in the edit box.

Your way is clear to me and concise.

In earlier stages, do you perhaps you hide (make invisible) the selection boxes for levels 3 and 4, if the user hasn't yet made a selection for level 2?

> click "Click Here" to edit the items without confusing the heck out of them. Any ideas?

Can you just make the text in "pickboxes" editable as well as selectable ("dropdown" instead of "droplist")?

Christopher Wells
Thursday, June 26, 2003

I don't find it all that intutive to use.

Tree structure is the best thing provided user can select item at any level. [Say they don't ALWAYS have to go to 4th level and pick an item!]

Regards,
JD

JD
Thursday, June 26, 2003

Thanks for the input.

1. The reason it isn't a treeview is because we felt that might confuse the user because a treeview only shows one "selection" (thing in blue) where this control is really mimicking 4 seperate fields (i.e. they can run reports on the items at each level.) so it needs to show all 4 items selected at once.

2. This one at the moment does support less than 4 items by just having the last picklist blank. At this stage it will never have to support more than 4 items due to government requirements (it doesn't normally hold animals - it will actually be used to categorise "Critical Clinical Incidents") but the way it is coded it is trivial to add a further level should requirements change.

3. I really don't want to make it a wizard because it is something the users will be doing 100's of times a month and qill qet quite annoying after a while if it is a wizard.

4. The link at the bottom is supposed to bring up some sort of UI that will allow them to edit the lists. This is the point I am having the most issues thinking of how to do.


But thanks all for the comments. I suppose I should reconsider it though

Chris
Thursday, June 26, 2003

But maybe we do need to reconsider and possibly make it a treeview?

Another option I wanted in the future is to possibly make it to type in directly on the initial form and not require the blow up screen. This could be using some sort of intellisense.

So user types "A" and the list of a items pop up. User chooses "Animal" and types ">" and the next intellisense pops up with a list.

Chris
Thursday, June 26, 2003

Sorry, I don't like it.  I agree with the other comments here that a TreeView may be more appropriate.

What happens if the user returns to an earlier combo and selects something different?

Does this automatically clear the "lower" options (in the hierarchy), and if not, why not?

What if, on the surface at least, a lower option may be valid but has just been cleared.  Won't this frustrate the user?

David Basil Wildgoose
Thursday, June 26, 2003

The other issue that make it a more difficult choice to use a treeview is that we have 2 products (a web version and a dekstop version) and both need to look and work the same because users use both of them and are easily confused.

And yes if you make your 4 selections and then change the level1 selection, the other 3 are cleared

Chris
Thursday, June 26, 2003

You can easily get a treeview behaviour to work on a web page, just like a control on a form. I use them all the time for my web development. There are loads of examples on the Internet, if you don't want to code it yourself (it is easy though).

In an ideal world, we could probably say that tree controls are not easy to use for non-techie Users. However, the fact that they are used in Explorer, etc means that people do know how to use them.

Also bear in mind that you don't have to show it collapsed when you open the screen, it could be all expanded, assuming the number of items is not enormous.

The Click here to change the lists option really shouldn't be on this popup screen. It's just confusing. I don't know if it'll close the popup (losing my selections) or pop up yet another screen. Also, if it pops up another screen and I make changes in there, but elect to cancel my first screen, what happens to my changes, are they saved or not ? All too confusing.

Steve Jones (UK)
Thursday, June 26, 2003

Do it as a treeview. To edit the values add a couple of toolbar buttons to add/delete the nodes.

Duncan Smart
Thursday, June 26, 2003

"In an ideal world, we could probably say that tree controls are not easy to use for non-techie Users. However, the fact that they are used in Explorer, etc means that people do know how to use them."

Its interesting that a number of people have said something similar to this - in Windows would a non-techie user actually see the treeview in Explorer? Most users probably just navigate via "My Computer" (yuck) - to get to Explorer you need to right click "My Computer", run it from the start menu, windows-e (or whatever).

What other apps might they see a treeview in? - only ones I can think of are MMC, some preferences dialogs (ie. mozilla)..., mmm, haven't got windows on this box so I can't look for more...


Pete

Pete
Thursday, June 26, 2003

Create prototypes of both a treeview UI and your existing UI, and do usability testing.

Frederik Slijkerman
Thursday, June 26, 2003

I find the tree view irritating so I turn it off. I think the average user is more likely to see a tree view on a web page than elsewhere now; not true in the Windows 3.1 days. You will see it on Outlook Express by default I think.

Most people like them when they know how. Whenever I am configuring Outlook on somebody's machine I suggest they turn off that hideous Outllook bar and have the folder view showing. Most people never go back.

Stephen Jones
Thursday, June 26, 2003

>I really don't want to make it a
>wizard because it is something
>the users will be doing 100's of
>times a month and qill qet quite
>annoying after a while

If the users will be doing it hundreds of times per month then a picklist will be equally as annoying.  Use mnemonics instead because, after hundreds of times per month, your users will quickly become very familiar with the codes.

Be sure to employ some type of lookup facility for novices, but don't force experienced users to navigate a GUI widget.  My rule for data entry screens is "Accommodate the novices without hindering the experts".

My 0.02 halallas.

Matt Foley
Thursday, June 26, 2003

I'm fully of the opinion that people fall into "love treeviews" and "don't understand treeviews" camps.  There is little inbetween. 

Anecdotally, I find that developers, people in accounts and philosophers tend to like treeviews.  Everyone else hates them.  (I think it's something to do with maths). 

Rahoul Baruah
Thursday, June 26, 2003

--"My 0.02 halallas. "---

Hey Matt, you're in Saudi too?

Stephen Jones
Thursday, June 26, 2003

"At this stage it will never have to support more than 4 items due to government requirements (it doesn't normally hold animals - it will actually be used to categorise "Critical Clinical Incidents")"

LOL!
Murphy says that you'll be asked for a fifth level the day after you deploy it.

If the last field is "Critical Clinical Incidents" - do these have codes? I'd provide an option for the users to simply type in the code (which automatically defines the other three categories). The picklist should only be for looking up a code.

Your data entry box should be:
[Code Textbox]    [Label lookup]
User types the code into the textbox, then when they tab out it populates the label.

Also, it looks like the link at the bottom populates the next drop down after they've made a selection? If so, that's evil - make it automatic in an onchange event.

Finally, I've taught dozens of lay users to use treeviews on various applications. They've never had a problem with it.

I've done some mindreading - apologies if I'm off the mark.

Philo

Philo
Thursday, June 26, 2003

You could keep this general style, as long as you emphasize the "Make a selection..." part so the user's eyes are drawn towards it.

If people are using this thing 100X a month, you likely want to optimize for data entry speed.  I'd have "Make a selection..." be a list of some sort if possible; this would remove the pointless click to open the dropdown box, and call attention to itself.

sammy
Thursday, June 26, 2003

Sorry, but I have to disagree with everyone. The method you have chosen is fine.

A treeview works in Explorer, because it represents folders within folders. If you are searching for a file this is intuitive because it has a real life parallel.

People can handle using a treeview to search for something, because they are familiar with the concept from Explorer. However, you are not searching in this instance.

The combos workfine, because they have a noice little arrow that encourages the user to click on it and select an item from the list. The interface tells you how it works, whereas a treeview does not.

If you want to make it fast to use, then make sure that it auto-populates, e.g. as you type one letter, two letters, etc. the correct word is selected. Codes are no good. People learn codes out of necessity not becuase that is easier than remembering the actual word. Not to mention, a code could mean one thing in one application and something else in another. It encourages mistakes.

Don't show or enable the other text boxes until the prior one is complete. Again this will tell the user how to use it. Blanking the other three when you change the first also tells the user how the hierarchy works, so that is fine.

As for adding to the lists, either put an 'Edit List' link next to each combo (which not only tells you what it does, but also tells you what the combo does), or allow the user to type anything in and when you exit the combo, ask if the user wants to permanently add the item to the list.

By the way, the OK and Cancel buttons are the wrong way round. People get use to the position of a button and every other app has them the other way round, so they will end up clicking the wrong one by mistake.

Pete J
Thursday, June 26, 2003

"Codes are no good. People learn codes out of necessity not becuase that is easier than remembering the actual word. Not to mention, a code could mean one thing in one application and something else in another. It encourages mistakes"

You need to get out among the users more.
Police use codes. Firefighters use codes. Warehouse guys use bin numbers. Admin types use form numbers.

When's the last time you said "hypertext markup language"?

Now I'm only talking about using codes if they're already there, not creating new ones.

You provide a way to type the code directly in, or to look up the code if they need to.

This is all *very* situational, mind you - I'm just pointing out that it's not an absolute either way.

Philo

Philo
Thursday, June 26, 2003

You may want to check out the UI in Microsoft Money for handling the budget category of a transaction. I'd never seen anything like it before. It looks like a basic drop down box, but it has a tree in it...

For example, your category could be food:groceries. You can either start typing "foo", autocomplete the word food by pressing ":" the begin typing "gro" and press enter when it autocompletes "groceries". Alternatively, you can press "f" and pick from the drop down box, which looks something like this:

food:
  groceries
  dining out
bills:
  rent
  etc.

It is a little hard to describe and I wasn't able to find a good screenshot of it, but you can d/l a MS Money trial from their website if you want to check it out. Not sure how well it would work for 4 deep. I agree with someone else here who said that if your users are entering these 100x a day, they will soon start to remember most possible/frequent combinations. Text entry with autocomplete might be very fast. I also agree that only usability testing will give you a confident answer.

tom
Thursday, June 26, 2003

You could try emulating the cascading list shown here:

http://time-tripper.com/uipatterns/cascading-lists.html

UI Designer
Thursday, June 26, 2003

Shouldn't the OK and Cancel buttons be the other way round? This is Windows, right?

S. Tanna
Thursday, June 26, 2003

If a treeview is too complicated, why not try using a menu with submenus (such as you would find on the top bar of most apps)?

Alyosha`
Thursday, June 26, 2003

Oh my good. All the responses. Thank you all.

Yes the buttons are the wrong way around. Thanks for pointing this out, When I was making this I completely forgot about that little detail. Thank you.

And Tom, yes I use Microsoft Money 2002 ALOT and I started of trying to emulate that listbox because I absolutely love it, sadly in the timeframes I have it isn't possible. That is what I was aluding to when I described the "intelisense" version of a textbox I would like to use in the future. And the Money listbox also answers the issue of how to have the user enter new list items, you simply type an item after the ":" and if it isn't in the list, a message says "do you want to add it?". That would be perfect (anybody seen a ActiveX control to do this?).

Philo, the link at the bottom is where I propose a "List Editing" dialog to be launched from, but as others have pointed out this can cause confusion "What happens with my current selections if I click that?", so as others have suggested, I think an "Edit" link after each combo is more ideal. - and yes the lists do autopopulate in an onchange event.

Well this thread has certainly forced me to rethink this. I am definately reconsidering a treeview.

Chris
Thursday, June 26, 2003

>Hey Matt, you're in Saudi too?

Yup, I work for a rather large-ish oil company.  You may have heard of them  :-)

Matt Foley
Saturday, June 28, 2003

>Codes are no good. People learn codes out of
>necessity not becuase that is easier than
>remembering the actual word.

Sorry, gotta disagree with that one.  Imagine if travel agents had their codes taken away and were forced to use full names when booking flights.

BAH-AMS-IAH is easier than Bahrain-Amsterdam-Houston.  What about cities like London with multiple airports?  Or cities in different countries that share names?  London, Ontario and Paris, Ontario?  And how many cities in the US are named "Springfield"?


>Don't show or enable the other text boxes
>until the prior one is complete

I disagree for two reasons.  Firstly this gives the app a linear feel.  He's developing for Windows, not for a mainframe.  Secondly, unless there is field-by-field validation there's no sense in doing it.  What's to stop a user from putting "x" in a field simply to display/enable the next text box?

Matt Foley
Saturday, June 28, 2003

*  Recent Topics

*  Fog Creek Home