My background in database design
I learned how to design relational databases back when I was an administrative assistant and was being asked to manage a lot of information that it was clear to me belonged inside a database. I had Microsoft Access and Google, so I went to work to figure it out. This is what originally inspired me to study User Experience and pursue it as a profession. I studied "real" database design in graduate school as well. In my UX design career this knowledge has proved incredibly valuable in making good design decisions.
Map of CMS Collections, relationships, and employment
I drew this map in Sketch to illustrate all the information I'm gathering and presenting on my website via the CMS.
Goals for CMS structure design and how I achieved them
Goal 1: Make the data entry interface support consistent structuring of content
Creating content is hard and honestly not my favorite thing to do, and the best way to encourage yourself to do something hard that you don't want to do is make it easy on yourself.
When I decided I wanted to share the Shortcuts I was building on my portfolio site, I thought of a few things that would make it as easy as possible:
- A dedicated field to store the Download link to make it easy to update and perhaps reference programmatically in some kind of fancy uber-Shortcut in the future.
- Since the things I want to say about a Shortcut usually fall into 3 categories, make the data entry field present those categories so I don't forget what they are or how I have used them previously. I want the content on the site to be professional and consistent. Also it makes data entry easier since the headings are hard-coded into the design so that's one less thing to do during data entry.
- Sometimes I come up with more than one shortcut around the same basic idea: Sometimes there are 2 shortcuts that work together, or sometimes I have different versions that do the same things in different ways. So I wanted the ability to collect related shortcuts within one page.
When to use a new field vs using a new table
These points naturally lend themselves to the idea that this type of content belongs in its own dedicated table that is linked to the Post table. It took a few iterations of the fields of the table to get it right but now I am pretty happy with it.
Structuring the way tables are linked to support better user experience as well as better database practice
When adding the new Shortcuts table, I had a choice when deciding how to link it to the Posts table: I could have each Shortcut reference a Post, or have each Post reference multiple Shortcuts.
Reasons I went with having each Shortcut reference a Post:
- It's best practice to only make changes to the structure of an existing table if absolutely necessary.
- Not all Posts have Shortcuts, but all Shortcuts have Posts.
- It's a better user experience. It's much easier to go down the list of all shortcuts and verify that each one is referencing the correct post than to have to deal with a small Multiselect form field and hope you remembered to include everything you wanted to include. You will probably wind up having to have the list open in another tab so you can verify that.
Goal 2: Make the content be stored in a way that can support multiple uses of the same content
Make all blog-like content flow into one "Post" object that can go out through RSS
If I am going to write all this content, I want to make it easy for others to find. So I wanted everything that could be published to be collected under one object, that would all be located in the same RSS feed. This means that all Shortcuts and My Work items are all stored in the same table and displayed on the same screens. I just have a few conditional show/hide things in the code of the Selected Post Page to allow for different post types to display their information differently according to their needs. In the future if I want to add different types of content that are neither Shortcuts nor My Work, I can add a new Topic to the Topic table.
Since Shortcuts reference their parent post, they can link back to their parent when on their own
I don't know if I will ever need to do this, but I wanted to structure the content in such a way as each object knows everything about itself that it needs to know to be useful. A shortcut on its own would need to be able to link back to its parent post, and this way they can. Also structuring it this way made the data entry process easier since it's just a simple dropdown to add a shortcut to a post.
All navigation comes from the database
This means that any new types of content I want to add will automatically be visible in the design and any changes I make show up everywhere they need to be without mistakes or oversights.
I also have a table that stores the "Keep in touch" links so that they can live in the navigation and also on the home page itself. This also saves me the double work and possibility of mistakes when trying to make the same updates and changes the same way in multiple places.
The only page that has content hard-coded into the design is the home page, and that's only because I thought about how I would store that and it didn't seem to provide any value to put it in the database just for it to sit there and only show up in one place. This may change!
At first, I was putting the same "How to use a shortcut" content manually into every Shortcut. I was adding the content because I know:
- Most site visitors don't know what a Siri Shortcut is and will need pointers before my content can be useful to them
- Most site visitors are probably not going to read every post
- Most site visitors are probably not going to go digging for information
- I want my content to be useful, otherwise there's no point to all of this work, so it must contain everything a site visitor will need on each page
However adding the content myself to every post got to be time-consuming and annoying pretty quickly. These were my requirements for a solution:
- I wanted a way to have it automatically show up on each Selected Post screen that referenced the topic Siri Shortcuts
- I didn't want to have to remember to select it when making a post
- I wanted the ability to add different boilerplate content to different types of posts
Building the solution:
- First I created a table called "Boilerplate" and had each "Boilerplate" object reference a Topic in the Topics table.
- Then I added a content block to the Posts page that looks for an item in the Boilerplate table that has the same Topic as the current post. I was really impressed with the flexibility and care that Webflow built into their product to let me implement what I wanted exactly how I wanted it.
This is what the page builder looks like. Here you can see it giving me the option to select posts from the Boilerplate collection and limit it to those that have a Topic reference that matches the Topic referenced by whatever post is currently on the screen.
When a post is referencing a topic that doesn't have an associated boilerplate, it just doesn't show up. The site builder gives me the option of editing the formatting of the holder when it's in empty state. I formatted the height of the container to be 0px tall so that it doesn't appear:
This way, once a Boilerplate item has been created and is referencing a Topic, it automatically shows up where it's supposed to with no further input from me.
Goal 3: Make the structure adaptable to new and different kinds of content without having to go back and edit old stuff to fit
While creating my post Verisimilitude in the UX research and design process, I wanted to provide a way to link to the icons I used and to a downloadable version of my Sketch file. Initially I just included them as links in the bottom of the post, but within a text editor links are annoying to format and have limited options. Instead I decided to create a new table in the database to store them, which provided the following benefits:
- A way to manage and update the links without having to go deep into a text editor
- A way to have full control over the formatting of the links in the post
I decided to call this table "Post Children" instead of "Links" or something like that because I recognized that I could use this table for any kind of content I wanted to attach to a post that wasn't necessarily a "link".
Once I created the table and started to add the formatting the Post screen, I realized:
- That the list would need a name
- That the name must be flexible and not hard-coded if I want to use this Post Children object for other things in the future
- That the name would be easiest to store with the Post in order to display it on the page
- That the name should be more or less consistent every time I use it, so making it a text field would prove annoying for me later on if I had to go back and look at other posts to remember what I used for different occasions
- That every post might not have a list
- That I don't think the list of Post Children would need to stand alone from the context of the Post, or be referenced independently, unlike Shortcuts, so there was no need to associate individual list items with the headline they would be shown under*.
Therefore I decided to make a new table to store the names, and reference them in the Post object using a dropdown menu.
*Then, I realized that I needed at least 2 lists: Icons and Downloads. So I decided to give myself the ability to add 2 lists to a page. So I would have to associate list items with the headline they would be shown under. Oh well, it was worth it. Being able to add unlimited lists would be ideal, but I think I'm limited to hardcoding the number of lists with this technology.
Here's how I added this capability:
- Adding a second List Name reference to the Post content.
- Adding a List Name reference to the Post Children table.
- Associating the existing Post Children with a List Name.
- Adding the display elements to the Post Page.
Database design and UX are a goose and a gander
Things that are true both about a bonded pair of geese and the relationship between database design and UX design:
- They work together to get the same jobs done.
- They share information with each other that they both need to be effective.
- They are unhappy when split up and isolated from each other
- The work you do to figure out how to make one happy shouldn't be that different from the work you do to figure out how to make the other one happy
Most of the time we say "You are not the user" but sometimes, you literally are the user, and that's okay
UX professionals sometimes need to be encouraged to use UX processes and thinking patterns to design the tools that they use to do their jobs. I think what's good for the goose is good for the gander. If we know that UX processes work to make other peoples' lives easier, we should always be mindful of how we can use them to make our own lives easier so that we can be more effective in making other peoples' lives easier.