Forms Component review Governance & Standards Team, DCX 08.04

FormsComponent review

Governance & Standards Team, DCX08.04

2 Dell - Restricted - Confidential

What’s the debate?Where we are today?

Inline Labels are the current approved standard

What’s the issue?

Problems have been arising and concern over sub-optimal user experience in some instances.

• Concerns and less than optimal experience with prepopulated forms

• Accessibility concerns

• Technical concern? (area we are lacking input – purpose for meeting)


Forms standard

DCX Standard consideration:

• Labels will appear to the left of the field and right aligned to the form field especially in desktop and tablet

• Small screens adapt to a label above the field with reduced title size and padding and form input field will stretch the length of the screen (potential exceptions to be documented as needed)

• Inline labels have a place on short recognizable forms like search and sign in


Mobile optimization options

• Why not look into reducing the *Titles(s)* sizes,

• Reduce the *Titles(s)* padding

• Reduce the input field padding

• Maybe increase the inline text color and italicize the input placeholder text

• Ensure that input fields span the mobile width and not have any “short” input fields

• Could highlight the first field and walk/step the user through the form field by field


Rational for right-aligned vs inline

From a customer perspective, right-aligned labels are a simpler solution to be applied to the majority of use cases, so we should minimize dev impact and risk of using inline sooner rather than later

Pros:

• Saves space on the page (forms appear shorter than top aligned)

• Alignment to accessibility principles

• Good visual connection between labels and fields

• Simpler and reduced development effort (as compared to inline/under on page load)

• Assures usability in most use cases with no

customer blockers or workarounds

Cons:

• Localization presents a less than ideal experience in some countries (issue pertains to most form options) – we will ensure guidance to reduce risk

Dell - Restricted - Confidential

Back up


What we know

Shorter forms work best

• TnT test shows all recipes had a completion rate 3x better than the control (inline and right-aligned)

• All the test recipes had a higher sign-up rate than control confirming that a simplified form with only the mandatory fields is preferred by visitors

Accessibility is critical

Inline is not the simplest option for all use cases

Simplified development and maintenance is a must

• Dynamic options create complexity and require additional development support


Documentation and rules (overview)• Forms should use right-aligned labels (optimized labels above the field for mobile)

– Especially in desktop and tablet– Inline labels can be used sparingly in short recognizable form fields like search and sign in

• Shorter forms perform better– Minimize fields – only ask for required fields when possible or minimize form length to pertinent

info– Organize form fields into groups– Use progressive disclosure to hide optional fields or keep most relevant required into elevated

• Help users along– Provide help text to assist users– Prevent errors by offering default values– Provide useful errors and inline validation where possible

• In instances of Localization/translation resulting in a long label wrapping should be allowed

Schuette, Nicole

check error documentation


Final Actions• Standards team w/UX assistance to document final rules (Nicole)

• Forms update to be made in Sherpa (Clint)

• Communication to entire team (Nicole/Standards team)

• Ongoing projects should begin planning for implementation (ExDs)– Instant implementation is not expected but we should begin to strive for consistency – STP – we should talk about the impact and assess the best and most time appropriate adoption

plan (Andres/Nicole)


Sign-up Rate and conversion of new registrations*

• All the test recipes have a higher sign-up rate than Control confirming that a simplified form with only the mandatory fields is preferred by visitors

• Recipes with inline field labels have a higher sign-up rate

• Conversion for the visitors creating an account is the highest for recipe C, but note in all test recipes that we have 3x number of users who complete the registration.

* From TnT test #2808 CA DHS My Account Form, Inline Labels

Difference of 8% points is not significant enough when weighed with

the dev effort and unknown factors


Pros and Cons of Inline FormsPros:

• Dev change implications – inline already built in STP

• Shortens length of forms / pages, especially in smaller real estate devices

• Creates a “cleaner” experience

Cons:

• Usability: Lost context with pre-populated forms (i.e., customer number,

service tag)

• Accessibility; Lost context for people with learning disabilities


Alternate Option: Label above fieldPros: Cons:

Labels are visible even upon focus or being filled. Creates longer forms/pages


Alternate Option – Inline + external

http://codepen.io/aaronbarker/pen/tIprm

Need to consider label placement for right-to-left reading languages

Pros:

• Labels are visually consistent inside and outside of the form field.

Cons:

• Only works if you can move labels in a direction where they won’t end up inside another form field.

Prepopulated Field Data Label 3

Data Label 2

http://codepen.io/aaronbarker/pen/tIprm


Alternate Optionshttp://bradfrostweb.com/blog/post/float-label-pattern /

Pros:

• User keeps context–The main advantage of this pattern is that the user keeps the field’s context after they’ve focused and entered a value. This provides for a more accessible, less frustrating experience.

• Clean and scannable by default– allows for a clean inline label experience by default, and only becomes a little more cluttered once the user has filled things out.

Cons:

• Doesn’t provide room for both label and placeholder–Because the label is occupying the same space as the placeholder, there’s no room for additional hinting.

• Small Label–The label becomes small and possibly hard to read, but at the same time it’s not as big a deal. Once the user has interacted with the input, the label becomes a reference rather than an instruction.

• Potential for code– there’s the possibility of wrecking accessibility and semantics.

http://bradfrostweb.com/blog/post/float-label-pattern/

http://bradfrostweb.com/blog/post/float-label-pattern/


Decision time

Any further discussion points?

Decisons:

7/28/2014 – Bill & Andres research impact / dev view on inline labels and ability to make modifications as

necessary to solve current and future issues. Will continue with inline fields until it breaks.– Accessibility issues need to be solved (contrast, deciding to ignore learning disability for now) – Pre-populated fields –Above field.


Outline Exceptions and Usage

Exceptions

• What do we need to document or consider that may not align?– Search input box will always use inline label

Usage rules– Pre-populated fields –Above field.

Dell - Restricted - Confidential

Backup


In favor of external labels - Accessibility

• If the pre-populated text disappears when focus is set on the field, it can be difficult for some users to recall what information they are being asked to supply. Examples include screen reader or keyboard only users that may have tabbed through too quickly to absorb the information, or people with certain types of cognitive disabilities (such as those that struggle with short term memory).

• Even if the pre-populated values remain until the user clears them (backspace or highlight + delete), they can still cause confusion, particularly if that expected action is not clear or made explicit to the user.

• Further, when the user is presented with prepopulated info within forms it can be confusing without any context. This is especially true with customer number, service tag or a date if the number is not automatically meaningful then the context is needed for the user.


In favor of external labels – T&T research

A. Control

B. Mandatory fields C. Mandatory w benefits

D. Inline labels E. Inline labels w benefits


In favor of external labels – T&T researchTest: 2808 CA Home My Account Sign-up FormPeriod: 05-Jun-14 to 07-Jul-14

Recipes A. ControlB. Mandatory

fields onlyC. Mandatory

fields w Benefits D. Inline labelE. Inline labels

w BenefitsVisitors 371 277 259 283 253Visits 495 375 357 356 351Orders 37 33 41 38 32Revenue (K) $23.2 $22.3 $27.2 $17.6 $18.5

Visitor Conversion 9.97% 11.91% 15.83% 13.43% 12.65%% Lift 19.5% 58.7% 34.6% 26.8%Confidence 78% 98% 91% 85%

AOV $625.7 $675.5 $663.5 $464.1 $577.9% Lift 8.0% 6.0% -25.8% -7.6%Confidence 62% 60% 88% 62%

RPVr $62.4 $80.5 $105.0 $62.3 $73.1% Lift 29.0% 68.3% -0.1% 17.1%Confidence 77% 95% 50% 68%

RPV $46.8 $59.4 $76.2 $49.5 $52.7% Lift 27.1% 62.9% 5.9% 12.7%Confidence 76% 94% 57% 63%


In favor of inline labels UI sample Fangs screen reader emulator, rendering the above UI:


Usability thoughts

• “When there’s only 1-2 fields (for example a search field or perhaps a sign-in form) the user will rarely forget the context as the entry type is singular and frequently executed. However, as soon as there are more fields, different types of data is needed, or the fields are used infrequently, inline labels become problematic.”

-http://baymard.com/blog/mobile-forms-avoid-inline-labels

http://baymard.com/blog/simplifying-sign-in


In-line validation – eSupport recommendations to explore

• Above the password field, the parameters are clearly defined before user starts typing.

• As user types a password and meets a parameter, the labels receive a green check. Real-time feedback.

• After account creation, a contextual email button is presented (based on the users entry in the email field I’m assuming) so that the user can complete the verification process.

• The LARGE FONT SIZE for the form fields.

Inline field proposal7 / 28 / 2014Bill Harrison

Global Marketing Dell - Restricted - Confidential

Proposal for inline fields• Initial display:

Confidential25

Data Label 2 Data Label 3

• Prepopulated field:

Prepopulated Field Data Label 3

Data Label 2


Interaction, affecting display of labels in fields• Initial display:

Confidential26

Data Label 2

• On selection Data Label 2

• On keypress Blah blah blah bl


Code interaction, leveraging label positioning• Basic coding structure*:

Confidential27

<error><label> <input><div - contextual-help-label><div - contextual-help>

• Not prepopulated:


• Prepopulated: <error><label> <input><div - contextual-help-label><div - contextual-help>

Data Label 2

Prepopulated Field

Data Label 2

… and this state displays.… code interaction changes …

If this condition occurs …

* Invisible label tag is readable by screenreaders on apple.com

Label tag is still read before the input on screenreaders.


Inputs that include contextual help

Confidential28

• Not prepopulated:


• Prepopulated: <error><label> <input><div - contextual-help-label><div - contextual-help>

Data Label 2

Prepopulated Field

Data Label 2

Why we need this

Why we need this

• Error State: <error><label> <input><div - contextual-help-label><div - contextual-help>

Prepopulated Field

Data Label 2Why we need this

Data Label 2: What’s wrong and how to fix it.


Best practices for form design• Q: What’s the best way to lay out a form?

• A: It depends.

• Consumers – coming to an experience for the first time– Breaking a form into pages doesn’t affect conversion – number of

inputs and elements does.

– Smaller pages makes a flow less overwhelming and more usable, to a point.

• Power users – repeatedly using an experience– Putting many fields on a page enables faster, more efficient

transactions.

Confidential29


Chunking fields by content sections• Scannable

• Intuitive

• Breaking into content sections = Less likely fields will be skipped

Confidential30

Data Label 1


Data Label 4 (Optional)

Page Title

Section Header 1



Section Header 2

Step 1 Step 2 Step 1 Step 2


All fields, no context• Overwhelming

• Usability issues: More fields = more likely for fields to be skipped by user.

Confidential31

Data Label 1



Page Title



Step 1 Step 2 Step 1 Step 2




Input + label comparison – inline vs. top aligned

Confidential32

Data Label 1



Page Title





Page Title

Data Label 1








Partial prepopulated fields on page

Confidential33

Data Label 1



Page Title





Prepopulated 1



Page Title


Prepopulated 5 Data Label 6


Data Label 10 Prepopulated 11

Data Label 1

Data Label 5

Data Label 11


“Edit” state –or– all prepopulated fields

Confidential34

Data Label 1



Page Title





Prepopulated 1

Prepopulated 2 Prepopulated 3

Prepopulated 4

Page Title

Prepopulated 7




Data Label 1

Data Label 5



Data Label 6



Data Label 11Data Label 10


Proof of Concept

Confidential35

• Existing wire - DSA


Proof of Concept

Confidential36

• Inline fields proposal - DSA

Global Marketing Dell - Restricted - ConfidentialConfidential37

Proof of Concept• Existing wire

- Create Quote


Proof of concept

Confidential38

• Proposed wire - Create Quote

Documents

Forms Component review Governance & Standards Team, DCX 08.04