Improve handling and look of Page, Area and Component edit bars (MAGNOLIA-4308)

[MAGNOLIA-4331] Change appearance of areas and components edit bars Created: 25/Oct/11  Updated: 22/Mar/12  Resolved: 08/Nov/11

Status: Closed
Project: Magnolia
Component/s: page editor
Affects Version/s: None
Fix Version/s: 4.5

Type: Sub-task Priority: Major
Reporter: Andreas Weder Assignee: Espen Jervidalo
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: PNG File Matrix - Area editable.png     PNG File Matrix - Area not editable.png    
Template:
Date of First Response:

 Description   

Area and Component edit bars should appear and work similarly and consistently. I've had a look at all area types and have defined the way the bars should look depending on whether the area itself is editable or not and depending on how many components an area can and actually does contain.

The two attached images show the result. Compared to the currently implemented solution in 4.5 Sprint III, the following changes have been applied.

No special treatment for single component areas

Single component areas are not treated any different from List areas. From the perspective of a user, this is more consistent. I've also found that a combined area/component edit bar is somewhat difficult to read and leads to many special cases.

In particular, with this solution, there's no need to distinguish between "Edit component" and a possibly existing "Edit area" (nothing prevents us from attaching a dialog to the area) - the buttons can be left with a short command, their location defines what they act upon.

In addition, the component of a single component area is not created using a "Create" button (and removed using a "Remove" button), but is created using "New" and "Delete" just as with any component of a List area. From the perspective of a user, an alternative could be to make a single component area act more like an actual component, but that doesn't solve all problems.

Edit always on right side

In contrast to the current version of Magnolia, on a Component edit bar, "Move" and "Edit" have swapped places with the "Delete" button. This paves the way for Magnolia 5, which will add labels for components as well and will only leave the most common "New" and "Edit" buttons on the bar, while "Move" and the destructive operation "Delete" will be moved away. Moving "Edit" to the right is also more consistent with how Area edit bars are working.

Remark
Areas without any buttons are actually dealt with more closely by SCRUM-494 - they will become even less prominent.



 Comments   
Comment by Espen Jervidalo [ 03/Nov/11 ]

Too early commit.

Comment by Espen Jervidalo [ 03/Nov/11 ]

Two problems discovered so far:
1. "Delete"-Button in area can't be floated left because of the label.
Possible solution in SCRUM-497

2. Creating new optional area with "New" -> After reloading the page you get a "New"-Button on the same place for the component inside the area. Confusing.

Comment by Andreas Weder [ 04/Nov/11 ]

1. Don't show the label of a component, only show it for an area. An for optional areas, the "Remove" button shall not be on the left of the bar, but on the left of the "New"/"Move"/"Edit" buttons, separated by some additional whitespace. See SCRUM-501.

2. That's why we use different labels for the buttons: optional area are added with "Add" and removed with "Remove": components are added with "New" and removed with "Delete". See SCRUM-501.

Still, having both a "New" and a "Remove" button on the area bar is confusing. Maybe we'll change the button names for adding/removing areas later to "Add area"/"Remove area", we'll see.

Comment by Federico Grilli [ 07/Nov/11 ]

On a general note, having "long" buttons labels can cause edit bars layout to break (i.e. the right-most button "drops off" the containing bar). As we did for area labels .mgnlAreaLabel maybe it would be good to truncate longish labels when area space is too narrow.

Generated at Mon Feb 12 03:54:46 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.