We now have editable file types for the File Entity 2.x. Soon also it will be possible to add new file types in a similar manner as how we work with content types in Drupal.
This will make it possible to create tailored file types such as "Logo Types" and "Cars" which can contain different fields as well as both images and videos for example.
However, we also need a mechanism to out-of-the-box handle HTML attributes such as alt and title as explained in the http://groups.drupal.org/node/219619 wiki page.
These, and other, standard attributes should be handled globally and be available as standard with options to set if the info stored can be overridden or not when used.
We need to do some research and UI designs to make sure there is a smooth workflow for content editors for this, as well as good features for site builders to use.
http://drupal.org/node/1343022 is adding alt/title fields. However, I haven't tested how that works now with the editable file types.
We also need to discuss if "File Types" is the right terminology here, especially since it is possible to combine different ones in the same type, including combine image, video and PDF in the same.
Thus, we do have a bit of a UX/usability issue to deal with too.
Thoughts? Ideas?
Comments
As per naming
I think one of the difficulties is we often talk about file types as mime types. However I don't think it's the case that is how end users approach them and looking at using the term "File Types" seems to be the right way to go.
We have at least two different patterns we could follow from core- content types and image styles. Personally I think "styles" is not the best terminology in this case as "styles" seems to not describe a collection of dissimilar things- it seems to express the concept of derivative. According to Apple's dictionary: "a way of painting, writing, composing, building, etc., characteristic of a particular period, place, person, or movement."
In content types I think the term type applies as a collection of things which are not necessarily similar by theme. Having fields on files also matches up well with content types. Again, according to Apple's dictionary: "a category of people or things having common characteristics". I'm not sure that "types" is ultimately the best word but I think it follows the pattern in core well enough to use it here as well.
http://24b6.net
Still in the process of fully
Still in the process of fully understanding both issues (http://drupal.org/node/1292382 and http://drupal.org/node/1260050), since they are rather big changes; they make a lot of things possible, but will need a lot of thought from a UI perspective. Some parts of it make my head spin :)
Right now, when a file gets uploaded (through the media browser or otherwise), its mime type 'corresponds' to a file type. The changes listed above make this relationship less strict.
I'm thinking of the consequences this will have in the (Media browser) UI.
1) With this new approach, a file that's being uploaded, could belong to more than one file type based on its mime type (see @effulgentsia's comment in http://drupal.org/node/1260050#comment-5040080). He suggests that when this is the case, we allow the user to pick which file type the file should belong to after a file is uploaded. I'm thinking this may easily get confusing to a user who wants to eg. upload a photo to use it in article, but isn't necessarily aware of the thumbnail file field on a video file type.
Perhaps it's easier if we allow the user to pick the file type he wants to add before we present the upload field(s)? When there is no 'shared' mime type across multiple file types, we could skip this step.
Also, would it be possible to allow only certain file types to be added through the media browser (maybe the changes introduced here already enable this, not sure ...)? I can imagine use cases where only certain file types should be 'add-able' through the media browser, and others only through file fields on nodes (eg. a news site where besides photos, videos and audio, there are also interview transcripts that are meant for archiving purposes).
2) Say, for example, you have a file type with three different file fields. When a user adds a new file through the media browser, this could easily become overwhelming ("I just want to add an image, why am I seeing three different file fields here?").
Would it be possible/a good idea to have an option to enable certain fields on file create forms/in the media browser, and have all fields available on file edit forms (without having to resort to form alter)?
This will depend heavily on the given use case, but it seems like something to consider.
Perhaps a good start would be to map out all the different options to add files, and look at the steps that are involved: