Title does not change to match the current folder when navigating folder_contents

[pigeonflight]

Title does not change to match the currently active folder in folder_contents

To reproduce:
When I click on News then click on contents the title in the folder listing is set to "News", when I then click on the home icon the title remains "News", then I click on Events and the title remains "News"
See gif:

Expected behaviour:
When I click on News the title should say "News", when I click on the home icon the title should change to reflect that I am now browsing the home folder, when I click on Events the title should change to say "Events"

[hvelarde]

confirmed: folder contents view is partially updated using AJAX calls; seems the location bar is updated using JS but the title is not.

[djay]

I don't think it makes much sense to have these screens inside the rendered
page. When I theme plone 5 use different front and backend themes and
anything backend like folder contents just has search and that's it. And
breadcrumbs. But no header or footer content or nav or title. Its just
taking up space and doesn't make sense in that context.
In the case of folder contents it shouldn't have breadcrumbs either.

On Fri, 12 Feb 2016 9:19 pm Héctor Velarde notifications@github.com wrote:

confirmed: folder contents view is partially updated using AJAX calls;
seems the location bar is updated using JS but the title is not.

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

[pigeonflight]

@djay You're saying, when in folder_contents view, don't render those parts?

That's a nice easy fix.

[djay]

@pigeonflight no global nav either. And once you do that you might as well remove logo, and search and footer...

This of makes it harder when you do want to include the contents pattern into your public site or extranet but I think that doesn't work well currently anyway and there is another ticket for that.

Personally I'm not sure we need any of that extra elements for edit page, sharing or any backend page. It just takes up space with little benefit. If we want true wysiwyg then we can have split panel live preview page in the edit view.

[thet]

I agree, this is not very intuitive.

The issue would be solved, if the folder_contents would open in an overlay (as it was in plone.app.toolbar times).
The page in the background should stay the same until a content item from folder_contents is selected to be viewed.

[davilima6]

Old overlay was great but I think it's an a11n win if we stick to flatter in-page interaction patterns for the more basic CMS operations. This way we leave room for using overlays when "2nd level" actions require user confirmation or input/details: renaming, changing state, uploading files etc.

I think for visual consistency it's important we keep logo, header and even search available. User might have lots of tabs open and not all of them are CMS pages. Header, and footer, also reinforce the in-context editing diferential Plone has so IMO it's sub-optimal identifying the edit page with a different layout: it's nice that user feels he's touching the real website and not some admin version of it.

So my vote here is to just do that what @pigeonflight originally proposed: update first heading, description and breadcrumbs in the manner location bar already is: to inform user that he/she just really navigated to that item and that from now on everything he/she does, like changing state or adding something with the toolbar will happen in that new place.

[jensens]

I would really love to see the folder_contents fullscreen, toolbar on left or top. That way we would only need to update the toolbar on location change.

We could provide a bix [X] to "close" the folder contents in the top right to make clear that this is something laying (semantically) over the normal content (even if it renders technical not as overlay)

I don't think the visual consistency is broken if the logo and search and other header stuff is missing (if we make it look like an full screen overlay), its more a big usability plus to have lots of space while working with this view.

[jensens]

ad breadcrumbs: folder_contents has its own breadcrumb, we may want to consolidate the appearance, at the moment the double-breadcrumbs are confusing for the users.

[thet]

I think, the following, red colored areas should be left out of folder contents:

In short, any navigatinal elements. But the title and description could be quite useful for orientation. The navigation should only be done in the folder_contents view. IMO it's also ok, that the folder_contents breadcrumbs do not look like normal Plone breadcrumbs, because their behavior is completly different. The first does a quick navigation within the folder_contents listing, the latter moves away from that view and shows the item in display mode.

[davilima6]

Since we still have Plone logo in the toolbar I agree not all visual consistency and page/tab identification is lost. I can also see the benefits of not having two breadcrumbs and, which seems more central, increasing screen space and narrowing focus for the user initiated system task (in this case, bulk managing content).

OTOH we immediately lose quick navigation to other sections (moreso when dropdown menus are enabled, which is common) and also search, which may be useful specially when results are force-opened in a new tab (ctrl+click).

Finally for mental model consistency I suggest we evaluate whether the following views shouldn't have the same behavior. I would at least hide portlets for these:

Manage portlets

Add File

Sharing

History View

Version History Form

[thet]

Not sure, if I really like to loose the Plone border for all those views.

What, by the way, is the problem with overlays in overlays (if the first one is a maximized overlay)? Is it technical or is it a UX problem in general? Still, IMO opening folder contents in an overlay could be the easiest way to solve the problem with it.

[davilima6]

It's mostly UX but there might also be some technical complications. See #717 and https://github.com/plone/plone.app.portlets/blob/master/plone/app/portlets/browser/manage-portlets.js#L46-L47

Besides in the case of folder contents it's useful to save/share URLs so we shouldn't take that control away from user.

I suggest we keep folder contents out of modals, do your proposed changes, @thet, and evaluate if we apply the same logic to the views listed above.

[thet]

I think, this could be solvable. We'd have to make some mockups for that.

However, I see technical problems with the solution, where parts of the site are updated according to navigational changes in folder_contents content structure.
If we update parts, we would depend on elements of the site where we don't know if they even exist. The Logo, globalnav and breadcrumbs could simply be dropped by Diazo or be completely different viewlets. Even other parts of the site could be dependent on the context, which would also need to be reloaded.

[thet]

Researching about UX patterns, I found this nice fullscreen overlay alternative. Imagine, Clicking on "Contents" would push the page away, while leaving the toolbar intact:
http://tympanus.net/Development/FullscreenOverlayStyles/index7.html

[djay]

Its virtually impossible to make it work generically for any theme. And I'm
not sure we are trying. Why does contents have to be inline? Its not a
visual editor.

On Tue, 15 Mar 2016 5:16 am Johannes Raggam notifications@github.com
wrote:

I think, this could be solvable. We'd have to make some mockups for
that.

However, I see technical problems with the solution, where parts of the
site are updated according to navigational changes in folder_contents
content structure.
If we update parts, we would depend on elements of the site where we don't
know if they even exist. The Logo, globalnav and breadcrumbs could simply
be dropped by Diazo or be completely different viewlets. Even other parts
of the site could be dependent on the context, which would also need to be
reloaded.

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

[thet]

Regarding opening folder_contents in modals - here is an example actions.xml file, which makes much of the toolbar items opening in a modal:

<?xml version="1.0"?>
<object name="portal_actions" meta_type="Plone Actions Tool" xmlns:i18n="http://xml.zope.org/namespaces/i18n">

 <object name="site_actions" meta_type="CMF Action Category" purge="False">
  <object name="sitemap" meta_type="CMF Action" purge="False">
   <property name="modal" type="text">{}</property>
  </object>
  <object name="accessibility" meta_type="CMF Action" purge="False">
   <property name="modal" type="text">{}</property>
  </object>
  <object name="contact" meta_type="CMF Action" purge="False">
   <property name="modal" type="text">{}</property>
  </object>
 </object>

 <object name="object" meta_type="CMF Action Category" purge="False">
  <object name="folderContents" meta_type="CMF Action" purge="False">
   <property name="modal" type="text">{}</property>
  </object>
  <object name="history" meta_type="CMF Action" purge="False">
   <property name="modal" type="text">{}</property>
  </object>
  <object name="local_roles" meta_type="CMF Action" purge="False">
   <property name="modal" type="text">{}</property>
  </object>
  <object name="contentrules" meta_type="CMF Action" purge="False">
   <property name="modal" type="text">{}</property>
  </object>
  <object name="syndication" meta_type="CMF Action" purge="False">
   <property name="modal" type="text">{}</property>
  </object>
 </object>

 <object name="user" meta_type="CMF Action Category" purge="False">
  <object name="preferences" meta_type="CMF Action" purge="False">
   <property name="modal" type="text">{}</property>
  </object>
  <!--object name="login" meta_type="CMF Action" purge="False">
   <property name="modal" type="text">{"prependContent": ".portalMessage", "title": "Log in", "width": "26em"}</property>
  </object>
  <object name="join" meta_type="CMF Action" purge="False">
   <property name="modal" type="text">{"prependContent": ".portalMessage"}</property>
  </object-->
  <object name="plone_setup" meta_type="CMF Action" purge="False">
   <property name="modal" type="text">{}</property>
  </object>
 </object>

</object>

For me, it makes perfect sense to open folder_contents in a modal. Also open the history, the sharing tab, personal preferences and site controlpanel in a modal.
Only, the modal needs some improvements: placements of overlays within the modal, opening links within the modal and a fullscreen option.

As I mentioned, a fullscreen overlay like this: http://tympanus.net/Development/FullscreenOverlayStyles/index7.html doesn't only look fancy but would also give us a nice "backend" metaphor.

[davilima6]

@thet, I added those to http://demo.plone.de/ so more people can test/feel the proposal.

[thet]

Thanks!
The modal pattern also misses an option to close it when clicking outside the overlay. But this is all solvable.

[davilima6]

I suggest we also update location bar if we go with overlays. But only on opening, i.e. in the case of folder contents, it shouldn't update as you walk through content tree because when you close the modal you want to be back to the page the overlay was initially launched upon.

Also IMHO we should keep those URLs also functional on their own (standalone) so if as a Site Admin or Editor I want to directly access folder contents for some URLs I already know about, I'm able to. Plone shouldn't turn into an inaccessible overlay-only based CMS.

[thet]

+1 for the functional-as-standalone requirement. This is related to that: plone/mockup#649
With your location bar statement you mean, that when you open the folder contents overlay, /folder_contents should be appended to the URL? Sounds like a good idea and could be handled by the modal pattern.

It looks like this has consensus enough to be PLIP'd.

[davilima6]

@thet: yes, that's what I meant.

Btw, while you're at it, wouldn't you like to add the view suffix, e.g. @@folder_contents? I think it's good way of identifying the native CMS urls, which will all soon be views. If not we might consider dropping for @@sharing, @@HistoryView, @@overview-controlpanel etc. But I guess that should be a new issue.

[agitator]

this is fixed with a new mockup structure pattern in plone/mockup#761
docs follow in plone/mockup#785