I’d like to suggest that a setting be added so an admin could change the default state of a page when double clicking it from the finder.
Currently, when a user double-clicks a page, they then must click on “edit” to get into the edit mode. This seems to me, to be an extra, and unnecessary step given that they already assume that opening a page in the editor makes it “editable”.
Workflow would improve if double-clicking a page from the Finder immediately put a page into a live edit mode since that would be the expected behavior (unless I’m missing the reason why Percussion requires this extra step).
In short, I agree. The current CM1 preview frame that loads when double-clicking on a page or asset does help to ensure that a user has selected the proper page / asset before truly opening the page in the editor, which then puts the page into the Quick Edit workflow state. While I see how you wouldn’t want users accidentally putting pages that should be Live into the Quick Edit state just by double-clicking on them (and thus making them unpublishable until re-approved), I think at least adding a direct shortcut to edit the page through the Finder toolbar’s gear action button (when a page is selected) would be extremely useful.
Hmmm. I’m not sure that the gear icon option improves efficiency.
Allow me to review the editing workflow options as I see them:
Current: double-click (counts as one click for purposes of this discussion) opens the page into a quasi-preview mode (not the actual preview mode which is accessed by single-clicking the blue page link in the Finder). Then click on “edit” button. 2 clicks.
Your suggestion above: Click ONCE on page, click on gear pull down menu, select a yet to be implemented “edit” option. 3 clicks.
My suggestion: Double-click page to get directly to edit mode. One click.
Option 3 requires a “cancel” button to be added to the editor menu bar in case someone makes a change they didn’t want to make (a button that I think is badly needed anyway.) In fact, I’m curious as to why Percussion settled on a cancel and save button for the layout and style tabs but not for the content tab.
[Digression: why is there a “style” tab displayed in the Editor mode? Can a user do styling while in this view? It doesn’t seem contextual.]
Regarding the content cancel and save button; I’d like to see CM1 more closely conform to common editor UI principles. It would be great if a double-click in the editor put the page in edit mode as this is an expected behavior and then add a save and cancel button to the editor content tab as this is also expected behavior.
I believe that currently, any change made to the content while in editor mode is immediately saved, even if you didn’t want it to be saved, correct? What happens if someone starts making a change to a page and then decides against the change? How do they cancel their edits?
Put another way, it seems that the reason that a page doesn’t go immediately into edit mode from a double-click is that from the moment a page is in edit mode, it moves to a draft state and changes are immediately applied. Even SharePoint (image below) has a cancel button to avoid this problem (sorry, that’s a low blow ;-).
Dan, The reason behind this design decision was to support organizations where “content departmentalization” takes place. In other words, organizations where Department A would be responsible for maintaining the content in one part of the site, while Department B would be responsible for the content in another part of the site. Both department A & B would have read-only rights to see one another’s content, but using the workflow configuration users would only have access to edit their content. There was also concerns of “incidental edits” if the page were open for review, but the user did not intend to make content changes. The thought was that users should take the extra step to “opt in” to editing to prevent mistakes.
That being said, I’m not certain these design decisions were the right ones. Where we thought departmentalization would be the more common use case, we are finding in practice that it more of the exception case. Many of our customers have a smaller number of users who have access to everything. Those who are departmentalizing want further enhancements to reduce “clutter” and steps for users with access to limited content.
As we go forward, we are absolutely looking at simplifying the user experience to optimize user efficiency. We appreciate the suggestions on this front.
All very good points, however I do want to point out that the current design forces the system to assemble the page’s content twice, whereas the idea I highlighted would only assemble the content once. So while you are counting the clicks correctly, with the current method you have to wait for content to load between clicks, and I feel that eliminating that wait and load period between clicks would improve the user experience. I hope I’m not splitting hairs as this point!
"There was also concerns of “incidental edits” if the page were open for review, but the user did not intend to make content changes. The thought was that users should take the extra step to “opt in” to editing to prevent mistakes. "
This I can sympathize with. Hopefully the idea of including a “save” and “cancel” button would solve the issue. Thanks for considering it.
