Make possible for Sections and Workspaces to have an optional front page.

I don't think that you want to add a new reference system. For users it is easier to go to the section (or workspace) click on 'edit' and modify the page's text and images in place - The idea is that if you can modify something directly then do it. This is what makes Plone so popular.

To solve this, we've added a Flexible Layout to the 'Section' portal type. Users that can manage sections can also change the section's "front page" by adding a text / image widget. There is no reason to complicate things by having the section on the one hand of the section's front page as a separate object.

Once you have this, you still need to show folder listings. This can be done by using the Navigation portlet.

You can also add a "folder contents" widget inside the document.

I should have added information on the behavior that you are describing. I'm sorry to have forgotten it in my first post.

The aim of the proposed enhancement is to provide the same functionality that the index_file file provides in Zope or that the index.html or a symbolic link provide in Unix.

Use case

One has a section with many documents in it and one wants to change quickly the front page of the section. Those front page changes may happen very often and be marked by tedious repetition. For example a web site may change its default front page every month to make special offers for some days, a web site may switch its front page to advertise an Anti-Software-Patent campaign for some days, etc.

We want to provide an easy switch for the front pages. As for the user experience, the described feature really seems a must have.

And finally, on the workflow side, the proposed feature makes it possible to take full advantage of the classical CPS document workflows: some contribute to documents, some validate those documents and finally the section and workspace managers decide which documents can be presented as the section or workspace front page.

Conclusion

Advantages:

• fast and easy switch

• takes full advantage of current workflows

• do not use flexible which are currently not very practical since this kind of schema cannot be updated after being instantiated

Disadvantages:

• introduce a new notion to the understanding of CPS

Thanks for your feedback!

OK if it's a quick switch, and it's for one page only or two. This is more like some sort of virtual hosting, a redirection without redirection. However it does not solve the number one use case when designing a website, i.e. showing pages and not folder listings (as if the site was an FTP server or a file repository).

I think that Eric added a flexible layout on the nuxeo.com site, to make sure that the user visiting the site always comes a page and not to an empty page with folder contents in it.

Most of the users at Chalmers that publish content have asked for the possibility to treat sections as if they were documents, i.e. with more than just a title and a description in them (in most of the cases a simple text area is enough, you don't have to use the flexible schemas). But the content almost never changes, so there are no switches from one month to another. There is a one-to-one relation between sections and sections' front-pages.

The only risk that I see is that it will be interpreted as *the* pattern in CPS used for decorating sections (because the *only* pattern). If it's used for 1 or 2 pages then it's fine because it fulfills its original function (quick switch), but when users start using it for *all* the sections on the site (and they will if it's the only way of doing it) because they want more than just a title and a description, then it will become a complicated way of doing something very simple.

Cognitively the problem is the same as the separation between content in workspaces and content in sections: the users think they're editing something while they're actually editing something else.

I can tell you that 100% of the users got confused because of this. They don't understand why they can't add content directly in sections.

A new option could also be added to the Document Portlet (a document path) to render another document than the current document. There is already such an option to render the document container instead of the container.

Then you'd add the portlet on the front page with an 'override other portlets' option. When you're done with the switch you'd remove the portlet, and you'd be back to the original section view.

That's the way I see it from a Zope3 perspective: i.e. keep presentation separated from the content. If you need to change the presentation, don't change the content, only change the presentation layer.

Your comments about section decoration patterns is worth thinking about.

According to those considerations about user confusion, your last comments about adding a document portlet to render another document and make that render replace the render of the container seems too complicated. This is at least is complicated than simply specifying which document a section/workspace could use as a front page.

And there is also the semantic and workflow side of it. It seems more semantic that a section should know what document it should present as a front page (if any). This information shall be present in the section itself (with the corresponding users allowed to modify it through the roles and local roles) instead of being present in another object with no connection with the section and the rights to modify the section content (section manager).

I understand that defining a front page for a section/workspace could be understood as in the realm of presentation, but I really don't think it is. There is a real semantical meaning in defining a page/document as being a front page. It is an important meaningful communication act. It is not like defining that whole section x is blue, while whole section y is green. While we were thinking about that at Nuxeo some people raised the idea of storing the information on which document is a front-page on the document itself. That was erroneous since this information really pertains to the section itself.

Finally please note that the proposed feature in this ticket would not prevent users/developers to add to the section and workspace schemas and layouts to use them as documents. This will not break existing web sites using it. But this way of proceeding kills the workflow approach and is really less flexible when it comes to contribution. That's why the needed solution should be :

• easy and fast to use if possible

• workflow based if possible

I've added the option to the Document Portlet in [26051]. You can test it if you want.

I think we agree that it is a presentation feature, I'm not even arguing that it should not be stored in the section itself, because the information do pertain to the section.

But one of the reason to put the presentation layer "above" CPSDocument in a portlet for instance is that if you're using a different theme you might want to not always associate a given page to a given section, you'd want to turn that feature off, just as someone recently asked on the list about how to remove the language switcher ([en] [fr]). Obviously it pertains to the section, but it should be kept separate from the document rendering.

The 'index.html' thing is a website feature, if you're in a document management situation for instance then it is just confusing because what you really want to see then is the content of the folder, not a default document.

In the back-office for instance this would be confusing, the user would think that a folder is actually a document.

So storing the information in the section is not the problem, because this information can in turn be used by the document portlet during the rendering (it can be activated in the website theme, and deactivated in the back-office)

The issue is if you're doing the document rendering inside CPSDocument with that option enabled all the time and you find out that you don't want it for presentation reasons.

My question is: how do you turn that off? in what layer above CPSDocument can you turn that off?

There is another side-effect too:

You'll have to hide the default document from folder listings.

If your site shows the section / documents in the main page area and a navigation menu on the side of the page shows the current folder contents, in terms of UI you will have two links to the same page: the section itself and the default document that will also be located in the section. So you will have to hide it somehow otherwise the user will think that these are 2 different documents.

In the web 'index.html' paradigm this does not occur since you never include the default document in the links listed on the index.html page

Where will that logic be put? in getFolderContents? in the navigation portlet itself? Will the default document be some sort of 'hidden' document? Will you store the 'hidden' information on the document itself?

What will happen when you do a site search and you go to a section with a default document in it: you will see the default document and you won't find the information you were looking for because for the catalog: section != default document.

It could be that the 'index.html' paradigm was designed for HTML web sites not for portals?

No, we don't agree that this is a presentation feature. Maybe I'm wrong but I've not yet been convinced of the opposite. So Jean-Marc, please re-read my previous post more carefully about the fact that this information is semantical and is about content management.

And yes you are right that if a section/workspace presents the rendering of an optionally selected front page document the management of the sections/workspaces would be a bit harder because it will be difficult for the user to know that a section/workspace is really a section/workspace. Administrators would know that a document is actually a section/workspace by the presence of the "Folder contents" action. They will manage the sections/workspaces through this action.Maybe a special presentation could be applied to clearly differentiate sections/workspaces with a front page from "simple" documents. This differentiation should be thought about.

The side effects you are mentionnling about navigation/searching are real blocking usability problems :-( and the solution with the portlets are really not simple to use and not workflow based :-(

I would like to read others' thoughts.

Obviously if a same section can be presented in two different ways (folder contents / document) then this is a presentation issue.

In terms of content management saying that a given document is *the* default document makes no sense. Either your section is a container or it is a document ... There are important documents, there are related document, there are published document but a document is not 'default'. There is no notion of default document in the dublin core.

You've got to admit that the index.html hack was designed to solve a presentation issue -- not a content management issue... even if you can afterwards rationalize the choice and make it appear as a semantic decision.

My impression is that CPS mixes too many paradigms:

- folders - documents - folderish documents

adding a new one won't help user understand better

It would be easier to only have documents and group them into categories, using smart folders, or keywords, but you'd lose the notion of hierarchy.

Actually you can still have hierarchies and get rid of folders

as it's done in sites based on Polopoly:

- www.svt.se - www.dn.se - www.gp.se

sections are built by creating relations between documents.

Plone uses the folder / file paradigm. Updating a Plone site must be easily done using FTP, DAV protocols. It means that content is published in place. Each folder can have a default content item (the equivalent of index.html) that can be set through the "Display" menu. There are lots of use cases that are not covered such as virtual publication but at least there is a consistent way of publishing content. It follows the web publishing paradigm.

In CPS, folders are based on CPSDocument; you can treat them as if they were documents except for the workflow part, folderish documents that can be published and published into, so the step taken is towards the document paradigm, the difference between folders and documents is very thin... What makes the difference is really the workflow definition and the way the UI is implemented.

The issue I think is that you have to choose for a paradigm and stick to it, be consistent or the user will get lost.

It would be simpler to say: everything is a document and will be treated as such, than to say that folders are not documents at all (just pure containers), and hence they need a default document to display some content.