Not obvious display menu changes item or preview change

[djay]

User problem

A common mistake is to click on display because someone wasn't sure what it did and changed it from a default view to something else. They aren't sure what happened or how to get it back again and sometimes don't notice something changed until much later.

• In addition, because they aren't sure what it does, they also can't preview what it will look like before making the change.
• In addition there is no history for a display change so can't be reverted that way. Often users had a landing page locked in and never changed this function so didn't know which page was supposed to be set.
• in addition the inclusion of all possible default pages on the current menu makes it go off the screen sometimes which makes it unusable.

(from UX hitlist )

options

1. Toolbar -> Edit folder -> layout tab -> pick layout -> save.

Remove display dropdown and make it part of "edit" of the folder (or any folderish type) as a seperate "layout" tab via a behaviour.

How (1) might look (but as seperate tab)

• Edit (on folder): goes to folder edit with new layout tab that has options to change layout or select an item as default page.
  • has live preview embedded in iframe.
• Edit (on page): won't allow setting as the default page. User would have to know to edit the folder.
  • maybe use info dialog with link to edit folder to select default page?
  • In that case of folderish items which can also be default pages. Then you get a warning to edit the folder like you currently do and they also have their own layout tab.
• Edit (on default page): results in dropdown of "Edit Folder" "Edit Page" "Change displayed Layout/Default page".
  • Alternatively could just edit default page and have the same warning "you are editing the default page" but add "to change the default page edit the folder". Or have a layout tab but include the warning and link in there instead of allowing changing default page from inside the default page.
• Edit (on a mosaic page): it would be: Edit -> properties -> layout.
  • could be a little confusing as there is already a Layout button on mosaic pages.

pros/cons:

• pro: unclutters the toolbar (see Toolbar: commonly used menu items too hard to get to or not where you expect #482)
• pro: gives more space to explain default pages the idea of default pages in not obvious #519
• pro: makes editing collections nicer as currently tabular view is controlled from both edit and display menus, ie two places.
• con: extra click and page load to change.
  • Does it really matter? it's not often used. And preview would be less clicks ot decide which to pick.
• con: Changing the default page is now 4 clicks - edit default page + edit folder + "layout" tab + "select item for default page".
  • could be mitigated by having a shortcut to edit a folder when it has a default page.
• con: won't work for mosaic unless you change how the edit button works
• con: could be complex to implement in backwards compatible way? Would need some kind of behaviour that adds a page when the object has more than one display option? or something in base dexterity?

2. toolbar -> layout (modal) -> select layout -> save

Display becomes a popup rather than a submenu. Similar to (1) but can't edit the content at the same time.

• pro: easyish to implement.
  • replace the menu item with a single item (Display/Layout) that opens a view
  • Render the submenu in a view
  • put in a warning description at the top about what this does
  • Put in a description for each item (not sure from where? registry?)
  • Preview could be either as symbolic images or using JS and iframe to show actual preview
• con:
  • doesn't get rid of extra toolbar item
  • doesn't make display changes go into version history.

rename to layout

The words layout or template are closer to what the user expects. Display does explain this feature well.

3. Mosaic and folderish content

Get rid of the display idea entirely by using folderish content and tiles adjust how an item is displayed see #519

• e.g create a summary view by using inserting a listing tile and setting its listing style.
• pro: default pages are not very intuitive the idea of default pages in not obvious #519

4. Version display changes

Changes to display go into version history. The user can then revert it themselves. Then user has the option to revert it themselves if they made a mistake.

• the problem is caused because the user didn't know they changed something. Someone else discovers it.

6. tooltips on existing menu

7. popup confirmation dialog

"This action will display a listing of the folder contents instead of displaying 'Home Page' as your landing page in this location" [Confirm] [Cancel]

related problems

• display menu can be too long so hard to use - see Insane long list of display options for folder with a collection as default view/Toolbar "display" usability flaws #1407 and Toolbar: commonly used menu items too hard to get to or not where you expect #482
• you can't preview or get a description what each view looks like in the current submenu
• display word is not obvious. Users are more used to "template" or "layout" for this kind of function.
• changes to display aren't shown in the version history.
• tabular view in collections is not obvious that it requires changes in "edit" and "display" to work.

Internal

• How many plugins rely on display?
• putting display into edit means it needs to be a behaviour. plugins would need to be updated

[polyester]

As intermediate step, there was the idea to record changes in the "display" into the history (both on the object and the container in case of default view changes).
That is not a real 'solution' (which needs a bit more thought, a plip, and so) but it at least provides an audit trail, allowing the user to get back to the old state easier.

[davilima6]

I have also faced this problem over and over so +1 on Display being less prominent, but not inside Edit, which is a full page load away (btw one of any CMS's slower kind of views).

Optimal solution needs more discussion but until then I'm +1 on previous positioning inside the generic "More options" toolbar item, together with portlet management, since both are less-then-everyday tasks therefore don't need first-sight priority.

+1 on recording history.

[hvelarde]

👍 on recording this on the history and probably on the event log also

[djay]

recording in history would be nice and does no harm but I'm not sure it would do much to solve the issue that it's not obvious what display does and not enough warning is given about such a big change.

more options is not an option now. the idea of a combined 2nd menu just didn't work. and it also isn't really explaining display either.

I think an overlay or page for display would be good and I don't think it matters it's an extra load. are we sure it's an action that happens that often?
I also think it does make sense within edit @polyester. we already have several layout options within items already such as table of contents and presentation mode. it makes sense to edit a folder to change its layout. it makes sense to edit a page to change its layout. I think it would also make sense to edit a page to select it as the default view of its parent.
I think with a lot of these things we need to try very hard to unlearn our way of understanding Plone based on how it works now so we can have an open mind about alternative ways. No one likes change, I know.

[davilima6]

Thanks, I'm more convinced with ToC and Presentation Mode examples. And since I believe Display is way less needed and used than Edit, I guess we could go with the extra load (hoping it doesn't decrease too much edit page load time). Only two reservations: a) it seems more intuitive and Plone-ish to edit a folder to set its default page than editing the page and b) I think Display deserves its own tab, mostly because that's secondary to primary fields and most of times user will stick to default view.

Still, I didn't follow the reasons why "combined 2nd menu didn't work". That would avoid the load and make Display less prominent. Previews could then be tooltipped to the right for each available option.

[djay]

It might work selecting the default page in either the page or folder.
But since this is for plone 5.1 now since not enough time then I'm hoping
we can get rid of defaults completely for 5.1

On Tue, 21 Jul 2015 18:29 Davi Lima de Medeiros [email protected]
wrote:

Thanks, I'm more convinced with ToC and Presentation Mode examples. And
since I believe Display is way less needed and used than Edit, I guess we
could go with the extra load. Only one reservation: it seems more intuitive
and Plone-ish to edit a folder to set its default page than editing the
page.

Still I didn't get why "combined 2nd menu didn't work". That would avoid
the load and make Display less prominent. Previews could then be tooltipped
to the right for each available option.

—
Reply to this email directly or view it on GitHub
#704 (comment)
.

[djay]

“combined 2nd menu didn’t work”:
If we had a more options and moved a item with a submenu like “display” into it, then we would have a 3 level menu structure which isn’t good usability.
This was solved previously by “unrolling” the 3rd levels into a combined second level menu. The problem with that is “display” can be really long and take most of the screen up byitself so we run out of room.
If display is to stay, I think it needs more room for explanation of what it is for and a second button to push and a POST request to show its an actual change on the object. Currently it doesn’t look or feel like something that makes a change to the content. Possibly the only part that is used often enough to justify a quick menu is “set default page” and that already has an overlay so already just as slow.

[pigeonflight]

I'm +1 for anything solution that provides a preview before committing to a new display.

BTW.. The word "display" feels wrong, from a user perspective. As a normal user I would expect a menu named "content layout" or "content template". In fact, when I explain the display idea to persons I almost always end up talking about layouts.

This may need to be another issue, but adding it here first for what it is worth.

[djay]

I just had another urgent support request for this same issue.

We need a quick win solution

[fredvd]

+1 To chime in, this is indeed a returning support issue where the display menu in the Plone toolbar is too powerful and 'instantanious' for beginning editors to realise what they are doing.

for me personally collective.sidebar seem a promising replacement for the default plone toolbar for me where there's more place (and better popup menu control) with a simpler visual layout where it's easier to implement easy/pro version of the menu's and space to add help texts.

A second, related issue with the display menu, is a selected default page. Either editors switch the display menu to something else and ruin their homepage/landing page, or they delete the selected default page from the folder because they don't realise the content items is used like that (note the asterisk, note the asterisk, I tell with content editing training). deleting a default paged item should get noticed by linkintegrity, which isn't the case in Plone 5.1 at the moment. But that should probably get it's own issue, if it's not already there.

[djay]

@fredvd I'd create the "deleting default page" as a seperate UX bug ticket. I haven't seen it. It's a good thing to fix.

[jensens]

I close the issue, because it addresses Plone 5.1 which is no longer supported.
If you think this is wrong please reopen the issue and assign a matching milestone.