What is the reason to have two binary types "File" and "Image" in Plone? In the age of Interfaces and behaviors they can be easily differentiated with their mime type. It would be easier for the user to have just one type and let Plone decide what it does with it (create scales for an image, extract metadata, etc.).
I would very much welcome this! PLIP for Plone5.1?
+1
it happens regulary to some clients, that they are uploading pdf files as images and images as files.
-1
This will be more or less what collective.flowplayer is doing with file: you upload a file an it magically became a video. theoretically a good and cool thing, in practice average user don't understand this magic.
IMO sometimes is difficult to explain that a "file" can be PDF. I had a case where we created different File clones.
Having a single type will be more difficult for many use cases:
- creating a collection of images (please, don't say "use interfaces and not portal_type" because is impossible to be used TTW)
- applying different views
An usability nightmare.
1 Like
getting rid of the image content type is an idea that has been around for quite some time now; but I have to say that we need to understand the big picture on how to improve Plone usability first.
7 years ago, Alex Limi wrote a series of posts about this and explained what had to be done and in which order; I think everybody in the Plone community should read it, because the way we are trying o improve things is just based on personal assumptions with no particular order neither long term vision.
here is the piece about handling of rich media.
I agree we need to work out what are the most pressing usability problems we are trying to solve and work back from there. Totally agree we need to stop looking at small local decisions and solutions and start looking at the bigger picture for beyond 5.0. Have a look at the list of issues on - https://trello.com/b/h8J1evdp/the-plone-ux-hit-list-beta. I'm not sure being confused between images and files even features on that list yet.
Limis post is advocating persistent tiles which have their own problems... even pointed out in the article. What happens when you want a gallery of images? A collection of videos? Workflow on images. You could create your own content types for those usecases but still need to list out how people do use rich media now.
Also note with plone.app.mosaic @datakurre has moved away from using persistent tiles, I think including for images.
BTW. for any interested there is already an implementation of a similar editing interface limi is talking about using tiles inside tinymce called collective.tinymcetiles. you can see a demo I did of it here https://www.youtube.com/watch?v=HuxLoXlchc4 which uses shortcodes instead of image representations. If thats better or worse than mosaic or can be combined with mosaic, I don't know.
Mosaic still use persistent tiles for images and "file attachments", because no one has implemented an alternative (e.g. a image repository based image tile with suitable widget). Yet, if content type has image field, that field could be placed into layout, but there are some other issues left. So, Mosaic does not have solution for this, but it is listening...
Might collective.instancebehavior point to the right direction?
I think uploading a file and then decide what should happen to it can be a good way as an image, a pdf, and so on is a file.
some parts of this decisions can be done automatically: using interfaces to mark what group of type it belongs to.
lets say:
IDocument for
- word doc
- excel file
IImage for
- png
- jpg
- gif
- svg
A separate thing is, how the file should be represented. As download or visual in the browser.
I have no real clue about that.