[Framework-Team] Question on folderish types | Folderish Images, Files and Links?

[Armin Stroß-Radschinski]

Am 16.12.2014 um 08:29 schrieb Andreas Jung <lists at zopyx.com>:

> Signierter PGP Teil
> Armin Stroß-Radschinski wrote:
> > Am 15.12.2014 um 17:25 schrieb Paul Roeland <paul at cleanclothes.org>:
> >
> >> On 2014-11-17 14:37, Philip Bauer wrote:
> >>> I have no strong opinion about this and would add these If the
> >>> framework team wants me to. OTOH I cannot think of a use-case for
> >>> folderish Images, Files and Links.
> >>>
> >> sorry for late butting in...
> >>
> >> I have a real-life usecase for folderish images: XMP files. That's
> >> metadata on an image, in a special (but widely used) format.
> >>
> >> Paul Roeland
> >
> > any files are containerish by nature, its not obvious but clear after
> > some reflective thinking. * PDF contain pages, accessing PDF pages as
> > single page files has benefits in search and load. * Slideshows
> > contain slides and transscripts * All kind of previews (forget image
> > thumbs) * Multipart mail and clipboard data are also chunky examples
> > where a physical block of data (file) contains multiple formats. *
> > Zotero manages Links together with local snaphots of the target ...
> >
> > A CMS that can access and map chunky data parts from managed files to
> > internal objects and back could be innovative again! We need such
> > features to be leading edge. I can provide more details on that on
> > request.
> >
> > So I strongly suggest possible containerish Images, Files and Links!
> >
> > And yes, it makes things not easier.
> >
> 
> I strongly object have a folderish behavior for files, images and links
> _by default_. Even if there are usecases for experienced users or
> developer, the normal Plone user will have problem with the semantics of
> images or files being folderish. If you need those types being folderish
> then make it somehow optional but leave the default behavior
> as it is.
> 
> my-3-cents
> -aj

I fully agree with aj that a "default" that is exposing this in the UI in a confusing way to the user is a UX nogo. 

And therefore it should be hidden (like with XMP data) and not a default "feature" to be claimed. But editing paragraphs in a wiki is an example where people can deal very good with "subcontent".

How can a developer distinguish in listings if the "containerish" nature should be exposed? Thats the challenge!

So I think the "behaviour" needs to be differentiated by attributes: 

	- work like a folder/container
	- feel like a folder/container

The different metaphor of folderish vs. containerish should be differentiated out and could help us to overcome the current issues in the UI. 

folderish -> to be recognised as an organisational "device" object that contains object with individual workflows and states of their own (cupboard like)

containerish[1] -> object with accessible subobjects that is recognised, workflowed and managed as a whole (from the user point of view)

[1] Since "containerish" is misleading finally, a native speaker may suggest a better term.

-- Armin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.plone.org/pipermail/plone-framework-team/attachments/20141216/460e012b/attachment.asc>