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.
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?
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?
On Tuesday, 13 March, 2012 at 6:54 PM, Ingo Schommer wrote: > 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
> -- > 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 silverstripe-dev@googlegroups.com (mailto:silverstripe-dev@googlegroups.com). > To unsubscribe from this group, send email to silverstripe-dev+unsubscribe@googlegroups.com (mailto:silverstripe-dev+unsubscribe@googlegroups.com). > For more options, visit this group at http://groups.google.com/group/silverstripe-dev?hl=en.
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.
> 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.
> 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:
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
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.
On Wednesday, 14 March 2012 at 12:40 AM, Sam Minnée wrote: > > 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:
> Putting the page title into the LHS menu made more sense than having "Edit & Organise" and "Edit page" as two items.
> -- > You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group. > To post to this group, send email to silverstripe-dev@googlegroups.com (mailto:silverstripe-dev@googlegroups.com). > To unsubscribe from this group, send email to silverstripe-dev+unsubscribe@googlegroups.com (mailto:silverstripe-dev+unsubscribe@googlegroups.com). > For more options, visit this group at http://groups.google.com/group/silverstripe-dev?hl=en.
> 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.
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.
- 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... 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.
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?
On 14/03/2012, at 2:10 PM, Sigurd Magnusson wrote:
> 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.
> - 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... 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.
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 :)
On Wednesday, March 14, 2012 1:31:38 AM UTC, Sam Minnée wrote:
> 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?
> On 14/03/2012, at 2:10 PM, Sigurd Magnusson wrote:
> 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:
> - 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... 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.
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 ;).
On , mrsteveheyes <steve.he...@studiobonito.co.uk> wrote:
> 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
> On Wednesday, March 14, 2012 1:31:38 AM UTC, Sam Minnée wrote: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?
> On 14/03/2012, at 2:10 PM, Sigurd Magnusson wrote:
> 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... > 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.
> --
> 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 silverstripe-dev@googlegroups.com.
> To unsubscribe from this group, send email to
> silverstripe-dev+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/silverstripe-dev?hl=en.
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.
> 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 ;).
> On , mrsteveheyes <steve.he...@studiobonito.co.uk> wrote:
> > 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
> > On Wednesday, March 14, 2012 1:31:38 AM UTC, Sam Minnée wrote: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?
> > On 14/03/2012, at 2:10 PM, Sigurd Magnusson wrote:
> > 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...
> > 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.
> > --
> > 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 silverstripe-dev@googlegroups.com.
> > To unsubscribe from this group, send email to
> > silverstripe-dev+unsubscribe@googlegroups.com.
> > For more options, visit this group at
> >http://groups.google.com/group/silverstripe-dev?hl=en.
> 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.
> > 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 ;).
> > On , mrsteveheyes <steve.he...@studiobonito.co.uk> wrote:
> > > 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
> > > On Wednesday, March 14, 2012 1:31:38 AM UTC, Sam Minnée wrote: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?
> > > On 14/03/2012, at 2:10 PM, Sigurd Magnusson wrote:
> > > 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...
> > > 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.
> > > --
> > > 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 silverstripe-dev@googlegroups.com.
> > > To unsubscribe from this group, send email to
> > > silverstripe-dev+unsubscribe@googlegroups.com.
> > > For more options, visit this group at
> > >http://groups.google.com/group/silverstripe-dev?hl=en.
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?)
On 14 mrt, 17:44, Mike Andrewartha <mandre...@gmail.com> wrote:
> 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 : )
> On Mar 14, 4:40 pm, Mike Andrewartha <mandre...@gmail.com> wrote:
> > 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 ;).
> > > On , mrsteveheyes <steve.he...@studiobonito.co.uk> wrote:
> > > > 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
> > > > On Wednesday, March 14, 2012 1:31:38 AM UTC, Sam Minnée wrote: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?
> > > > On 14/03/2012, at 2:10 PM, Sigurd Magnusson wrote:
> > > > 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...
> > > > 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.
> > > > --
> > > > 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 silverstripe-dev@googlegroups.com.
> > > > To unsubscribe from this group, send email to
> > > > silverstripe-dev+unsubscribe@googlegroups.com.
> > > > For more options, visit this group at
> > > >http://groups.google.com/group/silverstripe-dev?hl=en.
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 :)
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?
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.
> 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?)
> On 14 mrt, 17:44, Mike Andrewartha <mandre...@gmail.com> wrote: > > 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 : )
> > On Mar 14, 4:40 pm, Mike Andrewartha <mandre...@gmail.com> wrote:
> > > 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 ;).
> > > > On , mrsteveheyes <steve.he...@studiobonito.co.uk> wrote:
> > > > > 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 > > > > > On Wednesday, March 14, 2012 1:31:38 AM UTC, Sam Minnée wrote: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? > > > > > On 14/03/2012, at 2:10 PM, Sigurd Magnusson wrote: > > > > > 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... > > > > > 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. > > > > > -- > > > > > 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 > silverstripe-dev@googlegroups.com. > > > > > To unsubscribe from this group, send email to > > > > > silverstripe-dev+unsubscribe@googlegroups.com. > > > > > For more options, visit this group at > > > > >http://groups.google.com/group/silverstripe-dev?hl=en.
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
On 16/03/2012, at 1:08 AM, wolfv <w.vollpre...@googlemail.com> wrote:
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.
On Wednesday, March 14, 2012 10:47:34 AM UTC+13, mrsteveheyes wrote:
> 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
On Wednesday, March 14, 2012 10:47:34 AM UTC+13, mrsteveheyes wrote:
> 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.
+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.
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.
On Mon, Apr 2, 2012 at 3:43 PM, Felipe <felipeskro...@gmail.com> wrote: > 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.
> 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
> On Wednesday, March 14, 2012 10:47:34 AM UTC+13, mrsteveheyes wrote:
>> 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
> On Wednesday, March 14, 2012 10:47:34 AM UTC+13, mrsteveheyes wrote:
>> 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.
> 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. > For more options, visit this group at > http://groups.google.com/group/silverstripe-dev?hl=en.
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/Desig... 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"
On 2 April 2012 21:09, Ingo Schommer <ingo.schom...@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/Desig... > 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
> * 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)
> * 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)
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.
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.
