Experience Editor vs. Content Editor vs. Presentation Details

Anyone working within Sitecore XP will be familiar with one of the common questions that users ask: "Do you prefer Experience Editor or Content Editor?" This is a fair question but I would argue that if you are truly using the tool to its fullest it is not so much a focus on a dichotomy of Experience Editor vs. Content Editor, but rather you would use both at different times as well as I would throw a third option in as presentation details (which can be accessed via Content Editor. Instead of a dichotomy it is more a trichotomy.

The reason it is not a dichotomy but rather you would alternate between the three is it depends on what you are trying to accomplish. Obviously, there are Sitecore gurus who tend to lean on one heavier than the other, but even the most seasoned individual will bounce between the three. Below are some of the pros and cons to using each of the options.

Experience Editor

Most web producers in my experience tend to use Experience Editor a slight bit more than Content Editor because of the need to see what the actual page will look like. While Experience Editor is not a perfect one for one for the live site, but it gives the web producer or user the opportunity to see how the content will look in the context of one another. Some producers call this the front-end being that it looks closer to the live site. Doing this while building is essential for trying to see most spacing issues or when you thought a component had enough padding but it is appearing to be right on top of another component. Or even more simply, if you used two components near one another that you thought might look good based on the wireframe or mockup but on further review you may not have as much copy as expected or your content is slightly different from the component's original intended use.

Experience Editor is not the best for everything you need to do but is good to get an idea of how the page is enfolding. One of the drawbacks to using Experience Editor is having to wait for the page to render each time you move an item and also making sure to save frequently as work can be lost. There are many frustrations over the years between lost time and work from various web producers that I know. Another key drawback is that Experience Editor does not always show you every component element and there are settings like updating meta data that might only appear on the Content Editor side. You will want to make sure

I would also recommend that organizations should do two things: 1) create a workflow using Sitecore 's out-on-the-box tools; 2) have your IT team/Sitecore developers create a preview option, whether this is a new environment, Vercel , etc. The business is visual and are less technical so they want to be able to see how it will look almost exactly before it goes live.

Content Editor

The Content Editor is definitely the 2nd best friend of the web producer. In some cases, they might use this option more frequently depending on how their Sitecore instance is configured. The Content Editor is more of the back-end for web producers where you can see almost all aspects of your instance. Everything is usually laid out in a content tree format where if you are familiar with the structure you can open nodes in a hierarchy to find where various items live. The Content Editor lets you easily navigate to components and move them to their correct spots without having to publish.

Being in the Content Editor view you are able to set facets, upload images to your media library, and add redirects among other items. The Content Editor tends to show you a more structured view of your Sitecore instance. This helps if you are unsure where something may live exactly but you know the overall folder structure of your site. The search bar can be helpful with locating these items if you properly labeled the items in your site and also if you have this feature enabled. Sometimes developers may shut this off. Additionally to the search bar, you can also search within content to find where a field may be.

The major drawback to Content Editor is that you need to visualize the page as deconstructed into its structure. If you are visual or you want to check on spacing/padding Content Editor is not very helpful for this. Another drawback is that you can build the items here that will be the building blocks of your page but you will still need to add them via Experience Editor for them to show on your page. Sitecore does not automatically add the components you built for the page to the page even though you may build them under that structure on the backend. You do not want to publish your page and then notice that the items you built are not showing or worse you are receiving an error message. Toggling between Content Editor and Experience Editor at a minimum is important.

Presentation Details

The trifecta of these options which can technically be accessed via Content Editor is presentation details. This is definitely for a more skilled Sitecore user because you can accidentally remove items but you should be able to add them back via Experience Editor if needed. While it is not always necessary to use presentation details, it has two major pros.

The first is that it is very helpful in a similar way to Content Editor if you want to see another deconstructed view of the building blocks of your page. You can easily see each piece and move them around as needed. It tends to be a bit faster then Experience Editor which takes a little bit to render if you move items. This functionality comes in handy when you are having trouble moving items or more importantly you are asked to move several items. It make this process a bit easier.

The second pro is if your are using personalization. If you are using Marketing Control Panel and the personalization features within XP presentation details is also very helpful. The reason it is helpful is because you can see how many personalization rules are attached (if any) to each component. This may needed to remove or adjust these rules. You can also do this within Experience Editor on each component but it is a bit easier within presentation details to do so.

The drawbacks to using presentation details are similar to Content Editor as a whole. Presentation details uses a deconstructed view of each component (see image in header). This view is helpful to easily move components up and down on a page or to add/remove them too. However, while you can move the items easily they may not show up on the page in the exact order or place that you intended so there is a bit of rearranging that must happen in Experience Editor once you move the items occasionally.

Another drawback to using presentation details is that you need to be a bit more organized if you choose to create new components for a page via this route. It is not impossible but it requires you to make sure you are placing newly created components in their right folders based on your instance so that your organization does not get ruined.

To sum up, it is not so much a preference between Experience Editor and Content Editor, but the ability to use each option for the benefits that it brings to the web producing experience. Additionally, it is less a dichotomy and more a trichotomy with presentation details being the third option. Each option brings its pros and cons and I would recommend from my experience to toggle between the three to get the most out of the tool.