[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: |
|
||||||||
| Issue Links: |
|
||||||||
| 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: | |||||||||
| Description |
|
The green bars are really bad in sense of usability. |
| 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! Problem: Solution (similar to Neos): 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 |
| 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. |