Think bigger when thinking about Content Types

This post will be less from a technical perspective and more from a architectural one. I'm talking about a lesson learned and it remains one I'm still struggling with today.  With defined content types it's easy to think of the visualizer first then create a content type to support it and then for rinse and repeat.  Let me give you an example...

1st need (codename: current focus): I need to be able to put 3-4 high priority items on the front page, preferably I'd like to bring attention to them with a graphical header and a bit of text.  Then when clicked on take them to a page with more information. Ideally the client would like to see something like the bootstrap "card" presentation style.

2nd need (codename: article): I need to be able to host a blog/news section on the site. It should include the ability to have a listing index in a multitude of presentation styles and have the details of the "article" be either a pdf/word document or a link on another website or possibly even no further information at all.

So naturally when I started working on these I saw it as two different things, it was easy since it our current solution each was handled through different mechanisms the thought was to continue that thinking by keeping them separate.  Upon further reflection though I realize that they are in fact the same content item and the only difference is how they are exposed to the user.  This is exactly what EVOQ/DNN is headed with liquid content and it's the mind-set you have to wrap your head around.

I can use a single Content type and then just have multiple visualizers, one to show the items as "cards" and the other as a "listing". The trick is going to come down to filtering and tagging when it comes to what is shown where, but the data itself lines up the same on both.

Thus my plan is to build a "Article" Content Type which holds these fields:

• Title [Textbox, also becomes Content Item Name]
• Description [Multi-line plain Textbox]
• Article Date/Time [Date/Time] (this way people can post/pre populate articles)
• More Information Type (this determines where the title links to in the "list" visualizer)
  • Event Details [HTML]
  • Webpage [URL]
  • Document [Asset]
  • None
• Rollup Image [Asset]
• Optional Elements
  • Article Image [Asset]
  • Article Image Location (Top, Bottom, Left, Right)
  • Expiration Date [Date/Time] (this way you can prepopulate when the article should be removed from view]
  • Featured [checkbox]

Then I'll create visualizers that expose the "rollup" versions using various looks like..

• 3 wide cards (roll-up image on top)
• 4 wide cards (roll-up image on top)
• Cards (masonry/pintrest board layout)
• Article Listing (media markup, roll-up image on left)
• Article Listing (media markup, alternate sides roll-up image)
• Article Detail