CMS Interface Logic. - Is this the best approach?

Question

I am developing a cms system. Currently I am working on the Interface for adding new menu items to a menu. (Due to the cms Logic the menus are fixed, the user can not add or remove menus, only delete all menu items and Assign menu items to menus or menu items).

To add a new menu item, the user has to click on the big area above the menus (see img 2). This will make the input fields appear. Saving your inputs will result in a new menu item appearing in the „Unassigned“ box. To position the menu item you just drag it into one of the menus to the desired position.

If you want to delete a menu item you just drag it to the trash bin. If you want to edit an item you just click it, the item will be highlighted and the input fields (like the ones for adding a new item) will appear filled with the information from you selected menu item. Just change it and click save. To change the position of an item just drag it to the desired position.

I hope everything is easy to understand.

My questions are:

Is this idea easy to use and logical? Is it the best way to do it or do you have a better idea? Do you have any comments/ideas for improvement?

img 1

img 2

// Update.

Okay, so I did a mockup. I am did incorporate all of ArchieVersace comments as I understood it. As for the edit modal box: it is just a quick sketch, so no real inputs, size, ....

// Update 10/29/2010

So my current changes:

• no Trash bin
• vertical tree structure
• add button (next to menu name, but might be repositioned)
• unassigned menu item above menus if created without choosing position before Putting 3 Menus (average amount of my projects) next to each other each has about 300px width. That should be enough, because I nearly never have a menu with more width. I will add buttons to collapse the menu, but I would have all items not collapsed at the startup (but maybe save the last preference via cookie).

I do require javascript for my cms anyway, it will not be distributed like wordpress, but sold per project, so I can require js. This means, there is no need for a fallback (save/cancel) for the menu positioning.

My user may be using the system on a nearly daily basis, but some might also update content of their webpage only every couple month. Therefore I think it should be as easy as possible. Because of this I think it is vital to include another add button which is always visible. Adding a menu item with this button results in a menu item not assigned to any menu. In this case the part above the menus could appear holding the newly created item.

Do you think this is a good idea? It will not be visible/take upspace if no menu item is just created.

Answer 1

I think that the horizontal layout of the menu could be confusing. First, it doesn't make hierarchal sense - Why is only the first level laid out horizontally and the other levels are vertical? Another problem is what happens when there are more first-level items? Horizontal scrolling isn't a great solution in most cases. I would make everything vertical and then indent sub-items as you have already done.

The trash and meta menu sections are unneeded, in my opinion. If you only have 3 inputs to fill out for each menu item, recovery from trash isn't as big of a deal. Also, the functionality of the meta menu section could be replaced by a copy existing menu when you are creating a new menu. (If it's automatically populated by all pages on the site, again, you need to think of scale). Both sections could be replaced with an edit menu item section.

Other than that, it looks great. I love the simplicity of your mockup.

Answer 2

If I just look at these screens without your lengthy explanation, it's hard to figure out what to do, what to click on and what the order is of interaction. That in and of itself is pretty telling: a great user interface generally needs minimal explanation (think of something like the iPhone or the Wii, where it's very quickly very obvious what you need to do without needing a paragraph of text to get you started).

So the first thing I would do is show these screens to a few more people (IRL) and see how they respond without your explanation. Do they get it? Do they know what they're looking at and what's expected of them here? If not - if you need to explain things - then you should consider reorganising the screens. You can do this by collecting feedback from people, or by creating a prototype of the app and having people use it (be careful with suggesting to them what they should do - let them stumble around by themselves).

The feedback you receive at that stage will be a lot more useful than any opinions people here can give you.

Also, consider that as your images are currently black and white wireframes, it's going to be harder to figure out visual weight for people looking at the design than if you increased the fidelity a bit, added color, and used typography in varying degrees to assist with how my eyes should move over the screen.

Answer 3

I can offer you help with certain interactions (as I have below) but it will only be of limited use as I do not know what you are trying to achieve. What you really need to do is state the requirements of the system. What are your users trying to achieve? How often will they be using the system? What are their skill levels? etc.

For example, an infrequent user of the system may forget how to use it between uses therefore in this case you would need to make the interface very simple to use and pick up. However if your users are visiting frequently an over simplified approach may make it frustrating as users don't stay beginners for long; they very quickly will become intermediate users who demand extra power. I am not saying you make something hard to use but for intermediate users you should not be afraid to add extra power and complexity.

In terms of the mock up you have provided, here are some specific suggestions:

• Remove the unassigned, add and trash panels as they do not offer the user enough useful functionality for the amount of space they take up.
• Put the add button in context of where it is being added too, so that the user can add to where they want it rather than adding it and then positioning it.
• When a user wants to configure a menu item show a grey box with the fields to collect the information
• Add an edit and delete button to each menu item
• Add contract and expand buttons to each level within the menu, by default all levels are contracted.
• Allow a good amount of space for longer menu items
• You should consider adding rollback options such as save & cancel buttons

Below is mock up:

Answer 4

Another Update.

I am not sure about losing the add button. Would people figure out how to add menu items easily?

Also, how would you go about making it possible to add menu items as same level or sublevel? The one right now would probably me sublevel (actually for this the button should be moved a little to the right). But how would you add a new item the same level at your desired spot?

In the footer menu I tried to show how it would look dragging a menu item to a different position.