Consider filtration systems
Given any domain — in this case, a set of books by a specific publisher — there’s a strong chance people will want to search within a subset of everything within that domain.
After all, there are people who read voraciously, but only within the bounds of science fiction. Others won’t read science fiction at all unless it’s by Catherynne Valente (who’s amazing, by the way).
These offer you another great route for defining what does and doesn’t need a Collection. So for any given entity that you’re not sure about representing with a Collection, ask yourself two questions:
- Might I want to filter by it?
- Would I like to have a dedicated page for each item in the Collection?
If the answer’s yes to both, you’ve got a Collection on your hands.
But to get back to our example, potential filtration systems include:
We’ve already covered Author and Genre as high-level, Collection-worthy entries. But Awards is an interesting new wrinkle. We currently only list it as a characteristic (read: field) of the Author and Book Collections.
But given that Awards now shows up in more than one Collection and is a characteristic I might want to filter by, it’s rapidly becoming a strong contender for a new Collection. After all, I know I would love to read through all the Nebula award winners at some point. Awards also provide a strong inducement to purchase, since they’re like crowdsourced reviews, but sourced from the best readers.
Filtering, references, and multi-references
One other question that’s useful to ask yourself when creating Collections is:
Could an item in another Collection have multiple references to this potential Collection?
For instance, many authors write in more than one genre. Ian Banks, for example, writes both sci-fi and literary fiction, so being able to tag him with both genres would be useful for the end user. There’s an argument for this being the “most true” way to model an author in your CMS, but there are both technical impacts and epistemological questions raised by this choice.
On the technical side: displaying the same content under a bunch of different filtering methods can be problematic for SEO. To Google’s spiders, the Ian Banks’ card on the “Sci-fi Authors” page and the one on “Literary Authors” just look like duplicate content.
Probably not a huge issue since not too many authors wade in both of those pools, and thus those two pages should still be sufficiently unique in Google’s eyes to still rank well. But it certainly could be problematic with your crossover fantasy/sci-fi authors!
The other issue is that you can’t filter Collection lists on two dimensions with Webflow CMS (not natively, anyway). So if you’ve got an “All Authors” page, you couldn’t set up a filtering mechanism to show all authors that write both fantasy and sci-fi — or to show all the authors that do one or the other, for that matter.
On the epistemological front, we have a strong argument that attaching a genre to an author isn’t the logical path. After all, a writer is just a writer, with the agency to write in whatever genre they’d like. On the other hand, we tend to think of any given book as being fairly easily assigned to one or more genres. It’s easier to conceive of a genre belonging to a book than an author, so it might be a better idea to only reference Genre in the Books Collection — not authors.
Which leads us to:
Honor user’s mental models of filtering and sorting
One thing that’s easy to miss when considering your filtering and sorting methods is how people make use of such tools. For example, when creating an “Authors” Collection, it’s all too easy to just default to the pre-supplied “name” field.
But in a bookstore, authors are alphabetized by last name, which I can’t sort by if I just use one flat name field. To support that standard frame of reference for sorting Authors, I’ll need to split the name up into two fields: first name and last name.
Keep content governance in mind
One aspect of this discussion that content strategists often spend lots of time thinking about is the question of governance.
I.e., how do we not only publish the right content for the right people, but also manage that content down the line?
Managing content gets easier when your Collection structure is built for control of inputs. To illustrate this, let’s quickly return to our idea of having an Awards Collection on our bookseller’s site.
An Awards Collection would be handy for filtering, sorting, and creating cool landing pages to highlight award-winning books. We might also want to limit what Awards merit highlighting for us. After all, there are thousands of literary awards out there, ranging from high-profile nods like the Nobel, the Man Booker, etc., all the way to minor triumphs like a small press’s annual chapbook award winner. The latter aren’t likely to appeal to most readers, so we might want to focus on the big guns.
Having an Awards Collection will also be handy in controlling the presentation of the award. For example, the Man Booker is often truncated to just “the Booker.” If we want to avoid that truncation, having the Man Booker as an entity in our database allows us to more easily reference it in a consistent way!
Now, obviously, Collections aren’t error-proof, by any means. And people still have the power to incorrectly reference things anywhere they’re allowed to write freely.
What Collections do do, however, is simplify governance. When you know that your content is nicely chunked into the same pieces, item after item, you learn what to look for, what the system expects, and how you can use that content later in different contexts. Which eases not only governance, but also reuse.
Controlling your marketing messaging via your CMS
Anyone who’s ever marketed a product or service knows that you’ve got a certain way you like to talk about its features and benefits — and you never want to deviate from that messaging.
Handily, a CMS can help you control that message. To stick with our bookseller’s website, let’s say you’ve just launched a new e-reader that you’re keen to market through the site.
With a little market research, you’ve established that people love the portability, massive storage capacity, and ability to download any book, anytime. What they don’t love is the blue light off the screen, complete lack of old-book smell, and the weird plastic casing.
So when you add the e-reader as an entity on your website, you can also make its various features into entities that are referenceable in other Collections (ideally, via a Features & Benefits Collection). That way, when a new writer joins the team and asks how you’re selling the e-reader, you can just point them to the CMS!
Manage assets wisely
At the moment, Webflow poses two challenges for those looking to use numerous images in their Collection content:
- Individual items in a Collection may need a variable number of images. That is, your portfolio might need 8 images for that work you did on an HP ad campaign, but only 4 for that mobile app you just finished wireframing.
- The asset manager is Designer-only. Which means that your clients will need to either ask you for images to fill out Collection items and pages, or source their own (which could lead to copyright violations, plain old ugly images, and other designer nightmares).
Now, you could work around this by deciding on a max number of images per item and giving the Collection that number of image fields. Or you could just use rich text fields. But both feel a bit kludgy/hacky, and neither solves the various issues that come with issue #2.
My suggestion? Create your own asset manager.
That’s right: Just create a Collection of images, then identify the other Collections that need images, and add multi-reference fields to those. For ease of use, you could add categories to the images Collection (so your CMS users can sort by category) or create a naming framework (e.g., for a portfolio site, add the client name to the beginning of associated screenshots, so they all sort together).
The other advantage of creating your own image Collection is that your clients/CMS users will be able to access those images via the Editor! You might need to show them how to download the images from the Editor, but it’s easier than an ongoing email chain or shared cloud storage folder.
Never neglect your author experience (AX)
When you’re designing a CMS-driven site, you’re really taking on the role of a product designer. You’re not “just” designing an experience for end-users of the website anymore. You’re also in charge of the CMS users’ experience — commonly referred to as “author experience” or AX.
One big thing to keep in mind as you craft that author experience is that most people don’t share the content designers’ passion for well-structured data. When they think about writing a webpage, they likely think of it as equivalent to writing an email: There’s a shapeless field for them to fill with text and images and whatever, and when they hit Publish, boom, there’s a new page.
Which means that when they log into your lovingly crafted CMS and see a dozen Collections full of beautifully atomized content … they might be a touch confused. And when writing a blog post feels less like penning a magnum opus and more like filling out a government form, they might feel … a little bored.
That’s not to say you should abandon your meticulous structures in favor of shapeless blobs of rich text fields though! It just means you need to strike a balance between structure and experience. Focus on adding structure where it matters — and doesn’t create too much friction for your authors.
By way of example, I’ll criticize myself for a minute.
Not long ago, I built a CMS-powered site for a nonprofit that holds various literary and reading events in my area. As part of that, I created a Collection of authors that included a bio field. While creating this Collection, I read through dozens, if not hundreds of author bios — and noticed that 99 out of 100 author bios look like:
[AuthorName] is …
So I decided to design a bio component that cleaned that up, referencing the author name as a block element, then continuing the bio as another block element below the name. Then I added a note to the bio field that future authors should omit the first instance of the author name from the bio. That way, each bio would look like:
Cleaner, simpler, and without the repetitive instances of the author’s name.
Of course, not a single author of the site has paid heed to my directional copy, and each and every bio now looks like:
[AuthorName] is …
Granted, this is sort of a graceful degradation. Some of the bios look clean, and the rest look just like most bios look. No biggie.
But I did waste a little time there!
For more tips on designing for the author experience, check out our article, “5 tips on designing for content creators.”
Any other tips on structuring dynamic content?
I’m dead-certain many of you have discovered your own content schema workflows and best practices. So don’t keep them to yourself! Add your ideas in the comments below.