Minimum Viable Product - Part 2 - Organizational Structure

The Organizational Structure

This is part 2 of a series on how I get an Umbraco site to market fast with the minimum required features. Part 1 covered the ingredients of our site and now we're ready begin carving out document types, data types and templates. What follows is how I build a basic Umbraco site from scratch and other developers will certainly have their own way of doing it.

General site content structure

For me it's easiest to sort of think through how I want the site to be organized from a content perspective. We will need a home page that serves as the primary landing page of the site. The home page (of doctype HomePage) will have a few children:

  • About page - The all important about me page! This gets its own document type called AboutMePage since it's a bit unique compared to a BlogPostPage.
  • Contact page - This serves as the page that shows and handles contact submissions. The document type for this will be ContactFormPage.
  • Slack page - This serves as mostly informational and is using BlogPostPage as its document type since it will work just like a blog post.
  • Tag page - This serves as the 'show by tag' page and is of doctype TagPage.
  • Blogs folder - This won't have a template and will simple provide a URL segment and serve as parent to organizational folders as you'll see in a bit. The doctype for this is BlogsFolder.
  • Error pages - Boring but necessary ErrorPage doctype.
  • Search page - A page that shows the search results that the built-in searcher (Examine) gives us. The doctype will be of SearchPage.

The image below illustrates what we are going for in this example:


And now for the document types

I've noticed that structuring content and structuring document types seem to trip new Umbracians up. Structure your content as you want the content to appear logically to the visitors and editors. The URL's will be generated based on this structuring. However for document types, you should structure them based on data type inheritance. To get a better idea of what that exactly means, let's start with an image of how I structured my document types.

Please note that with Umbraco 7.4 (beta as of this writing), the UI will completely change. The workflow of 7.4 will (seemingly) be much much better. There is also a good chance you're working on a version prior to this and may want to understand why you may see document types setup this way. Also, there is a feature called 'document type compositions' which allow you to cherry pick certain document types into others. As such you may see a very flat (non-inherited) document type list as it allows for easier compositions.

As you can see from the above image, the document types do not resemble how the content is structured. It resembles how the data is to be structured. But yet there is one more catch in setting up your document types. You will need to allow document types to have children of their own. By default you cannot create a piece of content as a child of another unless explicitly allowed to. So in each document type, you can check a box that indicates which document types can be created underneath each other. Take yet another image as an example. If I expand my `Blogs` content folder (which is of type BlogsFolder), I see a level for a year and under that a level for a month and under that, a level that holds the blogs. While it seems like overkill, it'll really keep things tidy as I add more blogs. It also makes the url's take the form of http://foo/blogs/2015/12/blog-name.

Summary

So to sum up, organize your content based on how you want it to appear to editors and users keeping in mind that it'll drive the url in the process. Organize your document types based on data structure through inheritance or document type compositions. Finally you'll have to go into each created document type and allow other document types to be created. Next up will be the data types that live on the document types. Data types will serve as the inputs the editors will use.