Question: Average number of content types?

Quick question, for an average Drupal site that you’ve worked on, what would be the *typical* number of content types in use?

(I know there are lots and lots of different kinds of Drupal sites, just think about what would be average, common, typical for you. Not edge cases!)

thank you!

100 thoughts on “Question: Average number of content types?”

  1. (This probably goes without saying to most of us, but it should be said since this is for UX design purposes: This proliferation of content types means that it would be REALLY NICE if we could switch nodes from one type to another without losing data or metadata.)

      1. The only option I was previously aware of was Node Type, which comes with stern warnings that it does not do anything with CCK fields.

        http://drupal.org/project/nodetype

        Node Convert is definitely an improvement on that.

        That said, Node Convert does look to me like it’s not quite what I’m suggesting, because it discards field data if it doesn’t map to fields in the target type.

        I’m seeing people here using content types in highly specific ways that could cause them to end up with a lot of basically orphaned or oddball content, if there’s not some kind of structured way to add and remove things from a particular node without having to design a system before hand for adding stuff to and removing stuff from nodes. That is, you could plan to create a node as a Featured Item node type and then plan to convert it later to a Page or an Article when it’s no longer a Featured Item — but you’ve got to design a workflow for doing that.

        CCK it seems to me is intended to produce nodes that stay as they are for their history. The flexibility it affords is great, but it seems to me the next step is to create a way to assign characteristics on the fly — or remove them on the fly — without fundamentally changing the node type. I’m not suggesting doing away with the concept of content types; rather, I’m suggesting that they aren’t as set in stone as they are now, when you need a utility to convert them and you lose all the fields you defined if they don’t map to fields in the new type.

        Put another way, I’d like to see a way of letting a node keep properties it once had. E.g., if you create a product, and change it to a page, it would be nice to be able to change it back to a product again. (That’s not a great example — a better example might be if you had a node of type Consultant, and you converted it to a node of type Employee, you might want to be able to preserve the properties of a Consultant that don’t map to properties of an Employee — and vice-versa.)

  2. We have 7: Page, Article, Product, Event, Location, Person, Webform are the ones that I can think of from the top of my head.

  3. Sorry, I over-read the “for an average site” bit… about 5-10 for a medium site sounds about right.

  4. Not sure an average is helpful; as little as 3 and as much as 15 or 20.

    The content creation and editing experience gets messy when it’s the latter.

  5. My average is generally around 8. The only cases where I’ve seen the number of content types go above 15 could have been reduced by making a better use of taxonomies.

  6. Easily over twenty, and that’s before adding e.g. organic groups (where content types sometimes have to be bifurcated for complex permissions) and microsites (where different sites might need to serve up radically different content.

    If your site has had to serve any projects, which might have completed a business cycle but whose tailor-made content needs to hang around, then they will also add to the number. In retrospect I think we’d use even more in future, as config pages for simple project modules. We’re working on ways to improve the content types page with taxonomy to make this a more realistic prospect.

    An odd coincidence. I recently commented on (and responded to) a blogpost by David Yelvington on this very topic, where he mentioned having similar numbers of types to us, and said that people he spoke to were always surprised (which I suppose chimes with the lower numbers generally mentioned here.) But I think if you’re building a site for any complex organization then that’s perfectly reasonable. Job vacancies, staff biogs, news items, events, press releases, publications, products, images, webforms, groups, forums, blogposts, restricted content, one-off content, tailored homepage: they add up really quickly.

    1. Yes… a trick we usually do with homepages is to make content types for “featured items.” I’m currently working on a site with four different homepages that have two kinds of featured items. To make it easier for the client to “add featured homepage item” we have created 10 different content types. Should we ever need to combine them, views makes this trivial.

      So that’s 10 content types not including page, webform, blog, news, event, etc…

      Another use of content types: we sometimes create “secondary” content types that can be “attached” to “primary” content types. For instance, on a recipe site, we would have a recipe content type and an ingredient content type. Some might use taxonomies for this, but they can’t easily have cck fields.

      Which brings up a thought: with Drupal 7.0, fields work on users and taxonomy, right? So, my 15-20 content types might be cut down to 8-10.

  7. 6-8 on average.

    Most of the comments above that are describing more than that are showing a lack of understanding at how to best harness Information Architecture in Drupal. Content types are not the only tool in the box.

    1. Here, here.

      I read about creating 15-20 content types and my first thought is, “that’s insane.”

      I mean, I’m getting hints of some really creative uses (e.g., creating a content type for the top-level pages in each section, or for the home page, which could serve as an alternative to Panels [which I wish wasn’t necessary for anyone]). But still, the user experience challenge is non-trivial at several levels.

  8. 15, 17, 13, on the last ones we did. But for smaller sites like personal or niche things – about 2-4 content types.
    Completely agree with @J-P Stacey about complex organisations, and the odd replication of content types for working around permissions etc.

  9. Form 7 to 15. For example:

    Page
    Story -> Used as news item
    Container -> Page only for superadmin (section frontpage)
    Event
    Product
    Place -> With location
    Post -> Used as blog post
    Gallery
    Poll
    Webform

  10. How long is a piece of string?

    For the sites I’ve built average of 5 for simple brochure sites, 10 for sites with custom types (real estate, event and community, ecommerce). I imagine in large organizations it could grow well beyond 20.

    It seems to be easier for the user to present them with many content types thathave the same fields but tweaks (think page vs article).

    1. Could you expand on what you mean by ‘same fields but tweaks’?

      I take it as meaning that the type has all the same fields, but different templates and perhaps different display settings.

      Wouldn’t it be a simpler approach to have a property of a single content type that could force the use of a different template, or even just cause the node to be tagged with a style class? (Of course, offhand I can’t think of how to make Drupal implement the template idea, but adding a field to map to a style class would be relatively easy.)

      1. I mean it has all the same fields but a few minor tweaks like perhaps a different vocabulary, or maybe even no tweaks at all.

        A lot of users don’t think in abstract ways like us. Instead of having a vocabulary for an article with terms like ‘news’ and ‘sports’ I would make these into a News and Sports content type. This way the users can easily just go to Create content > Sports Article.

  11. Around 10.

    On the site I currently work on, we have:
    * Page ( + several variants that we created so that the user permissions would be different – grouping would be nice)
    * Blog
    * Weblink (uses weblink module to display a related link)
    * Webform
    * Event
    * several CCK types (such as Job, Volunteer Opportunity, Organization Listing, Consultant Listing, etc.)
    (These have to be different types because of the different fields.)

Comments are closed.