New Community Website

Ordinarily, you'd be at the right spot, but we've recently launched a brand new community website... For the community, by the community.

Yay... Take Me to the Community!

The Community Blog is a personal opinion of community members and by no means the official standpoint of DNN Corp or DNN Platform. This is a place to express personal thoughts about DNNPlatform, the community and its ecosystem. Do you have useful information that you would like to share with the DNN Community in a featured article or blog? If so, please contact .

The use of the Community Blog is covered by our Community Blog Guidelines - please read before commenting or posting.

Data is not Content - they are very, very different (200)

I often see developers solving content challenges with the data-oriented principles. This is fundamentally wrong, like writing a sentence using letters instead of words. Such data-solutions work - but only after educating the editor in database concepts. Our customers find DNN-solutions simpler than Wordpress - because of a paradigm shift which changes everything we do. I would love to help you to see the world in this way - here's an attempt at it…

Data Versus Content

Since most DNN web designers and developers know databases and tables, you probably know what data is. What you're probably not aware of is that content is more like knowledge - it's data + meaning + context. In terms of a CMS this means that:

  1. Data is raw, table-style lists of information - think of lists of records/entities/content-items where the selection of what should the user see will be determined by the software - interactively, or pre-defined by the editor
  2. Content is consciously arranged data - comparable to knowledge - think of a normal web page, lovingly created by an author - where the selection and sequence of what the user should see was deliberately created to assemble meaning

Note that data can be used as content, and content can be used as data. When you create data to describe a specific image on the image-slider you use it as content. And if you create a page listing all images on the site, together with the their descriptions then you are using previously created content as if it were data. A blog post is content, assembled manually, while the list-of-all-posts-with-the-tag-2sxc is data.

Completely Different Editorial Challenges

Here's a simple example where the same task is solved differently depending on the data/content focus: Imagine a web site showing various services and presenting faces of the preferred contact person on each page.

  1. The Data Approach would create a list of contact persons, assign categories related to the services and then create view-components which "show all persons with category X, sorted by seniority" which will be added to each page as needed. The idea is "manage a list of persons, and the output should happen automatically using categories". 
  2. The Content Approach would create a "show one or more persons" module which the editor adds to a page, and then fills in with the persons profile. The editor will add some persons or possibly pick persons to display which he had already created previously. The idea is "the editor builds the content step-by-step and selects what should appear, and in what sequence" 

What's really important is that the editor is forced to think in data-models (lists of contacts, automatic filters, automatic sorting) in the first case, while the second case is a straightforward editing process (show this here, that there).

Example with 300+ FAQs and Hundreds of Documents

I would like to demonstrate a typical scenario we implemented for the Swiss Social Security (AHV-IV). It has hundreds of FAQ-style items (yea! a table…or not?) and hundreds of downloadable documents stored with structured metadata. The data used for the documents is ideal for a table, and it's needed in various places - even for short-urls and QR-codes, so the data related to the document even has an impact on IIS-routing rules. Normally the solution would have been to create a database with the documents and then provide various view-modules to place them in the right spot.

Our solution was to not create a document database. We implemented it as a content. The user experience is to create a page, add questions and documents to that page, and her work is done. In the background, the content is of course managed in structured tables, but the user's experience is content - and the user could also break out and add a gallery or whatever at any time.



So while the user is creating pages, content and adding documents, the data is automatically categorized for further use. In the second phase there came the need to create consolidated lists of these documents - like this:


…but as you can see, the user perception is "I create content anywhere - and it's automatically available in the list-view as well". This is much easier to work with, than "I manage lists of documents and FAQs, categorize them correctly, give them priorities and hope that they appear in the right places and in the right order"

Same Technology, very Different Editor Experience

You'll note that both approaches demonstrated above will internally have structured data (person profiles) and structured output (face here, name there, phone-number…) but the concept makes a world of a difference to the editor.

Just to be clear again what the difference is

  1. The Data Paradigm starts by giving the editor a structured list of information to manage, and the output is handled separately, usually as a form of "extract" from the original data. It's easy to spot when you plan to train the user and have to start with "Before we start, I need to explain how it works". So a common indicator is the thought that "it's a system, and as soon as the editor gets it, it's easy". It usually isn't easy, but the developer sees it that way. 
  2. The Content Paradigm feels like the underlying data is just granted, the user doesn't need to think about it. The training-indicator is when you start you training with "This is how you add a product on this page - it's just like adding a picture, only with more fields". In content-mode the editor will focus page, page-layout and the current piece of content - and nothing else. It's the natural continuation of front-end-editing. When training the content-paradigm the user will often ask "but what if I need a list of these [people | products | questions | images]?" and the designer will say "don't worry about that, we can easily add that once you need it". 

Summing it Up

In our world view, this focus on content and content-editing is a key part to providing solutions which make the editor and site owner really, really happy.


I hope this was inspiring :)
Love from Switzerland,

Daniel Mettler grew up in the jungles of Indonesia and is founder and CEO of 2sic internet solutions in Switzerland and Liechtenstein, an 20-head web specialist with over 800 DNN projects since 1999. He is also chief architect of 2sxc (see forge), an open source module for creating attractive content and DNN Apps.

Read more posts by Daniel Mettler


There are currently no comments, be the first to post one.

Comment Form

Only registered users may post comments.


Aderson Oliveira (22)
Alec Whittington (11)
Alessandra Daniels (3)
Alex Shirley (10)
Andrew Hoefling (3)
Andrew Nurse (30)
Andy Tryba (1)
Anthony Glenwright (5)
Antonio Chagoury (28)
Ash Prasad (37)
Ben Schmidt (1)
Benjamin Hermann (25)
Benoit Sarton (9)
Beth Firebaugh (12)
Bill Walker (36)
Bob Kruger (5)
Bogdan Litescu (1)
Brian Dukes (2)
Brice Snow (1)
Bruce Chapman (20)
Bryan Andrews (1)
cathal connolly (55)
Charles Nurse (163)
Chris Hammond (213)
Chris Paterra (55)
Clint Patterson (108)
Cuong Dang (21)
Daniel Bartholomew (2)
Daniel Mettler (181)
Daniel Valadas (48)
Dave Buckner (2)
David Poindexter (12)
David Rodriguez (3)
Dennis Shiao (1)
Doug Howell (11)
Erik van Ballegoij (30)
Ernst Peter Tamminga (80)
Francisco Perez Andres (17)
Geoff Barlow (12)
George Alatrash (12)
Gifford Watkins (3)
Gilles Le Pigocher (3)
Ian Robinson (7)
Israel Martinez (17)
Jan Blomquist (2)
Jan Jonas (3)
Jaspreet Bhatia (1)
Jenni Merrifield (6)
Joe Brinkman (274)
John Mitchell (1)
Jon Henning (14)
Jonathan Sheely (4)
Jordan Coopersmith (1)
Joseph Craig (2)
Kan Ma (1)
Keivan Beigi (3)
Kelly Ford (4)
Ken Grierson (10)
Kevin Schreiner (6)
Leigh Pointer (31)
Lorraine Young (60)
Malik Khan (1)
Matt Rutledge (2)
Matthias Schlomann (16)
Mauricio Márquez (5)
Michael Doxsey (7)
Michael Tobisch (3)
Michael Washington (202)
Miguel Gatmaytan (3)
Mike Horton (19)
Mitchel Sellers (40)
Nathan Rover (3)
Navin V Nagiah (14)
Néstor Sánchez (31)
Nik Kalyani (14)
Oliver Hine (1)
Patricio F. Salinas (1)
Patrick Ryan (1)
Peter Donker (54)
Philip Beadle (135)
Philipp Becker (4)
Richard Dumas (22)
Robert J Collins (5)
Roger Selwyn (8)
Ruben Lopez (1)
Ryan Martinez (1)
Sacha Trauwaen (1)
Salar Golestanian (4)
Sanjay Mehrotra (9)
Scott McCulloch (1)
Scott Schlesier (11)
Scott Wilkinson (3)
Scott Willhite (97)
Sebastian Leupold (80)
Shaun Walker (237)
Shawn Mehaffie (17)
Stefan Cullmann (12)
Stefan Kamphuis (12)
Steve Fabian (31)
Steven Fisher (1)
Tony Henrich (3)
Torsten Weggen (3)
Tycho de Waard (4)
Vicenç Masanas (27)
Vincent Nguyen (3)
Vitaly Kozadayev (6)
Will Morgenweck (40)
Will Strohl (180)
William Severance (5)
What is Liquid Content?
Find Out
What is Liquid Content?
Find Out
What is Liquid Content?
Find Out