Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

UI Design: Thoughts and mockups #490

Open
ziburski opened this issue Jul 18, 2017 · 41 comments

Comments

@ziburski
Copy link
Collaborator

commented Jul 18, 2017

I understand that there is a larger goal of improving the UI in future versions. I wanted to contribute by sharing my ideas and design concepts. Not everything is a direct translation of existing features, but it can be seen as an aspirational concept for a 1.0 release.

Part of the reason for my contribution here is that I am frustrated by existing CMS. They all have similar information architectures with "Content", "Pages", "Collections" or "Entries". Editors usually offer a kitchen sink of fields that users don’t need. CMS don’t reflect how users think about their content, they instead rely on technical abstractions. Netlify CMS wants to make things easier, and it’s already nearly there. But I think we can still streamline the user experience, and let developers customize the UI to match their users expectations.

Visually, I think it’s good to keep it very light and simple for now. If only to show that it’s different from traditional, complicated systems.

Architecture and Editor

editor1

Sidebar Index
The sidebar shows collections and pages on the same level. You can still group pages together, but I think for new users we should lay out all pages right here by default. Note how there is no mention of collections, pages or entries — and it still works. There should also be a basic level of hierarchy represented here, but that’s another issue to figure out.

Editor
The editor should be very much focused on the users content, avoiding any unnecessary chrome or technical lingo. Text fields are white and feature a dedicated label for clarity, while other fields like boolean and select are easier to scan in a single line.

Title Field
I am also introducing a new title field here, which basically just has bigger text to improve the visual hierarchy. How exactly this could be implemented should be a different issue.

editor-markdown

Markdown Editing
Markdown toggle and add-image button is in the top right when the field is active. In the default visual mode, the inline editing bar shows the most important options.

Publish
The publish button is fixed on the right below the preview. It should also change state to show the page status.

editor-publishing
editor-published

Publishing Progress
Showing the publishing progress like that seems like a stopgap — ideally, it wouldn’t take more than a second for your changes to deploy. But for now, we at least need to indicate that something is happening after you hit publish.

Preview
By default, the preview is super small. That kind of context will often be enough, but you can also click to enlarge it.

editor-preview

Large Preview
Click on the preview to enlarge it, click again to shrink it. Straightforward, and a more direct interaction than a simple button. I think these previews need to look exactly like the website though, so I’m not sure if the current implementation with custom CSS previews is a good enough solution.

editor2

Blank State
Text and markdown fields that are not yet filled in start out collapsed to focus on the label. Especially useful if you have a lot of optional textfields.

editor3

All Fields
Here is how all currently available fields would work in this design. There is still some work to be done on polish and different states, but I think the concept is fine. Especially repeatable fields (which should exist), groups and repeatable groups profit a lot from clarity and space savings here. Not sure how to handle nested groups yet, but maybe that’s an edge case anyway. Also, there are two kinds of image fields here for different use cases (large and small preview).

Collections

collection1

Cards
Displaying your content in these cards is tricky, since all content is different. That’s why customization is key here. Developers could be able to decide which fields content is displayed on the card, and where.

collection2

Grid View
The same goes for the grid view. List view vs grid view again depends greatly on the content, so it would make a lot of sense to just have the layout (list/grid) as a setting in the collection config. Grid ist mainly good for images, so I feel like list should be the default.

collection-hover

Quick Add
Hover over a collection in the sidebar to quickly create a new entry.

Final Thoughts

Again, this is my opinionated stance on how I would like a modern CMS to work. There are a few further-out ideas here, but it should still be possible to salvage them for some UI directions.

I am providing the source .Sketch file for these designs for you to work with:
Netlify CMS.zip
(The .Sketch also includes some additional ideas and a first stab at translating this to mobile).

I know I’m brushing on a lot of different topics, but I still hope it will be a good start for a deeper discussion on the UI and UX of the CMS. I’m new to contributing to open source, and not much of a developer, so I’m eager to see how this goes and what I have missed. Cheers!

@erquhart

This comment has been minimized.

Copy link
Member

commented Jul 19, 2017

@ziburski this is awesome - I'll be having a close look soon. You should consider joining us for the bi-weekly cms planning meeting tomorrow, it's a community thing. More info here: https://github.com/netlify/netlify-cms/wiki

Related to #179 and #180.

@t1merickson

This comment has been minimized.

Copy link

commented Jul 19, 2017

@ziburski Just jumping in here quickly to note how fantastic this exploration is! Thanks as well for sharing your Sketch file. I want to spend some time to evaluate this further and further the concepts presented. 🙌🏼 Will follow up as soon as I can.

@verythorough

This comment has been minimized.

Copy link
Contributor

commented Jul 20, 2017

@ziburski I really love how this looks and works, and appreciate the thoroughness of thought.

I have one accessibility concern for the fields like booleans, where the fields names are very far away from their controls. It does make for a nicely balanced layout, but for a low-vision user who zooms in very close, it's difficult to associate labels with controls when both can't be seen on the screen at the same time.

@ziburski

This comment has been minimized.

Copy link
Collaborator Author

commented Jul 20, 2017

Great, I’m happy you like it and look forward to hearing further thoughts!

@verythorough That’s a good point! They are very far apart right now, even for users with good vision. A hover row highlight would help a little in that case. Would be interesting to experiment with a few different layouts here.

@liquidvisual

This comment has been minimized.

Copy link

commented Jul 21, 2017

@ziburski I love the simplicity of this, great work! I feel it's a much better solution to the current side-by-side editing approach - I feel that's too chaotic and overwhelming for the average user. I could easily imagine showing one of my clients this interface and have them just "get it", without needing extensive training.

@erquhart

This comment has been minimized.

Copy link
Member

commented Aug 21, 2017

From @ziburski in Gitter:

Is there any update on the planned UI revamp? I’d love to pitch in further to help with some ideas from #490

The latest is that @neutyp has begun digging into some of the UX intricacies of moving the CMS UI forward. The design in this issue has been a strong catalyst, but it was stated that the final UI may look different.

We definitely want to work through this improvement in the open. @ziburski to what extent are you able to contribute? e.g. collaborating on further design mockups, writing code, etc. Really loving what you've brought so far. Let us know!

@ziburski

This comment has been minimized.

Copy link
Collaborator Author

commented Aug 22, 2017

Sounds good! I can help with iterating on the mockups and any remaining design problems. A more open design process would be great I think, happy to collaborate. I’m not too comfortable writing production code here, but I can definitely do quick prototypes or tweaks if needed.

It would be great to hear from @neutyp what the thinking towards a realistic UI revamp is, and which features are being worked on right now.

@erquhart

This comment has been minimized.

Copy link
Member

commented Aug 22, 2017

@ziburski we're actually working on a brand new media library right now in #350 and haven't done any design or UX work (just using components as-is from React Toolbox). Would you be up for mocking a media library and how it would integrate with the vision you laid out above?

@neutyp also, can you provide a quick overview of the UX considerations discussed in last week's meeting for posterity/collaboration?

@ziburski

This comment has been minimized.

Copy link
Collaborator Author

commented Aug 22, 2017

@erquhart Yeah, I’ll give it a shot in the next few days.

@erquhart erquhart added this to the 1.0.0 milestone Sep 8, 2017

@dopry

This comment has been minimized.

Copy link
Contributor

commented Sep 11, 2017

@ziburski, I wanted to see if you'd made an progress. I'm poking around at some of the media stuff to support our editors. If you had some designs I could possibly lend a hand implementing them.

@erquhart erquhart added this to Sprint 3 (10/12 - 10/25) in Sprint Planning | Sprint 6 (11/23 - 12/6) Sep 13, 2017

@erquhart erquhart removed this from Sprint 3 (10/12 - 10/25) in Sprint Planning | Sprint 6 (11/23 - 12/6) Sep 13, 2017

@ziburski

This comment has been minimized.

Copy link
Collaborator Author

commented Sep 14, 2017

@dopry Thanks for the push!

Building on what was discussed in #350, here is what I’m thinking. The main use case for a media library is so that you can reuse your content without having to upload it again. Everything else, like uploading files directly to the library, viewing file details or deleting files, is secondary. For larger projects, we’ll at some point need file organisation features, but we can ignore that for now.

My mockups are below with some brief notes. As before, I have included some features that act as more of a long-term vision, but the basic design works without them. I would love to use it as a starting point for feedback and discussion.

01
Image Field
The image field at the bottom lets you choose between uploading and selecting from the library. Of course, drag and drop should also work.

02
Grid View Library
The media library opens in a popover to retain context and focus without taking over the whole screen. For image fields, the media library only shows images and uses a grid layout. The grid layout always sorts after date (since a grid doesn't make sense for a more data-driven search). More information for each image is shown on hover. You insert / pick an image just by clicking on it. On the bottom, you have search and possible filters (like filtering images/videos/documents, or only showing files used in the same collection). The focus is on the user content with as little foreign elements as possible.

03
Table View Library
You can go to table view with the switch in the bottom right. Table view is great if you need to look at the meta data or to use sorting. I think the combination of grid and table is important, since there are valid use cases for both. The default view should also be definable in the field options.

04
File Actions
In both views, click on the three dots to get file actions. You can use (insert in file field), view (open in new tab), view past uses (starts a search in new tab) and delete (might require more UI). This sort of menu could also be used for other option menus, like in image fields.

05
Standalone Grid View Library
Outside of content editing, you can get to the media library through the sidebar. The UI is very similar and again focused on the content, just this time with the option to upload content. Uploading content should only be possible in the standalone media library, to avoid clutter and confusion.

06
Standalone Table View Library
Search is also included here, although I’m not quite happy with having two search bars so close to each other. Might be worth to revisit if searching is ever worked on more.

08
Uploading
I think upload progress should be shown within the grid / table view, but I guess that also depends on technical constraints. I have included a similar UI for the grid view in the Sketch file.

07
Bonus: Reworked Field Layout
Aside from the media library, I also reworked all the content fields a little to make them easier to scan and use. Thanks again for the feedback, @verythorough!

Here is the .sketch file. It’s a little messy and I removed the images to save file size, but I hope it does the job: netlifycms-medialibrary-ui.sketch.zip

Again, I would be grateful to hear your thoughts. And I’m happy to assist with iteration and implementation, especially if any design problems come up along the way.

Cheers! :)

@indysigner

This comment has been minimized.

Copy link

commented Sep 14, 2017

Kudos to such a detailed work on the mockups and thinking through what's needed when. I do also agree on the issue of showing two search input fields at the same time: the main search input should not be displayed as long as the focus is on Media Library, I think.

I think the combination of grid and table is important, since there are valid use cases for both. The default view should also be definable in the field options.

Yes, fully agreed!

@dopry

This comment has been minimized.

Copy link
Contributor

commented Sep 14, 2017

@ziburski These look awesome.

Thank you for all the effort you've put into this. No oversights in the UX really jump out to me. WRT the search form it would be nice to have one search to rule them in non-modal contexts... ie) re-use the global search form and apply it locally, so users always go to the same location for search in non-modal contexts.

Have you thought at all about the inline image use cases? Our editors like to have a fair amount of layout control within their blog posts and pages, so we tend to use more inline images instead of fields.

Also 3rd party image/media hosting services, cloudinary etc. Have you thought about hoe they get integrated in the media library or if they should?

@Benaiah

This comment has been minimized.

Copy link
Contributor

commented Sep 14, 2017

@ziburski that looks fantastic! I love the thought and detail you've put into these mockups.

@ChrBach

This comment has been minimized.

Copy link

commented Sep 14, 2017

@ziburski Great work.

@ziburski

This comment has been minimized.

Copy link
Collaborator Author

commented Sep 14, 2017

the main search input should not be displayed as long as the focus is on Media Library, I think.

WRT the search form it would be nice to have one search to rule them in non-modal contexts... ie) re-use the global search form and apply it locally, so users always go to the same location for search in non-modal contexts.

@indysigner @dopry Interesting ideas. I wonder what the expectation and use case for the universal search is.

If it’s more of a quick "go to" bar, it should always search everything and probably just show the results in a simple dropdown. If it’s an extensive way to look through your content and media database, we need a more elaborate UI for selecting what you want to search anyway. Maybe both can be combined.

So I think we have to decide on what the universal search is for to see how that impacts the media library.

Have you thought at all about the inline image use cases? Our editors like to have a fair amount of layout control within their blog posts and pages, so we tend to use more inline images instead of fields.

I didn’t really work on that, but this UI should also work for inline images. There is a mockup for the Markdown editor in the first post, which could easily have a button to bring up the library popover. After inserting an image, it could look similar to the large image field in the mockup.

Also 3rd party image/media hosting services, cloudinary etc. Have you thought about hoe they get integrated in the media library or if they should?

No, I didn’t consider that. Honestly, I’m not very familiar with the modern publishing workflows involving those services. Are they just different sources to put your images, or is there more involved? For sources, you could probably add a filter dropdown but show all by default?

@t1merickson

This comment has been minimized.

Copy link

commented Sep 14, 2017

I would strongly hesitate on any kind of global search. Very hard to discern what a user would expect to search for with a global search and hard to deliver on their promises. Better to have search located at the top of certain lists where it would be obvious what that search would query against

@dopry

This comment has been minimized.

Copy link
Contributor

commented Sep 14, 2017

@ziburski, @neutyp, re: global search. I would hesitate on truly global search as well. I tend to design where the search box is positioned consistently in the same page, but primarily serves to filter the current view context. Whether it's at the top of the 'page' or at the top of the 'table' the positioning should be consistent through out the UX.

@ziburski, re: inline image editing. I see the controls, but I don't see what an actual inline image looks like in the editor. It would be nice to see how it's visually implement in the wysiwyg view. I know it's not media library specific but I think it is an important factor in the overall media experience.

@ziburski, re: 3rd party media hosting. This is honestly a huge can of worms. I've dealt with it originally in drupal, and now in my SPA projects. Different services offer different functionality and interfaces. A service like cloudinary provides a whole suite of features and client side tools you can use, as does filestack. When you try to build a UX to unify them you normally have to build for the least common denominator feature suite and lose the use of the components they provide. My gut says they each deserve their editor 'widget', but I think offering a unified search may be a real possibility. I think a good starting point might be bouncing back to #432 talk more about what services people are interested in and take a close look at what they offer.

@erquhart

This comment has been minimized.

Copy link
Member

commented Sep 15, 2017

Contextual search is definitely the way to go, especially in the near-term.

Regarding third party asset storage, that is something we'll need to support post-1.0, but we'll be abstracting away the differences between them and offering a consistent experience in the UI across providers. Worst case, perhaps some providers don't have certain features in the CMS if the API doesn't support it.

Fantastic work @ziburski!

@ziburski

This comment has been minimized.

Copy link
Collaborator Author

commented Sep 21, 2017

I would strongly hesitate on any kind of global search. Very hard to discern what a user would expect to search for with a global search and hard to deliver on their promises. Better to have search located at the top of certain lists where it would be obvious what that search would query against

That actually makes a lot of sense. I had kind of taken global search as a given, but contextual search seems a lot more useful. So I guess just remove the search from the header and keep it like this?

search

I see the controls, but I don't see what an actual inline image looks like in the editor. It would be nice to see how it's visually implement in the wysiwyg view.

I would just do it like this for normal (full-size) images. You get the same controls from the image field on hover.

inlineimage
inlineimage-hover

Regarding third party asset storage, that is something we'll need to support post-1.0, but we'll be abstracting away the differences between them and offering a consistent experience in the UI across providers. Worst case, perhaps some providers don't have certain features in the CMS if the API doesn't support it.

Sounds good. I think a media library is something that you can overload with features very easily, since there are so many different workflows and use cases. For Netlify CMS, keeping the basics very simple and not tailored to specific services seems like a good idea.

If anyone wants to work further on this, let me know and I’m happy to talk things through.

@erquhart

This comment has been minimized.

Copy link
Member

commented Oct 13, 2017

We're ready to start implementing! I believe we'll be handling the implementation in a separate issue that's more focused, and I'll link that here soon.

For now, here's the public prototype link (which accepts comments and annotations) from @neutyp, based on @ziburski's designs: https://marvelapp.com/6ggbi1e/screen/33390720

@erquhart erquhart removed this from Ready for Assignment in Sprint Planning | Sprint 6 (11/23 - 12/6) Oct 25, 2017

@erquhart erquhart removed this from the 1.0.0 milestone Oct 25, 2017

@erquhart erquhart referenced this issue Oct 25, 2017
@erquhart

This comment has been minimized.

Copy link
Member

commented Oct 25, 2017

Hey @ziburski, we're starting to think about the redesign of the editorial workflow, which is basically a kanban board with three columns for the Draft, In Progress, and Ready for Review statuses of unpublished entries. Would you be interested in providing some input on how that might look?

cc/ @neutyp

@ziburski

This comment has been minimized.

Copy link
Collaborator Author

commented Oct 29, 2017

Hi @erquhart. I didn’t include the editorial workflow in my mockups because I don’t feel I can contribute much there. I’m not very familiar with how editorial teams work and would need to do a lot of research to figure out what it’s all about. You and the team seems to have a very clear idea already of what you want to do there.

That said, a kanban board sounds like a great fit for the current card-based design direction. It will be interesting to see if we can design cards for the different content types that work across layouts and use cases.

And I wonder if the editorial workflow really needs to be a dedicated section. Maybe it would be easier to approach it as another way to view my content? We could have list, grid and kanban. That changes the story around the feature quite a bit though.

@t1merickson

This comment has been minimized.

Copy link

commented Oct 29, 2017

@ziburski I remember considering the same, eg. list, grid, kanban view. The problem, as I recall, is that not all posts/cards have editorial workflow statuses attached to them; or vice versa something to that affect? eg. users would see different sets of things in each view.

@ziburski

This comment has been minimized.

Copy link
Collaborator Author

commented Oct 29, 2017

Hmm, it’s bad if you can’t find your content no matter how it’s implemented. So what if you just had an “Unassigned” column for posts without a state? That would let you drag-and-drop sort those, too.

The bigger picture with having it as just another view would be that kanban might become an option that can be used for other multiple-choice fields as well. Maybe there is a use in having interactive kanban boards for your authors, categories, layout options, etc.?

@t1merickson

This comment has been minimized.

Copy link

commented Oct 29, 2017

I was just thinking that as well, actually. It's worth reconsidering and getting further input from the team. I'll being it up :)

@erquhart

This comment has been minimized.

Copy link
Member

commented Dec 8, 2017

Two things here that I'd still like to discuss:

  • The tiny preview concept, which takes us from the current "split" into simply having a standalone editor with an expandable preview off to the side
  • Kanban-as-a-view (or maybe getting rid of kanban altogether)

Can anyone think of anything else? We should get a list and split them out into separate issues so we can close this biggie.

cc/ @neutyp @ziburski

@t1merickson

This comment has been minimized.

Copy link

commented Dec 17, 2017

There are a few of @ziburski's great concepts I'd like to iterate on towards 2.0 — 1.0 as we know, was paired back to reflect the functionality we already had. but let's push the boundary for 2.0 where appropriate. The two you note are on the list, and I'll make individual issues for other ideas

@erquhart

This comment has been minimized.

Copy link
Member

commented May 30, 2018

@ziburski so I know it's been quite a while since you looked at your concepts above, but I've been eyeing them increasingly as of late, specifically your vision for the control panel itself. We're going to start having community created control widgets, and your design "gets out of the way" so those widgets aren't subject to much design constraint.

One detail that I'd like some input on if you can: how would you envision nested fields? Sometimes fields are nested multiple levels deep, and our current interface produces layers of boxes that crowd the panel, curious how we could improve on that with your design.

@ziburski

This comment has been minimized.

Copy link
Collaborator Author

commented May 30, 2018

Hey @erquhart! Glad to hear my designs still provide some inspiration. :)

One detail that I'd like some input on if you can: how would you envision nested fields? Sometimes fields are nested multiple levels deep, and our current interface produces layers of boxes that crowd the panel, curious how we could improve on that with your design.

Yep, I remember having a hard time with nested fields as well. Not sure if there is a great solution.

Generally, my thinking was that the most common / important use case is probably nesting just one level down. So I worked that into the mockups, with the image box fields.

For deeper nesting, maybe a modal popup is the way to go. Otherwise, it gets really messy when you show 5 levels on screen, and it’s often more confusing than helpful. So separating the levels in the hierarchy and drilling down one-by-one might work better.

Also, maybe Netlify CMS doesn’t need to support endless nesting. Are there use cases where having five, four, or even three levels are really the best way to structure your content?

@t1merickson

This comment has been minimized.

Copy link

commented May 30, 2018

Hey @erquhart and @ziburski :)

Shawn, I'm assuming when you say 'control panel' you mean the editor experience? Or at least an interface that uses the same concepts of nesting?

Back in the days of the 1.0 launch, I had originally hoped to push for an iteration of Lennart's great 'mono level' visualization of widgets in the editor. Specifically the idea that widgets don't need to be nested by reducing their pixel width.

My hope was a version that borrowed a lot from what the program Ableton Live has proven can be successful. Here's a walkthrough of what I mean. It's worth the 5 minutes: http://share.neutyp.com/2N2P3p0P420Q

@erquhart

This comment has been minimized.

Copy link
Member

commented May 30, 2018

@ziburski ah, didn't even notice the image box field had children, thanks for pointing that out.

@neutyp great recording, thanks for that! It's a pretty compelling approach for infinitely nesting the UI, seems like a great general direction to take this! My only concern would be showing a complex hierarchy of collapsed fields all at once and only clarifying relationship with focus styles, but I think improvements are possible there.

@erquhart

This comment has been minimized.

Copy link
Member

commented Jun 6, 2018

@neutyp @ziburski I started considering how to repackage the core strength of Ableton's nesting while providing clear hierarchy information at all times, and I want to run a potential solution by you.

What if we did the always-full-width thing that Ableton does, but instead of collapsing each parent into a full width bar, we collapsed it into a breadcrumb? We could provide the breadcrumbs in a bar for each top level parent, and they could wrap within the bar when necessary. This way we maintain infinite full width children but hierarchy is always obvious.

Thoughts?

@t1merickson

This comment has been minimized.

Copy link

commented Jun 6, 2018

At first blush this sounds compelling, but I'll admit I'm having trouble fully visualizing it. Shawn if you have a chance to do even a 'bad' mockup it would awesome to see and I'd be happy to help flesh it out further should any details need consideration

@erquhart

This comment has been minimized.

Copy link
Member

commented Jun 11, 2018

It will be very bad, I promise. I'll give it a swing when I get some time.

@t1merickson

This comment has been minimized.

Copy link

commented Jun 11, 2018

@erquhart

This comment has been minimized.

Copy link
Member

commented Jun 12, 2018

image

@ptim

This comment has been minimized.

Copy link

commented Jun 13, 2018

I really like the breadcrumb approach, and I wonder if it might be complemented by some extra contextual navigation... I notice that there's a fair amount of space available in the left column of the editor, and I'd be interested to see how a document outline (ala Google Docs) might work here.

For a quick example of what I mean, consider the Chrome extension Headings Map. Here's a screencast demonstrating navigating around a collapsable, hierarchical navigation: https://memelab.wistia.com/medias/lla1iihclt

2018-06-13 20-43-03 - getting better with graphql kalin chernev

Add a bit of colour coding, and you get the best of all worlds: brevity and clarity, and without losing any width!

If you wanted that space in the left column to be re-usable, another useful pattern could be hover/pin: only show the outline whilst hovering over an icon, or toggle a "pin" to force it to remain visible. In the absence of the outline, panel hierarchy would be indicated by the breadcrumbs suggested by @erquhart (see: chrome devtools, which use hovers to effectively indicate boundaries in the hierarchy).

2018-06-13 20-58-44 - interplay project

Anyhoo, love your work, people.. many thanks 👍

@angeloashmore

This comment has been minimized.

Copy link

commented Aug 17, 2018

Hi everyone, has there been any design progress since this thread? I don't see anything in GitHub Issues, but just checking if the main design has been updated elsewhere.

I'd love to help improve the CMS UI. It's not bad as-is, but I think there are some definite confusion points for non-tech users, namely the nesting of list items.

@erquhart

This comment has been minimized.

Copy link
Member

commented Aug 24, 2018

@angeloashmore that'd be fantastic, we're very open to design contributions. Can you open an issue outlining a specific problem you'd like to tackle? We'll probably close this issue up soon, too broad and longstanding.

@renestalder

This comment has been minimized.

Copy link
Contributor

commented Jan 17, 2019

I also would like to see contributions to this. I can also help if someone wants to approach this together. Also the proposal in this thread is already awesome. It could have some contrast improvements for accessibility reasons but overall, this is great work.

I'd say the functional design is very good so far with the current design of Netlify CMS. But what I think what has most potential for improvement is the visual design of the form fields. Especially when you start using flexible fields, nesting and groups that can be collapsed, it's very difficult to use at the moment for new users, based on my experience.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
You can’t perform that action at this time.