MODX 3: [Q] Space for content area width reduced by 25%. Why?

[jonleverrier]

Summary

MODX3 has reduced the amount of available space for the content area width by 25% when compared to MODX 2.x.x. In MODX3 the content area now occupies 48% of screen width compared to 72% in MODX 2.x.x

The content area has been reduced by adding "publishing", "template" and "behaviour in menu" panels in view and by grouping the content field within the document summary.

The point of this github issue is to understand why reducing the content area for a content manager is a good idea and the thought process behind it. I'm also trying to keep this issue fact based vs my personal opinion.

New MODX3 resource page:

What solutions do we have available to us today to fix this?

1. Use form customisation

We have the ability to hide the new "publishing", "template" and "behaviour in menu" panels using form customisation.

Issues with this solution:

1. The content area stays the same width
2. A content editor will no longer have access to the hidden panels
3. There is no way to re-place the content in "publishing", "template", or "behaviour in menu" in to different regions

Publishing, template and behaviour in menu panels hidden with form customisation:

2. Create a custom plugin to make the resource area go full width

This is an option, but doesn't feel right that you essentially have to "hack" a new product from launch. A custom plugin will have to override the pixel width of the wrapper and field divs that ExtJs sets, into percentage values.

Issues with this solution:

1. A content editor still does not have access to the hidden panels
2. There is no way to re-place the content in "publishing", "template", or "behaviour in menu" in to different regions

3. Close the resource tree

This is also an option and will perhaps just take time to get use to the extra click to browse resources or to train clients to use the arrow icon they have never used before - nothing that can't be overcome!

Whilst closing the resource tree helps, the content area still occupies only 65% of the screen width compared to 96% in MODX 2.x.x

Resource page with the tree closed and panels hidden:

Other impact

There are some plugins in the MODX ecosystem that use the content field canvas. In this particular scenario - there is so much wasted space. Prior versions of MODX, love it or hate it, allowed for flexibility and freedom.

Suggestions/Solutions

1. If modx-resource-main-right-top, modx-resource-main-right-middle, modx-resource-main-right-bottom is hidden, make the content area go full width
2. Provide a way to move "publishing", "template", or "behaviour in menu" panels into different regions within the manager
3. Provide a system setting to default to MODX2.x.x behaviour
4. Provide a way of collapsing "publishing", "template", or "behaviour in menu" panels like the sidebar on the left

Closing thoughts

There are 2 parts to managing content. The content and the managing! At the moment, it feels that the focus is on the managing part, and not the content experience or even creating a content first UI.

This particular implementation, also presumes that MODX users use MODX in a particular way. We all know that the beauty of MODX is creative freedom.

[julienstuder]

I agree with Jon ! That would be great that point 2 and 5 could be realised.

I really like the new modx 3 dashboard, but if it ends with a reduced usability, that would be bad.

[eighthday]

Such a great detailed issue 👍

The content should be the prime focus as this is what you will be editing 99% of the time. Reducing this by 25% is a big step backwards IMHO. "publishing", "template" and "behaviour in menu" are rarely changed so do not need to be ever present.

This is how I strip back the current version of modx to focus on the content:

Personally I would put everything that is not a page field, behind a settings button.

[gadgetto]

In my opinion, the space available for the content field is not decisive. From a usability point of view, the placement and accessibility of the field counts much more. I also think that the content field should have a similar width as the presentation of the content on the website.

On the web, approximately 45 - 75 characters per line are described as ideal. That’s the way I would see it for the content field too.

Compared to other modern CMS systems, the content field of MODX 3 is in the good average.

In addition, you can switch the content field to full screen when using a suitable WYSIWYG editor.

[gadgetto]

I don't quite agree with the current minimal width of the resource tree either. However, a discussion is currently taking place e.g. to remove the trash can tab area and place it somewhere else. You'd gain a little space with that.

You could also make the tab headings in the resource tree e.g. responsive. This means that icons could be displayed instead of the minimum pension specified by the tab text.

[gadgetto]

Just thinking about a distraction free mode for resource editor. e.g. Hit one button and resource tree + all right side panels are removed.

[eighthday]

distraction free / full screen mode is missing the point somewhat. The UI should start off in distraction free mode, with options as you need them rather than showing everything at once.

Compare Jon's first screenshot with the UI of Kirby or Craft - so many things going on and nothing telling you what the pertinent information is.

[raffy99]

Thanks for the perfect summary. In my opinion, the new design is a step back in terms of user friendliness. The main focus should be on the resource tree and the content area.

The new sidebar takes much more focus than the resource tree. Main menus as i see the sidebar is a main menu, are always on top of every software i have seen so far. The intention to get the content-field nearer to the top should and could be solved in an other way.

a short comment to the resource tree: i see there a mix of selectable tabs and a button

the content/resource area uses a mix of selectable tabs and accordions, which makes it feel cluttered. the accordion panels are a waste of space and the logical and visual context is not given. Needless to say, that a panel/accordion for a single select box (as it is for the template) makes no sense.

Sorry if I sound too hard, my english is not that good

[muzzwood]

I'm also not a fan of the right-hand sidebar. It would be nice to have that in the settings tab to allow more content space.

Personally I love that the top menus have been moved to the left side as all my monitors are widescreen and vertical space is also limited. That being said, I would love to see the menus such as content, media extras etc. expanding at full height like in this issue: https://github.com/modxcms/revolution/issues/13942

[raffy99]

...maybe the righthand-sidebar comes into action when the mystery of fred is revealed

CreateWithFred

[rthrash]

The right sidebar could also be collapsible like the apps are in Zendesk. That works well. (... And no, Fred has nothing to do with the sidebar. ;)

I agree about the min width on the tree menu and is one of the main reasons I lobbied for stacked accordion vs horizontal tabs. It will get worse with languages that are longer than English.

[JoshuaLuckers]

I agree, there is a lot of wasted space. The input fields for the dates (published on etc) are also to small to show the full dates.

[guyinpv]

I would caution against too many expandy/collapsy sections everywhere. One collapsing section is ok to increase real estate but if every column has to collapse, then maybe rethink if there is a better way.

I agree about the right column. Things like publish date and which template it uses are not exactly changing all the time and could easily go into a Settings tab. So the system could default to a Content tab and Settings. If a right column is useful, then it's only useful on widescreen monitors. I'm fine with it when my screen is 1920px wide, but anybody on a 15" laptop or less is not going to want to see it or manage it.

Especially with the rise of page builders, maximizing the content editing experience is paramount.

I would also suggest keeping the content area as high up as possible. If I have to scroll past a bunch of meta data just to get to the content, it's too much. I wouldn't even mind if the description and summary are under the content instead of over it for example.

[gadgetto]

Hmm... looks very similar to me:

Craft 2

Wordpress

MODX 3

[guyinpv]

That looks like an older version of Craft, the latest one does't have gaps between columns, and it is also responsive. At about 1220px the entire left sidebar disappears. At about 1000px the right column disappears.

Not even a pixel is left after the sidebars collapse.

[muzzwood]

So maybe that's the solution then.. Let the screen size dictate if the right side bar is retracted on page load?

[sottwell]

Personally, I'd prefer to have more basic editing space and less clutter and confusion. I gave away my 24" monitor years ago and have a relatively elderly 13" laptop. I somehow got the impression that MODX was intending to move towards more mobile-friendly Manager UI, and I don't see how this layout would be usable at all on mobile devices.

So my preference would be for more space for the most basic content editing purposes (pagetitle, longtitle, publish status, content) and everything else resource-specific in tabs.

I'm not comfortable with the left menu, but I suppose eventually I'd get used to it.

[Jako]

One big problem here is the missing responsiveness of ExtJS. Automatically collapsing (hidden) sections have to be well prepared and can’t be handled with pure CSS.

[StevenMorgan]

A smaller Content area will ruin the functionality of things like Content blocks. Editing experience moving backwards?

Are we sure these minor revisions are worthy of the MODX3 title?

[Mark-H]

Thank you for the constructive comment and reducing months of full-time work by a team of people to "minor revisions", @StevenMorgan... :/

The primary goal for the resource panel as I've understood it was to move the content further up, not to make it wider. I think that's been achieved and that the "content space has been reduced" in the opening post perhaps paints a bleaker picture than the reality. Isn't the optimal reading/writing width something around 60-75 characters? The core experience looks pretty spot on from me for medium-to-large-sized screens.

Extras like ContentBlocks will need a slightly creative solution, which is coming shortly, but the reality is that 90% of MODX sites do not use a tool like ContentBlocks and just need a rich text editor in that place. Focus on making the core better, let third parties (yes, I refer to myself as third party in this case) worry about third party stuff.

[Mark-H]

So let's talk solutions. What I gather from this thread is that smaller screens are the problem, so we need to make it responsive. ExtJS doesn't make it easy, but it has been done in 2.5, so we can do it again.

While perhaps less important, the boxes still need to be available. What about moving them below the panel on < 1000px, something like this (*bad mockup, imagine the fields being nicely aligned for the full width of the panel):

Would that satisfy people?

(Again, take ContentBlocks out of the equation, focus on the core here. I'd be happy to discuss ContentBlocks ideas on the modmore forum)

On mobile, it's already stacked (requires page refresh after resizing, cause extjs):

[eighthday]

I agree the content width is not necessarily the issue - its more there are so many elements / navigation patterns presented to you at once, its just very confusing. Mark''s mock up is better, but why not just have page fields and everything else under a setting tab / button?

[raffy99]

i also put this mockup in the round. i do not understand the need for the right column..

[jonleverrier]

I didn't mean for this post to paint a bleak picture. I just wanted to understand why the content width had been reduced and the publishing, template and menu panels given more visibility.

Whilst feedback can be seen as "design by committee" or FOD - regardless of the tone with some of the responses, it's only because we care about MODX.

One main reason that @Mark-H @gadgetto mentioned is that the optimal reading width is around 60 characters per line - so that is a valid point. But could a user not adjust their browser window or resource tree or write content in an app like iA writer frist, to make the content length feel more comfortable ?

The sound bites that i'm hearing from the discussion, for what they are worth are:

less unnecessary clutter, more focus on content

some of these concerns could be fixed with responsive design, but we're not entirely there yet

concerns are more focused towards the publishing, template and menu panels than the content area

Whilst I appreciate 90% of users use a standard WYSIWYG, the MODX2 approach was rather agnostic in this manner - content just slotted in without creating unnecessary gaps or space.

It was scalable - which one could argue that modx-resource-main-right-top, modx-resource-main-right-middle, and modx-resource-main-right-bottom are not, unless you sit in the 90% camp.

I like @Mark-H mockup if we're talking solutions. I also mentioned some suggestions/solutions in my original post. My favourites were (which give you full creative freedom);

1. If modx-resource-main-right-top, modx-resource-main-right-middle, modx-resource-main-right-bottom is hidden, make the content area go full width
2. Provide a way to move "publishing", "template", or "behaviour in menu" panels into different regions within the manager

[OptimusCrime]

I like your mockup @raffy99 :)

Personally, I do not touch the stuff in the right side panel 90% of the time.

Question: What about extjs makes responsive design so hard? I know there are some hard coded widths there, but that is widths we have added outselves. Does extjs add hard coded widths by default too?

[Jako]

Yes, the widths are set by ExtJS

[OptimusCrime]

Oh, that sucks. Have anyone investigated how we can get around that? If extjs were only to generate the markup, we could make the design as responsive as we like. A bit difficult if inline styles hard codes width though.

[guyinpv]

I'm good with either dropping the boxes below, or moving most of the stuff into the Settings tab.

The only caveat is that when I create a new resource, I don't want to have to bounce between the content tab and then settings and then back to content just to set the basic page settings. But AFTER setting things like whether it's published, shown in menus, what template is selected, etc, then I rarely need to change those things and they could live under Settings from then on. I like Raffy99's screenshot except that the content column does not need to be 100% width. I would want a reasonable max-width just so I'm not having to edit content all the way across 1800 pixels or whatever on a typical widescreen monitor.

I think the content box should basically fit 100% wide when under around 640px (large phones) but then it should itself be anywhere from 600px to maybe 1200px wide and that's about it. Doesn't need to get any wider or writing content gets awkward. So the question is, how to get the right sidebar to play along in those restrictions.

I don't care if there is a sidebar when screen is wide enough to handle it. But I think the point most people are making is that those settings just aren't changed that often so visually having to see them at all times might be unnecessary.

What if there was something like a "page settings" button that simply popped up a modal with various rarely-used settings (i.e. all the sidebar stuff)? Many ways to skin this cat.

[SnowCreative]

Is there NO way to set column widths using CSS? If I could easily limit the right sidebar to 200px, that would help a lot.

[Mark-H]

ExtJS can do responsiveness, but instead of media queries you need to set it in the JS. That's why the current responsive features require a page refresh; they're only evaluated when the interface is generated.

[JoshuaLuckers]

Isn’t it possible to do doLayout() when the size of the viewport changes?

[guyinpv]

Here is a mock I did of potentially moving back to a top bar and a modal window for the extra management stuff.

Main dashboard:

Clicking on the menu:

Benefits to using a modal are numerous

1. Can use an icon grid or a list view and even switch between them.
2. Easily responsive.
3. Addons and plugins can add their icons to it and there is endless room to do so.
4. It could even be used as the CMP space after clicking an icon, the content goes in the same space and perhaps uses a back button to get to the list again.
5. Much cleaner main pages, and modal allows to split tasks into more icons rather than putting so many tasks under one icon.
6. If an icon (such as Manage) has a set of tasks of its own, it could simply replace the modal with another set of icons (and back button).

The new top bar can be as minimal as possible since there isn't much going on except a logo and a menu. I figure the search bar good to be universally available, and perhaps a little link that takes people to the front page as well.

I have no idea if Extjs can make this modal happen. But then, why use extjs at all? It might actually afford the possibility to let MODX start using a new set of tools to manage these icons and CMPs. Since it's a brand new thing, it doesn't have to use extjs right?

Just an idea.

[muzzwood]

With the release of Fred, the focus on the content field is lessened somewhat I reckon. The width of it doesn't matter as much to me anymore... I know this won't be the case for everyone however.

[sottwell]

Fred is nice indeed, but it's not going to lessen the importance of the content field. For one thing, just like Content Blocks, Fred is not going to be appropriate for all resource content. And for another, I think it will be a little time before the viability of Fred on mobile devices will be fully tested. So let's not be forgetting the cake for the icing.

[hugopeek]

Nicely formulated case @jonleverrier. I agree with most of what's been said, especially raffy99's comment: I also don't see why the settings in that right column shouldn't stay in tabs, where they are now.

And changing the width / layout of the content area is not only relevant for smaller screens. Also consider use cases like people with big screens using split screen, with MODX on 1 side and content (say, a Word or Google doc) on the other, or people making screencasts for example. Apart from the layout not being accurate anymore of screencasts that were already made (I guess that's bound to happen at some point anyway), people may also prefer to reduce their viewport to a dimension most suitable for video. Which is usually smaller than full screen. In these cases, the new 4-column layout takes up way too much real estate.

Mark's solution of putting the options below the content area is also not an option I think, because this will drive people mad on pages with lots of content. So again: why not in the currently available tabs? What's the reason for getting them out of there? Could we move things around inside the tabs for a better user experience instead?

Another argument is that content editors are currently used to this setup. Keep in mind that we (the designers; developers) are often not the ones using the editor every day.. Our clients are, and they are mostly fine (in my experience, anyway..) with how editing resources works in MODX. And some of them have been doing it like this for years! Changing that will burden us all. Clients will have questions about this, and right now, I don't see how I can explain to them why some of these changes took place.

But anyway, that's probably better to discuss elsewhere. I don't want to bash on the MODX3 UX team either, because it's definitely a good thing that someone had the guts to pick up the daunting task of giving the MODX front-end a makeover as well.. But please don't move too many things to unfamiliar places is there's not a really good reason for it other than: it sucks.

The start menu in Windows also sucked in many ways, but Windows 8 was not the answer either ;)

[jonleverrier]

It sounds like we need more flexibility with form customisation, perhaps some new regions, so we can:

1. Move the content field out of the document summary, so it can go full width
2. Move the 3 new regions "publishing", "template" and "behaviour in menu" into a tabbed region (subregions?)

That way MODX3 can ship with the new resource layout, and if people want to, they've got the extra flexibility and freedom to change it back? Everybody is a winner.

What do people think?

I'd be happy to help fund/crowdfund such a feature if the core team didn't think it was worth pursuing.

[donShakespeare]

My response to some of the comments that did/will suggest that certain Extras do make the new resource layout a non-issue.

The new layout is a core feature. It will always be there, it is the lowest common denominator. Extras, on the other other other hand, come, become obsolete, die off ... even in the prime of these Extras, there exists many users who will never hear of or use them.

IMHO, the call to or mere mention of these Extras is a total non-sequitur.

Think this: MODX backend manager + API etc, is like a veritable mansion. I never never forget that catch word: FREEDOM. To force users to use this or that Extra is like telling the man that he may enjoy his new mansion but while chained to a chair in the center of the house. And of course toss a few crocodiles around to intimidate him.

I highly suspect that this is just a test, in the real sense of the word. It is impossible to imagine that the layout will be left like this. I have yet to read any reasons that prompted the redesign ... that is, why the things that were before nicely tucked away in the settings tab are now allowed to be out.

Again, to my comfort, I conclude that this is a just a design test, and that proper actions are in place to speedily return the current resource layout to what was.

It is needless, to present my suggestions in pixels and stuff, everyone is full aware of what was ... And I hate to burden the developers and designers with my two cents of this or that ... I am only confident in that they indeed have designed this as an experiment and will, before final release revert to what was.

[BobRay]

It seems to me that a primary goal is a good responsive design. Imo, that's a lot easier to accomplish with things on separate tabs as they were.

In addition, I think tabs make things look much friendlier for new users who will mainly be just entering content at first, and can later explore the other tabs as their knowledge grows (and some lower-level users may never need what's on the other tabs).

[SnowCreative]

I and all my clients frequently toggle pages between unpublished/published and hide from menus/don't hide from menus while developing pages. So, I would much rather have these two checkboxes accessible in the main Document tab. Everything else in the right sidebar could either be moved to the Settings tab (eliminating those widgets completely), or else be part of a collapsible sidebar (one of Jon's original suggestions). If neither of these is possible, I suppose making the widgets tuck under the Document tab (as Mark mocked up) would be OK.

[jonleverrier]

Just found this on the MODX3 project site from week 12: https://modx3.org/updates/week-12-april-30-may-6-2018

Regarding the right bar: please note that we're working on MODX here. MODX means 'creative freedom'. This also means that you can change everything. You can move everything around with Manager Customization. This also applies to the right bar. For example, you can move TV's in that right bar if you want to. We're also thinking about shipping MODX3 with some pre-made Manager Customization configurations.

Doesn't mention anything about moving things out of the sidebar, but fingers crossed.

[Ibochkarev]

@jonleverrier After making changes to the styles of the administrative panel. This bug is not relevant.

View at the moment:

I vote for closing issue

[JoshuaLuckers]

Some great ideas are discussed in here. I prefer to leave this issue open until MODX 3 is final.

[SnowCreative]

Sorry, what's different about your new screen shots? Content editing still looks like the same setup to me.

[Ibochkarev]

@jonleverrier How do you like the latest changes in the design of the control panel? what do you think?

[jonleverrier]

@Ibochkarev The latest design changes @Mark-H put together are fantastic. But, that's not what's being discussed here in this issue.

[SnowCreative]

It's been a couple of years since the last comment. What's the current plan? Is there any consensus?

I wanted to add that I don't find pushing the stuff in the right column under the main panel to be a good solution. I regularly make custom layouts for certain content that add TVs above and/or below the content field. Sometimes there are quite a few of these. And, some people like to make the height of the content field higher. All of this would push the right column items much further down the page. It would also make these settings show up in a different location for different types of resource (that have manager customization applied). Hiding and showing resources in the menu is an action that many of my clients do very frequently, so it needs to be easy to find that toggle, as well as the Published toggle. Right now, they just have to edit the resource and those settings are right there. Additionally, it just seems weird to put these settings at the bottom rather than in a tab.

As for the comments about content width ideally being a certain number of characters wide, yeah, but that's true if there is just one column. If you're editing text that is two columns, or even three, there's not enough room.

Know what my ideal solution would be? Put the stuff in the right bar when the browser is a certain width. Smaller than that, make it go in a tab at the top. I know that's unlikely to happen, but it sure would be cool.

[SnowCreative]

Question: In form customization, why is it so hard to enable all the standard fields to be put anywhere, just like TVs can?

[hugopeek]

Update 2022: by now the right sidebar is indeed pushed below the content under a certain viewport width. That's mostly good, but I agree with @SnowCreative that this creates a problem with the Published and Hide in menu settings. You need to scroll (way) down now if your screen is smaller / split in multiple windows. Probably not the case for most users, but hell for those very few.

I also feel the description and introtext fields shouldn't be side-by-side. Especially when using an RTE on the introtext field:

[SnowCreative]

Here's another example of an issue. For some types of resources, I have no content field at all, just a bunch of TVs. So, in the current setup, that looks like this:

Not exactly user-friendly, and I don't really want to have to manually move 108 TVs into the content area using form customization. (Yes, that's how many TVs are in this template!)