you wrote:

> Okay, I'm all ears -- tell me about the user interface problem. What don't > you like, what would you do different? What are the problems? How would you > design a browser for an object database? Etc. (This question is not just > directed at John, of course.)

OK, you wanted to hear it, and I've finally overcome my posting shyness... ;) Take the following as *my* take, ordered in descending order of importance:

Problem 1: Too much (textual) information =========================================

A main consideration of UI-Design is not so much information presentation, but information hiding. Information should be "disclosed" in clear views, not thrust upon the user.

When browsing the odb, (a misnomer btw, more about that later) all the presentation takes place in the name|value|kind scheme. Additionally, the columns don't resize when expanding the table outline. Thus I get not only trouble, when expanding a bit deeper into the odb, as the names get cut off, I also have no clear visual feedback at which "depth" any given tablecell is. The value and kind columns go straight down and contradict the indentation information contained in the name column.

Usually, when browsing, the key information I want to see is the name and maybe a *clue* as to what kind the object is. I do *not* necessarily need the Value information, not even with strings. Mainly when I work with Frontier I work with tables, outlines, scripts and texts. I rarely need to manually change a stringconstant or a boolean.

A better UI for the odb would be more of a clay outline, that is the names (indented according to level) and a small icon denoting the kind of object. (Think QBullets). To edit an object I want to doubleclick. We would need "editors" for strings, numbers and booleans, as well as perhaps a hexeditor for binaries.

As a second consideration, most of the time I don't want to see *all* entries. I want to be able to *hide* parts of the root, and only see it when I definitely *want* to see it. Practical application: quite a few of the "#" tables and entries are irrelevant ot the daily work with the site. I don't need the system table, or at most only the verbs subtable, I don't need to see the user table in my daily work.

This is a much larger concern, when I give a frontier solution to a customer. The *only* tables the customer wants to see is the table he works with. The whole ret of frontier is irrelevant to him, and it is actually preferable if he doesn't see it, as he is intimidated by all the stuff, and afraid to change something by accident. (No exaggeration, daily experience as a consultant) The customer - as opposed to the developer - *wants* to be protected from the steaming innards of the solution you sell him.

Problem 2: No entry masks =========================

Back to the stringconstants and booleans, or "What to do with the #prefs table."

When we need to edit stringconstants or booleans, we usually have to edit more than one in context. Now we have to find each entry, click into the value field, delete the value there, (remember how to spell true ;), and the enter the new value. This procedure is bearable for frontierheads ;), not for anybody else.

What is needed is an easy, documented way to quickly design dialog boxes and data entry masks, where I can give a user an easy way to change or review his settings, without having to force him to dig for it.

MacBird might have been a solution, but as it was never really documented, nor easy in application, nor cross-plattform, it simply doesn't count.

Just to repeat: Data Masks are vitally important to any application development.

Problem 3: Menu Overload ========================

Frontier has to many menus. I don't propose necessarily a solution, as I recognize that almost all the Menus are important to be there, when they are there, and I can easily change, what I dislike, still, it is too much and not necessarily logical. Why is "comment" in the outline menu, while "breakpoint" is in the script menu, even more important, why are *both* menus active, when I work with a script? Wouldn't it be clearer if the navigation subset would be a submenu in bothe menus, the specifioc information in the respective menus, and have only the appropriate Menu show up?

Why do I have an HTML menu when browsing the odb? why not only when working with an outline or a text?

I'd suggest that you take a long look at all the menus and rearrange as needed.

Two sidenotes: 1) Navigators are nice, but why isn't there an option to make them simply submenus? That would be faster and easier. If I want the Navigator I'll open it, but usually I just need to go to one place *fast*. 2) The most important kbd-shortcuts are almost inaccessible through non-american keyboards. To toggle comments or set a breakpoint or run the selection, I need to hit 2 to 3 modifier keys, if the keyboard accepts it at all.

Problem 4: General Ugliness (sorry) ===================================

The whole of frontier is plainly ugly. I know that this might be a matter of taste, but the Interface simply lacks elegance. Might I suggest letting a graphic artist look over the whole thing?

I know this sounds almost vapid, but beauty and elegance of an interface *is* definitely a part of what makes a user-experience enjoyable or not.

-----------------------------------------------------------------------------

This has grown rather long, and probalby still doesn't cover half of the issues, but it's what I felt most important.

If you want further suggestions or clarifications, just ask.

Have a nice day, TH ------------------------------------------------------------------------- Mid Schwund muasst rechna, guada Mo. --------------------Thomas Hassan <thomash@t0.or.at>------------------- | URL: "http://www.t0.or.at/~thomash/" |

Enclosures

Replies