Symphony.

In the current menu there are 12 terms in the following structure.

• Content
• Blueprints
  • Pages
  • Components
  • Events
  • Data Sources
  • Utilities
  • Sections
• System
  • Authors
  • Preferences
  • Extensions

The largest inconvenience for me is menu jumping. Mainly transitioning between the components area and pages. To me a more convenient work-flow would be as follows:

• Compose
• Create — Single menu item. These would be on the same page similar to the current components page.
  • Views (Old Pages)
  • Utilities
  • Events
  • Sources
  • Collections (Old Sections)
• Configure
  • Users (Old Authors)
  • Preferences
  • Extensions

I’m not sure about the main headlines (Create / Configure) as the names of custom sections will most likely be nouns and not verbs. But I have to say that I really like Collections.

The largest inconvenience for me is menu jumping. Mainly transitioning between the components area and pages. To me a more convenient work-flow would be as follows:

I am a bit puzzled, aren’t your two layouts exactly the same (with exception to a few new names and an “Components” item that’s planned to be dropped anyways)?

@phoque Well, not really. The Create menu would be a single link and Views, Utilities, Events, Sources and Collections would all be on a single page. This would limit the number of clicks.

@nils To me a menu should drive home what you are trying to accomplish. I chose verbs because they denote some form of action. “I want to create an event or configure a preference.” It is more descriptive. Where as blueprints or system doesn’t give the user any indication of its function. If I’m a new symphony user I would have to think about what these mean because they are void of action. I have to go searching. But if at the very least I knew I wanted to create something I can go to the create menu and check it out.

Views, Utilities, Events, Sources and Collections would all be on a single page. This would limit the number of clicks.

This would be a UI nightmare, in my opinion, and would severely cripple the system’s functionality. If clicks were the only measure of usability, we’d just spit everything onto one page and call it a day ;)

I chose verbs because they denote some form of action.

I tend to prefer verbs too—just look at the site nav above ;)—but I feel like Compose and Create are not distinct enough to work in this context. It’s not clear why each is what it is, and you could conceivably swap them in your scheme and they’d still work. Alternate suggestions?

This would be a UI nightmare, in my opinion, and would severely cripple the system’s functionality. If clicks were the only measure of usability, we’d just spit everything onto one page and call it a day ;)

True, It would be a nightmare and it would look ugly. Now I’m wondering why I even suggested it. Thanks for bringing me back to reason.

I tend to prefer verbs too—just look at the site nav above ;)—but I feel like Compose and Create are not distinct enough to work in this context. It’s not clear why each is what it is, and you could conceivably swap them in your scheme and they’d still work. Alternate suggestions?

Create -> Build, Construct, Design
Compose -> Write, Publish

Ah, I totally missed the thing that said

Single menu item. These would be on the same page similar to the current components page.

I don’t think I would like that either. :-)

Now I’m wondering why I even suggested it. Thanks for bringing me back to reason.

No worries. Just return the favor when I do it ;)

Speaking of clicks though, I love the extension that puts a ‘Data Sources’ menu item directly under Blueprints. (rather than having to click thru Components at find another, smaller UI target).

@ashooner: this is already done for 2.1, all component items are split into its own pages.

I have to say that I find “pages” a bit confusing as well.. I worry what would happen if I created “Pages” as a “section”… My brain might explode.

Pages > Views makes perfect sense to me, but I’m from a development background so it might not suit all.

Sections is a weird one. It’s actually quite a good way of describing what it is, only the word is already used so much in web-building that it does introduce an ambiguity. Models would be accurate, but that’s really developery so I personally think “Content Types” or “Modules” sit in the happy middle ground?

Talking about Utilities, I think something like Services would work better. An appropriate name could be Libraries as well. Each XSLT template can consume one or more services (e.g. retrieving articles, loading typography enhancements, etc…) by importing one or more libraries.

I don’t think Services would work well here. Whenever i hear of a Service, I think of a third-party api i can use to retrieve information, not something that I would necessarily think of being in the Symphony backend.

Still trying to figure out why Pages is really confusing. To me it makes sense, especially in the grouping it is in (though it could be b/c i’m so used to this terminology already).

I personally think “Content Types” or “Modules” sit in the happy middle ground

I think Content Types maybe a good in place of Sections, though not Modules. I was thinking about it, and again like Pages thought it wasn’t super confusing. But as I thought about it more, you really are defining what kind of content you want to create. That content may not be for a particular section, but used over multiple sections (or the entire site for that matter). I’m not too set on Collections as that seems more of an ambiguous term than really defining anything.