[Framework-Team] Question on folderish types | Folderish Images, Files and Links?
developer at acsr.de
Tue Dec 16 08:05:31 UTC 2014
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.
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 -> object with accessible subobjects that is recognised, workflowed and managed as a whole (from the user point of view)
 Since "containerish" is misleading finally, a native speaker may suggest a better term.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
More information about the Framework-Team