Take the 2-minute tour ×
User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It's 100% free, no registration required.

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?

cms ui img 1 img 1

cms ui img 2 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, ....

Navigation Tree Add/Edit Box Trash Bin

// 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.

alt text

share|improve this question
    
Lukas, I'm really enjoying the exploration and improvements you're making to your design, but I don't think this question is the right place for that anymore. StackExchange is meant for questions which can have an answer, and you're currently iterating so heavily on the original material you posted in the first version of your question that our answers are becoming outdated. Consider posting a new question if you have new questions, or writing a blog post with your iterations, forming a single question, and linking to it from here. –  Rahul Oct 29 '10 at 11:46
    
Well, I guess I did get some important feedback. I do not think though, that your answers are outdated, because all the old images are still online, so one could read and understand all the comments and why there is this specific progress. Would you not agree? –  Lukas Oppermann Oct 29 '10 at 12:12
    
Yeah, but you have to do a lot more work to understand the order of answers given and how the question has been updated. :-) –  Rahul Oct 29 '10 at 16:53

4 Answers 4

up vote 0 down vote accepted

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.

share|improve this answer
    
Well, thanks for your answer. The Meta Menu thing is a misunderstanding. It is just a second Menu. Like a footer Menu, or something. You do have to fill out more than 3 inputs but not to many more. I just like it to be able to recover deleted items, but maybe it is really unneeded. I will think about this. I do see why you find the horizontal layout of the menu confusing, but if I have it all vertically, it takes up much more space and one has to scroll always. I do agree though, that it might be confusing, any better idea? –  Lukas Oppermann Oct 28 '10 at 9:47

Another Update. alt tree

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.

share|improve this answer

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: alt text

share|improve this answer
    
I am looking forward to the mockup. I will consider your ideas for my mockup too. I like the trash bin idea. I want the user to be able to simply undo a „delete action“, even if it was not the last action he did. Removing the „Unassigned“ pannel is no problem. Actually I am not that sure anymore in which situation I thought a user would have unassigned menu items apart from the just created one. The only thing I am not sure about yet, is the mentioned way to insert data. This way the user needs to first decide where to put the menu point. But I will give it a try. Thanks for all the input. –  Lukas Oppermann Oct 27 '10 at 16:05
    
I know the mock up does not have a the trash, i will add it in if I get time. but hopefully you get the idea! –  ArchieVersace Oct 28 '10 at 15:47
    
Hey, I think, that basically we have the same ideas in our mockups. While I think I could give the user some more letters for their menu labels, I do not think you ever need that much. Menu items should bee simple and short, not descriptive. something long could be "About long companyname" but normally the menu on the webpage already limits the amount of characters. I still have a problem with the way to add items though. How do I add a same level item after the current one? What if the user does not get the idea to hover an item to create a new one? No need to add a trash. I can loose it np. –  Lukas Oppermann Oct 29 '10 at 0:07

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.

share|improve this answer
    
Hey, thanks, user-testing would be my second step. I would create a prototype for this using real interface elements. I find that it is often easier to grasp an idea using a real interface. I just did this quick wireframe and all the explanation, to give you an idea how it works. I thought that having only the text in the images but real elements also indicating draggable parts, it would be fairly easy to understand. Would you disagree? Do you maybe have another idea on how to do it in a better way? Or do you think I need to do a real interface just to figure out if it is understandable? –  Lukas Oppermann Oct 27 '10 at 12:27
    
I think the way the screen is currently set up makes it hard for me to understand without your explanation, and it might be easier to understand if it had real controls, colors, and visual balance. The best thing to do is get to a working prototype ASAP. Wireframes are great for having a discussion with multiple people about the same thing without having to build anything yet, but if you really want to test, get something working. –  Rahul Oct 27 '10 at 14:01
    
Well, so I guess I will build a real looking prototype soon. Thanks anyway. I will have it up here in some days. –  Lukas Oppermann Oct 27 '10 at 14:07

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.