Decide on what content types to ship

[phenaproxima]

We'll need some strong, useful content types to ship with this package - I think that will greatly add value, and provide a strong foundation for adding additional components and functionality. Right now we only have the Page and Article content types, as they exist in the Standard profile.

What others might we want? I think an Event content type would be a pretty sound choice, but all ideas are welcome.

[phenaproxima]

Discussed this today with @lauriii and @goba and we agreed that we should ship at least three content types:

• Page (already done)
• Blog post (done in 1c6a5b7 and a few follow-up commits), instead of Article. I think this is a good, solid use case that makes sense to support OOTB. Blog posts are virtually identical to Articles, opting into tagging and comments (as they do in Standard).
• Event -- a very, very common need and I think it will make sense to build this out with a title, a body, a date range field, and an address field (with an automatic map) for location.

[larowlan]

Event is a can of worms, just saying. Things like repeating events and multiple timezones always make it tricky. We should probably document the assumptions/what isn't supported

[phenaproxima]

Yeah, I absolutely agree with you there. Right now it's pretty simple (I didn't enable support for repeating events), but further complexity needs to be carefully considered.

[larowlan]

Is Page structured? If so do we need a 'Landing page' that is unstructured (built with block content from LB) - if so added #12

[phenaproxima]

Page is structured; it's the Basic Page content type from Standard, with a few enhancements (scheduling, translation, moderation, etc.)

We definitely will need some kind of "landing page" content type, but that's also going to require us to have some sort of coherent component-based page building system. LB? Paragraphs? It's not clear yet.

It's also possible that we should just make Page unstructured, and use it as the "landing page" content type. I'm kind of leaning in that direction, to be honest; "page" is such a generic concept, I think, that it makes sense as an "anything goes" content type.

[thejimbirch]

Our top content types are Page, Post/Article, Event, Person, Organization, and Resource.

[thejimbirch]

If you want additional guidance, the Google Search Gallery defines (some of the) Content types that Google parses for inclusion in rich features in search results.

• Article
• Course
• Event
• Job Posting
• Local Business (subtype of Organization)
• Organization
• Product
• Profile (Person)
• Q&A
• Recipe
• Video

The remainder of the gallery are parts of pages.

[mandclu]

Another useful reference to consider is the Schema.org Blueprints module, which by design builds content models to align with standards and therefore optimized for search indexing.

[mandclu]

I also provided some feedback on the initial Event content type in #64

[mwetmore]

From a B2B perspective, Acquia.com as the following types and has some overlap with what others have provided:
Article, Award, Case Study, Event, External News, Integration, Page, Person, Press Release, Product, Resource, Webinar

Happy to provide a detailed overview if you need it 😄

[simesy]

Event is a can of worms, just saying. Things like repeating events and multiple timezones always make it tricky. We should probably document the assumptions/what isn't supported

What is the method by which it gets installed. If it's a recipe then it can be more generic without locking the user in?

[mandclu]

What is the method by which it gets installed. If it's a recipe then it can be more generic without locking the user in?

The code changes proposed in #69 would update the recipe already included to use Smart Date fields. At that point it would be only a tiny effort to add recurring date functionality. Perhaps that could be wrapped into an additional, optional recipe.

Smart Date fields are also designed to support the use of timezones, but the default widget hides this capability. All that would be needed would be switching to a different field widget, which again might be an additional recipe, but it only a couple of steps with Field UI enabled.

[phenaproxima]

without locking the user in?

I'm not clear on how anything we're doing would lock a user in...?

[simesy]

I'm not clear on how anything we're doing would lock a user in...?

It would be harder to remove a recipe than to add it. I think any friction in the experience isn't good. So we don't want them to have to pull all the config out manually or just accept it's too hard or they might break something.

It's the recipes job to add the config, then it leaves the management of that config to the responsible modules.

I think the installer will show a choice of Core recipes. Better for the engineering too because it will give the starshot project a way to add more generic recipes without a bloated user experience.

Then there is (in progress) the new Project Browser. Core could have an event recipe that is very generic, but if you work in not-for-profiit or an events company, you might want to choose from a range of contributed event recipes.

[YevKo]

Totally agree that it is "harder to remove a recipe than to add it". We have been using a custom installation profile and we had to document how to "disable" features thoroughly.

Also, the Starshot release will happen faster if we don't overload it with stuff.

[simesy]

I think the installer will show a choice of Core recipes.

That's badly worded. I think the installer should show a choice of optional Starshot recipes. I've created this issue to centralise different points of view on this.