You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Looking at the display types for media, we have displays set for "Events thumbnail" and also "Newsroom teaser".
Let's take those 2 as an example of what not to do and why.
We do not have a consistent naming convention. To fix, let's change to "Events teaser" and "Newsroom teaser".
We should not need to have individual media display modes for the same content view mode - teaser. Each content type using the "Teaser" view mode should use the same "Teaser" media display mode.
If we continue with the approach we currently have, and every content type wants to use a teaser image in, say, search results, we are going to have an unmanageable amount of media display modes - news teaser, event teaser, guide teaser, directory teaser, step-by-step teaser, etc
Now, if we then enable another view mode - say, card, for example - and follow the same approach, we are going to have massive technical debt in the future.
This reminds me of the issues we have on the frontend as well, where different developers or councils are implementing features but without the joined up thinking of a system. While this allows features to be independent and module, it sets us up for massive headaches in the future.
The text was updated successfully, but these errors were encountered:
Now that we have news almost ready, I'd really like to push to have a chat about this. I'd much prefer news teasers to use a media display mode called "Teaser" (and eventually events, services, directories, etc) to all use that when their content is represented in a teaser view mode.
This is scalable. Creating a view mode per content type multiplied by per content type view mode is taking us down a massive technical debt road.
Looking at the display types for media, we have displays set for "Events thumbnail" and also "Newsroom teaser".
Let's take those 2 as an example of what not to do and why.
This reminds me of the issues we have on the frontend as well, where different developers or councils are implementing features but without the joined up thinking of a system. While this allows features to be independent and module, it sets us up for massive headaches in the future.
The text was updated successfully, but these errors were encountered: