[PAGES-25] As an editor I want to edit like in Typo3 Neos, to have better usability. Created: 19/Jun/15  Updated: 23/Aug/22

Status: Open
Project: Magnolia pages module
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Story Priority: Neutral
Reporter: Michael Büchele Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: greenbar
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: PNG File green_bars_improved.PNG    
Issue Links:
Relates
relates to PAGES-236 Page editor: green bars should not af... Open
Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Date of First Response:
Team: AuthorX

 Description   

The green bars are really bad in sense of usability.
Please check out Typo3 Neos and plunder their CSS - It should easily be possible to offer the same usability in Magnolia. A huge improvement, even without the inline editing part.



 Comments   
Comment by Antti Hietala [ 16/Mar/17 ]

mbperi, can you add more detail please? What is it about the green bars that impacts usability?

Comment by Rasmus Skjoldan [ 16/Mar/17 ]

mbperi Here's a bit of background about that UI choice from when I was working with Neos:

Since the editing interface of Neos was primarily focused on inplace editing (for starters), we wanted to stay as close to a 1:1 preview as possible, intervening as little as possible with the frontend. The choice of the blue surrounding box over the component being manipulated by the user was made because it would work with most webdesigns (that are very rarely cyan blue). The box was supposed to give the author a simple sense of focus.

In the plans for using Neos' edit/preview framework to provide non-inplace, structured content editing we did not intend to reuse the same UI elements but rather build something on top of the raw content mode (previously "wireframe mode").

The green bars of the Magnolia interface function quite differently in different setups. There's definitely a breaking point when there are too many on one screen. Then they stop being helpful in regard to giving the user easy access to CMS functionality on top of the website design (which is intended to clearly show to the user how and where you can content manage the elements).

In those cases where you have 4, 5, 6 green bars on screen at the same time, I agree they do lower usability.

We're working on a new editor: https://trello.com/c/6JjxfEXl/1-article-editor

Would you be interested in giving us feedback on that, mbperi? It also addresses usability of editing, though not in the page-based scenarios.

For the page-based authoring (curating elements onto a page), I don't think it's a bad idea to have a look at how the green bars function.

Comment by Michael Büchele [ 04/Sep/17 ]

Hi guys, thanks a lot for your answers!
I try to add more detail about the problem and of my proposed solution that I think would help a lot of users:

Problem:
Klicking on a green bar adds paddings and margins to components and templates.
The green bars interferes with the layout of the page, which means that paddings and margins can't be controlled in detail.
You have to check the preview or published page to check the layout.

Solution (similar to Neos):
Klicking on a green bar shows an outline (blue box like Neos), without interfereing with the layout.
This can be achieved by using the css-property "outline".

It would not be necessary to change the way of editing itself, just the design/css/behaviour of the green bars!

Comment by Michael Büchele [ 17/Oct/17 ]

Here is another nice example, how it could be done
https://www.elegantthemesdemo.com/?et_fb=1#

Comment by Christopher Zimmermann [ 03/Feb/20 ]

We accept that the green bars can break the layout.

However, Indicating the extent and shape of a component/area via a rectangle is actually not possible in Magnolia because we do not enforce having a single enclosing element for a component/area.

In the next version of the Page Editor we will try to resolve this issue, but there is currently no schedule date for this improvement.

Generated at Mon Feb 12 06:14:52 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.