So, you’re a front-end developer. You’re trying to learn about Tridion and how it affects your life. Maybe you’ve met some Tridion architects you want to impress. Maybe you’ve aggravated them, but you’ve run out of whisky. Even after my last post on schemas, you still feel like there’s more to learn. Well, you’re right. There is more to learn about schemas in Tridion.
1. There aren’t that many types of fields for schemas
An entire website can be built with 7 types of fields.
- Embedded Schema
- External Link
- Multimedia Link
- Component Link
Seven types of field. Three are for linking, and one is for adding more fields. So really, websites are built with four types of fields. Tridion’s flexibility comes not by offering many different field types, but many options for few field types. All of these can be required, have multiple values, and default values, but some have additional options
- text field: 1 line or many, rich text (which has its own set of configurations), or plain text, list
- number field: list
- Date field: list
- Embedded Schema
- Component Link: Allow multimedia links
Why it matters to front-enders
- A field is either required, or it isn’t; you have no complex field validations or messaging. The burden is on your code and your communication to set the parameters for how to use a field
- Text fields are text fields; the difference between plain and rich text is setting it to be more than 3 lines and checking a box to make it rich. It’s deceptively easy to change a field to something that can have huge ramifications for how you write your code
- The Date field also captures time; this can be used if you need to capture time in a specific formatting
- There’s more to that lists option than you think
Knowing your field types and properties ahead of time helps you write code that’s in sync with content authoring expectations. In my experience, 2/3rds of “content authoring mistakes” aren’t; they’re the result of code that doesn’t fully acknowledge the configuration of the schema, or failures to communicate with the client. “They aren’t supposed to do that,” is not an excuse for poor planning 6.
2. There’s many ways to list-ify a field
I mentioned that you can make Text, Number, and Date fields a list. List is way too vague of a term, in this case.
You have the option to make a list, but you additionally have the option to choose what kind of list you want:
- Drop Down
- Select Box
- Radio Button
- Check boxes
Why list types matter to front-enders
Listifying a schema field can help regulate the kinds of content that a user outputs — but that’s not why this is my bonus #2 for developers. Listification is hugely beneficial when we need to give the user a tiny little bit of control over the presentation of content. Sometimes, we ask for a component template when really all we need is to give the user a few choices in the component:
- Should an image be on the left, right, or centered?
- Does the video need to autoplay?
- Does the user want to be able to add differently-colored borders around an image?
- Should a Call to Action use icons?
we can create component templates for each of these things — and we should create CTs if this presentation should be different. But if an image should always be on the left, and a video should always autoplay, this isn’t time for a new CT.
Dropdown lists may not always give you values
Suppose an image can be positioned left, right, or center. You might think, “great, this is a way to make sure it’s always positioned; I’ll use a dropdown list.”
Drop down lists only ever allow one value to be selected, but they don’t always guarantee a value! If the dropdown list doesn’t have a default value set for it, then on the other side, you may not get any position at all for that image — in which case, your CSS needs to account for a default positioning of that image. Unless you’re confident that the drop down has a default value, you may not want to use it for positioning an image.
Dropdown lists are more helpful for adding an optional feature to content. Suppose you’re using an image, and suppose it could have a multi-colored border, or none at all. A dropdown list with border colors is your friend.
Radios are automatically required
Going back to managing the position of that image, the radio list is perfect for this. In part, it’s because a radio list is automatically required; the user has to select “left”, “right” or “center”.
You can, of course, set a default value. But, especially with something like an image position where it’s visually appealing to keep images in different positions, you can leave out the default value and force the user to decide. So, you’ll always get some value out with the radio list.
Select Boxes can be confusing
I don’t often recommend select boxes and here’s why:
You can make select boxes multivalue, but it’s not obvious to the user that they’re multivalue. As you can see in the screen shot above, there’s no visual indicator that the first one allows multiple values, while the second one doesn’t.
And if it’s not obvious to a user that it could be none, one, or many, then it’s going to be hard to account for this in your code.
Check boxes beat select boxes
The fourth option for listification of a field is the checkbox. This sucker is perfect for the scenario where a piece of content can be none, one, or many things. This is what you can use when a user wants to have a lot of optional visual features on an element that don’t influence each other:
- Background Colors
- Border styles
- Text Colors
Each value of a checkbox can equate to a single class name in your CSS. As a result, you can offer “skinnable” options to the end user for managing the presentation of a piece of content.
My first four facts about schemas in Tridion took 1000 words. The last two took up another thousand. Tridion can do a lot with very few types of schema fields. The front-end developer owes it to himself and his team to ask questions about the fields that are being used to put content on a page.
Not only that,the many different ways we can “listify” a schema field can have many positive effects on how we give content authors control over various aspects of their content. In fact, the listification of a field might deserve its own blog post, in the future.
You’re a front-end developer. You’re writing for a component template. You hand off HTML for a back-end developer to write a view. The back-end developer looks at it, goes cross-eyed and starts muttering to himself. You explain it. He says, “yeah, Tridion can’t do that.” You read my last post; you’d know that there’s a good chance that Tridion can do that, but he starts rambling on about XSLT filters, metadata, and a broker database. How do the fields in schemas actually work? What can they do? Why does the Tridion architect smell like whisky and bad decisions at 10:00am on a Tuesday?
Let’s answer all of these questions.
So, you’re a front-end developer, eh? And you’ve been told that you’ll be writing code, and that it’ll be moved into a Content Management System. Called Tridion. And you can’t find out where to download it because there’s not a version on Github. There’s some random blogs out there, a Stack Exchange, but it all feels nebulous. And now you’re wondering, “oh, crud, what’s this going to do to my code, ” Or maybe you’re wondering, “how can I get some basic Tridion knowledge before this interview at [Tahzoo || Trivident || Building Blocks || Content Bloom]? ”
It’s going to be fine. Let’s learn some things.
The original title was, “CSS’ Units of Measurement and their impact to the quality of responsive websites”, and then I thought, “I wouldn’t want to read that — there’s no way someone else would.” So I figured I’d try something semi-punny, and then hit you with the real title inside, like a journalist or something.
Whatever. Here’s the big idea:
It’s not 1999, or 2009. We can’t predict, reliably, what devices consumers will use to consume our content. Designing a website that looks a specific way in a specific breakpoint is getting harder to do, and it makes CSSing those websites more unruly. A factor that contributes to that unruliness is the unit of measurement.
There’s more than just
em to consider now. There are many other units of measurement that can have a positive impact in a responsive website.
Having a propensity to be pedantic, today I finally reached a small breaking point with
line-height. In the grand scheme of communicating design requirements, this is a tiny little thing. But, a good understanding of line-height can improve design, documentation, and code quality all at once. If you’re not using a unitless line-height right now, I’d like to encourage you to consider it because of the benefits to the browser and your team.
We all fix things, and we all solve things. But sometimes we don’t know whether we’re fixing a problem in CSS, or solving it. And I realize that even I’m guilty of not recognizing one over the other. This isn’t good. The inability to discern a “fix” from a “solution” has huge implications for the sustainability and scalability of a code base. And if we turn a code base into a collection of fixes, we kill page load, the user experience, and ultimately ourselves.
This is part three of a series called “Front-end for the Middle”. Honestly, I didn’t mean to write three posts. But when one post is over 2,000 words without being finished, it’s time to get slicing.
Previously, we’ve talked about directing a front-end developer’s focus away from design, and on to content. And we’ve also discussed semantics and schemas. Now I want to zero in on the impact that the new HTML5 semantic elements has on how individual pieces of content relate to one another.
This is a continuation of a previous post that I wrote, entitled Front-end for the Middle: Focus and Design. Previously, we established that it’s better for a front-end developer to be focused on content, rather than design. In this post, we’re going to move into a discussion on how HTML semantics can influence what happens in the CMS. If your CMS-of-choice is Tridion, then the operative term is schema.