Design Problem: Selections in a Subfile

[dieter]

Hello,
in our green screen application we typically have subfiles with numeric seletions above the subfile. E.g. the subfile shows our customers and above the subfile we have the selections 2=Edit, 3=Copy, 4=Delete, 5=View etc. Has someone an idea, how this functionality should be realised in a graphical user interface? We have built a context menu for the subfile. But the menu is not operable by keyboard. The user has to handle the menu by mouse. Another idea is to set a dropdown box in every record of the subfile. The dropdown box would contain the program functions which are possible with the record. In some application we have many selections (more than 40) above the subfile.

I am interested how other Profound Users have solved this problem.

Dieter

[mpilo0]

We are having the exact same dillemma we have thought of a few solutions but none of them seem ideal for screens with many options. If anyone has ideas we'd also be happy to hear them.

[David]

My opinions on this...

If you look at a typical GUI or Web application, this type of thing is usually done with the mouse. For a small number of options, you find one of these approaches, usually:

1. For single selection, a small set of small icons (pencil=edit, magnifying glass=view, red x=delete) next to each row.

2. For multiple selection, a set of larger icons above the list, then row selection to mark items, then click icons.

3. For either, a context (right-click) menu can be used.

If you want to retain ability to navigate the lists with the keyboard, using a combo box is the only way, I think. Users who want to type the options can keep on doing that, others can use the pull downs.

I think, though, that if you look at applications that are designed for GUI from the start, you'll find that this sort of thing is typically NOT realized in a GUI. It's why we're scratching our heads here to envision what it would look like. The navigation is somewhat reversed from a green screen.

Rather than asking the user "first, find a record, then pick from 40 things you might want to do with it", the application asks "what do you want to do? ok, now lets find a record to do that with". So the user selects the "what" by clicking something on a nav. panel, then a list comes up to select the record for that function. When the record is selected, the user can then select from the other functions to perform on that record by clicking again on the nav. panel.

[Brian]

Another thought

If you are going the context menu route and have too many options, you could possibly set up your context menu with submenus.

So if your different subfile options can be categorized, you can then have top level categories with options underneath. To specify sub menu options, use a dash "-" before the option in the Choices property. So your choices property could look like this:

Record Management,-Edit,-Copy,-Delete,Orders,-Open Orders,-Order History,-Backorders,Credit Management,-Credit Limits,-AR Aging

Which would look something like this:

context_menu.png (5.54 KiB) Viewed 639 times

You can even go multiple levels deep. To do a second level menu, just use two dashes before the option. Does this help?

[dieter]

Thank you for the answers. I know that modern graphical user interfaces normally behave different from green screen user interfaces. When we write totally new applications we do not have a problem with selections in subfiles because our applications then will be fully designed for using a mouse. But we can't renew all applications. So we want to give the users the advances of Profound applications by only renewing the subfile selection program of a application. So we are looking for a way to integrate a new graphical subfile selection program into an "old" application. I am afraid that the users are not happy if they allways have to change between mouse and keypad.

We now have the idea to put an combobox into every subfile record. In this combobox we want to fill all possible selections e.G
02=Edit
03=Copy
03=Delete
...

Then the user either can select the choice by using the mouse or he can type the choice by using the keypad. So if the user types "03" the copy-Option would be executed. And we think it could be convenient for the user to type the text of the choice. E.g if the user type "del" the combobox should present only the choices which contain the string "del". Unfortunately the comboboxes do not support this very good. If we fill the choices and values by a bound variable there ist no possibility to do a "contains match". (I hope you can understand my poor english.)

Dieter

[Scott Klement]

I think the combobox is the best compromise between old-style functionality (type a number) and new-style (mouse selection).

I would not try to make it possible for the user to type the text of the selection (that doesn't make much sense to me... they should be using the numbers... I can't see why the user would want to type "delete" instead of just "4"). I would make the leading zero optional, however.

[dieter]

The reason for typing the text is that the users can easily find the option. In some subfiles we habe more than 40 selection options. In green screen the user has to press f23 to read all possible options. With a Combo box we could abstain from showing all options in the screen. The user may think 'i want to copy all orders' so he can type 'copy' . Then he gets the choices '03=Copy the customer' and '33=Copy all orders'. I think this is more convenient for him than searching all options of the combobox. And he can do this by using the keyboard. Of course if he knows the selection number he can type the number 33 directly.

Dieter