Questions About The CMS Design

[mrsteveheyes]

First of all, top work on version 3. It is looking like a great piece of kit and I am looking forward to developing with it.

I so have some questions about the design of the admin section.

It is more specifically with the decision of putting Edit Pages in the left hand column (div#cms-menu) once you start to edit a page. At the moment, I don't understand the logic behind the decision. I was thinking it should be in the Pages section. The CMS menu seems to be for more global navigation, such as reports, users and settings etc. I imagine that things such as cart and the like will go in there. However I don't get that when I edit a page; a new option appears called "Edit Page". I don't get why it is in a global menu rather than a more specific one for pages? 

Also, while in the "Edit Pages" section and I have Saved & Published and I want to add a new page, I have to either click on "Pages" and then "Add Pages" and or click the menu arrow which collapses the menu on pages and click "Add Pages". I was wondering why there isn't a "Add Pages" button in the "Edit Page" section. I would imagine if the "Edit Page" section was inside of "Page" then this wouldn't be needed.

As I said, a lot of great work has been done on V3, I am not trying to nick pick but I genuinely think that this would improve the CMS. One of the beautiful thins of SS v2 was it was very intuitive. When we moved over to SilverStripe from WordPress it halved the training times by half for our clients. I would love for this to continue and feel that the current design is not as intuitive. 

I would love to hear others thought and whether that it is just me and also what the reasons behind the decisions where.

Cheers,

Steve

[Ingo Schommer]

Hey Steve, thanks for your feedback! 

Having "Edit Page" as a separate toplevel menu entry makes

sense if you consider collapsing the menu and having a fullscreen preview next to it.

In this case, no sub-entries will show, only the icons - and authors will need an obvious way to get back into "cms mode". 

Since the original designs, we've added a bottom toolbar to the preview,

with an "Edit Page" button on the bottom right, which fulfils this purpose as well.

So the perspective of a collapsed menu + preview, the toplevel entry is no longer necessary.

But I would find it just as weird to have new entries appear under the "Pages" menu.

- "Edit & Organize" and "Add Page" would be generic, and always show

- "Content", "Settings" and "History" would be page specific, and need to be hidden if no current page is selected.

And I'm very reluctant to change those three sections to tabs in the interface (as one of Felipe's design suggests),

too much of the CMS architecture hinges on them being separate toplevel sections.

I agree that its too clumsy to get from "Edit Page" to "Add Page" only by expanding the menu,

and that its a very common use case. I'd be happy to put an "add page" button above the tree.

It also leaves the button in more or less the same place as in 2.4 (top right above the tree),

which will help people in switching to 3.0. How do others feel about that?

Ingo

[Liam Whittle]

I played around with the beta last night and had the same feelings about the add new page link. Felt like too many steps to create a new page when you were viewing a page. So I'd be for your suggestion.

I see the new site tree that has been added in that wasn't in the alphas I tested. I think it's a pretty elegant solution for those that were missing it. 

My question is how is performance with it? I remember with 2.4 if you had a site with 1000s of pages, it would really cripple performance to load the tree and spike the server/php memory usage. Has this been avoided this time around?

--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
To view this discussion on the web visit https://groups.google.com/d/msg/silverstripe-dev/-/udg3vhNdViYJ.
To post to this group, send email to silverst...@googlegroups.com.
To unsubscribe from this group, send email to silverstripe-d...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/silverstripe-dev?hl=en.

[Ingo Schommer]

The tree has been smart around loading nodes in 2.4 already, trying to limit to 30 nodes,
and lazy loading the rest on demand (node expansion).
That's unless you have flat structures, which it has to display in full.
But in general, yeah, its still the same performance impact.
As long as you stay within the "Edit Page" UI, that won't make an impact,
as it just loads the edit form when clicking on a page tree node.

But if you switch between "Pages" and "Edit Page" often,
its going to have a noticeable impact. We can counteract
this by not loading the tree when the panel is collapsed,
and ajax-loading it when its expanded.
For now, that's a low priority work item though,
unless anybody raises his hand to do it.

[Sigurd Magnusson]

I agree that its too clumsy to get from "Edit Page" to "Add Page" only by expanding the menu,

and that its a very common use case. I'd be happy to put an "add page" button above the tree.

It also leaves the button in more or less the same place as in 2.4 (top right above the tree),

which will help people in switching to 3.0. How do others feel about that?

Getting from Edit Page to Add pages does seem to take quite a few steps so that seems like a reasonable solution to build and see whether it works well in practice.

Having the chance to play with the editing, browsing, and managing pages, it shows that an additional, separate, progression could (should?) also be implemented to make Pages and Edit Page systems more intuitive; i.e. bring them together, and remove the duplication of having both. The narrow tree panel shown when editing pages could have an expand option or "Manage Pages" button, which when clicked, expands into the panel into the fuller Edit & Organise Pages view (and shrinks the edit page panel into a tucked away tab). When you click a page to edit it, in then narrows the tree again (back into a readonly tree view), providing room to the edit page. One major benefit of this is that when you use the filter system, then the narrow site tree shows the results still. Right now, if I click on a filter search result, and edit a page, the site tree shows (which is not what I want) and if I click 'back', then my filter has been lost. This is probably best explained in a screenshot, it's quite simple and I think, quite effective.

[Sam Minnée]

> But I would find it just as weird to have new entries appear under the "Pages" menu.
> - "Edit & Organize" and "Add Page" would be generic, and always show
> - "Content", "Settings" and "History" would be page specific, and need to be hidden if no current page is selected.
> And I'm very reluctant to change those three sections to tabs in the interface (as one of Felipe's design suggests),
> too much of the CMS architecture hinges on them being separate toplevel sections.

What about putting the current 'Edit Page' menu item as a sub-item of pages?

So, when you first click pages you will see this in the LHS menu:

Pages
- **Edit & Organise**
- Add Page

And then when you click on "About us" in the tree, to edit it, you will see this in the LHS menu:

Pages
- Edit & Organise
- **Edit "About us"**
- Add Page

Putting the page title into the LHS menu made more sense than having "Edit & Organise" and "Edit page" as two items.

[Ingo Schommer]

We'll need to put the "Content", "Settings" and "History" sections somewhere:
a) Third menu level *shudder*
b) Same level (with page name prefix?)
c) Outside of the LHS menu, e.g. in content area tabs

Felipe mocked this up here: https://github.com/silverstripe/silverstripe-design/blob/master/Design/ss3-ui_Pages-nested-nav.jpg

Frankly, its going to be a royal pain to change the UI around to accommodate it at this point in time,
as we need to make the tabs load via ajax, hook them into the HTML5 history state,
and create styles + behaviour for secondary tabs. There was a thread about this on the mailing list
shortly after alpha2 came out I think.

> --
> You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.

> To post to this group, send email to silverst...@googlegroups.com (mailto:silverst...@googlegroups.com).
> To unsubscribe from this group, send email to silverstripe-d...@googlegroups.com (mailto:silverstripe-d...@googlegroups.com).

[Sam Minnée]

On 14/03/2012, at 12:51 PM, Ingo Schommer wrote:

> We'll need to put the "Content", "Settings" and "History" sections somewhere:

Doh, I missed that I thought they were already in tabs.

> Frankly, its going to be a royal pain to change the UI around to accommodate it at this point in time,
> as we need to make the tabs load via ajax, hook them into the HTML5 history state,
> and create styles + behaviour for secondary tabs. There was a thread about this on the mailing list
> shortly after alpha2 came out I think.

OK - let's go for a simple fix for now and see what it's like.

[Sigurd Magnusson]

I know there was a discussion earlier, e.g. post alpha2, but from memory this led to us introducing the site tree back in edit-page view.

This thread is now dealing with the implications of that change --- which a lot of us are now having the first chance to play with.

Agree we'd hope to avoid major rework, but we do want to ensure we deliver something with a great, intuitive, interface.

Right now we do have an issue that stops us short of that goal.

Here's my skitch to show how the Edit Pages / Pages can be integrated:

https://skitch.com/sigurdmagnusson/8j4ms/screen-shot-2012-03-14-at-1.35.45-pm

- As you can see, clicking [Manage >>] widens the tree panel to become the existing Edit and Organize system; and when in that mode, clicking a page reverts the tree panel back to the view shown on Skitch. 

- The Filter panel needs to be there.

- I've left the fate of Content/Settings/History tabs as a question mark, as Ingo you've suggested a few ideas and I'm less concerned by how that part is resolved. That said, Felipe's link you posted at  https://github.com/silverstripe/silverstripe-design/blob/master/Design/ss3-ui_Pages-nested-nav.jpg does seem like a very clean and logical interface for shifting those items to top right.

- The result is we only need 'Pages' on the main left hand menu, and lose 'Edit Page' as a top level menu item.

[Sam Minnée]

I wouldn't want to do anything this major without Felipe's involvement, who's on leave at the moment.  For now, Ingo, my inclination would be to trial the smaller change you suggested and see how it plays out.

If we decide that a UI that takes more dev work is really going to be what improves the interaction, we can consider whether we want to prioritise that over other stuff in the pipeline.  It may seem like we're reworking it to death, but it is the single most common interaction and it is worth our attention.

Ingo - do you want to raise a ticket for your quick fix?

[mrsteveheyes]

Wow guys, I'm blown away my the speed of discussion and support there is in this! And there was me just thinking I was being awkward!

I think the quickest fix would be to add a "Add New Page" button above the tree in the "Edit Page". This would remove most of the confusion and wouldn't be too difficult to implement?

In the long run, I like Felipe's mock up, however I understand that having nest tabs in tabs isn't ideal. I really like you're implementation Sam. One thing I really liked about SSv2.4 was that when you logged in you where straight into the pages sections and the tree was there and you can edit straight away. Would it not be worth implementing most of the functionality in Pages > Edit & Organize into the the column (#cms-content-tools-CMSPageEditController) in "Edit Page". I guess similiar to how it was in SSv2.4. I realise that we want to expand and move forward and not necessarily copy the functionality in v2.4 but I genuinely think that the "Edit & Organize" section does not need it's own page. 

Also, is there any way to create global settings at the moment? In v2.4 you can create a SiteConfig_MySiteDecorator class in SiteConfig.php and add global stuff that can be used in the templates. If i did this in SS3 where would I be able to edit these? Haven't played about so doing that annoying thing of asking before trying but thought I'd ask.

Top work. The SilverStripe community and team shine once again :)

Steve

[edch...@gmail.com]

Interesting discussion last few days, and I must say I do like the change of having the site tree exposed now as soon as you log into the cms. My suggestion though to reduce the number of steps for adding a page, why not bring back the 2.4 method and have a dropdown and a create button above the site tree? Even when editing an existing page, I'm not sure of the performance hit this would cause but just a thought ;).

> --
>
> You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
>

> To view this discussion on the web visit https://groups.google.com/d/msg/silverstripe-dev/-/ECQbTlEenaAJ.
>
> To post to this group, send email to silverst...@googlegroups.com.
>
> To unsubscribe from this group, send email to silverstripe-d...@googlegroups.com.

[Mike Andrewartha]

I've also been thinking about this for a little while and hear is a
quick fix:

2.) One way to solve this could be to change Pages to 'Site Tree' (any
other name suggestions are welcome) and make this section just a add,
remove, modify site tree focused section. One thing that should really
be here is the ability to add multiple page in order to make this
section really come alive (another ticket I guess?). Once you create a
page you shouldn't be referred to the Edit page tab. I see this
section as just focusing on changing the site tree so unless you
select a page to edit, then you should be sent to the 'Edit Page'
section.

3.) Remove the hiding/showing of the 'Edit Page' section as this
really confuses me. When you click this page I guess the default
should either be the homepage or the last page selected (?)

Is this an easy change to make for the meantime? Then when Felipe
comes back he can look into it more carefully.

Mike.

On Mar 14, 12:26 pm, edchip...@gmail.com wrote:
> Interesting discussion last few days, and I must say I do like the change
> of having the site tree exposed now as soon as you log into the cms. My
> suggestion though to reduce the number of steps for adding a page, why not
> bring back the 2.4 method and have a dropdown and a create button above the
> site tree? Even when editing an existing page, I'm not sure of the
> performance hit this would cause but just a thought ;).
>

> > I know there was a discussion earlier, eg post alpha2, but from memory

> > this led to us introducing the site tree back in edit-page view.
> > This thread is now dealing with the implications of that change --- which
> > a lot of us are now having the first chance to play with.
> > Agree we'd hope to avoid major rework, but we do want to ensure we
> > deliver something with a great, intuitive, interface.
> > Right now we do have an issue that stops us short of that goal.
> > Here's my skitch to show how the Edit Pages / Pages can be integrated:

> >https://skitch.com/sigurdmagnusson/8j4ms/screen-shot-2012-03-14-at-1....

> > - As you can see, clicking [Manage >>] widens the tree panel to become
> > the existing Edit and Organize system; and when in that mode, clicking a
> > page reverts the tree panel back to the view shown on Skitch.
> > - The Filter panel needs to be there.
> > - I've left the fate of Content/Settings/History tabs as a question mark,
> > as Ingo you've suggested a few ideas and I'm less concerned by how that
> > part is resolved. That said, Felipe's link you posted at

> >https://github.com/silverstripe/silverstripe-design/blob/master/Desig...

[Mike Andrewartha]

Heh if you aren't sure there isn't a 1) so sorry about that...

Also +1 for a create page button in the Edit pages tree so you don't
have to keep on changing between sections just to add/delete 1
page : )

[Martine]

Only now found the time to start playing with the new 3.0.0 - and I'm
getting happier by the minute :-) it all seems to come together now!

As for adding new pages - right-clicking a page in the SiteTree will
let you add a new page as well, leading you straight to the 'Add
Pages' screen. The only tiny glitch is you cannot click is the
SiteTree root. OK - once you're on the 'Add Pages' screen, you can
change the location of the new page to 'root', but adding a right-
click on the sitetree root will make it even nicer. And that would
just be a simple fix (I hope?)

[Ingo Schommer]

Some suggestions that came up have been discussed in previous threads, specifically:

"Page" vs. "SiteTree" naming and the reasoning for "Edit Page".

So to avoid repeating the same discussions, here's a bit of reading material.

I hope that everybody taking part in this discussion has at least a chance

to glance through previous points that have already been made :)

"ss3 UI": https://groups.google.com/forum/?fromgroups#!topic/silverstripe-dev/9FHJZna-VWA

"ss3 tree view designs": https://groups.google.com/forum/?fromgroups#!topic/silverstripe-dev/qSP6OW_Wz0k

"Sitetree sidebar": https://groups.google.com/forum/?fromgroups#!topic/silverstripe-dev/XzWmMEfEDuw

"Edit page vs. Page section naming": https://groups.google.com/forum/?fromgroups#!topic/silverstripe-dev/sHWFHiogWLs

"UI discussion": https://groups.google.com/forum/?fromgroups#!topic/silverstripe-dev/ayLTLNrtzgI

"Substantial design changes released": https://groups.google.com/forum/?fromgroups#!topic/silverstripe-dev/WwYg2KrJ0Mw

BTW: It would be awesome if somebody could categorize the UI issues,

and summarize the arguments for/against different solutions. 

Somewhere between documenting decisions and helping to guide the discussion.

Any takers?

[Nicolaas Thiemen Francken - Sunny Side Up]

Hey Everyone

Creating a new page and editing an existing one are the two MOST important actions of any CMS.  I would vote for keeping things as they are until Felipe comes back and then ask him to work out a better solution - carefully and with consideration of all our opinions. Quick fixes or "developer" oriented solutions are less desirable I think.  If it takes a lot of re-coding then so be it.  This is the first thing that new SS CMS users will look at and if it is anything but surprisingly easy then we have lost them. 

Just to add my own five cents... I find the buttons on the upper-left (e.g. you click on settings and then need to choose between "who is allowed to view the page" and "behaviour") a bit out of place.  

Otherwise I am STOKED with 3.0.  VERY EXCITING.

Nicolaas

[wolfv]

And a submenu under the right-click menu for direct Pagetype-selection would make me the happiest man alive! I might give it a shot :)

> > > > To post to this group, send email to silverstripe-dev@googlegroups.com.

> > > > To unsubscribe from this group, send email to

> > > > silverstripe-dev+unsubscribe@googlegroups.com.

[Sam Minnée]

Sounds fine, but can we please make sure that we don't have anything on the submenu that can't also be accessed with a normal left-click button somewhere.

Sam Minnée
CEO
SilverStripe

[Felipe]

Hi Guys, 

Thanks for all the feedback. I agree the main function of the cms is to edit, add and remove pages and that should be simple, clear and 

straight forward. The designs evolved since the first concept and we still have things to adjust as we take those ideas to a 

working product. I had a play with sig the other day and I agree we have an issue with the flow from pages to edit page. 

Because there are several different interpretations of the right flow by just looking at the designs I've decided to 

design the main flow of going from pages to edit page and backwards so we can have a clear picture to discuss.

Please check https://github.com/silverstripe/silverstripe-design/blob/master/Design/Pages-flow.png

I've taken most of the feedback you gave in consideration let me know if that sounds like a good solution

@Ingo and @Sam please tell me if that's too hard to achieve

Cheers

Felipe

[Frank Mullenger]

Hi Felipe,

+1 for your changes to remove the "Edit Page" sub menu. When browsing a website in preview mode I'm happy to use the "Edit" button in the lower right corner rather than having an "Edit Page" icon on the left.

With your new designs where are settings for a page located? Personally I quite liked having the tabs for settings etc. similar to your first designs with nested tabs:
https://github.com/silverstripe/silverstripe-design/raw/master/Design/ss3-ui_Pages-nested-nav.jpg

Although it sounds as if nested tab support is not going to make it in? I tend to use quite a few nested tabs when developing, find them very useful and a few modules I use tend to organise their content with nested tabs too.

It would be great to continue using nested tabs I think, even if they weren't part of HTML5 history state perhaps.

Appreciate all the hard work going into this btw!

Cheers,

Frank

--

You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.

To view this discussion on the web visit https://groups.google.com/d/msg/silverstripe-dev/-/BsO8LDARNckJ.

To post to this group, send email to silverst...@googlegroups.com.
To unsubscribe from this group, send email to silverstripe-d...@googlegroups.com.

[Ingo Schommer]

Hm, one and a half steps forward, one step back. We're getting there...

Particularly due to the layout context switches (toggle various panels, complex view/panel reloads)

this is not going to be an easy task, and as so often, the devil is in the details.

More details than a graphic can express, so I think any design effort has to be accompanied

with actually writing stuff down in a ticket: http://open.silverstripe.org/ticket/7094 

Felipe, if you change the design, can you please ensure the ticket stays up to date?

(from a UI perspective rather than the technical details).

As Frank noted, we still need a place for the "Settings" and "History" views of a single page. Felipe?

I don't particularly like the pill+tab solution displayed here: https://github.com/silverstripe/silverstripe-design/blob/master/Design/ss3-ui_Pages-nested-nav.jpg

Its quite common to have two levels of tabs in 2.4, so this solution would make it three levels.

Yes, that's bad usability practice, but nevertheless a widely used one in pretty much all SilverStripe sites out there.

Technically, the first level ("Content"/"Settings"/"History") won't affect tabsets created via SiteTree->getCMSFields(), its more of a visual problem.

We could ask devs (module + custom code) to consolidate their content-related tabs into a single level,

but that's not always feasible due to the sheer amount of logical sections as well as the limited width for tabs in the designs (and no way to horizontally scroll them).

On the other hand, this record-specific first level conceptually doesn't belong in the menu.

How about displaying second level content tabs inline as "sections"/headlines within the same tab? Take the following (made up) example: https://skitch.com/chillu/8q6m7/myimage

More challenges:

 * Its unclear how this solution works with the preview expanded. When you navigate to a different page within the preview, I assume that a click on the "pages" icon would take you to the edit view of this new page? In other words: There's no direct way to get from preview to the full "pages" tree view (which I think is OK).

 * How do you get from the "tree sidebar + edit page" view back to the full tree? The only way I see currently is clicking on the menu entry

 * We can't easily show the amount of pages matching a filter, due to the way querying is implemented behind the scenes ("marking filter"). That'll be a major refactoring to fix in a clean and performant way.

 * The "filter" sidebar is hidden in "edit view", that's on purpose, right? More work, but makes the view easier on the eyes, and less confusing (no edge cases around changing filters while editing a page)

 * If the list or gallery view (not the tree) is shown, what happens when switching to "edit page"? I guess we'd have to switch to the tree view, and ensure its expanded in the right level? (assuming you can navigate into children/parent "folders" from the list view)

 * Implementation detail: "Ignore edge case where modifications to the currently edited page would remove the page from the filtered tree"

[Sigurd Magnusson]

On 2 April 2012 21:09, Ingo Schommer <ingo.s...@gmail.com> wrote:

Hm, one and a half steps forward, one step back. We're getting there...

I think, once implemented, this is more like 5 steps back, 15 steps forward, as in, I agree this creates rework and the bashing of Ingo's head against the wall, but, I think everyone will love the result ...

 

Particularly due to the layout context switches (toggle various panels, complex view/panel reloads)

this is not going to be an easy task, and as so often, the devil is in the details.

More details than a graphic can express, so I think any design effort has to be accompanied

with actually writing stuff down in a ticket: http://open.silverstripe.org/ticket/7094 

Felipe, if you change the design, can you please ensure the ticket stays up to date?

(from a UI perspective rather than the technical details).

I had a quick look at that ticket. It's hard for me to ascertain if this has captured everything in Felipe's diagram so I guess it will be a case of those interested in this thread commenting back when the ticket is partially committed back and in working code.

 

As Frank noted, we still need a place for the "Settings" and "History" views of a single page. Felipe?

I don't particularly like the pill+tab solution displayed here: https://github.com/silverstripe/silverstripe-design/blob/master/Design/ss3-ui_Pages-nested-nav.jpg

Its quite common to have two levels of tabs in 2.4, so this solution would make it three levels.

Yes, that's bad usability practice, but nevertheless a widely used one in pretty much all SilverStripe sites out there.

Technically, the first level ("Content"/"Settings"/"History") won't affect tabsets created via SiteTree->getCMSFields(), its more of a visual problem.

Felipe's shown two different designs with horizontal tabs/links at top right of the interface. This is a lot clearer than menu items for Settings/History on left side. I'd assert Felipe's ideas are an improvement on what's currently there and so, in the absence of any better idea being presented, his interface should be adopted. 

@Felipe, it seems you need to identify a third-level menu interface presentation idea, or state that Ingo's suggestion below is adequate. :)

 

We could ask devs (module + custom code) to consolidate their content-related tabs into a single level,

but that's not always feasible due to the sheer amount of logical sections as well as the limited width for tabs in the designs (and no way to horizontally scroll them).

On the other hand, this record-specific first level conceptually doesn't belong in the menu.

How about displaying second level content tabs inline as "sections"/headlines within the same tab? Take the following (made up) example: https://skitch.com/chillu/8q6m7/myimage

More challenges:

 * Its unclear how this solution works with the preview expanded. When you navigate to a different page within the preview, I assume that a click on the "pages" icon would take you to the edit view of this new page? In other words: There's no direct way to get from preview to the full "pages" tree view (which I think is OK).

Seems so. This will be something good to user test and see if the feature is enjoyable to use in this implementation.

 

 * How do you get from the "tree sidebar + edit page" view back to the full tree? The only way I see currently is clicking on the menu entry

https://github.com/silverstripe/silverstripe-design/blob/master/Design/Pages-flow.png states this.

There's a Edit Tree button. This button, IMHO, is very important to the interface and a large part of my argument much earlier in this thread.

 

 * We can't easily show the amount of pages matching a filter, due to the way querying is implemented behind the scenes ("marking filter"). That'll be a major refactoring to fix in a clean and performant way.

Does that block implementing something or did just prevent you from putting "123 results" somewhere in the interface. Listing the quantity of results isn't impt, I reckon.

 

 * The "filter" sidebar is hidden in "edit view", that's on purpose, right? More work, but makes the view easier on the eyes, and less confusing (no edge cases around changing filters while editing a page)

 

https://github.com/silverstripe/silverstripe-design/raw/master/Design/Pages-flow.png states "Filtered Tree. Clear Filter" so that seems to answer your question affirmatively.

 

 * If the list or gallery view (not the tree) is shown, what happens when switching to "edit page"? I guess we'd have to switch to the tree view, and ensure its expanded in the right level? (assuming you can navigate into children/parent "folders" from the list view)

It should show the same items you were previously browsing, I expect like the filter view with edit page, as shown in https://github.com/silverstripe/silverstripe-design/raw/master/Design/Pages-flow.png

 

 * Implementation detail: "Ignore edge case where modifications to the currently edited page would remove the page from the filtered tree"

Sure. :)

[Sigurd Magnusson]

Ingo has implemented a considerable number of design/UI improvements discussed in this thread and has asked me to put up a post with progress thus far and so he can head to bed :)

Please check out where we're at and offer ideas, noting there's still more work to be done.

To recap, the end goal is visualised at https://github.com/silverstripe/silverstripe-design/blob/master/Design/Pages-flow.png and spelt out by a few tickets such as http://open.silverstripe.org/ticket/7094 and http://open.silverstripe.org/ticket/7166

For those not wanting to download code: Ingo has also put up a screenshot at https://skitch.com/chillu/8u4m4/silverstripe-edit-page as part of a bug description and this shows current state and a few of the things remaining to be done.

I'm sure there are further issues and ideas yet to be articulated.

---

Ingo's words now:

Code:

https://github.com/silverstripe-big-o/sapphire/tree/7094-combine-tree-edit-view

https://github.com/silverstripe-big-o/silverstripe-cms/tree/7094-combine-tree-edit-view

Specifically this commit: https://github.com/silverstripe-big-o/silverstripe-cms/commit/6aeac37906bc2d244bccedd467f0402e5942166e

Notes:

- Only works in Webkit, cuts off tabs in other browsers (jQuery UI weirdness?). As I said, work in progress ;)

- Preloaded instance with a couple of hundred pages to demonstrate tree performance

- Tree HTML is cached on client after first load, so switching from admin/pages to admin/pages/edit/show/<id> is not as slow as it could be

- That being said, its still slow, as the tree needs to be rendered again from HTML. Looking into partial reloads, which will make things more complex, but faster. Post beta2 most likely.

- Breadcrumbs don't refresh on list navigation, same problem essentially - Julian has solved this in a branch.

- Jeremy is doing the required design changes at the moment, so tabs etc. still look rough

- Try filtering on admin/pages, it keeps it in the URL (which authors can bookmark/share => FTW).

  Also retains tree filtering when switching to page edit view.

- Lazy loading both tree and list view, which makes the initial admin/pages load perceived faster.

  Probably changing that to only lazy load the current view (denoted by query param), less processing on client.

--

Cheers, Sigurd.