revolution icon indicating copy to clipboard operation
revolution copied to clipboard

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

Open jonleverrier opened this issue 7 years ago • 48 comments

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:

screen shot 2018-07-04 at 12 12 19

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:

screen shot 2018-07-04 at 12 15 20

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: screen shot 2018-07-04 at 12 18 08

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.

cb_modx3

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.

jonleverrier avatar Jul 04 '18 12:07 jonleverrier

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.

julienstuder avatar Jul 04 '18 13:07 julienstuder

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:

screen shot 2018-07-04 at 14 31 22

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

eighthday avatar Jul 04 '18 13:07 eighthday

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 avatar Jul 04 '18 13:07 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 avatar Jul 04 '18 14:07 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.

gadgetto avatar Jul 04 '18 14:07 gadgetto

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.

eighthday avatar Jul 04 '18 14:07 eighthday

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

raffy99 avatar Jul 04 '18 14:07 raffy99

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

muzzwood avatar Jul 04 '18 14:07 muzzwood

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

raffy99 avatar Jul 04 '18 14:07 raffy99

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.

rthrash avatar Jul 04 '18 15:07 rthrash

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.

JoshuaLuckers avatar Jul 04 '18 15:07 JoshuaLuckers

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.

guyinpv avatar Jul 04 '18 16:07 guyinpv

Hmm... looks very similar to me:

Craft 2

craft3

Wordpress

wordpress

MODX 3

modx3-betas

gadgetto avatar Jul 04 '18 17:07 gadgetto

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.

craft

Not even a pixel is left after the sidebars collapse.

craft full

guyinpv avatar Jul 04 '18 18:07 guyinpv

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

muzzwood avatar Jul 05 '18 02:07 muzzwood

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.

sottwell avatar Jul 05 '18 04:07 sottwell

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.

Jako avatar Jul 05 '18 05:07 Jako

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?

StevenMorgan avatar Jul 05 '18 06:07 StevenMorgan

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 avatar Jul 05 '18 11:07 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):

schermafbeelding 2018-07-05 om 13 57 34

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):

schermafbeelding 2018-07-05 om 13 59 51 schermafbeelding 2018-07-05 om 14 00 47

Mark-H avatar Jul 05 '18 12:07 Mark-H

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?

eighthday avatar Jul 05 '18 12:07 eighthday

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

modxpreview

raffy99 avatar Jul 05 '18 12:07 raffy99

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

jonleverrier avatar Jul 05 '18 12:07 jonleverrier

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?

OptimusCrime avatar Jul 05 '18 13:07 OptimusCrime

Yes, the widths are set by ExtJS

Jako avatar Jul 05 '18 14:07 Jako

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.

OptimusCrime avatar Jul 05 '18 15:07 OptimusCrime

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.

guyinpv avatar Jul 05 '18 17:07 guyinpv

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.

SnowCreative avatar Jul 05 '18 18:07 SnowCreative

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.

Mark-H avatar Jul 05 '18 19:07 Mark-H

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

JoshuaLuckers avatar Jul 05 '18 19:07 JoshuaLuckers