The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

UI suggestions for my drop down menu

I tend to “follow” how most windows applications work in terms of my drop down menus.

So, for Excel,  for Word, for Outlook etc, in fact just about all applications you go


Often, you get another sub-menu of things that you can find.

The above dialog lets you “search”. So, for a considerable amount of time I also always used the above approach.

The problem of course is that while this leverages the users mental model, it also makes a extra step.  So, I would rather put the “find” sub-menu options in the “edit” menu. This saves a nice extra drop down menu step, and is some what quicker. Like Joel’s shopping cart example in his UI book, this simply makes things a bit easier.

However, it also breaks a bit with established products.

So, what do I do? Keep the extra menu that most applications have, and annoy users a bit, or simple remove the sub menu and break what most UI have now?

A screen shot here:

I just moved the drop down sub-menu items to the “edit” menu in the 2nd screen shot…but did not remove the “find” sub-menu (which I would in production)..

So, should I break with existing traditions to save one menu traverse here?

Albert D. Kallal
Edmonton, Alberta Canada
Albert D. Kallal Send private email
Tuesday, November 01, 2005
I find your revised version easier to follow than the original "correct" one. I'd have to think for a bit before looking for those items under "Find", but it's obvious what they're there for when they're in the main menu (with a separator and with their icons).

Hm... in fact, looking for those things seems central to the app. Should it be in an "Edit" menu at all? Is it more "View" or something?

My $0.02
EKB Send private email
Tuesday, November 01, 2005
I think that because your Edit menu is so short anyway, you should put all of the options on the one menu.
Daniel S
Tuesday, November 01, 2005
MS Office is coming out with a new menu paradigm, the "ribbon," there is a movie about Office 12 on MS Channel9:
Ben Bryant
Tuesday, November 01, 2005
Thanks Daniel, yea…I really should not fret over such a minor detail….

I think I just move the stuff to one menu, as it is so short. My brain just sees all the other office apps working slightly differnt. I can't iminage my users will even care, or notice...

>MS Office is coming out with a new menu paradigm, the "ribbon,"

Yes, that is a interesting issue, since all users currently think in terms of existing interfaces, this could well pose a change for me.

However, I should add that those screen shots and this applicied is built in ms-access. So, when I get the new version of ms-access, then I’ll get the new UI anyway.

However, for the time being I will keep a similar look and feel to office as it is now…

I deploy using the access runtime, so if I desire to upgrade clients to the new look, I can, and they will not need to upgrade their current version of office anyway.

Albert D. Kallal
Edmonton, Alberta Canada
Albert D. Kallal Send private email
Tuesday, November 01, 2005
I don't think that is a problem, in fact I think it is perfectly appropriate and will fit into the mental model just fine. However, I would take it a step further and add them directly to the Edit menu. Edit > Find Person, etc.
Tuesday, November 01, 2005
+1 For putting them right in the edit menu.
Almost H. Anonymous Send private email
Tuesday, November 01, 2005
I'm somewhat curious why you call it "find" in the menu but "search" on the form. Yeah, convention and all that. I say screw convention (seems to be all the rage these days)! The search function appears to be a rather important part of the program. I'd make a separate top level menu for it (If I have menus at all). Then again, I'd probably find a way to put the search box (at least a basic one. Maybe have it return the top 10 results in each category of items) on the main form (there's so much empty space to use for it) instead of behind a button.
Chris Altmann
Wednesday, November 02, 2005
>I'm somewhat curious why you call it "find" in the menu but "search" on the form.

Gee, find and search. What a great observation. You are right, that is a inconsistency here. One that I had for years, and not thought about. The button, and the menu option is the same option and function here – again good observation on your part.

I should note that the screen is not yet finished being laid out (the paint is still wet). However, it is based on a previous code base. There will be a few more buttions on that screen.

Since I am dumping the find sub-menu, then this silly “find” vs “search” issue goes away.

I guess I just like the word “search” better then find.

The use of the word “find” implies that the user has to go and find something. The use of the word “search” implies that the computer is going to go and search for you. Well, at least that is how I think some users perceive the use of the term!

Likely, this again is a non issue, but at the end of the day, I got to choose a consistent term (so, good point on your part).

I like “search” better, but I likely will stick with “find”, since that is what everything else uses (Excel, Outlook, Outlook express, Word…etc.). And, if I do have to expand, or break out the options into a “find” sub-menu, then again I can follow the other office programs in how they look and feel…
>(there's so much empty space to use for it) instead of behind a button.

Yes, very true.

However, that real estate is used for a “web” type shots display when the application starts (each time, you get a different picture). The customer can put pictures in a directory, so, they put in pictures of their Christmas parties etc. Further, I always ship with some nice default ones, and ones that tend to “reflect” the particular industry.

I added two more screen shots to give you and idea of what I mean by different pictures.

That main “form” is my “branding” screen for the customer. The title text, the color and color gradients, the logo, and even the color of the main text is actually a config file here.

This confile file is outside of the code base, and I only have to change the config file to create this title page (or change customer licensing options). So, for new customers, I just change this config file, and they have a new logo, name etc, and I don’t have to touch the code base.

I should point out that this “config” file is my license key that I email, or ship to them. I create this config file with a program of course, but in the future, the logo, and other information could be customer modifiable.

So, this page essentially “brands” the product to the given customer. So, they can copy the program, but they can’t change the config file (I got some encrypting stuff in it). So, the result is that what I ship to the client really becomes “their” product, and solves any issue of piracy for me. (they can easily copy the program, or install on other computers, but the setup of customer name etc. is set in stone for them. (I use Inno installfer for this whole mess).

The last screen shot shows the about screen, and you can see things like expire date, and customer name that is part of this license key/config file…

Albert D. Kallal
Edmonton, Alberta Canada
Albert D. Kallal Send private email
Wednesday, November 02, 2005
Regarding "Search" Vs. "Find," ask around, but I'd be surprise if people in general feel "Find" has more user-active connotations than "Search" (e.g., I am most active when I search for my car keys). I'd go with the term that best characterizes the feature based on people's stereotypes developed from commonly used applications: "Search" looks behind the scenes and presents a list of matches (like Google). "Find" looks *within a page/document* and moves focus to the matches (like MS Word or Internet Explorer).

But back to your main question, I agree with everyone else: go single menu, given you've so few menu items. Cascade menus are a pain. However, I am concerned that, once the Find menu item is removed, your users may not realize that menu items captioned Contacts, Pubs, Drivers, Guides mean *searching for* Contacts, Pubs, Drivers, Guides. Might they think it means *editing* Contacts, Pubs, Drivers, and Guides (they *are* in the Edit menu after all)?

One solution is to include the word "Find" (or "Search") in each menu item caption (so that issue is far from academic). It’s probably best to have it at the end  (e.g., Contact Search, Pub Search, etc.) so experienced users see the key discriminating word first. Including "Find" in the caption will also make it compatible with conventional Find seen in Office applications: Users looking for Find look in the Edit Menu out of habit, and, why, there's Find. Oh, there's *lots* of Finds. What's to confuse?

As a second alternative, I want to encourage you to seriously consider Chris Altmann's suggestion to make it its own top level menu. You've so few menus and all that wasted space at the top, so use it. Yes, many users expect Find to be in Edit, but when they slew the pointer up to the Edit menu and see Find/Search right beside it, I don't think they'll be confused. Meanwhile, users who don't expect it to be under Edit, won’t go searching through dead ends like File and Tools --their first guess on where Search is will be, um, under Search. I think a separate top level menu is especially appropriate if this is indeed a Google-style Search, rather than a Word-style Find, irrespective of what you see in Windows Explorer. Traditionally, the Edit menu is limited to commands for selecting elements within a page/document (Find, Select All) and modifying them (Cut, Copy, Paste, Undo). Google-style search doesn't fit with that.

As for the Office 12 Ribbon, it was designed to handle problems presented by applications with hundreds of commands. I don't think you have the problem. Indeed, if you were to use a Ribbon, you'd might only need one tab… which, come to think of it, wouldn't be bad at all. Why make users hunt through abstract and cryptic menus like "Tools," when you can have all menu items *right there* to see? Do you have 20 or fewer commands? With the use of separators, that won't be too much for a single menu. Hell, you can do that now with the current version of Access: Have *no* menu bar, but instead have a single toolbar with labeled buttons for all your commands.
Michael Zuschlag Send private email
Thursday, November 03, 2005
Gee, thanks for the input Michael

The “find” menu on its own solves a good deal of problems. I don’t have to “repeat” the find word each time as you mentioned.

Yup…I am sold, and the find is going to its own menu. If anything it will be MORE clear then hiding it under edit anyway.

Great idea here guys, and had made this post worth it weight in gold.

As for the new ribbon interface? The only “possible” issue here is consistency, and a same look and feel. I have to agree I am no where near needing a ribbon UI.

And, for using tool bars in place of menu bars? Well, I have a lot of context sensitive menu bars. Each form tends to have its own menu (a good many share the same one). I am just not sold on tool bars that much (but for any frequent command, they do make sense, and will keep the idea of tool bars I mind).

Albert D. Kallal
Edmonton, Alberta Canada
Albert D. Kallal Send private email
Thursday, November 03, 2005
I didn't read any of the text in this thread (lots of words), but I clicked the link and it looks perfect the way you have it shown.  Don't bother changing it. ( <- my opinion)
pds Send private email
Thursday, November 03, 2005
I agree with Michael. But another thing, does Ctrl-F work?
Saturday, November 05, 2005
>I agree with Michael. But another thing, does Ctrl-F work?

No, ctrl-f does not. And, the reason is that you got 4 (and more coming) option to choose from the sub-menu.

Note that while Excel + Word use ctrl-f, note that some products have a sub-menu for the find dialog. (outlook express is a good example)

Albert D. Kallal
Edmonton, Alberta Canada
Albert D. Kallal Send private email
Sunday, November 06, 2005

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz