Posted by & filed under PatternFly, UX Research.


Validation of design choices is important when designing new features of any product. The PatternFly Team values this process and frequently seeks input on different designs from users outside the team. This process not only validates the items in question, but can also provide new insights for future implementations.

Recently the PatternFly Team decided to further investigate pagination and determine what should be the recommended approach. The team also decided to investigate selection of items, action buttons, and gather any other comments from the users.

Option 1, pagination pinned at top & bottom. List view shown.

 

Option 2, pagination sticky at bottom only. List view shown.

 

Part 1: Finding & Selecting Items with pagination

Users were shown the interface beginning on a random view (Table, Card, or List). Some users began on Option 1, some on Option 2, but all users experienced both Options. It was explained that this is a prototype and some features are not functioning. Users were asked to complete the following tasks one-by-one:

  • Find the pink item and select it
  • Find the remaining 3 pink items and select them (these were on subsequent pages)
  • Later in the testing, users would complete these tasks on the other option

Table View showing the pink item.

Card View showing the pink item.

List View showing the pink item.

 

Results showed that all users successfully completed these tasks without confusion. Time differences between Option 1 and Option 2 were negligible. For Option 1, most users used the bottom-pinned pagination controls (7 of 11 users). Most users chose to use Card View for these tasks. Based on this data alone, we feel confident that both pagination options will feel intuitive and deliver successful results.

 

Part 2: Action Buttons

Following the first task, users were asked to select any item and perform an action using the buttons. This was repeated once.

Action Buttons, shown here.

 

Results showed that all users successfully complete the tasks without any issue. Time differences between Option 1 and Option 2 were negligible. Based on this data alone we can be confident that these action buttons are placed and labeled in an appropriate way.

 

Part 3: Selecting multiple items

Users were then asked about selecting multiple items in the interface. Users were asked:

  • How would you select all 75 items?
  • How would you select all the items on this page?

Selection options, shown here.

 

Results showed that nearly all users across both Option 1 and Option 2 could successfully complete the tasks.

  • For Option 1: 1 user gave up and could not complete the Select All task, all others completed the task successfully.
    • The user who gave up: “I would have used Command, A to select all items.” He did not notice the arrow that indicated the menu for selecting these options. He said that it did not make sense to him.
    • Most users (7 of 10) used the top controls.
  • For Option 1: all users successfully completed the Select Page task.
    • Most users (7 of 11) used the top controls.
  • For Option 2: 1 user gave up and could not complete the Select All task, all others completed the task successfully.
    • The user who gave up: “It was just difficult to find, I couldn’t find it.”
  • For Option 2: 1 user gave up and could not complete the Select Page task, all others completed the task successfully.
    • The user who gave up: “It felt hidden.”

Many users commented that they would prefer a selection checkbox in the top-left corner (especially in Table and List views) to select all items on the page. Many cited things like Gmail as an example, something with which they’re quite familiar. This is a point that should be evaluated in future studies.

A few users commented that the menu for selecting multiple items appeared more like a status than an actual menu they could use. This is a point that should be evaluated in future studies.

Based on the data for these tasks, we can recommend there be further investigation on how to improve the selection of multiple items. Not all users understand this element, and many have concerns about its visibility.

 

Overall Preferences & other insights

Users were also asked to indicate their preferred pagination design. At the end of all tasks, users were shown the differences between the two designs and asked which they preferred, and to provide any clarification as to why they made this choice.

Overall, the preference is split with 5/11 users choosing Option 1, and the other 6/11 users choosing Option 2.

  • Those who prefer Option 1 state:
    • “Its at the top, no scrolling needed to see my controls”
    • “I prefer things to be at the top, would be even better if it was sticky at the top”
  • Those who prefer Option 2 state:
    • “Its always available, no matter what”
    • “With the other option you can lose the controls when scrolling”

From these results, we can see that regardless of preference indicated here, users want their pagination controls to be always-available. A sticky pagination control would meet this need.

Other key insights include:

  • Ensure that future pagination options are always visible & available regardless of scrolling.
  • Investigate a Select All checkbox, especially in Table and List views. Users tend to understand this element and look for it.
  • Specifically for Card View: many users tried to select the items by clicking on the item (not the checkbox). Many commented that they think its more difficult to have to first realize there is a checkbox by hovering over the item, but then also to click the small checkbox. Simply clicking the item itself may improve usability. Team should also investigate selection methods similar to this for the other viewing options.

 

We would love to hear feedback on this process, please comment below!

Posted by & filed under Forms.


With so many new mobile phones, tablets and other devices coming out every day, designers have to be prepared to make common functions easy to do on these devices. The usual approach to this is responsive design.

The usability of web forms is by no means a new topic. It has been covered in general usability references. Forms are one of the most common elements on the Web, without them the conversation is only going one way. Forms are used for purchasing, contact, and so much more. It’s vital that the forms you produce are equally functional across the full range of devices, from smart phones to desktops. Mastering the art of making these types of functionalities small yet user friendly can be a task.

This blog is try to provide guidelines for designers in laying out Bootstrap responsive forms and includes how to work with the Bootstrap grid system, setting appropriate field width, and web vs. mobile considerations.

1.Bootstrap Grid System

Bootstrap includes a responsive, mobile first fluid grid system that appropriately scales up to 12 columns as the device or viewport size increases. It includes predefined classes for easy layout options.

Grid options

The Bootstrap grid system work across multiple devices with a handy table.

Breakpoints & Input Width Definition

1.Bootstrap user interfaces adapt layouts for the following breakpoint widths: 768px, 992px, 1200px.

2. We can find the definition of  input width in Bootstrap v2,but it has been replaced by the grid system  introduced in Bootstrap V3. The definition could help us understand the input width how long the length is large.

 

2. Responsive Forms Examples

Example 1: Red Hat Login

     

Screen width > 1200px    container=1170px  form-width: col-md-5

1200px > Screen width > 992px   container=970px  form-width: col-md-5

992px > Screen width > 768px   container=750px  form-width=100%

 

Example 2: PatternFly Login

    

Screen width > 768px   The form used classes (col-sm-7 / col-md-6 / col-lg-5) to control the width.

Screen width < 768px   Form width: 100%

 

Example 3: Openshift Login

    

Screen width > 768px    The form used classes (medium-11 large-9) to control the width.

Screen width < 768px    Form width: 100%

 

Example 4: PatternFly Modal

 

Screen width > 768px    The modal box width is 598px    The field width is col-sm-9

Screen width < 768px    The modal box width is auto        The field width is 100%

 

Example5: Theme Foundry

 

The form width is fixed 258px and the webpage background is responsive.

Screen width < 400px   The background hide and form width to 100%;

 

Example6: Kingshill Cars

   

 

3.Guidelines for Responsive Form Layout

 

1.With the help of Bootstrap Grid System,  select the appropriate length of web forms for different device. For form fields with a variable input length but within a standard average, you should find a good default you can use for all form fields of this type. The same width of the field will looks very unified in visual.

In most usage scenarios,  the form field length will not more than 530px (input-xxlarge). For different screen size, we could select the field width below. The bootstrap grid defines the xsmall screen size , so the field width will be 100% usually when the screen size less than 768px. The least field length should be over the content input width.

 

2. Pay more attention to form fields with fixed input length could reduce the enter mistake. Form fields with a fixed input length such as bank card number or ID card,  you could adjust the width of the field to exactly match the known input length regardless of the other fields on the page.

 

3. If the label width is long, present the labels on the top of the input field will be better on small devices.

 

4. Visual flow from top to bottom will be easier to read. The form column more than 2 columns will be harder to read. Some user confuse to enter the text from top to bottom or from left to right.

 

5. Put the related information in one line always. Such as Day / Month / Year、 Card number and it’s contract life…

 

Welcome other approaches that I have not covered here and you can expect to see these guidelines on the PatternFly site in the near future.

Posted by & filed under Communication, PatternFly Design.


Overview

The Notification Drawer is a content delivery system to expose time-based information such as events, tasks, and alerts. It is a self contained system that is viewable without having to navigate to another area of the application. Upon login it offers initial notifications for what has changed in the form of dismissible Toast Notifications and a permanent interactive icon in the header bar. It is hidden or revealed at the user’s request.

 

The goal of this design is to address the concerns related to notification drawer and how it should be collapsed in a responsive state for both the vertical and horizontal navigation.

 

Desktop State for the Notification Drawer

This is an existing design for how the notification drawer looks on desktop screens. More details can be found in PatternFly: http://www.patternfly.org/pattern-library/communication/notification-drawer/#/design

  1. Icon: Displays visual differentiator when new or unread notifications are present. Clicking on the icon will slide out a drawer and dismiss the toast notification. Clicking on the icon again will close the drawer.
  2. Drawer Title: Title of Drawer.
  3. Accordion: Only one notification tab may be opened at a given time -maximizing drawer space. Italicized text will indicate number of new events. Clicking on the title will expand accordion.
  4. Row: Example content shows relevant icon creating a visual differentiator between content severity or object type. New/unread notifications are shown in bold.
  5. Row Hover State: Example of hover state.
  6. Mark All Read: Clicking “Mark All Read” changes all visible unread rows (bold row type) to read (regular row type).
  7. Icon Empty: The empty state shows no new events.
  8. Row Actions: Clicking on the Kabob menu will reveal a drop down containing actions for that item.
  9. Infinite Scroll: Infinite scroll reduces need to identify time range on accordion tab. Allows for free-range historical search of notifications.

 

Design for Responsive State

The Notification Drawer can have two states: Without New Notifications and With New Notifications. The whole design can also be found in InVision: https://redhat.invisionapp.com/share/Y9BB120HR

 

Notification Drawer Without New Notifications

  1. The icon of Notification is exposed on the navigation bar (not in the navigation menu like before). Because we use full/empty state to show if there are new events, the icon should be visible at all times so the user will know if there’re new events at a glance. An empty icon is used to show the state of No New Notifications.
  2. When User clicking on the Notification Icon , the notification drawer will be open and the bell change to be full and blue (#0088ce).
  3. The notification drawer will take over the whole screen width. That is because the mobile screen is much smaller than the PC’s and there’re plenty of actions to make in this page.
  4. When there are no new notifications, all the labels are default to be collapsed.
  5. Only one Label may be opened at a time. The other two Labels will stuck in the top/bottom of the screen (if user open Label 2, Label 1 will stuck at the top and the Label 3 will stuck in the bottom)
  6. User can scroll up and down within a Label  to view more events. It will load 10 events at a time by default.
  7. When scrolling to the bottom of the list, user can pull up to load more events.

 

Notification Drawer With New Notifications

  1. When there are new notifications, the icon will change to be full.
  2. When User clicking on the Notification Icon, the bell change to be blue (#0088ce).
  3. The Mark All Read button will stuck in the bottom within the label.
  4. After clicking on Mark All Read, all the new/unread notifications within this label will change to be read and the Mark All Read button will be hidden. Also, the text under the Label name will show “0 New Events”.
  5. We used to have a unified expanded icon in the PC’s version. But it may be too complicated on mobile. So all the info will be shown and user don’t need to expand a event anymore.

Posted by & filed under Forms, PatternFly.


Description

 

After researched the quick filter using scenario and the products, Finding out that we could separate the filter function into Quick filter and Advanced filter in order to meet the different needs. 

The Quick filter is suitable for commonly used situation.It is fast, simple and obvious. It is used in the common scenario and easy to apply. 

Here is the Quick filter design: https://blog.patternfly.org/quick-filter-improvement-for-the-current-filter-pattern/

In some cases, for complicated using scenario, the quick filter can not meet the user’s need. Especially for those products that have large amount of criteria and multi select options. Developers of the products can only meet the needs by adding on more functions. We could design a new filter pattern to meet the requirement.

 

Overview

 

Advanced filter is suitable for users who want to:

  1. Quickly filter the data from a large amount of criteria
  2. Fast searching for data from a long list of value
  3. Combine multiple filter criteria into a single filter
  4. Save the custom filters that can be recalled and reapplied at another time

Here are some product examples:

1. Errata Tool

 

User : Developers / QE

Job: Working and cooperating on a certain type of advisory until the rpm package delivered to the customer.

Pain point: 

The user needs to filter and watch a certain advisory. When finish part of the work of an advisory, the user needs to deliver it to another department for review. During the review process, the user will work on other advisories. After review, the user will spend some time to configure the filter again to search the advisory to continue the work.

Since the configure field is too much, the user would like to have a function to save the custom filters that can be recalled and reapplied at another time. Currently, the user can only favorite the advisory page in browser.

 

 

 

2. Forman

 

User : Administrator

Job: Managing Linux systems.

Pain point: 

The user needs to filter and watch a certain Linux system. The user takes time to filter out the data from the multi categories. The common search field can not meet the needs well. The user needs a more accurate and visualized filter. Currently, the user can type in a rule to search.

3.Tendrl

 

User : Administrator

Job: Unify the portal of ceph and gluster storage systems.

Pain point: The user needs to filter and watch a certain storage system and filter out the data from a multiple filter criteria. Currently the filer can only filter from the single filter criteria.

4.Beaker

 

User : Developer

Job: Renting hardware.

Pain point: 

The user needs to rent a certain hardware. When filtering the hardware, the user needs to read through a long list of values and also fill in several criteria. The user would like to quickly get the correct value from the long list and to simplify the filter interaction.

 

More research could be found in google doc: https://docs.google.com/document/d/1Pw61shgHM2RmoPwsY1p0CgjdLa7pix_aCOXPrUXsy54/edit#

Design

 

Advanced filter is based on the current quick filter pattern and provides a filter solution that contains a group of dropdown menu and a custom selector.

The dropdown menu group includes single selector, single selector with search and multi selector.

The custom selector contains a button to create custom filter and also a dropdown menu for saved custom filter. It is used for users to define their own filters and save them that can be recalled and reapplied at another time.

Users could choose to implement either of the functions based on their own requirement.

Single dropdown selector

 

The quick searching filter remains the same as the current filter pattern.

  1. Attribute Selector (optional): Contains a list of the possible attributes by which to filter.
  2. Single dropdown selector: Use when there are less than 8 possible values. The filter is activated when the user click the dropdown.

Single dropdown selector with search

 

  1. Single dropdown selector with search: Use when there are more than 8 possible values.

 

Multi dropdown selector

 

  1. Multi dropdown selector: Use when there are multiple filter criteria to search in a single filter. Click the checkbox to check or uncheck the filter. Clicking the “X” of active filters could also remove the multi filters.

Custom selector

 

The custom selector contains a “create a filter” button and a “My filter” dropdown selector. When users haven’t save any filter before. The “My filter” button will not show unless users save one.

  1. Change the name: Use when saving the custom filter. Click the field to change the name and click “Save” button to save the filter. After clicking the “Save” button the filter is activated.
  2. Cancel: Use when canceling the custom filter.
  3. Apply the custom filter: Use when applying the custom filter but not saving it.

 

  1. My filter: Use when reapplying the saved custom filter.
  2. Delete button: Use to delete the saved custom filter. When hovering one of the filter, the delete button will show.

More design details could be found in Invision: https://redhat.invisionapp.com/share/XABBZKPJC#/screens/228445030_Quick1

 

 

Posted by & filed under Forms.


Description

 

In the previous discussion about the quickly filtering for dataset, we researched the quick filter using scenario and the products (oVirt / CloudForms  / RH Customer Portal / Errata Tool / Openshift), Finding out that we could improve the current filter pattern to meet the requirement.

 

The quick filter is suitable for commonly used situation. It is based on the current Patternfly filter pattern but adding on a group of toggle button. We also changed some of the design details of the current filter pattern.

Current filter pattern can be found here: http://www.patternfly.org/pattern-library/forms-and-controls/filter/

 

Overview

 

Quick filter is a component that enables a user to quickly apply stackable filters to a table or page full of objects.It should be fast, simple and obvious.

Quick filter is displayed as a component of the Data Toolbar with a quick searching function and a toggle button group. The toggle button group is used to filter the important certain value.

 

Product example:

Design

 

Quick searching Filter

 

The quick searching filter remains the same as the current filter pattern.

  1. Attribute Selector (optional): Contains a list of the possible attributes by which to filter.
  2. Filter Query Field: Use when there are more than 15 possible values. The user’s filter query is entered here. The filter is activated when the user presses the “enter” key and all objects that do not have a match to this value are hidden.
  3. Filter Query Dropdown (optional): Use the filter query dropdown when there are less than 15 possible values to allow the user to select from a known and fixed value list (e.g a list of statuses). The filter is activated when the user selects a value. Objects that do not have this value are hidden.

 

Active filters Bar

For the active filters bar, we changed some of the design. We move the “Clear All” button to the far left. Compare with placing the button to the far right,

it is a better way to avoid the  “Clear All” button from getting out of the user’s focus when the active filters list becomes very long.

Also, the “Clear All” button will show only When there are more than one filter activated. If there is only one filter that is activated, the “Clear All” button is hidden. 

  1. Active Filter: Quick Filters are labeled with the attribute and value used to create them. Clicking the “X” in the box will remove the filter. New filters appear to the right of existing filters and are highlighted briefly upon appearance. If no active filters exist, the active filters bar is hidden.
  2. Clear All Filters: Clicking this action removes all currently active filters.

Toggle button group

The toggle button group is a new adding on. Button groups is a commonly used and obvious way to display a filter.

  1. Toggle Button Group: It can quickly filtering the most commonly activated or the most important certain criteria. The toggle button group filter is preloaded. It is not like quick searching filter, which is activated after user clicking the enter key.  The number of the toggle button group is better less than four.

More research could be found in google doc: https://docs.google.com/document/d/1sDJvSZztOj6lQwirbjupMYfesmjaRnB-sfXVn2gf-Rw/edit#heading=h.r04qxhveoov

More design details could be found in Invision: https://redhat.invisionapp.com/share/XABBZKPJC#/screens/228445030_Quick1

Posted by & filed under Forms, PatternFly.


In designing enterprise applications, we very often encounter situations where the user needs to edit existing information.  In many cases this editing is done in the context of a form where users can make and commit changes.  You may sometime need to apply role-based access to enable editing for authorized users, only.  How should you accomplish this using components available through PatternFly?  This post identifies some common use cases for form based editing and potential design approaches.

Common Patterns

There are at least three approaches to editing that are commonly found.  Each of these has advantages and disadvantages so the right approach may be dependent on context.  Understanding the tradeoffs involved will lead to better decisions about editor design.  To illustrate these approaches, I will use a simple use case that’s easy to understand.  Let’s consider that an application has a database of users and I, as an administrator, want to edit the credentials of a selected user.  What are some potential approaches that can be taken?

First, let’s suppose our high-level view of users is presented in a list view that looks something like this:

If I want to edit the details of one or more of these users.  How should I proceed?

 

Pattern A – Drill Down to Edit Details

A simple approach is to open each user record in a separate editable form.  The editable form can be contained in a modal dialog or as a full-page drill down.  The user makes the required edit and clicks Save to commit them back to the user database.  Watch the video to see this interaction.

 

Or if modals aren’t for you, the same pattern can be accomplished by substituting a full page view for the modal dialog.

 

Advantages

This approach is clear and straight forward.  Users are clearly presented with editable information, can make their changes, and can click Save when done.  If using a modal approach, users are focused on the task at hand and cannot navigate away without saving or cancelling changes.  Role-based access control is easily accomplished by preventing unauthorized users from clicking Edit.

Disadvantages

The drill-down approach requires an extra navigation step to edit the details of an object.  It also does not allow these details to be exposed to some users in a read-only mode.  This may be a problem if there are details that should be viewable to all but cannot be represented on the parent view.

 

Pattern B – Toggle Between View and Edit Modes

One way to allow read-only access for some users and full editing privileges to others is to support drill-down to details and then require an additional step to enable editing.

In the example, the Edit button placed in the header of the page gives the user the option to turn the page into an editable form.  Access can be denied to some users by disabling or hiding the edit control.  After the user has made their edits, they can commit their changes by clicking Save or click Cancel to discard changes and return to the read-only mode.

Advantages

This approach allows the same page to be used for viewing as well as editing details.  Access to edit mode can be controlled via the Edit button.

Disadvantages

Switching between read-only and edit modes will require a page refresh.  Depending on the content on a page, it may be necessary for layout to change significantly when switching between modes.  This has the potential to disorient users as elements change position.

 

Pattern C – In-Line Edit on a Form

Like in Approach B, the details are presented in a read-only page view.  When users want to edit a specific element, they can put that element directly into an editable mode, make their changes, and save them.  They can make multiple edits on the same page in this way.

 

Advantages

This approach does not require a page refresh and only one element is made editable at a time.  This works well when only a few elements are likely to be edited at a given time.  If validation needs to be performed in the back-end, inline editing will provide more immediate feedback since each change is submitted separately.

Disadvantages

This method will become tedious if many items will be edited on the page due to the additional clicks required and the potential turn around time after each change is submitted.  Making this behavior clearly visible can also be challenging.  A small icon or other signifier can be added adjacent to editable fields, however this may add clutter to the form.

 

Conclusions

While there is not a one size fits all approach to editing data on forms, there are some high-level guidelines that we can apply in most cases:

  • In most cases drill down from some content view (Card, List or Table view) into a separate edit page should be your default approach.  This may be accomplished using either a standard modal dialog or on an edit page with appropriate submit buttons.
  • Toggling between view and edit modes on the same form is useful when you want to show the details to all users, but only some can edit.
  • In-line editing is a very efficient approach when users are likely to edit only a single parameter at a time.

What’s your take on this?  I welcome other approaches that I have not covered here and you can expect to see these guidelines on the PatternFly site in the near future.

 

Posted by & filed under Announcements.


The Red Hat UXD team is excited to announce the first ever PatternFly Conference on June 8 from 12 – 6PM at the Red Hat Annex in Raleigh.

The PatternFly Conference is a half day community conference dedicated to sharing ideas, techniques, and tools to power great user experience through front-end design and development. To register, submit a talk, or learn more visit: http://www.patternfly.org/conference/2017/

Best,
The Red Hat UXD Team

Posted by & filed under Forms.


Story Background

We currently do not provide any guidance on how to enter numeric data on forms. There is a Bootstrap Touchspin component in Widgets library for numeric data entry but no guidance on how this should be used.

There are four ways I founded to entering numeric data.

  1. Bootstrap Touchspin (stacked):   Data Input + Number Control
  2. Bootstrap Touchspin:  Data Input + Number Control
  3. Bootstrap Slider:  Number Control
  4. Selection: Number Control

(ps: The experience of input box entering data is included to A & B )

In this issue, I decided to do a small usability testing about

What is your preferred control for entering numeric data?

 

How did I test ?

Test A. Numeric Data Entry

Test link: http://file.rdu.redhat.com/tzhu/Patternfly-demo/tests/form2.html

Testing environment:Web

This test tested 30 participants from 5 departments of Red Hat.

 

Section 1- Observe the operation of users

  1. Invite participants to input the four test forms naturally without telling them too much test detail (To reduce the influence of user operation behavior). Observe the operation of the user behavior and make the records.

Testing Analysis

  1. The participants include 16 male and 14 female.
  2. 66.7% (20) participants use “Tab” button to switch the form field. 33.3% participants use cursor to select the field they need to input. There are 8 participants use mouse and 2 participants user touchpad to control the cursor.

Most participants like use the “Tab” button to switch the form field. They like input the information without too much interrupted.

 

       2.Observe the operation how the users use the BootStrap Touchspin.

Testing Analysis

  1. 96.7% participants enter text directly in the field of Working Years. Just 1 participant use the control buttons on the right.
  2. 86.7% participants enter text directly in the field of Working Years.

Most participants like to enter text in BootStrap Touchspin directly .

4 participants said they didn’t see the control buttons of BootStrap Touchspin (stacked) on the right.

 

Section 2 – Questions to users

  1. After user finished all the forms, asked user the question “What is your preferred control for entering numeric data? Please sorting for them ”
  1. Both test1 (BootStrap Touchspin (stacked) ) and Test4 (selection) get 37.5% votes. Users have a lot of user experience about this two patterns.
  2. During the test1, 2 users try to enter the number not belong to integers like 3.7 \ 1.5… The BootStrap Touchspin (stacked) adjust the number to integer directly. It takes some confuse to user.
  3. Some user said they don’t like the drop down selection when the options is too long especially appears ScrollBar in the selection box.

Both BootStrap Touchspin (stacked) and drop down selection are good choices to design form data entering. They are very familiar with users and don’t take many problems to them. If data greater than ten, we would better choose BootStrap Touchspin (stacked). If less, both patterns are make sense. Drop down selection is more efficient and less mistakes.

 

When will they use the control buttons?

The majority of users said they rarely used control button of BootStrap Touchspin (stacked).

There is a very interesting thing from participants. If the number is certain,such as my years old / my pets number, they would like entering the number directly. If the number is not certain,like he is shopping on website but he is not sure how many potatoes he would buy, he would like the control button to control the number.

  1. In this test, Bootstrap Slider is the least popular. 19 participants don’t like this interaction.

    Reasons:

  1. The users can not control it well;
  2. Some users don’t know how to use it;
  3. After the selection, the slider do not show the number clearly;
  4. Some user like use keyboard think it is very hard to control it with keyboard.

 

  1. Compare BootStrap Touchspin (stacked) and BootStrap Touchspin, Which one is your preferred control.

  • 66.7% (20) participants choose BootStrap Touchspin (stacked).

 

     Reasons:

  1. More than 5 participants said they like to use “tab” button to the input box and enter number directly; BootStrap Touchspin (stacked) just need one step, BootStrap Touchspin needs two steps.
  2. 4 users thought BootStrap Touchspin can not input the number directly, just use “+” and “-” button to control the button, so they didn’t like it.
  3. Many users with the use ability “tab” to switch field don’t know tab two times can go to the input box. When they filed use “tab” to input box, then they user cursor to reselect the box. This experience make them not feels very well.

4.They are familiar with this component.

  1. It is very tired to hover the mouse from left to right.  BootStrap Touchspin (stacked) is easier to control number.
  2.   33.3% (10) participants choose BootStrap Touchspin.

Reasons:

  1. They thought it is very hard to click the number control button of BootStrap Touchspin (stacked) because the control buttons are small. That takes them a lot of misclick problems.

 

  1. Compare the two pages, Which one is your prefer?

Wide one

Narrow one

 

94.7% (29) participants like the narrow one, even hope it can be more narrow. The input information is short, the wide one is too wide to them.

1 participant think the wide one looks more balance in the page.

 

Test B. Button within form

Test link: http://file.rdu.redhat.com/tzhu/Patternfly-demo/tests/form-input.html

 

  1. 73.3% (22) participants like example 2.

Reasons:

1.They looks example 2 is comfortable in visual ;

2.Two participants have the confusion the button is used to copy all the information or just the link. Example 2 is much more clear to him.

  1. 23.3% (7) participants like example 1.

Reasons:

  1. Text field and the button are seen as separate elements. The copy button is more clear to him with the clicking motivation.

2. The button in example 2 not look like a separate function button. Similar with a drop down button.

 

Guidance

  1. The Bootstrap touchspin with stacked buttons seems like the preferred method for entering numeric data on a form, primarily because it is easier to tab into the field using the keyboard, which is the preferred data entry method. However the standard Bootstrap Touchspin might be better for situations where target size is a concern, like mobile.
  2. Using a drop-down seems like a good approach when there are a small number of options.
  3. Using narrower field widths for numeric data entry is preferred.
  4. Looks like participants preferred to have buttons within forms directly associated with the input field (no gutter).

 

More detail test information please check https://docs.google.com/document/d/1kk9TIGW2sow1LZ5CX-zi1huqfdCdANOw2dBxld-JmeI/edit#

Posted by & filed under UX Research.


When adding new features to PatternFly patterns and widgets healthy debate sometimes arises among the PatternFly team about the best way to design the features. Other times, the team might be in agreement about the best design approach but still wants external validation before the design gets implemented. When either of these situations arises, we try to make decisions based on data provided by users through empirical testing. Recently, questions arose around three issues: (1) the best way to communicate pagination behaviors for table, list, and card views, (2) the best way to visualize links in aggregate status cards, and (3) the best way to provide syntax hints for form fields. To answer these questions the team conducted some “cafeteria tests” with users. Cafeteria tests are short usability tests conducted in a high traffic area (like a cafeteria) that typically focus on a single question or a small number of questions and can be completed in a few minutes. Participants can be recruited beforehand or just grabbed on the spot when they wander by the testing location. The rest of this blog describes the three studies we conducted and the findings and recommendations for each.

Study 1 – Pagination Behavior

The goal of this study was to gauge participants’ understanding and usage of the pagination controls in PatternFly table, list, and card views. The controls include a column selector for selecting all items currently visible, a Select All button for selecting all items (including those not currently visible on the page), previous and next buttons, and a drop down for selecting the numbers of items to view per page.

 

Participants were shown a table view and asked the following questions:

  • How would you select the items on the current page?
  • How would you select all of the items in the table.
  • If a single item in the table were selected, what would you expect to see when you clicked to the next page – would the current selection persist?

Results showed that the meaning of the Column Selector control is unclear. Some participants thought it selected all items on the current page; others thought it selected all items in the table; and some (about 1 in 3) either didn’t notice the Column Selector or didn’t realize it was a control. (Interestingly, about 1/4 of participants also noted that they never noticed the Select All control in the upper right corner of the table.) When asked about selection persistence, there was no consensus among participants. About 2/3 correctly believed that selections persist when moving among pages, while the rest thought they would not.

Based on these findings we made the following recommendations:

  •  Add flyover help text to the Column Selector explaining its function.
  • Change the appearance of the “Selected: x of y” when paging to help users understand selection persistence.

Study 2 – Visualizing Links on Aggregate Status Cards

The goal of this study was to understand users’ preferences for the way links are visualized in PatternFly aggregate status cards. Three options were considered:

  1. Static – Link text is always blue and underlined; nothing changes on mouse over.
  2. Text change on hover – By default, link text text is black and icon color is determined by status (green, yellow, or red). On mouse over, text changes to blue and underlined.
  3. All change on hover – By default, link text text is black and icon color is determined by status (green, yellow, or red). On mouse over, text and icon change to blue and text is underlined.
  
Static Text Change on Hover All Change on Hover

 

 

Participants were shown three identical web pages that included aggregate status cards. The only difference among the pages was how the links on the cards were visualized. Participants were not told what the difference was. Participants were allowed to view each page for about a minute and were told they could move the mouse around the page but not click, because none of the links were active. After viewing all three pages participants were asked if they noticed any differences among the pages. Then the different link visualization conditions were pointed out and participants were asked which they preferred and why.

Results showed that participants had difficulty identifying the subtle differences among the pages. Only three of 16 participants were able to identify the differences among the three pages without being shown. In addition, 12 of 16 participants did not notice a difference between the “All change” and “Text change” conditions until it was pointed out. Regarding preference, slightly more than half of the users preferred the “All change” condition and about 3/4 preferred either the “All change” or “Text change” conditions. The three users who stated a preference for the “Static” condition all said it was the most obvious.

Based on these findings we recommended that the “All change” condition be implemented. That is, by default text should be black and icons colored according to the status they’re indicating. On mouse over, icons and text should change to blue, provided the icon is clickable.

Study 3 – Syntax Hints

The goal of this study was to validate a proposed design for the way syntax hints are displayed in PatternFly form fields. The proposed design is to display hints in a gray, italicized font inside the form field itself. The hints disappear when the user begins to type in the field. We wanted to know if users are OK with this method of displaying hints and whether them disappearing would impact performance. Participants were given a card with various pieces of information (credit card number, date, IP address, etc.) and asked to input the information into a website form using the formats shown by the syntax hints.

Results showed that users had little difficulty correctly entering the information from the cards into the form fields, with one exception. No users input the Outgoing Mail Server correctly. They all neglected to include the “smtp.” before the server name. Whether this is because they did not notice it before the syntax hint disappeared or is an artifact of the test, in that users did not understand mail server formatting and didn’t think the “smtp.” to be necessary, is not clear. Despite having little trouble using the form with the syntax hints displayed in the form fields, user comments indicated that displaying hints in this manner is not universally preferred. Half of the participants commented (unprompted) that they want hints to be visible at all times and suggested moving hints outside the fields. 

Based on these findings we recommended that PatternFly continue exploring options for the syntax hints design pattern.

Posted by & filed under Announcements, PatternFly.


The Red Hat UXD team would like to introduce the PatternFly Angular 2 and PatternFly React repos! Big thanks to Dana Gutride and Patrick Riley for kicking off the effort by creating the repos and introducing a list of initial issues. At this point, these issues are a list of questions regarding repo setup. We would like to invite you to take a look at the current issues, comment and/or add any additional issues that should be addressed.

PatternFly repo teams have been organized as way to help coordinate the community efforts surrounding each repo to ensure contributions are meeting PatternFly design and development standards. The repo team roles and associated member are as follows:

  • Angular 2
    • Maintainers (JS Dev): Dana Gutride and Dan Labrecque
    • CSS Experts: Adam Jolicoeur and Andres Galante
    • Interaction Designers: Adam Jolicoeur and SJ Cox
    • UXD Strategist: Cat Robson
  • React
    • Maintainer (JS Dev): Patrick Riley
    • CSS Expert: Jenn Giardino
    • Interaction Designers: Jenn Giardino and Matthew Stevens
    • UXD Strategist: Mary Clarke

We are excited to enable Angular 2 and React development for PatternFly and look forward to building out these repos with you.

Best,
The Red Hat UXD team