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!

Em terça-feira, 8 de maio de 2012 11h38min49s UTC-3, James Cocker escreveu:

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*
*purplespider.com <http://www.purplespider.com>*

On 8 May 2012 15:53, ser...@bruder.com.br <sergio.bru...@gmail.com> wrote:

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.

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.

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

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.

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*
*purplespider.com <http://www.purplespider.com>*

On 9 May 2012 08:50, Ingo Schommer <ingo.schom...@gmail.com> wrote:

I've written a tutorial on how to add a "quick access" bar to the CMS a while ago:
http://doc.silverstripe.org/sapphire/en/trunk/howto/extend-cms-interface
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 < 1K Download

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*
*purplespider.com <http://www.purplespider.com>*

On 10 May 2012 17:08, James Cocker <j...@purplespider.co.uk> wrote:

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

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.

One thing I forgot to mention is that page type selection should be above
selecting location (designs do not reflect this).

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*
*purplespider.com <http://www.purplespider.com>*

On 28 May 2012 00:23, Paul Clarke <p...@silverstripe.com> wrote:

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).

On 28/05/2012, at 12:52 AM, Paul Clarke wrote:

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.

<https://img.skitch.com/20120530-1b56gy7itdnu9snijci7ijnsxc.jpg>

<https://img.skitch.com/20120530-r5ud7w92mtpiebwg98kayece6k.jpg>

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

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?

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.

On 30 August 2012 01:26, Ingo Schommer <ingo.schom...@gmail.com> wrote:

@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.