[PAGES-33] Create a page component status indicator Created: 05/Jan/15  Updated: 19/Aug/15  Resolved: 13/Aug/15

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

Type: New Feature Priority: Neutral
Reporter: Eric Hechinger Assignee: Espen Jervidalo
Resolution: Fixed Votes: 0
Labels: affect-vn-project, ux
Remaining Estimate: 0d
Time Spent: 3.25d
Original Estimate: 3d

Attachments: PNG File 1-Indicating change.png     PNG File 2-Indicating change.png     PNG File 3-Indicating change.png     PNG File QA-1-2.CSS change.png     PNG File QA.1-1.marker-not-wide-enough.png     PNG File QA.1-3.marker good width.png     PNG File QA.2-1.marker on parent.png     PNG File QA.2-2.marker on child.png    
Issue Links:
Relates
dependency
depends upon MAGNOLIA-6335 Add activationStatus to page editor c... Closed
depends upon MGNLUI-3517 Provide styles for page component sta... Closed
duplicate
is duplicated by MGNLUI-3311 Create a page component status indicator Closed
relation
is related to PAGES-37 The "changed" marker is not removed f... Closed
is related to PAGES-36 Click on "changed" indicator selects ... Closed
Template:
Acceptance criteria:
Empty
Date of First Response:
Sprint: Sprint 5 (Basel)
Story Points: 5

 Description   

In pages app, create a visual status indicator at the component level.
http://wiki.magnolia-cms.com/display/VN/Component+Status+in+page+editor



 Comments   
Comment by Michael Mühlebach [ 30/Jul/15 ]

weder has to provide Mockups for this feature.

Comment by Andreas Weder [ 30/Jul/15 ]

Added a link to the page describing the UI design and containing the mockups.

Note that it's not enough to just mark a component as "changed". We also have to show such a mark on the parent bars if a changed component is currently not visible. You'll find all the details on the wiki page attached to this issue.

Comment by Andreas Weder [ 30/Jul/15 ]

I've attached the visual design for the solution.

We've tried different placements (front, back) and visual emphasis (yellow dot on transparent background; on green bar; on yellow, separated background), but decided for this one, for the reasons also mentioned in the linked wiki page.

We'll thus start with a quiet visual solution. A yellow dot on a yellow background grabs your attention better, but it's very strong.

Comment by Sang Ngo Huu [ 10/Aug/15 ]

The codes has been submited to branches:

@ejervidalo The testcases RestorePreviousVersionActionTest.java has failed when changing dependencies to 5.4.1-SNAPSHOT, seem have a change on supper implementation of Action makes it failed, I gave a fix, but I'm not sure it is fine. Could you please help me review it, and contact code changer if it is not good fix. Thanks.

Comment by Federico Grilli [ 10/Aug/15 ]

I see some code duplication in MgnlArea and MgnlComponent which I think can be moved to their superclass MgnlElement.

  • static final ACTIVATION_STATUS_KEY = "activationStatus";
  • public int getActivationStatus()
Comment by Espen Jervidalo [ 10/Aug/15 ]

sang.ngo, hm that testcase is part of magnolia_ui, and already updated to 5.4.1 on master, so that can't really be? It succeeds locally for me as well. Could you point me to the commit, where you added the 'fix' you mentioned?
Apart from that the info.magnolia.ui.contentapp.detail.action.RestorePreviousVersionAction has been deprecated and moved to RestoreItemPreviousVersionAction, so I don't really see any reason to keep that test around. Feel free to delete it.

Comment by Sang Ngo Huu [ 11/Aug/15 ]

@ejervidalo I don't see any deprecated marker on RestorePreviousVersionAction , it is on Pages module, not UI. So I cannot delete it. And when you change dependencies core and UI of Pages to 5.4.1-SNAPSHOT, then run with maven, it failed. Please help me recheck. I worked on latest code on master.
@fgrilli I fixed, sorry for duplicated code. Please check on PAGES-33 branch. Thanks

Comment by Espen Jervidalo [ 11/Aug/15 ]

info.magnolia.ui.vaadin.gwt.client.editor.dom.MgnlElement#getActivationStatus
The method should go to the interface as remarked in the TODO-statement. The problem with TODOs is that they never get done and if we start breaking the pattern it's just a matter of time until it's completely broken. This is GWT code which is not extended by any clients anyway and safe to add something to the interface.

Comment by Espen Jervidalo [ 11/Aug/15 ]

We should do the QA before integrating, as Andreas suggested, to make sure it matches the look&feel of his mockups.
When integrating, make sure the commits are properly squashed.

Comment by Andreas Weder [ 12/Aug/15 ]

I've done a first round of QA tests and found three problems with the current implementation, which cause me to re-open the issue.

More important:

  • QA 1: The "changed" marker is not wide enough; it does appear unbalanced.
  • QA 2: The "changed" marker is not removed from a parent element, if the bar of the actually changed component is shown.

Less important:

  • QA 3: If a click on the "changed" marker or the "modified" marker in the status bar of the page editor, the first changed component is not selected. (see PAGES-36)

I'll add more details with screenshots in comments that follow.

Comment by Andreas Weder [ 12/Aug/15 ]

QA 1 - The "changed" marker is not wide enough

The "changed" marker appears unbalanced, as its icon is too much to the right:

Below is the current CSS for the element, plus a change I quickly made to fix the problem - I'm not saying this is the good solution, but it creates a result, which looks fine.

Comment by Andreas Weder [ 12/Aug/15 ]

QA 2 - The "changed" marker is not removed from a parent element.

Since our bars are once visible, once not visible, we often have to temporarily show a marker on the bar of a parent element, if at least one of their components has changed.

Once the bar of the actually changed component becomes visible, however, the "changed" marker must be removed from the parent element and only shown on that components' edit bar, as else both the parent element and child component appear to have changed.

More details can be found here:

https://wiki.magnolia-cms.com/display/UX/Indicating+changes+in+the+page+editor#Indicatingchangesinthepageeditor-Markparentbarsifachangeisnotvisible

The "changed" marker is not removed from the parent, of course, the both the parent and the child have been changed.

Comment by Andreas Weder [ 13/Aug/15 ]

Let me try to rephrase this.

So a component has been changed. If its bar is visible, it will feature the "changed" marker. If its bar is not visible, the first parent item with its bar visible will show the "changed" marker. Once you click on the parent item, the bar of its sibling components become visible and the marker switches to the one that was actually changed.

With this solution, you always know where to look for the change, you don't just know that there is a change (we already know that). Complementary with PAGES-36, you always get to the actually changed element with a single click.

The alternative - only mark the page itself as "changed" - would mean that you would have to hunt for the change. Since the task was to always visually mark changes in the page, I consider this not an acceptable option.

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