Bildung

contentmodeling

This is somewhat Drupal specific, but the graph view in Obsidian is a fun and flexible way to visualize a content model.

Assuming you want to document these different kinds of things and see how they relate:

  • Content types (news, product, person, form, event, …)
  • Vocabularies (event types, colors, sizes, materials, …)
  • Media types (image, video, audio, document, …)

Steps:

  1. Create a separate vault for the content model
  2. Create a note for each content type
  3. Use wikilinks to relate different content types
  4. Use tags to indicate vocabularies
  5. Create and insert image, video, etc. placeholders
  6. Look at the pretty graph!

Create a separate vault

This is just a folder somewhere on your computer. Store it in your dropbox, google drive, nextcloud or similar to access from other computer machines, but you knew that already.

From the bottom-left sidebar in Obsidian click the thingy which wants to look like a vault. From there, you can name your new vault and point to the folder you want to use.

Create a note per content type

Start creating a note for each content type that is in your model. Use the name of the content type as the file name. So create a “product.md” for your product content type, “news.md” for your… you get the point.

Create links between related content types. In Drupal content type speak, these would be reference fields. A reference field lives on the content type that does the pointing to the other content type. The direction matters so it's meaningful to create the link in the file for the content type that will have the reference.

Use tags for vocabularies

Obsidian understands hashtags (“#somelabel”).

Now here we need to make a mental leap. In regular use, hashtags are often used as quite specific labels, e.g. “yellow”, “banana”, “merino wool”, etc.

Not here. For your content model you're not primarily concerned with the specifics of wether a content item is tagged with “blue”, “apple”, or “denim”. What you want to document is that your content types want to use tags from (in this exampe) these collections of terms: “colours”, “fruit” and “textiles”. In Drupal speak: use hashtags to indicate which vocabularies the content type will be able to use.

Create and insert media placeholders

Images, videos, documents and the like are considered media types in Drupal. Similar to content types, but media objects are treated as a separate type of content types, because technical reasons, mostly.

A similar leap as we did with tags for vocabularies above with an additional simplification. Instead of using placeholder audio and video files, we'll use images for each media type. Use the name of each file and a bit of iconography to make them distinct. Create these images and add them to the vault:

  • image.png
  • video.png
  • audio.png
  • document.png

(audio icon via https://freesvg.org/volume-icon)

For each content type that uses one or more of these media types, embed the corresponding image in the body of the note.

Here's an example of a testimonial content type note that contains a video and uses the fruit and colours vocabularies. The file would be called “testimonial.md” and the minimal contents would be:

# Testimonial ![[video.png]] #fruit #colours

Look at the pretty graph!

Got your content type notes in place and linked, hashtags for vocabularies added and media items embedded? Great, now switch to the graph view.

By default you'll probably only see the content type notes. Expand the “Filters” section in the little box top left of the graph and toggle the switches to also show tags and attachments. You may also want to toggle the “Arrows” switch that is in the “Display” section. The arrows will show the direction of your references, or, which note is doing the pointing to another note.

Here's the content model of the Umami food magazine demo that ships with Drupal core:

(download these umami content model files here: https://github.com/yoroy/purple-maze)

What I think works well

  • The very explicit network-like presentation, which is very much not looking like a sitemap.
  • For a more complex content model like the one in the picture at the top of this post it clearly shows which content types are the workhorse hubs in the collection, connecting to many other pieces.
  • Extending, changing the model is very easy to do, it's all just simple markdown text files and a few image attachments.

Further explorations and limitations

  • Content types, vocabularies and media types are the three essential building Drupal content modeling building blocks. The Obsidian concepts of notes, tags and image embeds are the three availabe kinds of things to map to. Should you need a fourth type of building block like e.g. a custom entity type, I don't know how to introduce a fourth type of thing in Obsidian. It's scriptable so there's probably a way around this?
  • You could add the other fields a content type uses (body, summary, duration, etc) as a list to the content of the corresponding note. I don't think this simple markdown format is the best way to specify the configuration details for each field.
  • Maybe there's a more fine-grained way to do this, using a note for each field instead of for each content type. Would probably need to use folders for each content type then.

#contentmodeling #drupal

Het goede en gewenste van structured content is ook dat sommige dingen daardoor juist niet meer mogelijk zijn!

Gestructureerde content maakt het makkelijker om daar waar dat gepast is (opsommingen, gerelateerd, inserts) zaken op basis van regels en filters te tonen. Business rules?

Daar alsnog een directe redactionele ingreep op mogelijk maken via een grafische gebruikers-interface gaat daar dan recht tegenin. “Soms” is een special case van “altijd”, dus die telt niet om de vraag kleiner te maken.

De management tools zijn in die gevallen eerder indirect: tweak de business rules, pas je taxonomie aan, stel de regels voor filtering bij.

#contentmodeling

Written in response to

The most obvious reason to create separate content types is because different content structure, different fields.

Other reasons to define a separate content type can go beyond differences in the needed field structure:

  • Different editorial workflows.
  • Governance: difference in content life cycles.
  • A simple(?) way to segment who can access what

Yes, there are other tools available to achieve the above (i.e. taxonomy, roles, groups in Drupal parlance), but at a certain point, the maintenace and complexity cost of DRY (don't repeat yourself) can become too high.

The definition of the function of a content type is a wider consideration than its functional-structural definition on field level alone.

(I suspect there's an analogy to be made here with object oriented code. Not all giraffes, kangaroos, wolves, mice, cows, lemurs should be instances of the same mammal class?)

An example of “all in one”: in one case we pushed really hard on gathering wildly variable service-related content into a single content type for:

  • future extensibility. Much of the service was info at first. Actual handling of service requests (order this, request that, subscribe to) will be added over time and can be made available across the whole set.
  • governance: tighter control of who can create these items to reduce the chance of duplication, which was a problem

At the same time we created different versions of a training because even if most fields were shared, which ones were required varied greatly. No meaningful (predictable) shared set of what we could assume to be available. Hard to create view modes for that.

#contentmodeling #drupal