Suggestion: C3 Menus

  • As I've been exploring C3 (coming from C2), one thing I've found is that the menu system is affecting productivity - particularly coming from the easy ribbon approach of C2.

    I'm not sure if there's plans to revamp the menu system, but with things like "Guided Tours" oddly being made the second most important menu item, it seems a good time to reorganize things. I had a little spare time and wanted to offer some suggestions to build the menus more around workflow.

    Maybe other users have suggestions as well. Food for thought, anyway!


    • Fewer, deeper categories: easier to navigate and read
    • Organized by frequent use: your user data will help this
    • Removed most icons: they take up space, only repeat the words
    • Reduced remaining icons: arrows, checkmarks, etc.
    • Consistent language and icon placement



    • All options are now in categories, no random options
    • Moved "Bars" to the Root menu, due to frequent use
    • "Settings" for the dev environment
    • "Construct" for the program as a whole



    • Order of options revised for efficiency, frequency
    • More consistent order and language in Save As / Open menus



    • Order revised for frequency; put the two reference options at the bottom
    • Checkmarks moved to the right for consistency, ease-of-use
    • Removed the word "Bar" from the options



    • Grouped all project-management-level options into one category (export, addon, storage)
    • Old "Settings" renamed to "General"



    • Grouped all non-project-related options
    • "Start Page" and "Guided Tours" grouped as starting points



    • Order adjusted for frequency of use

    There's definitely more to consider besides one person's use case (education, younger audiences, first-time users, etc), so perhaps menu customization is part of the answer. These are some suggestions on how to gear the menus toward workflow efficiency, hopefully for all users.

    Thanks for your time!

  • I think some aspects of this organisation are more confusing. Having "Construct" as a main menu item inside Construct itself seems odd - isn't everything else to do with Construct as well? You've also put a bunch of things in the Settings menu that are not settings, it's become more of a general purpose "miscellaneous". The frequency of use is probably significantly different between users too - for example personally I almost never use the "Bars" menu, it's only there because if you close a bar, there needs to be some way to bring it back.

    UI design is hard and it probably won't ever be perfect, but the existing ordering is modelled after de-facto standards for menus: "Project" is basically "File", then there's also "View", "Settings", "Help" and "About" in the top level, which is similar to most existing software. Also the more you diverge from what existing software patterns do, the more confusing it is for beginners.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • Thanks for the reply! Totally agree that this isn't easy; it's part of what I do for a living. It's definitely not something that one person can solve, and my suggestions are to show what can be improved: the benefits of reducing visual clutter by reflecting workflow habits.

    To me, there aren't enough options that deviation from the norm is a barrier. Or at least a bigger barrier than workflow barriers we currently have.

    For example, while C3's "View" technically contains anything you can "view", which by that logic should include Settings and Scirra Store. However, most of the options in View —when judged by the user's intent — are things we want to "Configure": addons, storage, etc. Similarly, the Start Page isn't something to be "viewed", it's where you open a new project or a tutorial.

    So in my example, the grouping is the main point; the labels can totally change. To your point, "Settings" should be changed to "Configure", and General back to Settings. But all the items in that menu are grouped by user intent to Configure, as above.

    (And I agree that Bars is probably user specific, and perhaps is actually best as a little icon next to save/preview. Though that's getting back into ribbon terrain... :)

    In the end, of course, it's just the menu. I only want to show that this portion of the platform could be improved. Perfection is a series of small things done well, and all that. I love construct, and these kinda things can help users enjoy it more.

  • I am totally against some dropdown menus with submenus, where you have to navigate mouse like some maze.

    There should be extra menu button/arrow icon, near your username. You can click on it and single menu appears with simple icons and options. With 2 clicks you can get access to all settings.

  • Less is more with context menus. It's super annoying to try to find something in a sub menu only to have the whole thing collapse if you move the cursor the wrong way.

  • Actually a better reason not to make any significant changes to this is because it would make a mountain of documentation, tutorials, videos, lesson plans etc. out of date and all need updating. That creates a huge amount of work for us, and much of it (notably third-party content) will likely never get updated. Then there will be a steady stream of confused users for years to come. We still get people asking where the function plugin went, for example.

  • Completely agree; the proposal above has only one more dropdown menu than we currently have, and it's just to more logically organize some of the scattered options.

    But believe me I'm a huge fan of the quick-access that a ribbon, photoshop toolbar, or dropdown-style that SnipG suggested can provide, which would help a ton. Someone else brought up how the Grid options had been moved to layout properties; this causes a lot of workflow problems because there's nowhere else in the reduced UI for it to go.

    But I don't think it's a good idea to use the Root Menu as a catch-all at the cost of a submenu. The placement of Guided Tours and Install as App are good examples of that; there's no logical place for either of those in the current submenus. If Root Menus do have standalone items in them, ideally they're be the ones most used.

    EDIT: Sorry, just read your post Ashley. It's a fair point, and while the past might be too much work to change, perhaps there's a case then for a redundancy option – quick access to popular tools – as above.

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)