Adding Media Pinkeye to Summary

[willykaram]

I've added Media Pineye to the ToC/Summary. I put this in a separate PR, as I'm wondering if we should re-order the Table of Contents/Summary by alphabetical order or perhaps by category (as in the modules folder). Unless someone is familiar with how the modules interrelate. Right now they might think that the ordering is arbitrary, which would be good to avoid.

[slashrsm]

Yes, I agree that we should have some kind of structure. I'd rather have it ordered by category/topic than alphabetically.

Entity browser could go under "Browsing" and embed modules could go under "Embedding". It would be great to figure out few more sections for other modules. "Cropping" and "Storage" seem two reasonable candidates. We could also have "Displaying media", "Full-featured solutions" and "Uploading". Those should cover everything that we have at the moment.

[willykaram]

Could we possibly simplify the categories a bit by grouping them into these 3 top level categories (with some sub-categories), as suggested below.

I'm working to add some of this to the roadmap section, based on some of what we had in the planning Hackpad and roadmap Hackpad. Once we get this plan together in the documentation and the next larger sprints organized (presumably New Orleans and NYC/July), hopefully in the next month or so, then I'm hoping to shift from working on planning/documentation to starting to contribute some code/module ports.

Presumably this categorization will evolve over time if needed, but if we can agree on an approach then I'll document what's agreed upon as the starting point.

Suggested Categorization

1. Storage: this would cover modules for getting assets into Drupal, whether via a file upload or from an external source. The modules in this category would be:

• DropzoneJS
• File Entity
• Flysystem
• Media Entity
  • Media Entity Image
  • Media Entity Twitter
  • Media Entity Slideshow
  • Media Entity Instagram

2. U/X: this would cover modules for working with media assets once they've been stored, and would be particularly focused on user experience for content editors (i.e., browsing, cropping, display. etc). For instances, a workflow such as browsing/selecting media, then working with it (cropping or selecting crops/formatting), and then adding it to a node/entity for display (whether as an embed or in a field). The subcategories are likely going to make sense, since in time there are likely many variations and different approached that may emerge. However, currently, the modules in this category would be:

• a. Browsing and Embedding
  • Entity Browser
  • File Browser
• b. Embedding
  • Embed
  • Entity Embed
  • URL Embed
• c. Cropping
  • Crop API
  • Image Widget Crop
• d. Display/Formatting:
  • Fallback Formatter
  • Field Formatter

3. Extending: this would cover modules for working with assets outside of Drupal, particular complex solutions such as AWS Elastic Encoder, ThePlatform or DAMs (e.g., Bynder or Entermedia). These are solutions more complex that a simple storage, stream wrapper of embed from social media or stream services. We don't any D8 modules in this category yet; but as with D7 this will likely start to emerge as D8 migrations begin.

4. Solutions: this would cover full-features solutions that provide out-of-the-box functionality by stitching together the individual modules with some glue code/UI in order to deliver a complete set of functionality or a starting point (similar to Media Pinkeye). Currently this category only included Media Pinkeye. However, include course it would also ideally include:

• 'Media Starter': which provides a simple solution with basic media functionality, and essentially feature parity with tools such as Wordpress (e.g., images, videos, embeds, and possibly cropping, galleries and/or slideshows etc.). This is similar to could be replaced by Media Pinkeye (but ideally there would be an options/offering for each of File Entity and Media Entity). This solution would most commonly be used for smaller sites or those with more basis needs.
• 'Media Kit' which would deliver the common requirements of moderately advanced Drupal implementation, which in addition to the above would include basic integrations with third party services and from a features/functionality perspective fall somewhere between the 'Starter' solution above and the 'Extend' solution below. This solution would essentially delivery on the roadmap fro Drupal 7 with a rich suite of media functionality, while ideally avoid some of the complexities that come with extending media to DAMs and other more complex solutions.
• 'Media Extend': which would provide very advance media functionality for extending the Drupal Media ecosystem and integrating with custom or third party solutions. This solution would likely only be used by very large enterprises with very advanced implementations. For instance, advanced integrations with cloud servers (e.g,. AWS Elastic Encoder, ThePlatform, Ooyala) or DAMa (Bynder, Entermedia, Razuna, etc) -- i.e., beyond simple embedding. Examples of these sorts of companies would be NBCU, Time Life, The Economist, Sony, etc., most of whom have historically and currently still need to implement custom solutions as opposed to using Drupal Media modules.

[slashrsm]

I generally agree with this structure. Just two concerns:

• DropzoneJS in Storage feels wrong to me, but it also doesn't belong in any other section. Main reason for this concern is the fact that it doesn't provide actual storage. I am afraid this will be confusing to people. It could live in UX, but that seems even worse. In order to prevent fragmentation let's put it in storage for now. Later, if more uploading tools appear, we could create a separate section for them.
• File browser should be in "Solutions" in my opinion. It was born at BADCamp when we were trying to define MVP for media solution for D8. When we did that we realized that we have most of pieces already in place. One could probably argue that it is not a "real" solution but more of a demo module. This is partly true, but it is also the best "solution module" that we have at the moment.

[willykaram]

I agree with you fully on both those points. I actually debated raising them/making similar suggestions, but the prior comment was already so long. I think this is a good starting point, and then we can evolve/reorganize if needed as new modules emerge in the D8 media ecosystem.

[slashrsm]

I agree. Do we want to do this as part of this PR or create a new one?

[willykaram]

I'll make the revisions and squash the commits so we can do it in this PR