Improve Add Page for Blog Posts etc

184 views
Skip to first unread message

James Cocker

unread,
May 8, 2012, 10:38:49 AM5/8/12
to silverst...@googlegroups.com
I've been closely following SS3's progress and must say it's looking great. Especially now that there are Add and Edit buttons in the site tree sidebar.

However, there is one aspect of the CMS that I'd really like to see improved, and that is how users add new Blog Post pages or News Article pages etc. This has been the main point of confusion to my least computer literate clients in 2.4, and it would be great to see it improved in 3. As it can also benefit advanced users by cutting out several unnecessary steps.

Let me explain. Currently in SS3, in order to add a new News Article page (or similar) to a News page, the user has to:
  1. Click Add new
  2. Select Under another page
  3. Click in the page dropdown
  4. Click on the News page
  5. Select the News Article page type
  6. Click Create

This process could be greatly shortened to something like this:

  1. Click Add new
  2. Click News Article
  3. Click Create

Much nicer! Users shouldn't have to select the page to create the article under, as it should be possible to tell it in the code that new News Article pages should automatically be created under the News section.

I understand users can right click a page in the site tree to create a new page there, but as this isn't immediately obvious most new users will not realise they can do that.

So I was just wondering if there are any plans to improve this area? Even being able to add buttons to the main Pages page, such as "Add News Article" and "Add Blog Post" which in a single click would create the appropriate page type under the appropriate section would be amazing!

sergio...@gmail.com

unread,
May 8, 2012, 10:53:49 AM5/8/12
to silverst...@googlegroups.com


Em terça-feira, 8 de maio de 2012 11h38min49s UTC-3, James Cocker escreveu:
I've been closely following SS3's progress and must say it's looking great. Especially now that there are Add and Edit buttons in the site tree sidebar.

However, there is one aspect of the CMS that I'd really like to see improved, and that is how users add new Blog Post pages or News Article pages etc. This has been the main point of confusion to my least computer literate clients in 2.4, and it would be great to see it improved in 3. As it can also benefit advanced users by cutting out several unnecessary steps.

Let me explain. Currently in SS3, in order to add a new News Article page (or similar) to a News page, the user has to:
  1. Click Add new
  2. Select Under another page
  3. Click in the page dropdown
  4. Click on the News page
  5. Select the News Article page type
  6. Click Create

This process could be greatly shortened to something like this:

  1. Click Add new
  2. Click News Article
  3. Click Create
This works only if you have only one news holder page. If you have more than one?

James Cocker

unread,
May 8, 2012, 11:05:39 AM5/8/12
to silverst...@googlegroups.com
The vast majority of sites I create just have a single holder page per page type. But for those with more, then the normal way can be used. I see it working by setting a default parent for new page types in the code. If a default parent is set, then new pages of that type are created under it, if not, then nothing extra needs to happen, and the usual select parent page method is used. There is already a "default_parent" static on SiteTree but I don't believe it's functionality has been implemented in SS3 yet.

James

Purple Spider Web Design


--
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/-/9yvLeIWONtAJ.

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.

Sam Minnée

unread,
May 8, 2012, 6:15:37 PM5/8/12
to silverst...@googlegroups.com

So I was just wondering if there are any plans to improve this area? Even being able to add buttons to the main Pages page, such as "Add News Article" and "Add Blog Post" which in a single click would create the appropriate page type under the appropriate section would be amazing

Well, changing the radio buttons to a series of buttons seems less important, but the idea of selecting a default location is something that was present in 2.4 but buggy.  Tidying it up seems like a reasonable idea.

There is also this ticket - http://open.silverstripe.org/ticket/7267 - which I added, suggesting that by default, pages are loaded in uncategorised, rather than in the top level, which means that people could start creating content first and deciding how to categorise it second.

With both of these changes, it might make sense to shift the page type selectors to be above the page location selector: select a page type and then select where it goes.

Taking the idea further, you might even have custom page location fields depending on page type.  For example: if you select "create a blog entry", it just shows you all the blog holder pages as an OptionSetField and you choose one.  No mucking around with a tree at all.

However, right now there is stuff higher on the core team's priority list, so it might be a good thing for someone else to pick up.

Paul Clarke

unread,
May 8, 2012, 7:37:46 PM5/8/12
to silverst...@googlegroups.com
I like the idea and makes sense, if anyone does pick this one up I could work with that person to provide some sort of designs to select what you want to add from the "Add new" button. There are a few different ways of going about it especially if there are multiple blogs/news areas.

Nicolaas Thiemen Francken - Sunny Side Up

unread,
May 8, 2012, 9:15:56 PM5/8/12
to silverst...@googlegroups.com
What a simple yet super idea. In case there is more than one "holder" why not just put it under the "first" (dataObject::get_one) holder OR ask the user to choose one. Nicolaas

Ingo Schommer

unread,
May 9, 2012, 3:50:25 AM5/9/12
to silverst...@googlegroups.com, n...@sunnysideup.co.nz
We've already got a "power user" way of doing this through right clicking on a node and adding a page there. You still have to select the page type, but its less clicks.
In general, we could make this URL a bookmark as well: Either an actual browser bookmark, or a quick access link in a customized CMS template.
So with one click, you can create a new page - depending what data the bookmark contains, this might be under a specific parent, or a specific type.

I agree that we should de-emphasise the hierarchy on page creation,
but wanted to illustrate how we can get around the "one size fits all" problem
by utilizing the existing CMS architecture around form submissions etc.

James Cocker

unread,
May 9, 2012, 4:22:34 AM5/9/12
to silverst...@googlegroups.com
Being able to add buttons to the main Pages view such as Add Blog Post and Add News Article, using the existing CMS architecture would be perfect!

It would also be nice to improve the handling of this scenario on the Add Pages view, for the users that go straight there from the Editing interface. A possible way of doing this would be to swap the order of the fields, so that a user first clicks a page type, and then choses the tree location. This would mean the tree location could be automatically set if a default_parent is set for the selected page type. Alternatively, the tree could only appear if default_parent wasn't set, and stay hidden if it was to simplify the interface.

I'd be happy to help on this, but wouldn't know where to start on the code side, so could work with someone who is, to come up with the best solution.

Purple Spider Web Design


--
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/-/hSFmLtg7N94J.

Ingo Schommer

unread,
May 9, 2012, 4:36:45 AM5/9/12
to silverst...@googlegroups.com
I've written a tutorial on how to add a "quick access" bar to the CMS a while ago:
The template overloading is currently broken due to a bug in TemplateManifest, see http://open.silverstripe.org/ticket/7085
but that should give you a general idea.
signature.asc

James Cocker

unread,
May 10, 2012, 12:08:08 PM5/10/12
to silverst...@googlegroups.com
Looks good, I'll have to have a play with that. Although it does seem to be a lot of work for something I feel should already be built in, perhaps this will help someone build in support to make it easy for devs to add "New Blog Post" buttons etc.

James

Purple Spider Web Design


James Cocker

unread,
May 11, 2012, 7:58:39 AM5/11/12
to silverst...@googlegroups.com
Just seen ExpressionEngine for the first time (pretty interface, but far too complicated), but one thing it does do is make it dead simple to add a new News Article / Blog Post etc. Once you've logged in, just 2 clicks give you a new item to start populating, it's effectively: click Create, then click on the item type you wish to create, and you have a new item ready to populate. http://spdr.me/xzfW If the page type requires you to select a parent, then the drop down appears along with the other fields for that page, like Title, Content etc, rather than adding an extra step in.

James

Purple Spider Web Design


Paul Clarke

unread,
May 27, 2012, 6:52:08 PM5/27/12
to silverst...@googlegroups.com
These are some designs that came out of the SilverStripe Hackfest last Saturday. The designs do not solve all issues raised above but do make it easier to add a page without being taken away from where you currently are.

https://github.com/silverstripe/silverstripe-design/commit/eb54b3af3cd1d037630c8cf38db7c32909336a7c

There has also been a couple of suggestions about the larger page tree view for building your site structure quickly, it seems that choosing a page type is the main decision the user has to make.
  • A list of the page types that you can drag directly into your tree
  • An area for newly created pages which have not yet been added to the site tree (Unsorted pages – slightly separated from the site tree)
  • Inline page name & page type editing

Slightly related but part of another discusion:
One of the main things about this design is that the filters panel has moved to be less prominent, I suggest changing the title  "Filters" to  "Find pages" – hopefully that make more sense to uses, leaving that panel purely for site navigation.


Paul Clarke

unread,
May 27, 2012, 7:23:42 PM5/27/12
to silverst...@googlegroups.com
One thing I forgot to mention is that page type selection should be above selecting location (designs do not reflect this).

James Cocker

unread,
May 28, 2012, 5:25:02 AM5/28/12
to silverst...@googlegroups.com
Nice!! I like! As you say, swapping the page type selection & location should make a dramatic improvement to the issue I described, especially if the location box can be automatically set (or even hidden) when using $default_parent.

James

Purple Spider Web Design


On 28 May 2012 00:23, Paul Clarke <pa...@silverstripe.com> wrote:
One thing I forgot to mention is that page type selection should be above selecting location (designs do not reflect this).

--
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/-/VCX1dFuM6s4J.

Ingo Schommer

unread,
May 29, 2012, 8:10:26 AM5/29/12
to silverst...@googlegroups.com
The "add page" quicklink is really cool! Do you think it would replace the fullscreen view completely?
If that's the case, I think it diminishes the usefulness of descriptions, since you have to select items first
to see it (as shown with your RedirectorPage example). But since we use Chosen.js dropdowns,
we could customize the dropdown display accordingly as well with smaller description text.
If you think its a good idea, do you maybe want to draft a design?

The "add page" right click option on a page node could still be left in place,
if we scroll up and open the inline "add page" dialog automatically with that parent selected, right?

How do you envision an active page filter? Maybe a blue highlight on the "find page" text?
It'll be very confusing to users if the filtering is not apparent, particularly because its contained
in the link, so might be retained when one authors sends a CMS link to another
(sometimes the filtering is desired there, sometimes its not).

--
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/-/IaVLNS4NatgJ.

Paul Clarke

unread,
May 30, 2012, 1:30:38 AM5/30/12
to silverst...@googlegroups.com
The "add page" quicklink is really cool! Do you think it would replace the fullscreen view completely?
That's what I was hoping, every time a user is taken to another screen it takes time and thought to adjust to the new screen. The view changes too often compared to the time needed on the add new page.


If that's the case, I think it diminishes the usefulness of descriptions, since you have to select items first
to see it (as shown with your RedirectorPage example).
The help text is something you browse over to confirm what you already know, most of the page types are pretty self explanatory already but you are right it "diminishes the usefulness of the descriptions", but hopefully it's a trade off for the better?


But since we use Chosen.js dropdowns,
we could customize the dropdown display accordingly as well with smaller description text.
If you think its a good idea, do you maybe want to draft a design?
Yeah sure I can give it a go, I was hoping to keep the "Add page" dropdown to a minimum height so that the tree can still be seen below it, I think it is important if possible to see alterations to the tree.

The "add page" right click option on a page node could still be left in place,
if we scroll up and open the inline "add page" dialog automatically with that parent selected, right?
Exactly, and if they are currently in the blog area we can suggest that the next page would also be a blog post.

How do you envision an active page filter? Maybe a blue highlight on the "find page" text?
It'll be very confusing to users if the filtering is not apparent, particularly because its contained
in the link, so might be retained when one authors sends a CMS link to another
(sometimes the filtering is desired there, sometimes its not).
We would need to be very clear that a filter has been applied, but you don't see the "Find pages" button in the smaller tree view. So i would opt for a message or warning that prompts you to clear the filter.

Paul Clarke

unread,
Aug 26, 2012, 9:59:40 PM8/26/12
to silverst...@googlegroups.com
Thought I should add an additional mockup I created some time ago which allows the smaller tree to have the same capabilities as the larger page tree view but with more compact actions. This means there would be no need for the "Edit Pages" button and it could be removed.

The main idea behind this is that the smaller tree panel is actually the same as the larger sitetree view just collapsed also removing the need to refresh the page on expand and collapse.

https://github.com/silverstripe/silverstripe-design/blob/master/Design/Page-options-dropdown-16.png

Ingo Schommer

unread,
Aug 29, 2012, 9:26:24 AM8/29/12
to silverst...@googlegroups.com
Heh, funny to see how we come back full circle to the "do everything in one UI" that we had in 2.4.
Now we're just missing a mockup for the list view in the sidebar ;) Just an observation, I won't deny the usefulness of avoiding to switch views.

The icon-to-title hover effect makes good use of the space available,
particularly as the icons communicate their intent really well in those three cases.
But how do we deal with this for mobile? I guess we could linearize the tabs
in this case, and break it into multiple lines with the full icon/title view showing by default?

Sigurd Magnusson

unread,
Aug 29, 2012, 5:06:10 PM8/29/12
to silverst...@googlegroups.com
Paul, your screenshot has broadened this topic from an 'add page' discussion to one about the higher-level layout of the page list/tree area and page editor.

I thought on this is that the ratio of width (horizontal area) of the tree/list area versus the page editor should be fluid. The user should be able to select any ratio with their mouse, but with the system making sensible defaults in the much the way it does currently. (It's good it opens in full tree/list mode, it's good you can see a narrow tree when editing pages, but there should be a tidier way to revert from page editing to full-tree/list view, etc)

A fluid ratio enables many 'variations' to be accommodated; the variation of site sizes (page counts), the variation of user action, i.e. hard core tree manipulation vs hard core content authoring, the variation of screen sizes including supporting narrower tablet, possibly even smartphones.

Certain functions might be laid out different or disabled/changed when the tree/list area is narrower.

I feel this broader topic can only be partly advanced, as it should be considered in combination with the side by side editing, i.e. showing preview of page at same time as seeing the page editor, which is something pegged for inclusion in v3.1. 

Cheers,
Sigurd.


--
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/-/7mzpQ5vVM8cJ.

Paul Clarke

unread,
Aug 29, 2012, 7:23:55 PM8/29/12
to silverst...@googlegroups.com
@Ingo
But how do we deal with this for mobile? I guess we could linearize the tabs in this case, and break it into multiple lines with the full icon/title view showing by default?
No, I think for mobile the icon is plenty enough description for clicking on. When a user clicks on the search icon the panel opens and then the Add pages label disappears and the Find pages appears.

@Sig

I thought on this is that the ratio of width (horizontal area) of the tree/list area versus the page editor should be fluid. The user should be able to select any ratio with their mouse, but with the system making sensible defaults in the much the way it does currently. (It's good it opens in full tree/list mode, it's good you can see a narrow tree when editing pages, but there should be a tidier way to revert from page editing to full-tree/list view, etc)
I don't want to take the full page tree away at all, I just wanted to show that they can provide the same functionality expanded or collapsed without looking overloaded with buttons etc. I agree the user should be able to decide how much space they need so this illustrates that the same code can be used when expanded or collapsed and its just a matter of a css change to adapt to the space. What I really would like is that there is no page refresh to go from full page view to collapsed.

When doing a lot of page changes the user would find full view so much more useful esp. when having to scroll and do bulk actions.
The Edit pages button is basically just a double-up for dragging the panel open, and it isn't that intuitive that you have to view full tree view to search for pages and the only other thing that it offers are the actions.

The one issue I see with having the actions in the smaller panel is that the checkbox's are only visible when you click actions button for the first time (like we do anyway on full tree view at the moment), once the checkboxs are visible the actions button would then have the dropdown with actions on click.
Reply all
Reply to author
Forward
0 new messages