views:

83

answers:

5

I have a file which stores a list of enumerations with their associated values. The following is an illustration what the file looks like (rather than its actual contents):

Enumerated value        Meaning (associated text)
0                       Sunday
1                       Monday
2                       Tuesday
3                       Wednesday
4                       Thursday
5                       Friday
6                       Saturday

I am writing a C# program to allow users to look up between the enumerated values and their associated texts. In other words, they should be able to look up the text from a value, and vice versa.

I wonder what is the best way to design the user interface? I have several ideas:

  1. Have two text boxes. The user can fill in either of them and the other automatically populates as the user types. If the value is invalid, just leave the other text box blank.
  2. Have a text box for the user to fill in the side of the information they have, a radio button to specify what information they are filling in to the text box, an OK button which when pressed, updates a text label with the result or an error message.
  3. Same as 2, but do not have the OK button. Just update the text label as the user types (i.e. handling the Control.KeyPress event).
  4. Have two separate screens (one to search enumeration from text, the other to search text from enumeration) and the user can flip between them by a tab or a button. Have a text box for user input, an OK button and a text label to display the result or error message.
  5. Have two separate areas on the same screen. Each area has the same format as in 4.

I thought 2 is what I would expect from a GUI application, although it may be a bit slow and there is a problem of What to display if the user just typed "S" and pressed OK. Option 1 is messier but may be more interactive (displays the answer quicker).

Sorry if this is not strictly a programming question, but I think it is a UI design issue which comes up often enough. Does anybody know of any industrial standard best practices please?

Thank you very much.

+2  A: 

How many items do you anticipate having in the list? If it's a reasonably small number, maybe < 100, I'd actually take the Tufte approach and just display two well-designed tables side-by-side (one sorted by value, the other by meaning). The eye/brain connection can parse data much faster than we realize; I think Tufte claims each eye is capable of ~10Mbit/second.

If you've got lots of various types of data, though, I think #1 is your best bet. Fewest number of form controls, and you can retrieve the data via AJAX or an inline array quickly. Make sure that your instructional text is perfectly clear and concise.

The only downside I see to this approach is that it prevents users from seeing the relevant data set and establishing patterns on their own. For example, if you tell me that 0 = Sunday and 1 = Monday, I could make a reasonable assumption that 2 = Tuesday. If a user understands the pattern, I'd rather see them make use of it, rather than having to use the form for each individual value.

Mark Hurd
Thank you for your reply. I am talking about about 200 enumerated fields with a few to >500 items for each enumerated field. The items in the enumerated lists are not organised logically. The example is just for illustrational purposes!
Andy
Then it sounds like you want Mark's second paragraph (and your #1), at least for fields with 100s of possibilities. That's especially given you've got 200 pairs. Real estate has to be a serious issue, and you're going to want as few controls as possible. I would only add that you provide some feedback (not just a blank box) for invalid input (e.g., the text "no match" under the text box). You may also want a small button to open a window or page for searching for a value when the user doesn't know it (I'm assuming the user usually does).
Michael Zuschlag
A: 

Assuming you have enumerations set up something like this

public enum Days { Sunday = 0, Monday = 1, Tuesday = 2, Wednesday = 3, Thursday = 4, Friday = 5, Saturday = 6 };

Couldn't you just use a couple of helper methods?

    public static int GetEnumValue(string name, Type enumType)
    {
       int result = -1;

       foreach (var item in Enum.GetValues(enumType))
       {
           if (item.ToString() == name)
           {
               result = (int) item;
               break;
           }

       }

       return result;
    }

    public static string GetEnumValue(int value, Type enumType)
    {
        string result = null;

        foreach (var item in Enum.GetValues(enumType))
        {
            if ((int)item  == value)
            {
                result = item.ToString();
                break;
            }
        }

        return result;
    }

Or did I misunderstand the question.

mdm20
I am afraid you have misunderstood the question. I was really asking for suggestions and advice in how to design the user interface. The example file is also for illustrative purposes - the real file is an XML file which is quite unreadable which a lot of information we do not need). The design certainly needs to come before the code in this case!
Andy
+1  A: 

I think your variants are way too complicated. Provided there is no need to BROWSE the enums, I think the best keyboard-based interface would be having just one text field with auto-complete function and a label beside (below) to display the result.

As the user types, the program searches in BOTH values and texts and presents partial matches as suggestions. As soon as there is a match (full or maybe even partial), its counterpart is displayed. So if match is with a value, corresponding text is displayed and vice versa.

Or even simpler, just display the list of matching value-text pairs as the user types, incrementally updated with each typed character. No need to press Enter whatsoever.

Alex Jenter
+1 I love this answer (except for cases in which it's difficult to tell values and texts apart). It may not even be necessary to distinguish partial-match 'suggestions' from full matches - you could just show multiple partially-matching pairs until there's a single unambiguous match.
Jeff Sternal
I agree with your comments and I have adapted your suggestion in the design of the first window.
Andy
+1  A: 

I used a solution like #1 once. The important part it to make sure you always keep the boxes in sync, or the user might mis-read an old value as a valid translation. In my case I cleared the other box as soon as the user started typing (or even pasted) in one.

It also depend on the type of use - will this be something used frequently by its users and can allow some learning curve if it will minimize keystrokes, or something that a given user will rarely encounter?

Marc
A: 

Thank you very much for your answers. After considering all your input, I have come up with a proposal for the interface.

  • At the start of the program, a list of all the enumerated fields and their field numbers, as well as their enumerated values will be loaded.
  • The initial interface will consist of a TextBox and a ListBox. Initially, the ListBox will show all the enumerated fields. As the user types in the TextBox, the items which do not match (either the field name or field number) will be removed from the ListBox.
  • By double clicking on an item (i.e. an enumerated field) on the ListBox, or by selecting it and then pressing ENTER, a new window is displayed.
  • The new window will display all the enumerated values and their associated text (for the enumerated field selected in the first window) in a table with two columns.
  • The list is sortable by clicking on the columns. The user should also be able to use Ctrl-F to search the list (hopefully this is allowed in C# applications).

I made the choice for the initial window in order to simplify the interface (only 1 text box and list box) and to make it easy to use. Also, I think displaying the enumerated values together and allowing the user to play with the information as he/she likes, is much superior to hiding everything behind an elaborate interface.

Your feedback on the interface design would be much appreciated.

PS Currently, users have to go to a website, find the latest version of an xml document, download it, open it, and then search through the XML to find the field they are looking for and then the value they need. My application should simplify things for them immensely.

Andy