Content model for sample content in Out of the Box Initiative

https://docs.google.com/document/d/1aSJ2fFqCvxFpS4UqrfzIcdYiO6-EB9Ml3PvM...

We need to finalise this before next week's sprint.

Stories in the backlog align to the current model in the doc above.

Will distill it here and set to needs review for someone to RTBC

Hm, is that an 80% use case though? We typically don't add new features like that to core unless they're something that would be of use to the majority of Drupal sites. Seems pretty specialized.

I think on the call we agreed to 'key ingredients' being a tag for now and having just normal text fields for the steps/ingredients. Just a simpler way to built it with what's in core (as a first step).

So that'd be

Pages (in main menu)

• Home
• About the market (Custom block)
• Description (use default body field)
• Hours (custom field)
• Address (custom field)
• Telephone (use telephone field)
• Change language (block)
• English (language)
• Spanish (language)
• Vendors (views page)
• Recipes (views block)
• Recipes (views page)
• Recipes (view)

Content types

• Recipe
• Description (use default body field)
• Image (use default image field)
• Ingredients (text field - multivalue)
• Preparation (text field - multivalue)
• Cook time (text field)
• Key ingredients (term reference)
• Organization (for vendors)
• Organization name (title field)
• Organization type (entity reference, term from types of organization)
• Description (use default body field)
• Image (default field)
• Address
• Phone (use default phone field)

Taxonomies

• Ingredients
• Organization types

Moving to needs review so we can progress this.

The new proposed content model for the publisher site has been worked on. Here's the latest version of that.

Content types

• Basic Page
  • Title (string)
  • Body (long text)
• Recipe
  Try to follow schema.org Recipe schema as tightly as possible. More information and the schema can be found here: https://schema.org/Recipe
  • Title (string)
  • Images (array of images) (first could be used as lead image but see below)
  • Author (reference to user)
  • Recipe category (reference to recipe category taxonomy)
  • Preparation time (ISO_8601 duration)
  • Total time (ISO_8601 duration)
  • Difficulty (select)
  • Ingredients (reference to ingredients taxonomy)
  • Recipe instruction (long text)
  • Number of servigs (integer)
  • Tags (reference to tags taxonomy)
  • Nutrition per serving (TBD, see: https://schema.org/NutritionInformation)
  • Recipe reviews and testimonials (reference to comments)
  • (Magazine recipe or user submitted?)
  • Lead content fieldset (Suggested option for recipe leading cards if we want or need different editorial control of the leading cards. For the scope on this project, I could imagine this only being needed if the design requires it. It’s a set of fields that can be used across every content type where lead cards are used to promote the content)
  • Lead image (one image only)
  • Lead summary (as opposed to body field summary. Provides for better control over micro copy)
• Article
  • Author (reference to user)
  • Title (string)
  • Date (datetime)
  • Body (long text)
  • Image (image)

Taxonomies

• Ingredients
• Recipe category (Desserts, Lunches, Sacks)
• Recipe cuisine
• Tags (Veggie, Vegan, Italian, French, Catalan, Japanese)

Super nice to see this gives us 3 content types of increasing complexity. A simple Page, a medium Article and a complex Recipe.

Maybe we need to move this one to the ideas queue to get it signed of as an approved plan?

Changing Preparation time and Total time from ISO_8601 duration to text because durations aren't supported by Drupal core.

Changing Preparation time and Total time from ISO_8601 duration to text because durations aren't supported by Drupal core.

Can we change it to an integer and specify it in minutes? This is just my inner physicist trying to make sense here :)

Of course!

Updated the formatting in the issue summary.

Few comments about the currently proposed content model:

1. We probably should make the ingredients a multiple string field instead of term reference since we don't have tools in core for making it work with terms
2. Can we leave nutrition away from MVP?
3. Not sure if I still remember what "Magazine recipe or user submitted?" means, maybe we should just remove it?
4. Do we need multiple images in a recipe? It seems like it would be a lot of work to provide multiple images for recipes for a little benefit.

Updated the data model according to #20 and the call we had today with @e0ipso, @ckrina, @dawehner, @Gábor Hojtsy, @yoroy and @kjay.

Removed the leftover ingredients taxonomy vocabulary from the proposal

@lauriii I think we resolved on removing the Summary field and using the summary property on the Recipe instruction field. Is that correct?

@e0ipso: I think we should have a separated summary field since the summary isn't composed of the instructions, so there is no point in using the summary property of the instruction field.

As discussed in our recent UX calls, here are the latest wireframes illustrating the layouts for the food magazine sample content scenario that closely follow the content model described here.

There's plenty to discuss around these wireframes and the content model but here's a few notes to get things started...

General

1. We are designing under the working title of 'Umami' for the food magazine publisher scenario
2. We are producing layouts that will present sample content that is structured as per the content model in order to illustrate key features of Drupal core and provide the opportunity to create a great looking theme
3. Taxonomy is still a work in progress as we need to work out its structure and implementation

Home

1. A mix of promoted articles and recipes along with sample content about the latest magazine edition
2. Throughout the wireframes we use the idea of surfacing content as 'cards' and use the content itself to deliver the bulk of the visual design richness
3. Cards can follow repeated and/or similar patterns providing great example of content reuse and view modes
4. Title, teaser and lead image fields from both the article and recipe content types provide simple content promotion

Features

1. For the listing of all the feature articles
2. The features listing page can include a 'hero' article with high visual impact and provides an alternative way of surfacing promoted content
3. Great imagery and well-written content will continue to deliver the visual engagement
4. Categorisation through tags can be included

Feature/Article page

1. The content model is simple and well suited to demonstrating the author experience around article creation
2. Related content / Views can be demonstrated via related author content

Recipes listing

1. For continuity, we can use the card style to list recipes whilst making more of the recipe section categorisation and filtering
2. A great opportunity for showing off taxonomy and Views

Recipe page

1. Recipe pages will surface lead image, cooking time, servings, difficulty, ingredients and the method
2. Related recipes can be displayed based on terms
3. The goal is to create a design that works really well through the content and layout and obviously do a great job of showing off the recipe!

We discussed the taxonomies and categories on the call today and decided to remove cuisine taxonomy vocabulary and move the category from a taxonomy vocabulary to an enum because that allows us to create easily some pre-filtered views blocks.

Looking really, really cool so far.

Throughout the wireframes we use the idea of surfacing content as 'cards' and use the content itself to deliver the bulk of the visual design richness

Will these cards be a particular styling of the Teaser view mode, or a distinct 'card' view mode? No need to gild the lily, but it'd be nice if this demonstration of Drupal's content modeling capabilities could also show off customizable View Modes, which are a big part of D8's flexibility…

Recipe pages will surface lead image, cooking time, servings, difficulty, ingredients and the method

It looks like Umami is going to require with a custom theme that's not very reusable outside of this demo — a lot of the layout/visual styling is impossible without custom CSS and tailored image assets, perhaps even some custom templating. I don't think that's a bad thing, but it is something to keep in mind. Its purpose as a demonstration of Drupal's capabilities, rather than an out-of-box reusable theme for general purpose sites, helps keep things sane.

We want to use media images for the API-First distribution. That means that if we were to share content model configuration and migration for CSV to content, we'll need to have the same setup in this initiaitve.

I understand that Media is entering as in beta mode in 8.4.x. Would you be open to using media as in core for the images in the content model?

I understand that Media is entering as in beta mode in 8.4.x. Would you be open to using media as in core for the images in the content model?

At least conceptually I think this is fine, given that the installation profile is experimental, but well, actually media is stable in core.
Keep in mind that we need at least three issues to make image media support useful:

1. #2831937: Add "Image" MediaSource plugin
2. #2831941: [PP-1] Re-create Image field widget on top of media entity
3. #2831943: Use "rendered media" (not links) as default media field formatter; add modal to configure the used media view mode

FYI The original approval for the 'add an experimental install profile' was predicated on the assumption that is would showcase experimental modules too.

I think media was initially discussed being one of the features that we would like to demonstrate. However, at some point, it was dropped from the MVP requirements most likely because we were not sure what the status of the module will be like at the time we are implementing this. I personally don't have any objections against depending on media since it is a very important feature in Drupal core, and it fits well with the goals of the demo site.

@e0ipso could you update the content model proposal to include the proposed changes?

One thing I learned today, which wasn't clear for me, is that media will probably not be stable in 8.4, but rather just in 8.5. I think we should consider this in our decision.

Right now, none of Media is available. Lets not build in dependencies on things that aren't there yet but use what we have now. Once Media source plugins are available, we should switch to those. Lets not get ahead of ourselves, we can always iterate on the plan itself as more good stuff becomes available and implement it *when it's there*.

I agree with the media bit. We can always switch over and then even say: Hey we have now even media support :)

Difficulty (select)

What kind of difficulties should exist? I guess three: Easy / Middle / Hard would be a good limited enum list?

@dawehner I updated the issue summary. I only changed middle to medium.

Adjusting issue summary to change total time to cooking time

We had the opportunity to work together during the sprint at Frond End United and produced the attached v4 wireframes.

Front:
- Front page article/recipe 'Sub-heading' removed. This sub-heading/summary does not appear in the content model and is removed for now at least. We agreed this is one that can come back if necessary but removal simplifies things
- The magazine promotion block in the center of the page can link to the Magazine page
- 'Dinners to impress', 'Learn to Cook', 'Baked up' and 'Quick and easy' are updates to the content being presented in this block. These will link to a View (yet to be wireframed) that will list recipes via their category, difficulty and cooking time
- The pre-footer region has been simplified to reduce the number of links that would otherwise become content dead ends. The contact form 'Get in touch' is linked, plus we are proposing that we have a page providing information about the demo theme itself

Features:
- Updated to remove category/tag from each card as these were not included in the content model

Feature article:
- Updated to remove category/tag from the article and the aside articles list
- How we demonstrate related content remains a work in progress. For this version the related author information block has been removed in order to reduce the amount of content required

Recipes:
- The plan for this recipe landing page is to create Views blocks that will list a selection of recipes for one or more categories or filters set for each View block
- With the recipes being grouped by category, it will be repetitive to see the category name above each recipe title and so it has been swapped for difficulty. This will further demonstrate using alternative view modes
- The idea of having a list of tags has been bought back into the wireframes and placed in the pre-footer and these can link through to list the tagged recipes - plans for this View will likely be discussed in our next call

Recipe:
- Swapped recipe author for displaying category and multiple tags
- Split Preparation time and cooking time
- Updated the recipe cards at the bottom of the page to use difficulty in place of category/tag
- Included the tags list in the pre-footer as per the recipes landing page

Magazine page (Page content type):
- The magazine page will use the page content type with an aside containing a block that promotes the contact form. The idea is to simply have this content type work in a consistent way for any further pages that may be added to the theme. The contents of the aside can be reviewed as the requirements come together
- The contents illustrated for the page can all be provided via the ckeditor, keeping the design for the page simple but with plenty of opportunity to have some great looking sample content

Contact page:
- Work in progress with discussion on the need for including contact forms ongoing. For now the default website feedback form has been illustrated with an additional telephone field added for demonstrating form editing

Ha, trying to work out the ordering of the files displayed and failing!

I really like this iteration of the wireframes. It feels less cluttered.

Oh I have one question which I observed while looking at the wireframes. They seem to indicate that the method to fullfill the recipe is actually a list of steps rather than a full text, see

Recipe instruction (long text)

. Maybe it makes sense to change the data model here to be a little bit more flexible? See https://www.drupal.org/files/issues/5%20-%20Umami%20recipe%20wirefame%20...

@dawehner It's a good point and another item for us to discuss on Thursday's call. I had in mind to look into any current CSS styling techniques for ordered lists, anything that might degrade gracefully perhaps. But maybe there is something more flexible that makes the demo better as well.

We had some questions regarding the first wireframe:

• Search: how does the search icon behave? Does it link to the search page?
• How do we select the items in the lead section?
• • We assume we fectch 3 latest promoted nodes (articles and recipes).
• In this month's edition.
• • We cannot use the concept of custom blocks because we don't have the page context to place them into. We're going to use a dedicated "Emebeddable text" content type.
• Underneath the magazine block: will those blocks be dynamic? Will they always be the same category/difficulty/category/time?

Regarding wireframe 3:

• Main body. We will assume for now that it's just a long text field with full html. In the future we want to find a way to make the image "responsive" (have the Android app only get a reduced version of it).

Regarding wireframe 4:

• How do the view more buttons work? Do they append the recipes in place, or does the link take you to a dedicated page?

On wireframe 5:

• There is a More Recipes section. How are these recipes selected?

Thanks for this awesome work! Some people at the Contenta initiative are already working with these.

Wireframe 1 - Home #41
- Search: how does the search icon behave? Does it link to the search page?
I bet for having an expanded/expandable search field that send you to a list of results.

- How do we select the items in the lead section?
Yes, latest promoted articles and recipes.

- To answer:
Underneath the magazine block: will those blocks be dynamic? Will they always be the same category/difficulty/category/time?

Wireframe 3 - Article #42
- Main body will be a long text field with full html with the possibility to have images inside. We haven’t faced the idea of having responsive images inside WYSIWYG yet. Just to point out that the main image is a separate field.

Wireframe 4 - Recipes #43
- How do the view more buttons work? Do they append the recipes in place, or does the link take you to a dedicated page?
I think they’d go to a list page with same filters applied. Is that right @kjay @lauriii?

Wireframe 5 - Recipe #44
- There is a More Recipes section. How are these recipes selected?
We have 2 options: other recipes with same categories or referenced recipes to showcase how Drupal is able to relate content apart from other entities like users or taxonomy. We discussed this and agreed on using referenced content, but there wasn’t an strong position for this so it could be changed if you would like to.

Thanks for the clarifications @ckrina. Please let me know when those open ended questions are resolved.

We may need wireframes for that page if we want to link to another page.

I think they’d go to a list page with same filters applied.

Underneath the magazine block: will those blocks be dynamic? Will they always be the same category/difficulty/category/time

I first thought they would be menu links but because of it must contain 2 fields it cannot be a standard menu link. I think these should be just static links.

- How do the view more buttons work? Do they append the recipes in place, or does the link take you to a dedicated page?

We planned with @kjay that these would use the Views ajax load more functionality since we won't have enough recipes to make it worth it to link to a separated page.

There is a More Recipes section. How are these recipes selected?

We discussed more this and we would like to use the category to find more recipes so then we don't have to introduce another entity reference in the recipes just for the more recipes block.

Since this issue has been quite stable for a while, I will mark this as RTBC for now.

This looks great, complete and sufficient. If necessary, any changes would be minor tweaks so lets take it from here. Thanks for working this through. Onwards!