[Plone-UI] Making the contents tab consistent - a solution

[Danny Bloemendaal]

I think this is a good idea. It makes it a bit more cumbersome to get 
the parent-folder's contents view but that's ok.

One thing I want to mention though is that the reason to open 
folder_contents is not only to do batch processing. Many products have 
another default view (like blogs) and in these cases, the only way to 
see what is in a folder is to open it in contents view. In the blog for 
instance, the default view only shows published items. Items in draft 
are inaccessible without contents view. Just my two cents ;-)

Danny

Alexander Limi wrote:
> Hi,
> 
> We had a sit-down here at the EuroPython sprint where I presented a  
> solution on how to solve the contents tab problem in a better way than 
> we  have now. I'll try to summarize the discussion, and would like some  
> assistance to implement this - preferrably as soon as possible, so we  
> don't change this in the beta period.
> 
> First some history:
> 
> Plone 1 had a link in the navigation tree "Switch to contents view" and  
> "Switch to item view". This was replaced in Plone 2.0 with a tab at the  
> top of items that was named "Contents".
> 
> This approach has several problems:
> 
> 1. The contents tab shows up on non-folderish items to have a way to 
> get  to the folder contents from any item. This is clearly wrong, as it 
> implies  that every item is folderish - which it is not.
> 
> 2. Related, the "Add new item" did the same thing: it either added an 
> item  to the containing folder, or inside the current item if it was 
> folderish.
> 
> 3. Clicking the "Contents" tab is inconsistent since it will either a)  
> bring you to the contents view if you are in a folderish item, b) take 
> you  up to the containing folder *and* bring you to the contents view if 
> you  are in a non-folderish item.
> 
> We have tried a couple of different approaches in the current 2.1 alpha  
> releases, namely moving the contents link to the content action bar and  
> other variations.
> 
> I think we have a better way of doing this now, though.
> 
> We re-introduce "Contents" as a tab, but only on folderish items, and 
> on  items that are default views for a folderish item.
> 
> Let me walk you through how this would work:
> 
> 1) This is how the UI looks when you enter a normal folder without any  
> default page explicitly set. Contents tab is shown, Folder is 
> highlighted  in the navigation tree:
>                   __________   ______   ______
>  ____________   _| Contents |_| View |_| Edit |___
> | Navigation | |__________________________________|
> |____________| |
> | *Folder*   | | [] DocA - by Smith
> |   DocA     | |
> |   DocB     | | [] DocB - by Wesson
> |____________| |
> 
> 
> 2) This is the how the UI looks when you're inside a non-folderish item  
> (DocA). Notice that there is no contents tab, and that DocA is 
> highlighted  in the nav tree:
> 
>                   ______   ______
>  ____________   _| View |_| Edit |________________
> | Navigation | |__________________________________|
> |____________| |
> |  Folder    | | DocA
> |   *DocA*   | |
> |    DocB    | | Body text
> |____________| |
> 
>  To get to the Contents view of the containing folder, you have to go 
> to  the containing Folder and then click the Contents tab there. This 
> isn't  really as convenient as it sounds, since you have  
> Cut/Copy/Paste/Delete/Rename/State directly on the object, so you would  
> only do this for batch operations - thus it would be quite rare to do 
> this  in everyday usage, and also mostly done for more significant  
> changes/updates.
> 
> 3) The final view is how a default page in a folder would look like this:
> 
>                   __________   ______   ______
>  ____________   _| Contents |_| View |_| Edit |___
> | Navigation | |__________________________________|
> |____________| |
> | *Folder*   | | DocA
> |   DocB     | |
> |            | | Body text
> |____________| |
> 
>  Notice how a) the *Folder* is highlighted (since you're in a folder, 
> but  looking at the default view), and b) that there is a Contents tab 
> even if  you're technically in a document. This is because you have used 
> the folder  to "folderize" the document, and thus they behave as one 
> entity. Also  notice how DocA is *not* visible as a separate document in 
> the nav tree  when associated as the default page.
> 
> I believe this approach combines the UI simplicity of Plone 2.0 with 
> the  consistency of the other approaches we have attempted. It gives you 
> all  the different options available, and optimizes for the common use 
> case,  making the less common use case (batch operations) only 
> marginally harder  to reach.
>