Help Create the Best Content Management Experience

Building an intuitive, accessible, efficient and progressive manager and site management experience is a challenge worth undertaking. There has been much recent discussion and some examples popping up of Mockups of UI treatments and those are coupled with suggestions for improving the user experience along the way.

This post is merely a jumping off point for the sharing of ideas and discussion of challenges, problems, solutions and user perspectives to drive future of managing content.

Check out Mark Hamstra's prototype of a proposed interface treatment. I consider it a living sketch for reference and also a fresh take on the existing Manger to allow us to reflect on how we can build a tool that will give people more power, more confidence and in the fewest number of actions possible.

In the very near future like in all the other Special Interest Groups, we will be holding discussions and seeking new ideas, visual treatments and assessments of the existing ui/ux. I personally challenge anyone interested to look beyond CMS interfaces, look for inspiration in interfaces and tools that make your life incredibly easy or that is so intuitive that you forget it's even there.

One thing that has irritated me from the very beginning is how Template Variables are tied to templates, when they really have nothing to do with templates at all. They are custom resource fields. What I would love to see is categories for resources, and Template Variables being tied to resource categories. No more need for a dozen templates just to organize TVs!

I like and am happy with the current layout of the manager, what bugs me about it is the speed.

The whole page has to reload after every action. It completely misses the benefits that asynchronous javascript has to offer.

We need to make it faster, not change the layout.

I like and am happy with the current layout of the manager

+1

We need to make it faster, not change the layout.

+1

What I would love to see is categories for resources, and Template Variables being tied to resource categories.

+1

I would like to have not a Resource-Tree but just a folder- or category-tree and have all the Resources in a grid-view.
The Folder/Category-Tree could be a filter for the grid. There could be a dropdown, where you can define the depth for the resources to show in the resource-grid and some other (configurable) filters what to show in the grid-view.
(did something like that allready with MIGXdb, where the folder-tree is a dropdown-combobox-filter, but if we could use the left-side tree for filtering the grids, I think this could be very handy)

It should also be possible to add Resources to multiple tree-nodes.
And it should be possible to define tree-nodes as custom-table-nodes (something like MIGXdb-nodes, where the grid should be configurable like its done with MIGXdb).

Sorry, I don't like Mark's left-side slide-down-solution.
We had something like that on early days of Revo and it wasn't very practicable. I like the current solution much more.


[ed. note: Bruno17 last edited this post 11 years ago.]

About TVs and their role: I would like to remove nearly all of the current default resource fields (description, longtext, summary, content etc.) and replace them with TVs.

Seeing as how I developed the first top menu bar with the dropline (taken directly from this article) as a change from the original Etomite upper-left block of links (which Etomite still has, by the way) I suppose I'd have to say I'm partial to the main menu structure the way it is.

Susan, I am with you there. TVs are custom fields and currently are associated with Templates to tie them to the Content when with custom content types you could associate them in that way. My other consideration is with regard to adaptive content and reuse. Templates essentially bind content to a single view and the only way to create alternate views is via getResources or symlinks. I would prefer a more elegant solution, where you could assign views to content and depending on the tool or request context the right version of the view would be delivered to the user/consumer.

Thingstodo, what if the speed of a new manager UI was a non-issue? What if it were a given that it would be fast, if not faster even than evo? Then what? Should be not look beyond the speed? I think we all want for a tremendously efficient Manager experience but in 8 years the CMS industry is getting more refined and user expectations along with it. I don't want to just focus on fixing the existing issues with yesterday's manager but focus on creating tomorrow's.

Bruno, You've indicated you agree that you want to keep things the same but below that you're talking about getting rid of the resource tree (which I am neutral on by the way) Expression Engine has handled this in a smart way with its Structure add-on/module (or whatever extension-y things are called in EE).

Mikko, We're again heading down the EE route with your suggestion too (channels and channel creation). I don't disagree with you by the way, however, I think shipping with ready to go content fields that would also allow for the import and mapping of fields from legacy installs of MODX. It would be a matter of decoupling the fields and shipping them as a default set of fields. It could perhaps be an advanced install option to use the traditional MODX fields.

My personal mission is to consider the expanding present and not locking MODX into a 1 resource 1 view paradigm and to allow content managers and content strategists the ability to manage and govern content accross multiple properties. Handling the create once publish everywhere that is going to power the future web.

Susan, on your manager layout note. I too am partial to the top nav. It stays out of the way and new trends in persistence and hover allow it to be always available. If I were designing things, I would definitely stick with a top action menu. I will say, my sketches thus far are pretty minimal as many of the actions of the current revo manager do not need to be accessed as frequently as they are. I am also toying with linking and contextual referencing of related actions from specific task contexts.

One of my other personal wishes is to drastically reduce the amount of clicking and task switching. The quick actions in the tree were a great start but you can quickly get a bunch of modals open and lose track of where you're working. It's often necessary to change something in one resource and have to bounce to an element and then to a snippet and IMO modals may not be the right way to handle this. The simplest way to fix this could be enabling folks to use multiple tabs in browser but other ways might be to have multiple tabs from within the Manager in a specific task context. (That's lowercase, user context).

Try to think of balancing the interface and experience for our user trinity of Designers, Developers and End Users and how things could change for the better for all three without sacrifice for one over the other.

Quote from: smashingred at Mar 25, 2013, 12:44 PM

Thingstodo, what if the speed of a new manager UI was a non-issue? What if it were a given that it would be fast, if not faster even than evo? Then what? Should be not look beyond the speed? I think we all want for a tremendously efficient Manager experience but in 8 years the CMS industry is getting more refined and user expectations along with it. I don't want to just focus on fixing the existing issues with yesterday's manager but focus on creating tomorrow's.

Well if speed wasn't an issue then that would be great!

The manager has evolved over time so it must have some good things going for it, I don't think we should change things for change's sake and risk throwing the baby out with the bathwater. I think there needs to be a well thought out, well argued case before changing stuff.

I don't know about the more refined expectation of other users, but I would be interested to find out.

Quote from: thingstodo at Mar 25, 2013, 01:04 PM

The manager has evolved over time so it must have some good things going for it, I don't think we should change things for change's sake and risk throwing the baby out with the bathwater. I think there needs to be a well thought out, well argued case before changing stuff.

I don't know about the more refined expectation of other users, but I would be interested to find out.

I am certainly not suggesting we change for the sake of change, however, I am also considering the way the CMS industry is maturing. Less skilled people will be able to do more and more and think less and less about how to do it and get on with that work. User expectations of refined and elegant interfaces (not just end users) put pressure on staying relavent. People do not want to still be using the Windows 3.1 interface even if it's fast and practical.

This thread is exactly the discussion for making suggestions on improvement. At the very least, we can document the wishlist and the most we can build something that helps people do things more easily, efficiently and sanely than ever before. My goal is not a redesign but to reflect and suggest possible new ways to make the experience better. Some conventions and interface elements may be entirely perfect in the Manager others we know are worse than getting a root canal after a 3 day bender.

Again, I come back to, how can we make MODX more intuitive, efficient to use for the user-trinity while being flexible and ready for the future of content and content based applications. My focus is on productivity over beauty, however, aesthetics do play a part in the psychology of user experience and perception of ease of use. Busy interfaces with many options are intimidating to some and are undefinably sloppy to others.

While I plan on making a case for change I equally expect people to make the case for things to remain the same. In our discussions there should be no fear of getting it wrong.

My manager wishlist:

- responsive layout
- touch friendly
- flat interface style
- keep total flexibility provided by lexicons, systems settings, menu actions, form customisation, but simplify into one area
- make the interface as minimal as possible
- keep the tree! clients get this
- make migx style tvs an absolute priority