# Trade-offs ## Flexibility When designing the authoring experience for a CMS platform, it's crucial to consider the appropriate level of flexibility to provide content authors. There's a balance between flexibility and usability that should be carefully weighed. Overloading users with unnecessary choices can complicate their workflows and make it harder for authors to create pages with a consistent brand aesthetic. {% hint style="info" %} What kinds of components and layouts will users need to build? Providing flexibility where users need it – and hiding choices where they don't – is key to building a coherent authoring experience. {% endhint %} ### Content fields When building text input fields, we recommend thoughtfully selecting what text styling options are shown to users, instead of showing every possible styling option. In some cases, it may make sense to provide a simplified text area and specify font styles in the front-end code. This helps avoid inconsistencies and hierarchy issues. For example, perhaps your content authors need to bold, italicize, or hyperlink parts of an image caption, but they don't need to change the font size or add bullet points. In that case, it makes sense to hard code the font size in the component and declutter the user interface.
On the left, users see a minimalistic text box for entering image caption; they see options to bold, italicize, and hyperlink text. On the right, users see a cluttered text box for entering image caption; they see a drop-down menu for selecting a font size, and options to bold, italicize, itemize, and hyperlink text.

On the left, users see a minimalistic text box for entering image caption; they see options to bold, italicize, and hyperlink text. On the right, users see a cluttered text box for entering image caption; they see a drop-down menu for selecting a font size, and options to bold, italicize, itemize, and hyperlink text.

### Pages Starting with a blank page can be daunting for content authors. They may not know what the page should look like or what components to use. Rather than requiring content authors to make design decisions every time they build a page, it may be helpful to provide a template. For example, blog posts on our website are templated. Content fields are mapped to predetermined components to limit what page modules authors can add, edit, or move on the page. The page layout can only be modified by chancing code. The CMS essentially acts as a content database.

Our blog posts use templated pages. Users can write and edit content in predefined fields.

Some pages require a tad more flexibility. For example, our careers page has a templated section and another section where authors can add page modules from a list of options.

Authors can add page modules to the non-templated section of a hybrid page.

More advanced content authors may need to assemble entire pages from scratch. For example, they may need to create product pages with unique page layouts and A/B test which variations convert better.

Authors can add and move page modules and customize the layout of a non-templated page.

Rather than making every component available for use, however, we recommend delimiting which components can be used on a given page type. This helps standardize how the pages look and feel and declutter unnecessary components in the page content model. We'll discuss when to template pages and how much flexibility to provide when architecting page layouts in the [content modelling section](/headless-cms-playbook/content-modelling/best-practices-for-content-modelling.md). --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://tbw.rangle.io/headless-cms-playbook/authoring-experience/trade-offs.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.