2

I'm making a restaurant menu editor. There are menu "items" and they have "options". For example Turkey Sandwich or Hamburger would be items and lettuce, tomatoes, onions etc would be options.

Restaurant owners need the ability to add/remove/edit menu items, add/remove/edit options and edit/see the relationships between the two. That last part is where my current design doesn't work at all and I'm looking for suggestions on how to improve it. Current dysfunctional design

Currently the user can select a menu item (Burger in the image) and check the checkboxes next to the related options (Onions, Tomato, Pickles, Combo meal in the image).

Both of these lists can get huge - some restaurants I've dealt with have 200+ items and 100+ options. Options tend to be very similar for a group of items (all sandwiches may have a Tomato option)

There's even more weird stuff, such as options can be related between themselves, such as you can choose one of several sauces but that's handled separately right now and that's ok - mentioning it just in case you come up with something about that.

3

I can't find any good modern writings on checkboxes in über-long lists with academic weight, but personally (sorry 'bout the subjectivity), I find it very hard to get an overview in these scenarios. Yours doesn't seem to be any different, though I find it a bit hard to follow exactly how this is being used.

As I see it you have a couple of problems here, and maybe they should be discussed separately:

  1. Information architecture
  2. Managing the content
  3. Sorting and filtering

Information architecture
Something appears to be broken in the structure as one can find both Combo meal and Tomato on Burger, where I guess Combo meal is something that a burger can be included in while Tomato is something that can be included in a burger.

A logical approach could be to introduce a hierarchy where a meal (such as combo meal) has several "items" and items has several "options". That would reduce some of the mess.

Managing the content
It might be wise to build the interface more like an old-school list builder, with a procedure where you add/remove options to/from items rather than enabling/disabling them; instead of checking the Tomato box on Burger, you click Add on Tomato when you're in edit mode on the Burger. The benefit is that once you have made your initial setup, it's a lot easier to check what you have on the items respectively. The exact same approach can be used when dealing with Meals (sets of Items) See deeply flawed wireframe for example: enter image description here

Sorting and filtering
Since you say both lists of Items and list of Options can be very long, sorting and filtering becomes very important. The item list could probably be divided in to groups to narrow down the sets the user has to deal with while browsing. Maybe Mains, Sallads, Sides, Sauces, Beverages, etc. Same with the Options. You can add "Browse by group" (Sallad options, Sandwich options, etc.) "Browse by type" (Proteins, Vegetables, Spices, etc.) and "Browse A-Z" or something like that. Search can also be a good feature if it's common that the user knows what there is to find rather than browsing for suggestions.

Like I said above, there is not much to go on when it comes to the user scenarios here, but I hope it helps. If I'm completely off, maybe you could add a bit more meat to the bone...

  • what you call "information architecture" describes what I call "order": a list of menu items with their respective options. I've searched for a while and I couldn't find a good model on what a restaurant order should look like, mostly because it's messy in its nature. For example you could define a menu item for each different combination (obviously not a good plan). – Sten Petrov May 15 '14 at 21:05
  • the reason why I went with checkboxes was so that you can select a subset of menu items and check/uncheck options for a lot of items at once; The benefit of this is lost because of the unclear intention of the UI tho – Sten Petrov May 15 '14 at 21:09
  • Are you sure? I was more referring to not mixing up hierarchy levels, or actually, establish a hierarchy. But you may be right, possible misuse of the term. – Babossa May 15 '14 at 21:11
  • Haha, it's so confusing with the double meaning of the word 'order' in this restaurant/ux-context. I don't understand :) – Babossa May 15 '14 at 21:13
  • Here's a more complete view. Menu is presented in two ways: for clients and for owners. The menu items are structured in a tree based on categories assigned to them, but using tree for the owner view complicates UX even further. Clients see the hierarchical structure. Data is stored as flat list, hierarchy is determined by an item field, which refers to a food hierarchy (tree) structure. There are many ways one can structure a "Hamburger with cheese and fries", I've only shown one sample. Owners need to be able to add/remove daily specials, so a good UX is badly needed. – Sten Petrov May 16 '14 at 18:17
0

I have answered a similar question here.

Basically there are concepts in front-end development frameworks like Foundation and Bootstrap framework that provide UI components to build a richer/complex interface behaviour. You can see some examples for Button Groups in Foundation and Nesting Buttons in Bootstrap and how they can be tailored to suit your specific needs.

  • It doesn't look like you read the question at all – Sten Petrov May 15 '14 at 21:11
  • Sorry if the answer seems a little bit obscure, but what I am suggesting is that you don't use two separate lists which are more difficult to navigate and associate together, but that you try and use more advanced controls that will give you more functionality than just a check box list. By combining button bars with dropdown buttons you can put both interactions in the one UI control. – Michael Lai May 15 '14 at 22:23
  • It still doesn't look like you read the question or at least I'm not understanding your idea. I said both the lists can be very large, I don't see how to make such "advanced controls" – Sten Petrov May 16 '14 at 18:11
  • I think it would be hard to explain without building something in CodePen, but the idea is that you can create more sophisticated levels of hierarchies with your UI controls with some of the new design frameworks. This means that you can make a control a button map which also contains multiple button maps or groups. This will allow you to categorize the options according to multiple groupings, and for the user to navigate or select them in different ways. – Michael Lai May 16 '14 at 23:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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