2.0 Admin UI Design Updates

[jacobsfletch]

Ahead of some big features shipping soon in Payload 2.0, we need to overhaul the general navigation within Payload's admin panel. This is primarily to make room for a new Live Preview interface, but this is also an opportunity to make serious UX gains in other areas too, and to fix all of the common pain points raised by content editors.

Here is a quick list of the design goals:

• Maximize usage of horizontal space to allow for live preview
• Improve visibility of localization features
• Lay groundwork for best-in-class editing experience
• Prepare for additional views
• Minimize breaking changes
• Prioritize UI elements with the most value to editors
• Explore top-level navigation sub-panes

Here is a list of the features covered:

• Introduce the Live Preview interface
• Surface the Localization controls for easy switching
• Dedicate an entire view to Versions with more space to compare differences
• Introduce a new Relationships view to help coordinate multi-document / cascading publication
• Introduce a new References view to help identify all instances of a document and their exact reference points
• Create a new API view for testing, querying, and filtering REST endpoints
• Support the ability to add custom views to the edit screen

Here are the potential breaking changes as a result of this work (there isn't much):

• Custom draft / publish buttons may need some CSS love
• If you’re overriding / customizing the entire Edit view, you may need to migrate
• Sidebar positioning hacks / custom nav elements may need CSS love

OK let's get to the good stuff. There are two main directions that could be taken here, the first being dubbed "multiple toolbars". This is probably the strongest direction of the two, although everything shown here is subject to change (and likely will).

Multiple toolbars

The pros of this direction are mostly related to information hierarchy. UI elements are given a much stronger reasoning for their placement on the screen based on the needs of most content editors. The navigation is much more visually digestible and its very clear exactly what you're editing at any given time. Document meta and controls are deliberately placed according to their usage within a typical editing workflow. For instance, status and modified dates are prominent near the top of the screen, but duplicate, create new, and delete are nested within a dropdown. Users will typically edit documents, and these actions can also be made from elsewhere within the app, although still available on the document itself.

This setup does take up more vertical space, though, at least before scroll. The second navigation is sticky, which is super nice for those who are editing deeply nested fields, but this means that the top of the document may appear more intimidating for some.

Default:

Default (Scrolled):

Live Preview:

Live Preview (Scrolled):

Versions:

Relationships:

References:

Compact, Universal Toolbar

Probably the biggest advantage to this approach is a much simpler top area. When users land here they are not overwhelmed with tools and controls, although no controls are left-behind. This also means that the sticky menu is complete. There are no other controls that scroll away. So when editing deeply nested fields, you can still perform all document-level actions. But while this may render less and feel more digestible, non-tech users may find it harder to understand because most things are hidden away and everything is jammed together.

Default:

Default (Views Menu Open):

Default (Locales Menu Open):

Source Files

Everything here is public, feel free to take a closer look or leave a comment directly in our Figma document.

What's next

Everything designed here will not be built right away. We're going to implement this new UI strategy alongside Live Preview first. Here's what's to come at a high-level:

• Rich text editor overhaul
• Blocks within rich text
• Dramatically improved editor UX
• Better versions diff view(s)
• Interactive API view
• Relationships / References views

Community Call

Everything here was discussed today in a live stream with our Discord community. I will post a recording of that stream to this thread as soon as possible. But let's keep the conversation going! If you have any thoughts about any of this stuff I'd love to hear about it. Leave a comment or two or three and let's talk about it.

Live Preview

For more conversation around Live Preview specifically, there's a separate, ongoing discussion for that here: #3061.

Localization

We've got a bit of work yet to do around localization. Specifically, we need to:

1. Visually differentiate localized fields from non-localized fields
2. Allow editing multiple locales at once.

For more on that work, follow along with this discussion: #1234

[ChrisGV04]

I was late to the Discord conversation 🥲 But I love those proposals! And Live Preview is going to be a big selling point to customers that are stubborn when migrating from WordPress, so I'm very excited about it.

The only area where I believe many of the CMS's that I have tried lack or don't feel as intuitive is with the localization editor. If my non-technical editor has to remember that they're currently editing content for Spanish, it opens up the possibility of them starting to write the content and realize midway through that they are in the wrong language.

My favorite approach has been how Directus managed it. They show an icon with the current locale right besides the label of the fields that support localization, so you always know which locale is selected and which fields support localization as well. And something I find useful is that if you click on that icon, it opens a drop-down with the available locales and which haven't been filled, but if you click on them, it opens the field side by side so you can compare the content between languages. That would help for translating content on-the-go since you can see what you wrote for the English version while writing for the Spanish one.

[jacobsfletch]

@ChrisGV04 really really good stuff here. Editing multiple locales at once is actually on the horizon for us. Although we haven't begun any serious design work around this yet, here's the conversation for that: #1234. That work will likely address your concerns head on, which is:

1. Visually differentiate localized fields from non-localized fields
2. Allow editing multiple locales at once

What do you think about this? I'll add a link to this discussion into the main thread here too.

[ChrisGV04]

@jacobsfletch Oooh that's nice 👀 I'll definitely stay tuned for all of this. Also if there's something I can help with, I would be glad to contribute.

[DrMint]

Hi! Thanks for the Community Call; that was exciting to see what the team was up to and to be able to interact a bit.
About the two approaches, I do prefer the multiple toolbar approach. I think it's kind of the best of both worlds because it's one scroll away from being just as compact as the universal toolbar, while also be more accessible and spaced out when you want it to.

Just a thought but what if the scrolled version in the multiple toolbar approach was just a tad more like the universal bar? At least the views and locale? I could see how having the current locale(s) always visible could be beneficial while editing the content. These two could appear in the sticky bar as the other toolbars collapse while scrolling down, and disappear as we scroll up. That way, the scrolled version is (almost) just as complete as the universal one.

At the same time, if these options are just a scroll up away, maybe it's not that important to see them at all time. And it might be too much next to the buttons. Food for thought.

[jacobsfletch]

Thanks @DrMint! I think the thought here is that if you are editing deep within your document, scrolled far down the page, you are likely truly editing and do not need to quickly toggle between views. As opposed to first navigating to the document. This is more likely when the user will choose which view they'd like to interact with, which by the way will save the user's preferences. As for locale, that is a totally valid point. We're losing the locale selector in the sticky nav. BUT that being said, I think that's going to be mostly solved in #1234

[isaackoz]

These are some very exciting changes! I wasn't able to make it to the community call, unfortunately so I apologize if this was already brought up/mentioned. I've been using PayloadCMS for my eCommerce platform, which has been a wonderful experience. One issue I had, however, was stale data overwriting new data in the admin UI.

If a client orders on my front end, it will run a few hooks in Payload and do all the payment/processing logic there. This has been working great, but there is just one issue. Let's say I have an admin viewing/editing a client, and that same client does something to trigger an update to their account in the client collection (let's say it updates their "orders" field to keep track of all their orders). If the admin who was already viewing the page goes to save that user, it will overwrite the new changes made by the local API from the hooks triggered by the front-end user.

This is potentially dangerous as data would be lost without the knowledge of the admin editing the document. This is fine for static websites/blogs that don't update often, but for collections that often update through an API, it could quickly become a problem.

I explain in more detail here and propose a solution that has been working for me. I'm not sure if there's already a way to do this or if there's a better solution, but something like server-sent events would be ideal.

[jacobsfletch]

@isaackoz this is great, I totally see your point and I think long-term we absolutely need to solve for this. We might be able to consider this while we work through locked document editing in #1490. Not that these features are technically similar, but the design solutions might be better thought through together. Not only do we need to protect documents from being updated by two users users simultaneously, we also need to ensure that server events happening in the background won't be overridden once the user updates the document.

[58bits]

I wasn't able to make it to the community call either, but the changes that are coming here and elsewhere all look fantastic. @jacobsfletch . Nice work!

[jacobsfletch]

Thank you @58bits! 🤘

[Inaztm]

Hі. I offer this option. It is more compact and the tabs are visible, it is clearer for me:

Default

And after scroll

[jacobsfletch]

Thanks @Inaztm!

[coxmi]

I think these are going in the right direction, and the discord chat yesterday was great fun! I do think there are a few issues with the proposed two routes though, so without trying to step on any toes, can I put some thoughts out there?

• Header change on scroll — When in live preview mode, it feels like it would bob up and down a little when users are scrolling either the field pane or the rendered live page view.
• In the different tab views, the document fields are rendered in multiple tabs (fields and live preview), which feels like they could lose their 'solidity' as the single source of truth.
• When the live preview pane is expanded into a new window, i'm assuming the fields would grow back to full size for easier editing. Would this result in two tabs with the same view?
• Getting rid of the left sidebar is a step down in usability for me, but I think the feedback mentioned yesterday was that most people use the breadcrumbs to get back to the table view. In that case, it might be better to carry the list view to the sidebar of the document edit screen, rather than the top-level menu as has been previously, so it's easier to jump between pages/documents within the same collection.
• In both mockups, I feel like the publishing actions and state (date created/modified) are too far away from each other, and there's an opportunity to group these visually.

I've had a go at mocking up an alternative to try and get around these issues. They're by no means perfect, but I thought I'd add to the discussion with some visuals :)

Notes

• This style of publish/edited UI would likely require more fine-grained updates, and ability to clear edits since the last published version
• I've added green dots for anything with unpublished changes in the left menu
• Carrying the list/table view across to the document edit page would require visual and functional changes to the normal table view so it can work in a thinner column — but i'd imagine it would just drop down to one column, really.
• The positions for API and live preview buttons probably aren't ideal, but as these are the only two that need the full screen view, I've not put them in as tabs.

Figma link here, if anyone wants it: https://www.figma.com/proto/V2H9gDAN2aw20ZcXgKXreL/Payload-mockup?page-id=0%3A1&type=design&node-id=9-616&viewport=3180%2C1930%2C0.41&t=220143wASs0Yu4WO-1&scaling=min-zoom&mode=design

[coxmi]

Yeah, great point, and I totally forgot to write about it in the blurb. I've included 'SEO' and 'Settings' tabs as an example of tabs set in the collection config, just smooshed in with the rest if they're top level, because they're ultimately at the same level in the hierarchy. They've got the full width of the page to expand into, and could end with a dropdown if it gets too long.

The hierarchy I was going for was:
Global (breadcrumbs/user/language) → Document (title, publish/draft state) → Then everything else related to the document

Some views (live preview and api) clearly need to open in a new overlay or full-width pane, so the button design for those was meant to hint at that distinction — it could certainly be much better though!

[kalon-robson]

I do really like the dropdown button because "save draft", "publish", "preview", "whatever button someone wants" don't need to always be on display. But the tabs, I think the Payload team have mapped really well.

[coxmi]

I suppose you could do something like this. Keeping user-defined tabs on the left, and system views on the right. So any of the system ones would just open a pane, where you'd have a back button to go back to the document after it has opened. Tabs just do tabs things :)

[kalon-robson]

I guess, but if I open relations and want to go back to edit would I click Content (which in this case would work) but what if my collection is really simple and I don't want tabs (in the fields) so a simple "edit" tab would be the better option and keep the field tabs in the content area

[coxmi]

1st one — click back in the relations pane (the intent was for those ones to appear over the content in some way)
2nd one — tabs wouldn't be there, so it could use a tiny bit less screen space

Anyway, I was mainly trying to include the page list on the left (to get rid of the burger menu), and have a more condensed header with all the publish state in one place. Tabs/views are definitely a problem in this mockup, but I can see a good use case for having top-level tabs that can use multiple columns, and they're not so different from views really. I think slide-in panes might be the answer, but it needs a bit of thought.

[paulpopus]

Only two pieces of feedback from us right now that would be 2.0 exclusive:

• current font doesn't do enough to differentiate between letters i, capital i and lowercase l: Iil, default font should perhaps be a bit more accessible in this way
• can the API tab contain the graphql playground as well?
  • can we pre-generate basic requests?

It would be nice if whatever solution was settled on for the publish buttons section would be flexible enough to allow for additional plugins that do workflow management and scheduled publishing. You may not always have a save/publish button and have other ones instead

[jacobsfletch]

@paulpopus 💯 I agree with all of this. The GraphQL playground actually was included in some early design iterations and will likely end up in the API view ultimately.

[jacobsfletch]

Just got some major progress done to Admin 2.0 before the weekend, here's a quick recap:

• Established pattern for custom collection and global views
• Improved collection and global view routing
• Built new main menu modal
• Overhauled admin navigation

Updated 09/22/23 by @jacobsfletch

• Supported custom document tabs

Updated 10/02/23 by @jacobsfletch

• Overhauls main nav
• Refines doc controls
• Overflows step nav
• And much more...I'm going to stop posting updates at this point as they are becoming more and more granular.

This work completes the new Admin 2.0 overhaul by ~95% or so. While we refine the remaining 5% of UI, we're officially ready to begin building Live Preview, the new API view, and much more 🚀

[95rade]

Sorry I am late to the party. Are you guys planning on replacing admin dashboard with figma UI builder? Thats exactly what I need for the front end. Not suggesting to turn Payloadcms/admin into Elementor/WP but some page block building and style editing from the UI would benefit many. thanks