Thanks for the suggestions Craig.

I have a few questions:

1) Where can I get a reference (not super detailed) on "current user experience thinking". I did some searches but had to wade through a lot of stuff I didn't need. I ordered some books on amazon.. waiting for them to arrive, but in the meantime web resources would help.

2) What is the history of using "new/open" and treating the entities in a system as "documents". Is this somehow tied to OOP? What is the rationale for it? My point was that it seems misplaced for a transaction processing system, which, to me, seems fundamentally different in what it does than say a word processing system, or spreadsheet software. My point was that it doesn't seem to work very well, or be very helpful as a model for organizing the information.

3) I fully understand the idea of, and the value of engaging the users in the design, and understanding their naturual language in explaining/modeling the entities they work with. However, that said, and not to be glib, but I think that in this case engaging the users in the menu design would not be helpful for my purpose here. My goal is to use the latest principles of interfaces design, with PROVEN BENEFITS, in terms of efficiency for both the end user and the developer. I don't want to just blindly copy the same old tired interface, or do it the way everyone else has done it, just because that's "the way it is done".

4) The application is used in a fast paced environment with 60 to 100 users of varying skills, from users with limited English skills, who do a repetitive task in the system, to "power users". So my goal is to present a unified interface for all the users that is really efficient. Take, for example, the common practice of repeating menu or screen elements multiple times in an interface - .e.g a file menu with the words "open, new, save" and then repeating the same thing on a toolbar. What is the rationale for that? To me, intuitively, it seems inefficient. I guess the idea might be to have a gui based presentation and a text based presentation. But to me it is just clutter. Ease of use seems to be driven, in part, just by virtue of whether something has become an established standard, ubiquitous, and expected, regardless of whether the idea is any good to begin with. "Standards" seem to evolve and change quickly, i.e. they are barely standards, and users seems to just get used to the latest interface "fad". So, the outlook style panel, or word "ribbon" might be the latest design, but, how has it improved ease of use, ease of adoption, maybe it has, but for me, I just don't get it. That said, I'm eager to be proven wrong, i.e. to be shown why MS's modern interfaces are better, and bring benefits.
In fact, part of the impetus to a potential rewrite is to improve the application. I've got some pretty sophisticated people in management here who want concrete reasons as to why we would need to rewrite, redesign the system. Hopefully I can give them something more concrete than "well that's just Microsoft's latest interface - everybody needs Microsoft's latest interface" (and then mutter under my breath, how else do you think Microsoft and I make a living)





>MDI means Multiple Document Interface, where you have multiple forms open at a time. Current UX (User eXperience) thinking is that MDI is a thing of the past. Current thinking is something like Outlook, where you have a single Window and different "panels" that are selected, but only one active at a time.
>
>As for how to organize things, you should talk to the users. Ask them what terms they use to refer to things. How does their workflow work? Do they consider "maintain" as something they do? If not, then don't go there.
>
>Maybe you can mock up two or three ideas. Just do it on paper or a whiteboard and run it past your users.
>
>>I just inherited a large VFP app. A rewrite, either in dot net, or VFP is under consideration.
>>
>>I have an idea of how I would like to see the user interface overhauled, but I would like to kick the ideas around, validate them with others.
>>A lot of my notions of what a user interface should look like come from my use of AccountMate (vfp based accounting software).
>>I think it's a good interface, but I'm sure others have opinions on this.
>>
>>Starting with the app to be overhauled: It has the classic menu and toolbar structure, i.e. a file menu with New, open, close, delete, save, save as, print choices, and those are repeated on the toolbar.
>>It's an order entry system, but not for the classic warehouse/distribution/widgets, but close enough.
>>
>>Upon clicking the New button you are given a choice of what 'new thing' to create - account, store, distributor, order
>>Upon clicking the open button you are given a choice of what to 'open' (roughly the same choices as new)
>>I suppose I should know the terminology or design principles that go with this design - but I don't. I guess it's "MDI"
>>but, from a practical standpoint and my basic understanding, it's an effort to treat the order entry system (or any other system that's not a spreadsheet or a word processor) as a set of "documents" that can be created or modified. I used to be fond of this idea - but now I'm inclined to think it is misguided. In a word processing system or spreadsheet system you create ONE type of entity a document or spreadsheet. In an order entry system you have NUMEROUS types of entities - CUSTOMERS, SUPPLIERS, ORDERS, STORES, ACCOUNTS, USERS, TAX CODES, ETC, ETC AD INFINITUM.
>>
>>So, to restate, when you click on new you are given a list of the "entities" you can create new, and the same for open. This seems inefficient. It seems like it would work as an interface design for the case where you only have a few entities. Take VFP for example, what do you get when you click on "New", a very lamely constructed form with a zillion radio buttons of vfp objects.
>>
>>Now, compare this with Accountmate. There is no EXPLICIT concept of New or open, although there is an implicit concept.
>>Accountmate has a Transactions Menu pad and a "maintain" menu pad. Maintain gives you a list of things to maintain, things that can be added, edited or deleted that are not SYSTEM TRANSACTIONS. A new customer is fundamentally different than a new order.
>>So customers, suppliers, stores, etc go under maintain. Sales Orders, Purchase orders, global price changes, things like that go under transaction. Then, once you open the "thing" screen you are presented with an empty form that will let you either open an existing thing or edit an existing thing. This makes sense. From the empty form you key in the value or lookup string of the thing you want. If the system doesn't find it it asks you if you want to add it, if it finds it, it presents it for editing. This fundamentally makes sense in terms of work flow. For example if you have a customer on the phone, you want to "look them up first" to see if they are in the system - if they are,bring them up, if not allow adding them. It makes no sense whatsoever to blindly choose a "new" option.
>>Just as importantly, it seems that it makes much more sense to choose the entity that you want to work on, first, and then, second, "flow into" whether you want a new one, or to edit an existing one. Why would you want to FIRST choose New or Open, and then choose the entity type?
>>
>>I'm sure that I don't know enough about OOP to understand the value or underpinning of some of these design concepts or choices. Can someone help me out here on how OOP relates to this discussion?
>>
>>So, in short, there is an opportunity to drop the "new, open document model" in a system rewrite. I say drop it. What are your suggestions?