Posted by & filed under Navigation, PatternFly, UX Research, What's New on PatternFly.org.


As the design of PatternFly becomes more modular, a project has been kicked off within the community to update the website’s information architecture (IA) to better align with the new framework architecture to better meet user needs. To guide the decision making process for the re-design we’ve decided to employ the Open Decision Framework (ODF), a tool developed within Red Hat for making project decisions based around open source principles.

Open Decision Framework

According to the ODF, “open decision making is transparent, inclusive, and customer-centric. It involves clearly sharing problems, requirements, and constraints with affected parties; collaborating purposefully with multiple stakeholders to secure diverse opinions and comprehensive feedback; and managing relationships and expectations across competing needs and priorities.” [1]  The four main phases of the ODF process include:

  1. Ideation
  2. Planning and research
  3. Design, development, and testing
  4. Launch

How We’re Using the Open Decision Framework

Our plan is to use ODF principles to guide the design decisions made in re-architecting the PatternFly website. We will:

  • Create and maintain a common fact base where important facts and information about the project will be shared with all PatternFly stakeholders.
  • Engage the PatternFly community to participate in the UX research activities that will feed the design process.
  • Publish a project plan with roles, dates, constraints and proposed activities in the common fact base.
  • Provide regular updates through the PatternFly blog and @patternfly_des on Twitter.
  • Publish and solicit feedback from the community on all research findings.  
  • Communicate the decision factors and provide opportunity for community feedback when key design decisions are made.
  • Evaluate, acknowledge, and incorporate the feedback and highlight any design changes made in response to that feedback.

What’s Been Done So Far

Over the past several months, some background UX research has been completed in preparation for the project.  In March 2016, a baseline usability test of the PatternFly website was completed to identify issues with the existing website information architecture and design. As a result of this test, minor updates were made to the website’s Home, Patterns and Blog pages. In January 2017, interviews were conducted with 10 experienced PatternFly users (both designers and developers) to identify concerns with the current PatternFly website IA and determine requirements for a new IA. A summary of results from that activity is available here.

Next Steps

In the coming weeks and months, we will conduct additional research to guide the design of the new PatternFly website. Two activities are currently being planned.

  1. A tree-testing exercise to test the usability of a newly proposed taxonomy for PatternFly website that would reflect Modular Design principles. Participants will be given a series of tasks in which they will need to navigate the PatternFly site-map to find specific pieces of information. The time taken and number of steps to complete each task will be recorded.
  2. An online card sorting activity to help understand users mental models of the new taxonomy  and how different content should be organized.

We plan on leveraging the PatternFly mailing list and social media to solicit volunteers to participate in and possibly help facilitate these activities. We look forward to leveraging the PatternFly community and ODF to help improve the user experience of the PatternFly website.

 

[1] https://opensource.com/open-organization/resources/open-decision-framework

Posted by & filed under PatternFly.


As the application landscape evolves, design resources must also evolve. The PatternFly community has rapidly grown and technology has evolved so we are now able to push the boundaries. PatternFly was originally designed with a utilitarian mindset, focused on supporting data dense management applications. This mindset shaped the design of the PatternFly we see today.

 

With the growth of PatternFly, we now have a more diverse community. This diverse audience brings a much more diverse set of applications and use cases. Specifically, they have brought consumer facing applications, which have a marketing focused aesthetic that is missing from our current design. These new consumer style applications bring different styling expectations such as, bold, colorful graphics which help them stand out from their competition.

 

In an effort to support these new consumer style applications, we have taken a few steps to evolve our current design to meet these needs. Our goals are to create new graphically bold styling. The focus of this effort is on the look and feel – color, sizing, positioning, imagery, type, icons and will not affect content or interactions.

 

Since styling can be subjective, it is important to gather quantifiable data to inform design decisions. We conducted a desirability study to compare our current design against two new designs. All three concepts used the same content and interactions to easily compare.

 

Measuring Look and Feel

 

Desirability studies are designed to measure participants’ emotions by giving them a vocabulary of positive and negative word pairs that they can assign to each design. Additionally to ensure we received a definitive result, we also asked each participant to choose which design best described one of a series of positive attributes.

 

Twenty-two participants were lead through an identical workflow foreach concept.  Then, they were asked to rate each concept, based on the provided vocabulary, and encouraged to share any additional thoughts for each. We also gathered additional information about the participants, such as company, occupation and their role.

 

The Concepts

 

Using the sample application content and Red Hat branding as a base, we designed three concepts. The control design uses our current PatternFly design styles. The new concepts use two different styling techniques to display content. The dark design relies on heavier graphics and imagery whereas the light design utilizes typography and color to establish hierarchy. We purposefully exaggerated each concept with the intent of generating a distinct reaction to more easily compare the desirability of each concept. These are just concepts, specifically designed to get a reaction, to validate a new visual direction.

 

 

The Results

 

We calculated the total number of positive and negative words associated with each design concept. A majority of the feedback was positive for each concept. The control design receiving majority of the negative word associations and the Light receiving a majority of the positive.

 

We broke down the words associated with each concept and arranged them by frequency. The saturation of the color is associated is scaled to reflect the frequency.

The control design received 44% of the total negative words associated with the concepts. As stated above, this concept reflects the current PatternFly styling, which was created with a utilitarian approach. The study reflects this strategy with the highest associated terms being “Useful” (20) and “Conservative” (9).


 

 

The dark design received neither the most positive or negative responses.  The highest associated terms were “High Quality” (21) and “Confusing” (8). This concept was rated highly for ‘Unwelcoming’, potentially a result of the dark black and red values, which people tend to associate with evil.

 

 

The light design received 36% of the total positive words associated with the concepts. The highest associated terms were “Interesting” (22) and “Conservative” (5). Every participant rated this concept as “Interesting”.

 

 

We compared each design across the total positive and negative word counts. You can see in each design how we improved or regressed as you look at the frequency across terms.

 

Overall Performance

 

Lastly, we asked users to choose between each design based on the positive terms above. For example, which design is the ‘highest quality’? You can see in the results below, participants rated the new concepts higher than the current PatterFly design by a margin of at least 50%. The darker design rated highest for “High Quality” and “Easiest” to use while the lighter design rated highest for “Innovative” and “Satisfying”.

 

 

We also examined the data by role. There was a distinct preference between participants with business and design backgrounds. The business participants preferred the dark while the designers preferred the lighter design. One theory could be that  participants with a sales background prefer the more bold and impactful designs because it helps their products stand-out from the crowd whereas designers prefer a more nuanced and subtle approach.

 

In summary, the data shows that users prefer the newer designs three times as much as the control.

 

 

What’s Next?

 

Since these designs are just concepts to test a direction, there is still a lot of design decisions and work left to be done. There are many considerations that these designs do not address.

 

This is only the starting point. It will take time to create a great solution to fit the PatternFly community’s needs. As we progress, we will continue to keep you updated.

Posted by & filed under PatternFly.


Hello friends!  I recently gave a talk at the first annual PatternFly conference on some easy ways to take the writing you do for PatternFly from good to great.  In it, I shared a few items that would comprise a short checklist that you can refer to as you write.  Those items, and some others, are included here.

For patterns:

  • Does this address Faith the front-end developer’s main questions and concerns?
    • Does it give her what she needs to know to build a UI that impresses her team?
    • Does it give her design guidance and info without lots of jargon?
    • Is it written clear and completely enough that a beginner can be successful?
  • Does this address Ron the reluctant front-end developer’s main questions and concerns?
    • Does it include all the details he needs to plug-and-play?
    • Is it written concisely without a lot of detail (backstory, implementation details, etc.) that won’t help him achieve his goals?
    • Have I described how all the pieces work together, in case he wants to reverse-engineer it?
  • Does this address Inga the interaction designer’s main questions and concerns?
    • Have I described the use cases that this pattern addresses well?
    • Have I described use cases that this pattern is NOT suited for?  Did I include links to other patterns that might fit those other cases?
    • Are the differences in the variations clear?  Is it clear when to use one vs. another?
    • Was this pattern tested with users?  Is there a link to the findings?
  • Have I addressed outstanding issues (i. e. incomplete information) and questions?  Is there upcoming work on this pattern that I should mention?
  • Is the writing style straightforward but not formal?  Does it have a tone that sounds neutral and not like I’m telling you about it personally?

For blog articles:

  • Can I break this into multiple posts?
  • Is my call-to-action clear?
  • Did someone who is like one of the personas read this?  (For bonus points, have someone like each of the personas read it and give you feedback.)
  • Did I run this through Grammarly to check spelling, punctuation, and grammar?
  • Did I read it out loud?
  • Does this sound like something I would say?  In other words, is this written in my voice?

This list is not complete and should be considered a living document.  If you have suggestions for additions, please let me know if the comments.  If you use it for your writing, comment on how it worked for you.

Finally, if you attended my talk, I appreciate it!  Let’s keep the conversation going — let me know your thoughts below about any writing you’ve done (or would like to do) for PatternFly.

Posted by & filed under Announcements, PatternFly.


Last November we published the PatternFly roadmap where we put forward the idea for PatternFly 4 and 5, an effort around web components, and a CSS rewrite. Alpha releases for PatternFly 4 and PatternFly Web Components delivered initial progress on these efforts. However, the story has grown more complex with the introduction of additional PatternFly framework repositories. In this post we will provide a status update on our delivery of our roadmap, and explain how all these repositories and future versions tie together.

The Big Picture

The PatternFly design system consists of:

  1. A set of patterns for use in enterprise applications
  2. A CSS implementation of the patterns’ visuals
  3. JS implementations of the patterns’ behaviours

 

Implementations of the behaviours are offered via multiple framework integrations (Angular, React, and jQuery) to enable more code reuse and increase developer productivity. We are positioning web components as our vehicle for code reuse between our framework integrations, as described in a previous PatternFly Web Component post.

Independent releases

Each of the PatternFly repositories will move forward with an independent release cycle and version (following http://semver.org). This is in contrast with the version lock we’ve had to date between PatternFly and Angular-PatternFly.

Angular-PatternFly 4

Taking advantage of this break in the PatternFly/Angular-PatternFly version lock, we have released Angular-PatternFly 4.0.0. Refer to the release notes fro complete details, but the major deliverables of this release are:

  • A port of the Angular directives to Angular 1.5+ components
  • The jQuery dependency is now optional
  • A major ui-bootstrap dependency update
  • A number of new component implementations

Angular-Patternfly 4.0.0 relies on version 3.25.0 of PatternFly..

PatternFly 4

The changes introduced to date in the Patternfly 4 Alpha and RC’s did not warrant a major version bump. As such those changes were merged back into the master branch, and delivered as PatternFly 3.25.0.

We will move forward with a PatternFly 4 effort centered around splitting the CSS and jQuery implementations into separate repositories to be consistent with our model of PatternFly presented above. This will facilitate uses cases that consume PatternFly CSS but don’t want to bring in the jQuery implementations, such as the various framework integrations.

PatternFly will also move to a continuous release process, rather than the current sprint-based release cycle. A release will be triggered with every PR merge to master, applying semantic versioning as appropriate. This will make it easier for downstream to consume PatternFly changes in a timely manner.

Framework Repositories

PatternFly Web Components and PatternFly React have initial releases and will move forward with a continuous release process. Look for a PatternFly-ng release soon.

PatternFly CSS

What we initially called “PatternFly 5” is being carried out in the PatternFly-CSS repository.  It consists of a rewrite of our CSS based on Bootstrap 4. Check out the PatternFly-CSS component showcase to follow along with progress. When this new CSS implementation is ready, it will replace the current CSS implementation.

Get involved

There is a place for everyone to get involved in one of our PatternFly repositories.

Get in touch with us via any of the mechanisms on our community page to learn more about contributing to the above efforts.

Posted by & filed under PatternFly, UX Research.


In an increasingly mobile-oriented world, it is important to test and validate design decisions and how they affect usage on mobile devices like smartphones. The PatternFly team gathered some user feedback at Red Hat Summit 2017 in Boston, MA to gain some insight into designing for these devices.

 

The team tested two different designs, and various elements within those designs including:

  • Filtering
  • Breadcrumbs
  • Actions

Using a dataset including US cities within the categories of their respective states (e.g. Detroit contained in the Michigan category), users were asked to locate individual cities, groups of cities, and navigate through the different categories using breadcrumbs.

Option 1, Table View

 

Option 1, Card View

 

Option 1, List View

 

Option 3, Table View

 

Option 3, Card View

 

Option 3, List View

 

*Note that there was an Option 2, but it was not tested

 

Searching via Filtering

Filtering in this version was difficult for some users. Most users understood the concept of filters and how to apply one, however difficulties were encountered when removing the filters and changing the filters.

Applying both City and State filters simultaneously was common, this resulted in no results being shown. Some users who experienced this error were confused by how to remove filters.

About half of the users searched via filtering, and the others chose to simply scroll through the full list of cities to find and select the target items. It may be inferred that scrolling on mobile devices is a learned behavior that users are comfortable using, as many smartphones and tablets encourage infinite scrolling.

When asked to locate and select all cities in the state of Illinois, most users could complete the task, but some had difficulty applying the filter, and finding how to select all the items.

When asked to locate all the cities beginning with the letter “W”, every user could complete this task, though one had some difficulty with the filters. This user ultimately cleared all filters to start fresh, and completed the task.

Looking at the filtering behavior, we can see that there needs to be some further evaluation of these elements. Clearing filters should be examined in future studies to ensure it is simple to understand. We must pay attention to filter design so that users always understand which are applied.

Option 1, showing an applied filter in Table View

 

Use of Breadcrumbs

Breadcrumbs were utilized by about half of the users when asked to navigate back to the top level of the interface. Some users simply did not understand how to do this, and could not complete the task. There we no discernible differences between Option 1 and Option 3 regarding Breadcrumb design. Based on this, Breadcrumbs should be investigated further – a more complete test of Breadcrumbs could reveal whether they are appropriate for a mobile design.

Option 1, Breadcrumbs variation, Table View

 

Option 3, Breadcrumbs variation, Table View

 

Action Buttons

During the searching tasks, user were also asked to use the action buttons (Edit, Remove) after selecting the target items. Most users successfully located and used these action buttons. They seemed to understand these functions well. Some users commented that they would expect in-line actions on each item in the interface, meaning Edit and Remove would be shown as actions on each item, not just at the top in the toolbar. This would be something to investigate further, and you can see in the screenshot below that Table View had a placeholder for such actions.

Option 1, Table View, Action buttons expanded

 

Key Insights

Overall, there were some issues we discovered when these designs are used on a mobile platform. Things like filtering need some adjustment and further study to determine the best practice for implementation on mobile devices. Applying and clearing filters needs to be simple. Filter status needs to be apparent. Breadcrumbs need to be examined further to determine whether they make sense on a mobile interface. Selecting multiple items is an important feature that needs to be easy to find. Action buttons are important, we should investigate whether in-line actions are preferred over keeping them in the toolbar.

We also observed some interesting behaviors that are specific to mobile devices that should be investigated in future studies:

  • On Android, the OS “Back Button” feature was utilized by a couple users to navigate back through the hierarchy instead of breadcrumbs. This was not anticipated, and should be considered for future designs.
  • On both iOS and Android, using the touchscreen to zoom in was observed. After zooming in and pressing “Enter” to apply a filter, users expected the screen to zoom back out, but it did not.

 

Future studies can focus on these elements specifically in the mobile interface. Judging by the small sample we have from this Summit 2017 testing, we can see there are some challenges and different needs when designing for mobile devices.

Posted by & filed under Forms, PatternFly.


1. In-Line Edit for Form

Inline Edit pattern enables users to edit text directly on the same page instead of navigating them to another page for editing the text. This is useful when the user may want to make a single edit without the need to refresh the entire form to make it editable. This pattern would help user to edit the info they need edit accurately and reduce the mistake operation.

Single Field Inline Edit Design

  • Only one item can be edited at a time. Users commit to or cancel changes by clicking Save or Cancel.

Example A

This a Staff Management System,most information in the form is management by company, only nickname and personal telephone number can be edit by employee.

There are three status to show to the in-line edit process.

 

Example B

This a personal information page, all the info in the form is added by users and all the info allow user to edit.

 

  1. In the usage scenarios like example A which with fewer fields can be edited. Displaying the Edit icons will help user discover them directly.
  2. In the usage scenarios like example B, most information allow user to edit. The edit icon can be hidden. Because when there are too many edit icons. The UI is obviously going to look cluttered. You can hover your cursor over the name. Once you hover over the name, you will see the information getting enclosed inside a rectangular box.

Multiple Field Inline Edit Design

A user try to edit a group information such as his birthday. When he hover the birthday number, he will see the hover status same as the following image. Once he click inside the rectangular box, the field becomes input groups with save and cancel buttons.

Guideline

  1. This pattern applies to form content views.
  2. This pattern does not include bulk actions (editing multiple fields at once).
  3. This pattern applies to fewer fields need to be edited.

 

Field Inline edit components need to be created

 

2. A toggle to a full edit mode

If the form need users to updated a lot of information at one time. We would better giving a Edit button on the top. After click the edit button turn the page to edit status with group of fields.

  • Users commit to or cancel changes by clicking Save or Cancel

View status

Edit status (full page view)

Guideline

  1. This pattern applies to edit multiple fields at once. If users usually edit only a few fields, do not use this pattern. Field Inline Edit will be better.
  2. Either edit view in a full page view or modal is make sense. We would better keep the consistent use habit. If the information add by modal, when you click edit button, you can return to modal status with the origin information. If it from a full page, you can return to the full page view.

 

3. Real-time sharing form

Some real-time sharing form such as Google sheet which without cancel and save button. Keep edit mode always on.

Welcome more feedback about Inline Edit on Forms. Thank you~

 

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