These notes were the result of a discussion about how to decouple the metadata editor design from the custom content editor created for the Iteration 1 demo. The purpose of designing and developing an independent metadata editor is so that it can be implemented independently into any content editor. In addition to being decoupled from the content editor the metadata editor must also be developed to be modular and flexible.
The following are two likely scenarios for implementation:
In this case, the user wants access to the metadata authoring and/or editing functionality and is not interested in creating a custom integration. An example would be someone who runs a Wordpress blog and downloads the FLOE Metadata Editor from the plugin repository and starts using it in their blog. Another example might be the case where a user (e.g. a librarian) is using the metadata editor to simply tag media content with its available accessibility features and has no interest in authoring or editing metadata features.
In this case, the user has a web application already and they want to add elements of the FLOE Metadata Editor to their existing user experience. An example would be someone who maintains an internal CMS and would like to add selected pieces of the FLOE Metadata Editor that are applicable to their context, and possibly also apply their own styling and branding to these elements.
Note: the "bucket" refers to the UI feature (shown here) which holds the existing and recommended metadata features icons for each media item. See the full designs here.
- Collapsed metadata editor
- Persistent metadata editor
- Milestone 1 design (floating bucket within content editor)
- Bucket appears outside of content editor
- Bucket appears in toolbar
- Table of contents/summary (no bucket)
- This could apply to the tagging scenario described above