[META] [UX] Field UI redesign.

[clickbox]

The field UI could use some love. Several of these things we can do right away, but a complete overhaul may need to wait until Backdrop 2.x. Below are some ideas for improvement:

• [x] #1183 | Skip the field settings step when adding a new field if there are no settings (field settings before entity-bundle settings)
• [ ] #1441 | [UX] Move the "Title field label" setting of content types to the "Manage fields" tab (as a title field setting).
• [ ] Use dialogs where helpful
• [ ] #1438 | [UX] Add a "Add new style" link next to the "Preview image style" drop-down menu in the image field settings form.
• [ ] #1442 | [UX] Do not offer an option for a widget when there is only one option to be selected.
• [ ] #1443 | [UX] Allow the label of fields to be edited straight from the "Manage fields" and "Comment fields" tab.
• [ ] #4898 | Move 'Add new/existing field' functionality to a new page via an action link
• [ ] #5292 | [UX] Provide users with a visual way to understand and build content types (a.k.a.: Dream Fields in core)

Related issues on d.o:

• Redesign the Field UI
• Redesign Field UI hook architecture
• Title field label on manage fields
• Edit the body and teaser as fields
• Redesign the manage display screen
• Adding a field should be a separate step
• Model Field UI off form builder
• Provide users with a visual way to understand and build content types (dream fields) as an experimental module.

[klonos]

Do we have any rough ideas as to what needs to be done? Any previous mockups, discussions or d.org initiative perhaps?

[klonos]

...also wanted to note that since this will touch the UI that two of my favorite modules (that are fairly popular) rely on, we should take them into account when designing the new UI. I'm talking about Field Group and Field Collection (or Multifield alternatively).

Related #647

[clickbox]

I made this issue based on feedback from issue #744 "Make field settings visually clearer, no indication that you’re a layer deeper."

I think the rough idea is to design a UI without the constraints previously in place set by cck tools. Ideally there should be less "pogo sticking" or change the appearance in a way that makes menu link levels more obvious.

Thru collaboration with @dariusgarza who has been working hard to update the style guide I think this will be an obtainable goal. @klonos Taking those two modules into consideration seems like a great idea to me unless anyone knows otherwise. I love the image for Multifield's module page...

[clickbox]

I'm not certain what d.org initiative means. If you think it would help, could you please explain?

[klonos]

I love the image for Multifield's module page.

Me too. Milla Jovovich ++ !!!

...ooh, you meant the actual screenshot from the module admin page. Now I get it :stuck_out_tongue:

[docwilmot]

What would be great would be an add more button on the manage fields page, so you could build all your fields at once. Set defaults for all fields, and then a notification for fields which require further manual settings like selects. That would be cool.

[jenlampton]

I was fairly involved in the issues for redesigning the Field UI for Drupal. Let me gather some links and add them into the first post in this thread.

[clickbox]

I should had some descriptions for more context but this is a wireframe of an idea I have for the field ui. My goal is to achieve a more graphical approach to editing and organizing fields.

My hypothesis is that to consolidate "manage display" with "field settings" into an easy to use GUI would simplify creating and managing content types. I like the idea of drag & drop icons to represent field types and source order while being clickable to access the individual field settings.

[jenlampton]

Keep in mind that we also have the Layouts UI that can be used in place of "Manage display" long term if what we end up wanting is drag-and-drop that includes laying out content on the page. Field configuration (Manage fields) could become the same pattern as adding and configuring a block.

edit: New core issue created for this: https://github.com/backdrop/backdrop-issues/issues/6039

[quicksketch]

Regarding the original post:

remove the extra step (field settings before entity-bundle settings)

As an easy fix, I'm working on skipping this step if there aren't any field settings in the first place, as is the case for Link and Email fields. https://github.com/backdrop/backdrop-issues/issues/1183

[klonos]

Regarding the original post:

remove the extra step (field settings before entity-bundle settings)

Yeah, I changed that task to point to #1183 and renamed it too. ...before you made that comment.

[wesruv]

Here's a pitch for a redesign of the field creation process. I liked the direction @clickbox was headed and I also thought of 'IFTTT' (which I like to steal from for complicated multi step forms).

I'm going for more of a wireframe than 'finished design', so don't take aesthetic touches too seriously.

Specific requirements from what I was thinking below the mocks.

Let me know what you all think :smile:

Step 1, Data Type

Step 2, Editor Interface

Step 3, Field Options

Functionality requirements that I'm thinking:

• The Manage Fields page would not have the few 'starter fields' that send the user to the second step of this process, instead there'd be a 'Add a field' button that would send them to this page.
• Doesn't create field until all 3 steps are done (big blue button at the bottom)
• 'Hovering over' or 'selecting' a Data Type will reveal the appropriate Editor Interface on the right
• I'm simplifying Data Type options from what's in the current form, as a non-database person, a lot of them seem redundant in the interface. I think we can decide how to specifically store the data depending on 'Editor Interface' or 'Field Options', which may require that we have a few extra field options in some cases. For example(s):
  • For Text: short and long text could be decided by what Editor Interface they chose
  • For Number: Integer, Float or Decimal could be decided by a Field option
  • File, Image, etc.: Could have a Editor Interface option for 'Content Image' vs 'Downloadable File', which would provide slightly different companion fields (alt text, vs link text, or whatever)
  • Any List option (List Number, List Text, List Float) could be decided by Data Type and Editor Interface
  • Entity Reference could have a field option for Entity Type & Bundle, no need for Node Ref, Term Ref, etc etc options
• The user can go back and edit previous choices, but they might get a warning dialog if that means they'd lose data they'd entered
  • e.g. Radio Machine/Human name data would be lost if they decided to switch to a link field, but it should not be lost if they decide to go from radio to a checkbox Editor Interface)
• The radio button options would dynamically populate the Default value section as they leave the text field, but 'Default Value form' should have default values if the user hasn't populated anything yet. I chose 'Label' and 'Value'
• In case of form progress being lost, it'd be nice if we stored the form values in the user's session as they're entered, and wipe those values when if the field gets created. Key/Value local storage should be available for most of our site builder's browsers, and if they don't have that we could forgo that feature, or look into some crazy pants fallback.
• Selecting any option would scroll you down to the next step (if there's any scrolling that needs to happen)

[docwilmot]

Wow, wow. Nice! There was an issue somewhere to change the order of creating fields by starting with offering what "Editor Interface" the user wanted first then allowing to choose the data type based on that. But this actually probably makes more sense as it allows better categorization. Either way it looks fantastic! Are you working on the code as well or just the design concept?

[clickbox]

This is great! Simplifying Data Type options seems like it should be a high priority.

[wesruv]

@docwilmot I can definitely work on the interface, but wanted to run the workflow/idea/design through it's paces first.

I can do the front-end part, but some of the JS and mapping user choices to config might be a bit steep for me. Not that I couldn't do it, but I'd need a lot of help.

Tag teaming this would be fun too :no_mouth: stares at everyone else

[Graham-72]

I too like the look of this.

[docwilmot]

Tag teaming this would be fun too :no_mouth: stares at everyone else

This would be above my level but I'll be happy to help any way I can. One thought though that this design idea doesn't address (and even pushes further back), is the feature request that the UI allow multiple fields to be added at once.

[serundeputy]

does this seem like the rantings of a crazy person or does this make sense to anybody else?

I think it would be a big undertaking, but I think it could work: https://docs.google.com/document/d/1aJdtyybC-SxOdgLXXJaV4WqlNM_ZU4W9wnDxLLEZWaU/edit?usp=sharing

[wesruv]

@docwilmot cool! I'd like to understand the use case to create a bunch of fields at once. It seems a bit goofy the way I'm imagining it.

If you or anyone has instances where this would have come in handy, I'd like to understand what was at play.

@serundeputy I love it!

So if I understand it right, and I was laying out an article node's full view mode, I could have:

• article header block with title, date and author name
• article body block with body field and featured image
• article footer block with author name, twitter handle and author image

And plop those in some regions in the layout.

I was thinking similarly to you (not nearly as good as this idea though). It seems like we should have an "entity layout" that is similar to our current "page layout" interface. We could score some good UX points if we used a similar UI and metaphors for entity layout.

To pick nits on the interaction, I'm thinking if you drag a field into a region that doesn't have a field block, it auto-creates a block for you, and you can decide to add other fields to it or not.

Each block could also have settings like our current block system in Backdrop of wrapper tag, classes, etc.

[wesruv]

One thing that got me thinking about...

The distinction between page and node has frustrated me a lot in the past. For instance, I'd want a view block in a node's "full" view node presentation, but couldn't figure out a good way of doing it for quite a while.

Nowadays I know that I can invoke a view with code in the preprocessor to shove into the template somewhat easily, but it's a bit obtuse and feels like something we should address with a UI in Backdrop.

[docwilmot]

If you or anyone has instances where this would have come in handy, I'd like to understand what was at play.

Just channeling this: https://github.com/backdrop/backdrop-issues/issues/292

I thought it was a good idea. An "Add more" button on the current manage fields form. you fill all the field names, data types etc, at once, and either have smart defaults, and save all, or a views-like sequential settings screen: settings for field 1 pop up, save it, the settings for field 2 load in same dialog, save, next, etc.

[jenlampton]

smart defaults

yes please, fewer steps up front++

[wesruv]

Here's some design refinement based on Nate and Jen's feedback on my Add Field form.

So I'm trying to integrate ideas from webform.com, wufoo.com and some other sources I'm probably not remembering right now. Trying to simplify the user interface further into groups that more people can easily understand.

Step 1:

More like a Denny's menu (big pictures so you can point at what you want, even when hungover), this first step makes smart defaults more feasible than my other design's first step.

Step 2:

You can see I selected a Text field, and there are two things we need to know before we can create a field, the field name and what widget they want.

At this point you could "Create Field" and go back to the Manage Field screen, or you could hit the other button and edit the other options that people don't usually change.

Other field types may require more things on this step. E.g. Multiple Choice would require the options that could be chosen from.

For Label, Field Name might be a better label there, but once they start entering it the machine name will get auto populated and can be edited if they click on it

Step 3:

Check out Step 2 being all filled out, machine name is grayed out because the field has been created.

For a text field there's only a couple other things that can be customized, though different fields types/widgets could have more/different options.

For the Default value bit of the form we have the field label populated correctly, and it'd be cool to have the field description update when the field Help text field looses focus.

[wesruv]

Oops... in the "Pick a Widget" section the first option should not have the text "Option 1"... that was a Photoshop hacking artifact that I forgot to remove.

[wesruv]

@quicksketch @jenlampton any thoughts? Warmer, colder?

[klonos]

@wesruv sorry for not commenting earlier. I meant to come back with a thorough(er) and more constructive response, but unfortunately I have no time. Let me then quickly say that definitely warmer. ...A LOT!!

I especially like the way you expose the field types by a visual representation rather than just a name that users might not be familiar with. I think that we should make a pattern out of it (we are already doing this with the layout selection screen and their icons).

Thank you!

[klonos]

...not so sure about the single-page thing though. Once the user has selected a field type, there is no reason to still show the whole list at the top. It seems more confusing and many options in one page might intimidate new users.

[klonos]

...how about after type selection we show a different page with "[field-type-name] field setup" as a title and a "select a different field type" link next to it? That page can have the main "Basic settings" section that holds only the minimum things required to set up the field and an "Advanced options" section that holds additional, optional settings (could be collapsed by default in order to keep the page clutter to a minimum).

[klonos]

...would also loose the bullets from the widget selection.

[klonos]

Made this a meta-issue and filed a few issues for things that were listed in the issue summary. Will file a few more...

[klonos]

...and a better title.

[docwilmot]

Once the user has selected a field type, there is no reason to still show the whole list at the top. ...would also lose the bullets from the widget selection.

agreed.

I had initial reservations because this doesnt allow for bulk adding fieelds. But this would be MUCH quicker than the current process, especially with the option to "create field" with default options, so it matters not as much

:+1: from me.

[wesruv]

Watched this Karen McGrane talk and it reminded me of our layouts/block/Field UI Redesign efforts. Highly recommend!

http://karenmcgrane.com/2012/09/04/adapting-ourselves-to-adaptive-content-video-slides-and-transcript-oh-my/

[edit] updated link to the above: https://karenmcgrane.com/talks/adapting-ourselves-to-adaptive-content ...and direct link to the video: https://vimeo.com/56705945

[klonos]

...close to a year later, I'd like to say that perhaps this should be targeted as the main new feature for 1.7.0.

I have not thought this through thoroughly yet, but now that we have seen the success of the Layout UI, I would like to propose the following:

• Add a new special-purpose layout in core for the node/%/edit path.
• Have the various regions of that layout be rendered inside the "Manage fields" tab of content types.
• Instead of "Add block" buttons, the regions of that layout (when rendered inside the "Manage fields" tab) would have "Add field" buttons.
• These buttons would be opening dialogs that have those beautiful, widget-image field type selectors designed by @wesruv back in December 2015.
• The dialogs would be acting as configuration wizards, pretty much how block configuration dialogs work.
• Instead of having the fields be rendered as dragable table rows as we have them currently, they will be added inside the various regions of that special layout, visually looking like blocks that can be dragged around.
• People can be cloning that special, default layout that we ship with core and adding visibility condition(s) for various content type(s) to it. That way, we will be allowing different layouts to be used for the "Manage fields" pages of various content types and thus also for the create/edit pages of these content types.
• Once we have #647 in core, we can have it so that these field-widget-blocks can be nested inside field-group-blocks that will have "Configure" buttons of their own, allowing users to render the fields contained within them as fieldsets, vertical tabs, accordions and what-have-you.

...essentially a visual form builder. Can you see the magic?! 😜

[klonos]

...I realize that this would mean that the way that the "Main page content" works would need to change and that is something fundamental, but as I said, it's just an idea:

I have not thought this through thoroughly yet...

[klonos]

I have added https://www.drupal.org/node/2539740 to the list of related d.org issues.

[Oct. 2021 edit] I've split my last couple of comments into a separate issue here: #5292