Posted by & filed under PatternFly.


We’d like to officially announce that support for Sass has been added as a core feature of PatternFly and is now available in the 3.31.0 release. Many in the community had already been using the PatternFly-Sass package and the concepts behind that repo have been brought into PatternFly core.

We are doing this because many products found that they preferred using Sass instead of LESS for their CSS preprocessor and the community provided PatternFly-Sass needed official support so it wouldn’t fall behind.

How will this impact you?

For Consumers of PatternFly:

If you are using PatternFly css in your website only, this shouldn’t impact you at all. If you are using the less partials instead of patternfly.less or patternfly-additions.less, the mixins file had to be broken into two separate files (mixins.less and bootstrap-mixin-overrides.less) so you’ll need to add a second reference to the bootstrap-mixin-overrides.less file.

Contributors to PatternFly:

Supporting Sass as part of our release means that each contributor to PatternFly core css needs to make sure they build the Sass and include it with their PR for review. The readme explains how to do this here: https://github.com/patternfly/patternfly/#less-to-sass-conversion. Any code reviewers should also ensure that any less changes are accompanied by corresponding Sass changes.

As always, we appreciate feedback on this and any other PatternFly features that have been provided and please either use the mailing list or our slack channel (http://slack.patternfly.org to join) to ask questions. To learn more about how to contribute to PatternFly or how to use it in your project, please see the readme at: https://github.com/patternfly/patternfly or view our website at http://www.patternfly.org.

Posted by & filed under PatternFly, PatternFly Design.


 

One of the biggest challenges with web design is understanding typography. Font choice, weight, size, and spacing are all important things to consider when you are setting up type for your website or application.

If you aren’t familiar with the term vertical rhythm, simply put, it’s what keeps vertical spaces, between elements on a page, consistent with each other.

Having a hard time with type?

If you look at this article and you get warm fuzzy feelings from the type, but don’t understand why, vertical rhythm might be for you.

I am a core contributor to PatternFly, a design system for enterprise web applications. We are really excited about our next big CSS release and we’ve been working on a bunch of great new features for it.

One feature we are building out is vertical rhythm.

With PatternFly our goal is to offer a consistent design that is easy to implement. We want our users to feel confident that the overall style is well thought out and considers things they may not have an eye for.

Let’s talk about our PatternFly type

By default PatternFly makes the font choice of Overpass for you, we also consider things like line height, weight and size for paragraphs, lists, and a bunch of other type elements.

Often users will use heading tags based on the style they want, rather than the semantic meaning of the tag. In order to avoid this, we’ve stripped all the styles from the headings and offer classes to style them instead. So you can use that <h1> at the top of your page and apply the .h3 class to get the style you want.

This results in a scenario that is not ideal because our users have to apply classes to all headings for pages that are full of content.

That’s where vertical rhythm comes in.

Using our .pf-vertical-rhythm utility class you can apply it to a wrapper and any encompassing headings will get the weight, size and margin that we’ve defined.

Let’s take a look at some examples.

Below you will see and example of an pretty standard page full of content. I’m sure some of you look at this and don’t know where to start.

Now, let’s look at the same page with a class of .pf-vertical-rhythmapplied to its wrapper:

By adjusting a few styles, we now have a page that looks much better.

Vertical rhythm is not complicated, but it can easily be overlooked if you don’t have an eye for it. We wanted to offer something to our users who would rather rely on a set of predefined rules than come up with something on their own.

By implementing vertical rhythm through out the application you ensure a consistency that your users will be grateful for, wether they know it or not.

This is still a work in progress, we’d love to hear your feedback and suggestions.

Posted by & filed under Forms, PatternFly.


Overview

Problem Solving

Toggle filter addresses the problem of a user frequently accessing filters, repeatedly, and having to select them over and over again. It will allow a user to quickly toggle, an individual filter criteria on and off, and immediately see the results, without having to relocate the filter criteria, via the drop down. It also addresses users knowing or discovering the existing filters and learning what data will be returned when selecting a filter.

Use Case(s)

User of an application, repeatedly uses, common filtering criteria, and wants to be able to frequently vary the return results of the criteria, without having to open and close a filter and relocate the same filters over and over again.

Requirements

The requirements  stemming from the product that some users comp up with the requirement and send email to the [email protected].

  • Toggle filter can be used with or without other filter patterns, but the filters cannot be active at the same time.
  • An application will pre-define the toggle filters.
  • Toggle filtering will not offer the ability for an end user to define which individual filters are used.
  • There is a finite number of toggle filters.

Products already using this UI

Currently, customer portal is using similar UI as below:

 

 

Design

Description

Toggle filter is a component that enables a user to quickly access a common, singular filter criteria. It is displayed as a toggle button group. The application can use up to 4 quick filter criteria.

Example:

Toggle filter used Filter

The toggle filter can be used with or without Filter pattern, however, the filters cannot be active at the same time. When using together with the Filter, the results of the two filters are separate. Toggle filter results are not dependent on the Filter.  When a user clicks the toggle filter, after getting a result from the Filter, the previous filtering criteria (pill) and criteria results will be cleared, and replaced by the new results, based on the toggle filter criteria.

Example:

Design Interaction

1.Toggle filter attributes:The attributes are single select buttons. The toggle filters are not representative of multiple filtering criteria per button. Each toggle button is an “or” command. Only one button can be chosen at a time.The widget style is using the style of the current Patternfly Button Group. See Patternfly button group.

 

2.Toggle filter used with Filter pattern,  toggle filter not in use: When using together with Filter, The filtering results are independent. The widget style will be the same as the current filter UI. Current filter pattern can be found here

 

3.Toggle filter used with Filter, toggle filter in use: When a user clicks the toggle filter after Filter activated, the previous filtering result will be clear and replaced by the new result.

 

4.Toggle filter used before Filter : When a user clicks the toggle filter after Filter pattern activated, the previous filtering result will be clear and replaced by the new result.

 

5. Toggle filter used Filter: In the case that user uses the Filter after having a result from the toggle filter, the filter result will be replaced by the Filter when the Filter is activated.

 

Please feel free to leave comments on Github: https://github.com/patternfly/patternfly-design/pull/362

Posted by & filed under PatternFly, UX Research.


by Melody, Tao & Haley

List views have been used widely across products. After we did some research about the applications list view (Research could be found here) , we find out that we could update and create some new guidelines for PatternFly. Summarized as following:

 

1. New Content Layout Template

Currently we don’t have a content layout template for Pattenfly list view pattern. Following is a new layout template to clarify the content order of the list view pattern.

2.  Alignment rule and Responsive Rule Improvement

Currently Patternfly have two different list view status:

1. Standard List View

2. Stacked List View ( list-view-pf-stacked)

We redesigned the alignment and responsive rule based on the two above situation:
1. Standard list view alignment – The default alignment for the list view row is vertical center aligned. When the screen size is less than 992px, the list view row will change to top aligned ( the same as stacked list view).
2. Stacked list view alignment – The list view row is top aligned in all screen sizes.

List View Row Change Based On the New Alignment Rule

The second and the third row will change form vertical aligned to top aligned.

3. New List View Row Template

“Date” and “Lable” are common element in application, so we try add some new template to PatternFly.

Please feel free to leave comments and suggestions.

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.