Illustration by

The Homepage Exception

Everyone wants beautiful homepages. It doesn’t matter who’s running the organization, what industry they’re in, what design trend is hot, or what CMS is being used. A homepage is the front door to an organization, and organizations want homepages that reflect their sparkling missions and content.

Article Continues Below

Obviously this is where we, the web professionals, come in. We identify patterns in a company’s content and design. We build an ordered system to manage the site, with content stored in structured fields and cross-referenced by neatly stacked taxonomic containers. We build drool-worthy designs into pretty template patterns, into which a CMS can automagically flow that content. Relax, humans! The computer robots have got this.

And, of course, the robots drive homepage content, too. A common type of homepage—which I see a lot in my work with nonprofit organizations, but can be found in any industry—is a mix of somewhat static, explanatory content, with dynamic chunks populated by the most recently published content from a CMS. When these organizations are on tight budgets, often without a lot of staff and resources, it seems like a good idea to code the static parts and automate the dynamic parts. That way, staff doesn’t have to fuss with edits, updates, or technical interfaces, and the organization can focus on doing important work helping people. Homepage: done.

Until the request inevitably comes: the board of directors needs a slider because they want a way to highlight more than one post at a time. Furthermore, they need each slide to be able to feature a blog post OR a donate page OR an about page OR their gift catalog. And it’s important to the executive director that all static blurbs be wordsmithed especially for the homepage, and the blurbs may need to be tweaked during peak fundraising months. My easy homepage publishing system just left the building.

Maybe the robots shouldn’t win#section1

After having this conversation about 242 times, I’ve realized that the homepage is almost always a giant exception to the rest of the ordered system for a reason. It’s the most human page on the site, where the potential helpfulness of computer robots collides with the messy reality of humans.

The homepage is a company’s elevator pitch that must telegraph an organization’s priorities and values as succinctly as possible. The fundraising department, program staff, and board members may feel anxious about ensuring their interests are visible on this valuable real estate. These internal forces, or the politics of partner organizations or funders, will affect what is presented on a homepage, even if it may not be the most logical choice for content, design, or structure.

Instead of wishing for (the ever-elusive) Total & Complete Control, it’s more useful to accept this human foible. Rather than fighting it, let’s build something specific to handle this exception better, in a way that’s least likely to break down the road.

Of blobs and chunks#section2

Here’s a homepage I am currently rebuilding for Small Can Be Big, a non-profit project of the marketing agency Boathouse. Small Can Be Big works with Boston-area partner charities to help keep local families from slipping into homelessness. Let’s break it down:


A screenshot of the Small Can Be Big homepage, showing the first two sections of the design.
  1. Hero area: the organization wants to be able to put anything they want here. This content and its design are unique to the homepage.
  2. “How it Works”: three quick points about the organization’s process. These are also unique to the homepage.

  3. A screenshot of the Small Can Be Big homepage, showing sections further down the page.
  4. “How it Makes a Difference”: A list of brief highlights about the organization’s impact. Blurbs very similar to these live on an “Impact” landing page of the site, and could be pulled in automatically. The content admin, however, needs to be able to wordsmith these blurbs specifically for the homepage, so they are unique.
  5. A newsletter subscribe form: this form may get used elsewhere on the site, so it will be stored in a sitewide-accessible block or a widget and then displayed on the homepage and on other pages as needed.
  6. The latest blog post: This will be automatically populated.
  7. A custom call to action with supporting content, just for the homepage.

So, we’ve got one sitewide, global element here (the subscribe form), and one systematized, auto-populating region (the latest blog post). How do we let this organization custom-craft the other pieces of this page?

One way to approach this is to create this page in a single body field, and give the client a WYSIWYG with which to maintain it. This offers the ultimate flexibility. But as anyone who’s written a goodly amount of HTML knows, giving content admins a big WYSIWYG blob can lead to broken code, elements that aren’t accessible or semantic, failures in the responsiveness of the page, and content that doesn’t fit within the constraints of the design. This can quickly lead to a schlocky-looking (that’s a technical term) homepage.

A better approach is to break the page up into little custom WYSIWYG chunks (blocks, panes, or custom text widgets). You assemble them on the homepage via whatever best methods your CMS offers, and the client maintains each and every little snippet in its own block.

The advantage is that the homepage gets broken down into components, reinforcing—at least somewhat—the separation of the content from its layout and design. For example, the “How it Makes a Difference” chunk might be built as four separate blocks or custom text widgets, floating next to each other:


A close-up screenshot of the Small Can Be Big homepage, showing three icons and blurbs under How It Makes a Difference.

The downside is more complicated management over time: the containers holding these chunks are generic tools, wired together in a front-end display. Each chunk may be maintained at a different URL. Specific help text can be tricky to include. And lots of small bits in the backend can be difficult for content admins to track, especially if there aren’t editorial guidelines and a strong governance plan in place. Eventually, the quality of the homepage, and the site, can start to degrade.

Let’s embrace the exception!#section3

What I’ve been increasingly doing is making a content type that exists for one purpose: to serve as a structured form for homepage content entry and maintenance. This can feel weird from an information architecture perspective. Content types are generally reserved for pieces of content that share common attributes, implying that there is more than one instance of that content. As one of my colleagues said the first time I suggested this: “A whole content type for one piece of content?! That’s not what content types are for!”

But here’s exactly when we need to check back in with the goals of building CMS content structures in the first place: robots are here to serve humans, not the other way around. If this exception is needed, let’s embrace it rather than fight it. A single form to edit all of the custom content on the homepage can make things easier on the content admin, and helps enforce design cohesion and content consistency.

In breaking down the content type for the Small Can Be Big homepage, I looked for logical content and design patterns so I could group fields in a helpful way. For example, the three “How it Works” blurbs are there to inform donors about how their contributions work:


A close-up screenshot of the Small Can Be Big homepage, showing three icons and blurbs under How It Works.

It’s logical for this sort of element to live on a homepage, and it will likely always be needed for this site. So I built it as a list of three items, and called it exactly what it is: How it Works. In the CMS, it looks like this:


A close-up screenshot of the CMS homepage edit form, open to the How It Works tab.

I included help text about what HTML goes into each field, and some sample content. If the homepage changes in the future, these fields can be tweaked, or deleted and replaced with something else. But if the content structure remains the same, the design and/or layout can easily change to restyle this same three-item list. Either way, this setup is flexible.

The homepage edit form is your oyster#section4

How you break down a homepage into a content type is dependent on the kind of content and design you’re working with. In the Small Can Be Big example, I’ve broken the form itself into the different content and design areas of the homepage: the lead feature (hero) section, the impact section, etc. This makes the form a lot less overwhelming to edit.


A screenshot of the CMS homepage edit form, open to the hero edit tab.

The breakdown is also dependent on your client’s staff resources. In my example, the client has a dedicated technical person on staff to edit homepage content. We collaborated with the content admins throughout the development process; we know the homepage content admin knows HTML well, and when we asked him what editing tools he wanted, he requested no WYSIWYG. I wrote help text to remind him of the HTML elements that are allowed and expected in the field (if he tried to put messier HTML in there, it’d get stripped out by the CMS), and provided him with a quick inline example or reminder of the content that should go there.

For a less technically savvy admin, I might make more fields, rather than fewer. Fields could be made to hold icons, images, and alt text. I could put WYSIWYG editors on each of the text fields, customized for the expected markup. Alternatively, I could make every element its own field: image fields with clear, descriptive help text for the icons, and plain text fields for the H3 headers and paragraph blurbs. I would then output those values into customized HTML templates, giving me complete control of the markup around the content.

The homepage edit form is a fantastic opportunity to add helpful UI elements for content administrators. It’s also a very good idea to add a general help text block, like I did in the example, linking off to the site documentation. You could also link here to the site’s style guide, if it has one, or add voice and tone notes.

Of course, how far you can take this is also a function of your project budget and timeline. If possible, it’s wise to build time into ongoing project budgets for regular adjustments to these customizations, to ensure they continue to be helpful for content admins in everyday use. But even adding a little structure and help text can go a long way.

Let the humans win#section5

My job is to map messy human communications onto computer systems to help make it easier for people to manage those communications. That means that I need to balance the boolean realm of computer code with the far more ambiguous needs of organizational communications. By creating a structured exception for the very human homepage, I can better ensure the consistency I crave as a developer while giving content admins the flexibility they need.

Adding more logic and structure to homepage editing has another benefit as well: it encourages people to evaluate the meaning of their homepage content, making them plain old better. Rather than concentrating solely on visual “wow!”, and putting up icons and copy “because it just needs a little something there,” a structured edit form can force people to inventory what’s there, and identify that “little something’s” purpose. This encourages conversation around the role of the homepage, and keeps it from becoming a pretty parking lot subject to the whims of the boardroom.

The homepage exception is just one example of the many kinds of accommodations that human beings need in the coded, structured systems we build for them. It’s our job to adapt computer systems to their needs, not the other way around. If we don’t, then our robot overlords have won. If we expect, plan for, and even celebrate these messy, human exceptions to our logical systems, we get closer to making a web that works for both people and machines.

About the Author

Johanna Bates

Johanna Bates has been developing nonprofit websites since people were freaking out about Y2K and she had complete mastery over spacer gifs. She co-owns DevCollaborative and thinks about web accessibility and feminism a lot. She writes her best CSS while listening to music, lives rurally, and is raising her kid to embrace the inherent awkwardness of human existence.

33 Reader Comments

  1. Some critical omissions?

    * If we “View Document Outline” with the Web Developer Toolbar, along with View Source, there’s little (nothing?) to help crawlers infer what the site is about. Therefore this will never rank, and so it stands little chance of discovery. Suggestion: “it”, as in “How it works” is usually not the best text inside an H2 tag. Both the title and the H1 tag are not determinant in any way.

    * Javascript and other assets are served un-minified, and mostly in the wrong places amid the page order.

    The veneer is nice, and the analysis of the layout structure is interesting; good job on that.

    Edit: I suppose what I’m really saying is, there are conflicting priorities — more than first meets the reader’s eye — in homepage content strategy.

  2. This is the kind of article that I know I will send to my internal clients and frequently reference. It’s thoughtful and written for everyone, not just developers. Thank you.

    One technical question: I love the easy-to-read layout of content editor in your screenshots (the tabs on the left). I can see it is Drupal and I’m wondering what theme or module combination gives you that layout for node editing? Or maybe this is the default Drupal 8 editor and I just haven’t seen it yet. 🙂

  3. Robert, check out the Drupal 7 field_group module, which allows you to place fields into logical groupings on both the edit interface and/or the public displays. These groupings can be configured to display as tabs, fieldsets, or arbitrary HTML containers.

  4. @Robert Knight: Thank you! It’s Drupal 7, and the module that allows for those left side tabs is good ol’ Fieldgroup: https://www.drupal.org/project/field_group

    @Johnny Martin: Thanks for those great module recommendations! They look super helpful.

    @Steve Black, @Colin Mitchell: Yes, this rebuilt homepage is not yet in production as of the time of this writing.

  5. Ha! This is the approach I have been implementing for few last days for my base WordPress theme.

    Typically homepage (but many other pages too) contains the same content sections across the site. And there were all the time problems with managing content on them within one wysiwyg editor field.

    So I created few content types (section types), defined templates for each one, made it extensible for future content types.

    Now, editing homepage is about dragging boxes from “available sections” list to “active sections” list

  6. Wonderful article! Thanks 🙂
    And as an aside, I love the use of Drupal here! It’s always such a great system when we take the time to build intuitive UIs for our clients.

  7. Excellent article! This is definitely how modern home pages (and all page templates for that matter) should work and I just want to make the point that you can achieve this on low budget projects too.

    For instance on WordPress you can achieve this using the Advanced Custom Fields plugin along with the makers Repeater add-on. If set-up correctly they enable an editor to do some pretty cool stuff like re-ordering chunks of content and adding new content blocks like list items or anything you can think of really.

    There’s no reason why you can’t have these kinds of tools and templates ready to roll out even on the smallest of one-pager projects!

  8. Terrific read. My company just tackled this same issue with the same approach.

    One thing that worked well for us: have one person implement the technical wire-up of the home page fields and a different person format the admin editing and instruction text.

    It’s hard for a single person to speak robot and human at the same time. The person who implements the technical side almost “knows too much” about how it works to communicate effectively with non-technical users. Plus, we found the person doing the coding often wanted to cut usability corners to save implementation time and reduce technical complexity.

  9. @Stephen Haney:
    Thank you, that’s an excellent tip. We sometimes get to work with a content strategist who delivers great help text along with her content models, that we can then build right into the content types. I love this, because it’s help text written from the perspective of the whole larger content picture. And it’s so easy to build in when it’s delivered in the beginning like that.

    That help text is then further refined by others, including project managers and the content admin users themselves.

  10. I completely agree with your article for making the homepage bespoke. As a Drupal developer myself, it was interesting to see your implementation with Field Group. What I usually do is create a custom page using Panels. So your method is something new to me that I’ll definitely try out as well.

  11. Great article……. many web designers fail to appreciate the purpose, role and function of a homepage…… the idea of thinking of homepage content as your elevator pitch is a great one

  12. A very interesting article, because there now a new standard for web design and Google love it also. The standard themes and sites are old nowadays we do designing with Bootstrap a lot more nicer and cleaner and not so hard to do. But again a great post!

    Click here to go to Zone Romantica UK

  13. Hi Johanna. Nice article. I agree with what you’re saying. The homepage should always stand out and be special. You’re mentioning a “CMS” in your text and also provided some screenshots. Would you mind telling me what CMS you’re using?

  14. Far from creating a “whole content type for one piece of content,” you have created a whole content type for one (very unique) type of content… exactly how a system like Drupal is intended to be used. Nice job!

  15. Johanna, really interesting read. I always used to wonder why homepage is designed differently than the rest of the website. You article was much helpful in answering some of my questions.

  16. @Timo This is the Drupal CMS (Drupal 7), which is the CMS I’ve been primarily working in for years now. But I’ve worked in many CMS platforms, both open source and proprietary, and this kind of approach is possible in the best of them (for example, this kind of approach is definitely do-able in WordPress).

  17. Nice article. Websites forms an integral part of business that acts as a medium to connect visitors with the business offerings. It is important to have engaging and responsive website that invites visitor interactions.

    With the emergence of Web content management system, these task has been easier, however selecting a right CMS can be challenging. Make sure to select a platform you are comfortable with. Ensure to choose a flexible, scalable, easy to use and secured content management system that comes with number of functionalities and features to power your website. Using WordPress can be an easy choice as it has all that is required to create attracted and responsive websites that is powered by amazing themes and plugins to represent the content beautifully.

Got something to say?

We have turned off comments, but you can see what folks had to say before we did so.

More from ALA

Nothing Fails Like Success

Our own @zeldman paints the complicated catch-22 that our free, democratized web has with our money-making capitalist roots. As creators, how do we untangle this web? #LetsFixThis