Another nice feature for MB is making background images responsive. For example i have a menu I am trying to build that has a green spotlight oval image I want to come active when you hover over the button. Works great except for when you shrink the menu down it doesn't shrink the image it just truncates both sides.

It would be nice to be able to have the option use images instead of only text as the buttons.

I just edited my menu with the newer rebuild and am having the same trouble with Spanish accented letters. They previously showed up ok the site but now they have that ? symbol.
Thanks
Alison

Some pop-up blockers stop windows from opening when they use the target value _blank. You might consider adding a target value of "Other" which then opens a box where the user can enter the target window name.

Brian,

Out of curiosity what is the full link to the page that was blocked?

When working in the menu builder, this would be a great time saver:
After having selected say 'menu buttons', we may want to work our way through them one by one, and if it were possible to skip to the next button just by clicking on it, and the right tool panel would change along with it, that would save time and energy (maybe different icons but some settings being the same), especially if we run into problems and have to double and tripple check.
I would like the same to happen if e.g. the submenu buttons, or any other subsubs, were selected.

I'm aware of the kbd shortcuts to Menu and All buttons, but there are no shortcuts further down the hierarchy or for individual buttons.

And while I'm at it, here's another enhancement suggestion: A preview button in the top tool bar!

This has probably been mentioned before, but we are still waiting for it. The kbd shortcut only takes us to the 'default' browser, if we want one of the other ones, we still have to go the long route.
The other new programmes from CC all have a preview button, so it's only fair to have one in the MenuBuilder as well.

I haven't actually seen it happen in some time. Back when pop-ups were being abused and the blockers started coming out, they blocked any window that opened. If you used _blank to open a new window, it got blocked. Therefore, I got in the habit of not using _blank; rather, I named every new window. Therefore, my thought was not prompted by it happening. Instead, I thought about it from the way things have happened in the past.

The more intuitive a program whether by sight or by built-in guidance, the better the experience.

In the elements menu (where you create the menu), consider this from a new user's perspective. it is possible to:
1. Create Buttons and Submenus
2. Change a button to a submenu by moving it in (but it still says button)
3. Change a submenu to a button by moving it out to the top level (but it still says submenu)

The tutorial at http://www.coffeecup.com/help/articles/ … ld-a-menu/ doesn't make a distinction between buttons and submenus. It says they are interchangeable. ("To create a Submenu, just select the button you want to put into a Submenu, click/hold and drag it slightly to the right, under the menu button where you want it to appear.")

I've been using MB for awhile, and I still don't know if there is a functionality distinction between button and submenu other than position.

A good video game (bear with me) introduces a character to how the controller works as they play the game. By the end of the first level, the user knows the basics of the game without having to read instructions.

IMO, the elements window is one of those introductory levels where the user needs more guidance. It's the first window a new user sees (beyond picking horizontal or vertical menu). They probably will not have read the documentation yet.

With this in mind, you might consider one or more of the following.

1. In the area below where the user enters the URL for the menu items, you might include a link to the 'Getting Started' page. I know this already exists in the help menu, but many people initially don't think to look there as plain as that should be. This link will be especially helpful for new users.

2. Define the distinction between buttons and submenus in the online documentation and possibly in the elements window. This is especially important if there really is a difference in the functionality of the two.

3. If there really is no distinction except position, make the words "Button" and "Submenu" in the Elements window change based on position. If it says "Submenu" and it is moved to the top level, make it say "Button." However, if the user has changed the wording, it needs to remain the same.

I'm quoting myself here, because what I want to write here has directly to do with the quoted suggestion:
In the property panel for any buttons, being it main or sub or subsub it would be nice to have an option saying 'Inherit from parent' and one saying 'inherit from sibling'. That way, several buttons could be formatted at the same time, another great time saver.
I think actually that I've seen someone else suggesting this, but I can't find it. Therefore I thought of mentioning it here.