Problem/Motivation

There are several ways we could construct the model here that map to the basic story. For example are individual ingredients terms or content entities? Should we use simple entity references or entity reference views for ingredients? Is the "vendor" type a unique content type or is it a more generic type like "organization" with a taxonomy term of "vendor".

We should resolve some of these questions before we go too far down the road of building the profile.

Proposed resolution

The out of the box initiative team has defined the following content types and taxonomy vocabularies as the basis for the sample content:

Content types

Page
  • Title (string)
  • Body (long text)
Article
  • Author (reference to user)
  • Title (string)
  • Date (datetime)
  • Body (long text)
  • Image (image)
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)
  • Image (image) (first could be used as lead image but see below)
  • Summary (long text)
  • Author (reference to user)
  • Recipe category (enum, Desserts, Soups, Salads, Entrees, Snacks)
  • Preparation time (integer, minutes)
  • Cooking time (integer, minutes)
  • Difficulty (enum, easy, medium, hard)
  • Ingredients (array of strings)
  • Recipe instruction (long text)
  • Number of servings (integer)
  • Tags (reference to tags taxonomy)
  • Recipe reviews and testimonials (reference to comments)

Taxonomy vocabularies

  • Tags (Vegetarian, Vegan, Italian, French, Catalan, Japanese, Healthy, Fish, Meat, Low carb)

Remaining tasks

  • Discuss the model in Drupal UX meeting, report back here.
  • Approve the proposed content model

User interface changes

None

API changes

None

Data model changes

None

Members fund testing for the Drupal project. Drupal Association Learn more

Comments

tkoleary created an issue. See original summary.

larowlan’s picture

larowlan’s picture

Priority: Normal » Major

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

tkoleary’s picture

Here's the latest version of the model.

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 (custom field with term and amount)
    • Preparation (custom field)
    • Cook time (custom 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
tkoleary’s picture

In the slack @kimb0 suggested that we could use Entity Reference Quantity for the ingredient with quantity, and presumably propose it as a new core field (experimental) since it's so small:

the module is just three classes (a widget, a field type and a formatter)

I agree.

webchick’s picture

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.

tkoleary’s picture

@webchick

I think if we could make it 'field with value' or 'compound field' it would be broad enough to be valuable to many sites. For example.

Cart
[entity reference: product node],[value],[units]
eg.
Items in cart
Paving stones, 25
Fertilizer, 2, large bags
Pesticide, 3, ltr

Or
Generic alternatives with equivalent doses
[trem reference: drug],[value],[units]
eg.
Amoxycillin, 10mg
Arithromycin, 15mg

Or
Required credits (or hours) for transfer
[category: term reference], [value],[units]
eg.
History, 20 credits
Science, 15 credits
Math, 30 credits

larowlan’s picture

Issue summary: View changes
Status: Active » Needs review

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.

tkoleary’s picture

@larowlan

Thanks.

Also moved the question of using Entity Reference Quantity to a separate issue #2822595: Add Entity Reference Quantity as an optional field in core

lauriii’s picture

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)
lauriii’s picture

Assigned: tkoleary » Unassigned
yoroy’s picture

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

yoroy’s picture

Title: Settle on architecture of content model » Content model for sample content in Out of the Box Initiative
Category: Task » Plan

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

lauriii’s picture

Issue summary: View changes
yoroy’s picture

Issue summary: View changes
ckrina’s picture

Issue summary: View changes

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

dawehner’s picture

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 :)

ckrina’s picture

Issue summary: View changes

Of course!

yoroy’s picture

Issue summary: View changes

Updated the formatting in the issue summary.

lauriii’s picture

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.
lauriii’s picture

Issue summary: View changes

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

lauriii’s picture

Issue summary: View changes

Removed the leftover ingredients taxonomy vocabulary from the proposal

e0ipso’s picture

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

lauriii’s picture

@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.

kjay’s picture

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!
lauriii’s picture

Issue summary: View changes

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.

eaton’s picture

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.

e0ipso’s picture

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?

dawehner’s picture

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: Users expect rendered media, not links, and configuring the entity reference display and view mode properly is challenging
larowlan’s picture

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

lauriii’s picture

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?

dawehner’s picture

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.

yoroy’s picture

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*.

dawehner’s picture

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?

lauriii’s picture

Issue summary: View changes

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

kjay’s picture

Issue summary: View changes

Adjusting issue summary to change total time to cooking time

kjay’s picture

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

kjay’s picture

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

dawehner’s picture

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...

kjay’s picture

@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.

e0ipso’s picture

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?
e0ipso’s picture

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).
e0ipso’s picture

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?
e0ipso’s picture

On wireframe 5:

  • There is a More Recipes section. How are these recipes selected?
e0ipso’s picture

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

ckrina’s picture

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.

e0ipso’s picture

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.

lauriii’s picture

Status: Needs review » Reviewed & tested by the community

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.

yoroy’s picture

Status: Reviewed & tested by the community » Fixed

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!

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.