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

On Monday 27 June 2005 01:42 am, Danny Bloemendaal wrote:
> 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.

This seems to imply that the default page object itself is hidden in the 
NavTree.  Should this be the the case?  I think it's a good idea, though I'm 
no usability expert.

Also, if the parent folder has syndication available, should we also show the 
syndication tab on the default page?  This would seem to make sense, except 
in the case where the default page itself has it's own syndication method 
(Smart Folders now support syndication and provide their own tab for doing 
so), which we can likely test for.  I think this is a good idea, as it 
extends the 'default page is the folder' paradigm we are setting up with the 
contents tab.

Alec


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click