Solidus: Create two form layouts for the Solidus admin

[Mandily]

Forms are a bit of a mishmash right now, and with the recent implementation of Bootstrap into the admin, there's a great opportunity to clean up the forms while moving them over to Bootstrap.

Once we get this information a little more solid, we'll put it in the style guide.

I'm proposing 2 form layouts: Helpful and Sidebar.

• The layouts aren't as simple as full width and max-width. We'll need to combine both components on most pages simply because there's a search form on so many table pages.
• Left aligned to the left side nav (same as the full width layouts) so that the tabs and main content area stay consistent.
• Don't use empty sidebar containers in a page just for the sake of it. (see the option types wireframe.)

_Helpful layout_

• This one has a main column on the left and secondary column on the right for information to describe what happens in each section of the form. I expect this one will be used more often than the other.
• Use this for forms that would benefit from a little extra explanation of how to use the section.
• Use this for forms that have minimal fields and have many equal priority items in them.
• Try to use this form layout first before using the next one.

_Sidebar layout_

• This one has a main column on the left and secondary column on the right for form things.
• Use this for dense, self explanatory forms that have secondary information to them like timing on a product or promotion.
  

I suspect once we start building these out, there will be some things I haven't touched on here, but here's my first crack at how forms should be built.

Labels

• Left align field labels and do not include colons.
• Display field labels above text fields, text boxes and drop downs, and to the right of checkboxes and radio buttons.
• Labels should be in sentence casing (first letter of the first word is uppercase, the rest are lowercase)

• Do not add underlines to labels

  Inputs

• Layout inputs in a logical order. Try to group similar input types to make it easier to fill out.

• Display a downwards pointing arrow in all dropdown fields, and Select2 dropdown fields.
• Use radio buttons instead of drop downs for small finite lists and toggles.
• Stack radio buttons and checkboxes. Use more space between them if they aren't a group of similar items.
• Size a text field or a text box so that it's indicative of how much text goes inside of it.
• Display date range fields side by side (and shorter than other text field types).
• Mark mandatory fields with an *.
• Validate mandatory fields client-side to make sure content is present.
• Display a calendar icon in the right of date picker fields. When either the icon or the field is clicked, a calendar picker should appear.

• Include a way for users to access a plain text version of their password in a password field.

  Actions

• Display form buttons at the bottom of the group, after the form inputs.

• Primary action buttons and icons should be one style, secondary actions a second style, and destroy actions a third style. See #1276 for more info.
• Display search buttons and upload image buttons attached to the left side of the text field they accompany.

• Allow users to submit a search form with the enter key when the cursor is inside of the search field.

  Help text

• Include a "i" icon and tooltip beside form labels with supplementary information.

• Display input restrictions below form labels and above inputs (example: max 100 characters or specific formats).
• Don't display placeholder text inside text fields and boxes.
• Use helpful text like 'select a taxon' in dropdowns that don't have anything selected.

• Display a progress/loading message or graphic if it takes a long time to submit a form.

  Errors and success

• Highlight the fields that have caused an error and display helpful error message that will help the user correct mistakes.

• Display a success message when the user successfully submits a form

  Inline validation

• Display field labels in red when there is an error in their respective field.

• Outline inputs in red when there is an error inside.

• Display validation text in red and below the input it is referring to. It should be closer to that input than anything else on the page.

  Layout

• Group inputs associated with one function within a background container.

• Display form fields side by side only if they're reasonably related. Don't do it just to fill the space.

_Input widths_
This is outdated and needs to be updated to accommodate different content types within form fields and also what happens in a responsive environment. This will be added to the style guide.

| Input | 1/3 sized columns | 2/3 sized columns |
| --- | --- | --- |
| text field - 'normal' | full width | full, half, or quarter width |
| text field - date picker | full width | half width |
| text field - multi selects | full width | full width |
| 2 text fields - date range | full width | full width |
| text box | full width | full width |
| drop down ('regular' and select2) | full width | full, half, or quarter width |
| checkbox - single | full width | full width |
| checkbox - list | full width | full width |
| radio button - list | full width | full width |

Form in tables

• Display all table functions outside the table.
• Display form submits outside of the table at the bottom.

Please feel free to comment if you have anything you disagree with, want clarification on, or want to add.

[isaacfreeman]

Agree completely on all the form design guidelines.

The layouts also look good, but I'm a bit unclear on when we'd use the Helpful Layout and when we'd used the Sidebar Layout. Could we get a couple of examples for each of where they'd be used?

[tvdeyen]

Great work and fully acknowledged. 👍

For client side validation we should use something like https://github.com/DavyJonesLocker/client_side_validations to avoid the need of implementing them twice.

[kennyadsl]

@Mandily great work! I agree with @isaacfreeman on the need of a couple of real example at this point, just to make sure these options are valid and to start defining a "guideline" about how to choose which form layout is better for a specific form.

[Kingdutch]

This looks great!

Could you give some feedback on what it would look like on mobile devises? e.g. Will the help text for the helpful layout simply be shown before the form or will it be hidden completely?

[Mandily]

Good call on the examples. I'm working through a few different page types myself to double check all those guidelines up there satisfy our real life examples. I'll post a few wireframes back to this thread when I'm done.

As for the mobile view - I don't have a good handle on how many people actually use solidus on tablets and phones, so until I understand their motivations a little better, I'd like to keep as much as possible responsive and in view. So the title and help text would be shown before the form group, and in the sidebar model, the sidebar information would be shown after the main content panel.

[Mandily]

I've learned so much in the last 24 hours trying to build wireframes with all of the ideas above.

Here's what I've learned:

• To keep the tabs in the same space, we need to left align the max-width form layouts. Sometimes a layout is all table and other times it's all form. If we centered the from layouts, the tabs would be jumping around at the top and would be a pain to switch quickly back and forth.
• The layouts aren't as simple as full width and max-width. We'll need to combine both components on most pages simply because there's a search form on so many table pages.
• Similar to keeping tabs in the same place, we should keep the primary and secondary columns in the same layout too. So the wider content area is on the left and the thinner on the right in both the helpful and sidebar form layouts.
• We shouldn't stick an empty sidebar container in a page just for the sake of it. (see the option types wireframe.)
• We're going to need smaller width fields for things that are only a couple of characters long or else it just looks funny and takes up too much space. Keeping them smaller also helps them stay grouped, especially for things like shipping measurements.
• Titles should be a part of the form group they're attached to and not in the sidebar area. It helps the user know what they're looking at when the title is close to the information it's labelling.

Some things I'm still working out:

• I'm not convinced the buttons are best only at the top in a sticky header.
• I'm not sure if the search form should be the same width as the main content area of the form, or slightly larger in a width that would reflect both the main and secondary content area. It would be nice to be able to use the same component, but I also like the idea of maximizing the space above a table, and I've heard some of our stores at Stembolt do customize those search areas.
• Whether we should move the edit/delete/clone icons into the tables. If we used only horizontal lines for the tables, I think it would be easier to follow across if the icons were in the table. I haven't looked into the technical feasibility of this though or space considerations.

Other things that go hand in hand with this, but aren't covered in this issue:

• collapsible search with one 'quick search' field revealed
• combining the new and edit functions into the main page

I'll update the #1153 Tracking Bootstrap Implementation to do list with what layout/components should be applied to each, but for now, here's a few wireframes I've been working on. Let me know if there's any tricky pages in the admin that you think would be beneficial to work out.

Product listing

Product details

New variant

Option types

Orders list

Stock locations

I realize this is quite a large comment, but I wanted to keep you updated of where this is at. Feel free to give all the feedback you can, and if you have clients that might be able to user test this, let me know too. If anything isn't clear, or you see a different way I could present this information that would make more sense for you, let me know that too.

[Kingdutch]

Having the buttons at the top actually tripped me up a few times. I believe most applications have their buttons after the content (of course both is possible). I usually look at the state of a page then look to the bottom right to figure out what I can do. I actually missed some of the Solidus buttons in the top right on my first run through.

[Mandily]

I can argue (and did argue in my SolidusConf presentation) for buttons that are always in the same spot on the page (sticky header) and therefore always available and findable for the user. I can also argue for the other side where the buttons should be within easy reach and context of the form or information they're related to. It's really a good thing to do user testing on, and I don't have any of those at the moment, so I'm still pondering it.

[isaacfreeman]

User testing FTW.

[Mandily]

Just a note that I've updated the first message in this thread to reflect some of the changes that were mentioned in the "updates" section. It's a bit hard to maintain this kind of stuff in GitHub, so I'm going to make the jump to adding these notes to the style guide. Will post back when it's been updated. Thanks everybody for your feedback thus far!

[jarednorman]

This is pretty stale (it deals with the admin design prior to the recent update to it) and unfortunately for us @Mandily is no longer active in the community. I suggest we close this.