UI changes to the CMS site tree and filter panel

[Paul Clarke]

We are wanting to address a few issues which were confirmed late last year (e.g. users being confused that there are two different site trees with different actions, and the ability to find the deleted pages and not knowing they could retrieve them). We have a few suggestions we would like to put forward for feedback.

Some of the things you will notice in the interactive wireframes:
We are moving the filter panel to where the search icon is making it available to both site trees and other areas of the CMS if needed.
The site tree toggle has been separated out of the tab system to reduce confusion between content that can be viewed in multiple contexts rather than completely different content available in tabs.
Both site trees look the same and contain the same actions (eventually we want them to be the one and the same)
Breadcrumbs have been moved over the page name, as this will effect the area available for the far right tabs so we are considering removing the bulky tab look which will also allow more space for the tabs.

These wireframes are click-able and you can comment directly on the wireframes if you choose to but please remember that these are not hi-fedality designs and things will be improved as we go.
To see the clickable areas just click on the screen to look for hotspots. http://invis.io/T53A9E7QA

Let us know what you think, cheers

[Ingo Schommer]

Hey Paul and team, great work, love it, soooo much better! Trying to find something to complain about, but can't :D

Observations:

- Once we have bulk actions in the list view it'd be more a consistent experience as well. Some bulk actions will be easier to select through tree (deep hierarchies), others through the list view (search results, large amounts of pages).

- The "search" panel might get longer depending on how its customised. I want a "limit to currently selected parent" option in there for the list view at some point, and we could conceivably come up with separate "published" vs. "edited" date range selectors. I guess that can be solved by scrolling the panel, to avoid pushing down the tree outside of view.

--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to silverstripe-d...@googlegroups.com.
To post to this group, send email to silverst...@googlegroups.com.
Visit this group at http://groups.google.com/group/silverstripe-dev.
For more options, visit https://groups.google.com/d/optout.

--

Ingo Schommer | Solutions Architect
SilverStripe (http://silverstripe.com)
Mobile: 0221601782
Skype: chillu23

[Gregory Smirnov]

Hello Paul,

 

I like the improvements as well.

 

However Search panel should not grow in size. It should be divided into Quick Search and Advanced Search to cover filter functionality with ability for developers to override both forms.

The quick search form should consist of 1-2 fields and be used as shown in your wireframes. It should have a link to advanced search where current layout looks more appropriate and the filter panel allows to add more and more options.

 

We have a custom field that allows to quickly jump to existing page by url. It uses auto complete ajax to get related URLSegments. Then an editor selects url and presses the button [GO] to open editor for the page. This is the most popular way to navigate to pages for our editors.

 

Gregory

[Paul Clarke]

Cheers for that Gregory, we agree with the "Advanced" search fields but for now we are leaving that as an additional enhancement to try and limit the work making sure it gets out sooner rather than later. Thanks for the tip on the URL link, we'll consider that as another enhancement along with Ingo's request to limit search to the current page as well (they seem to overlap in some respects).