edui-2014
edui-2014
0 0
edui-2014
Beyond Putting Lipstick on the PIG presentation at EdUI conference 2014On Github alienresident / edui-2014
Beyond Putting Lipstick on the Pig
Usability Testing and Designing New UIs for Open Source Projects
A personal journeyAbout This Presentation
I am using reveal.js for my slides. They're on githubYou can follow along on bit.ly/edu_pig
I'll post a PDF of these slides afterwards to Slideshare.What you’ll Learn
Usability
- How to conduct usability tests
- How to communicate the results of the tests to generate excitement and commitment to fixing issues
- How to divide solutions into quick wins and long-term fixes
What you’ll Learn contd
Designing Web Systems
- The best way to organize chaos and build a foundation via a style guide and a design pattern library for developers
- How to use modular design to create a sophisticated and highly customizable skin
- How you can contribute to an open source community and share your efforts
What you’ll Learn contd
Selling your work but not your soul
- How to get buy-in from the multitude of stakeholders, committees, and service teams without going insane
- How to bring innovation to a risk-averse IT culture without compromising the design
Mark Reilly
WHO: am I? [down]User Experience ~ User InterfaceUX~UI T-Shirt at UIStencils.com
What: do I do? [down]Contact
@alien_resident - Twitteralienresident - GithubMark Reilly - LinkedIn
Background How to get in TouchBackground
A Common Scenario
A web designer or developer is tasked with adding the institutional branding and colors to a vendor’s software.
Background [down] Most software products these days are created with this in mind: Allowing you to add some lines of CSS and an image. It’s usually straight forward. Find (and skim) the documentation and add the styles and images.Background contd
A Uncommon Scenario
- Researching Users Needs
- Finding Users Problems
- Designing Solutions
- Working with Developers
- Testing to see If Users Achieve their Goals
- and Iterating
Background contd
How was the Product Selected?
- Project Requirements were Drawn Up
- RFPs were Solicited from a Small Pool of Candidates
- Selection is Based on Budget and their Sales Pitch
Background contd
The Result of this Broken Process?
A product:
Pretty Interface Graphics Previously Installed by another Group Prioritized Integrations over Goals Poorly Implemented GUIBackground contd
Then you’re Tasked
To ‘tart’ up the product by adding your institution’s branding.
What you’ll Learn [down]The Muppets Take Manhattan - 1984 (TriStar Pictures) Youtube
So, when I google this last week I learnt that there was a rivalry between Miss Piggy and Joan Rivers. It’s all on the HSN and youtube. [down]Aftermath: Unhappy users
- The system doesn’t meet their needs
-
Users aren’t satisfied
-
You’re frustrated
- You’re unable to get the vendor to change things without additional funds
- You’re not in control of what get’s prioritized
How Can We Change this Cycle?
Selecting Open Source products is a good start.
How Can We Change this Cycle? [down]Why Open Source is Different
In theory you can see the code and make changes In practice this is not always that straight forward A certain amount of technical expertise is need: internal resource or a hired specialist Why Open Source is Different [down]Why Open Source is Different
... “free software” is a matter of liberty, not price. ... you should think of “free” as in “free speech,” not as in “free beer”.What is free software? gnu.org
Why Open Source is Different [down]Why Open Source is Different
“Free as in kittens” Why Open Source is Different [down]Sakai to Replace BlackBoard
NYU decided to move from BlackBoard to Sakai in the Fall 2011.
Sakai to Replace BlackBoard [down] Bringing it back to my recent experience... I was tasked with adding our branding to Sakai and make NYU Classes.Usability Testing
Typical Testing Schedule
- 3-5 users per test
- scheduled 1 test per hour
- allows time to tweak and reset test
- bathroom break
- connectivity issues
Usability Testing
Breakdown of a 45 minute test
- 5 mins introduction
- 10 mins of free exploration and general questions
- 20–25 mins script based test
- 5 mins feedback of the test
Usability Testing
Our Criteria
- Never used NYU Classes/Sakai
- In their own environment — not in a usability lab
- Familiarity with other online class courseware
Remote Usability Testing
Things to Remember
- Describe how the test works
- Obtain verbal permission to record (voice and screen)
- Remind Participant to close private documents
- Pass ‘presenter control’ to the Participant
Communicating the Results
- We done our usability tests!
- We found issues!
- We have solutions!
- Now what?
What to Fix?
“When fixing problems, always do the least you can.”
“Focus Ruthlessly on Fixing the Most Serious Problems First”
Steve Krug, Rocket Surgery Made Easy
Communicating the Results? [down] Steve Krug — of Don’t Make Me Think and Rocket Surgery Made Easy fame If there’s one issue that’s tripping up your users: what’s an easy fix?Explaining the Results
Categorization
- Heuristics
- Measuring
- Weighting
How to Communicate the Results
- Not a dry report that no one reads
- A dynamic presentation
- Show don’t tell
- Present solutions
Quick Fixes
What can you do in the short term?
- Clarify the language?
- Draw attention to the solution using color?
- Add support documentation?
- file bug reports?
Beyond Quick Fixes
A Gut Renovation
Create a reusable, well organized, and easily extendable UI.
- Establish a new foundation
- Remove old CSS hacks
- Use a CSS preprocessor
- Organize and modularize the styles
Beyond Quick Fixes
Organizing Chaos
We’re not designing pages, we’re designing systems of components.
Stephen Hay
Beyond Quick Fixes? [down] In the past, when we designed web pages, we usually started by converting Photoshop mockups to HTML and CSS. We would start in the top left corner and work down the page. We may start with the homepage design or if we were more adventurous we’d start with an interior content page. This pattern is often referred to as designing from the outside in. This worked fairly well with simple static sites. There were only a few templates to worry about. But with more complex content management system this pattern started to be less useful. Often there were pages or variations of pages that were not captured by the initial mockups. The markup was sufficiently different and our styles were too closely coupled that it started to break. We ended up with a lot of half styled pages. In more dynamic system components may be on a page based on context. We can’t always know what’s forsee what's going to be on every page. We now realize that we need to design web systems and not web pages. We need to design from the inside out not the outside in. Design the small discrete chunks of functionality that comprise parts of our sites. In such a way they can be on any part of our site and not tied to one location on a particular page.Beyond Quick Fixes
Designing Systems
Brad Frost Atomic Design Jonathan Snook Scalable and Modular Architecture Samantha Warren Style Tiles Dan Mall Element Collages Beyond Quick Fixes? [down] One common pattern is to design using a component based style guide first and worry about layout at a later stage. This makes even more sense in the age of responsive of design. We no longer have an authoritative layout. Elements will shift, grow and shrink, depending on their context. We can no longer design under the mass delusion of a canonical screen size; be it 960, or 800 x 600 before it. This gives developers a freedom to do what they do best and not worry about design decisions. If a developer his creating the User Interface then someone has not thought this project through.Beyond Quick Fixes
Styleguide driven development
Living Styleguide
- Reusable
- Modular
- DRY
- A Manual (RTFM)
Beyond Quick Fixes
Using modular design practices
There are only two hard things in Computer Science: cache invalidation and naming things.
-- Phil Karlton
Beyond Quick Fixes? [down] Naming things is hard. Organizing a UI system is hard too. Rather than reinvent the wheel I looked at what others were doing and chose the one that made most sense to me and the projects’ needs.SASS
Syntactically Awesome StyleSheets
- Variables
- Mixins
- Extends
- Nesting
- @import & Partials
learn more at sass-lang.com/guide
Getting SASSY: [down]SASS contd
Variables
$instution-color: #fc3;
a {
color: $instution-color;
}
nav {
background-color: $instution-color;
}
SASSY: Variables [down]SASS contd
Mixins
@mixin default-type-size {
font-size: 16px;
line-height: 1.5em;
}
p {
@include default-type-size;
}
footer {
@include default-type-size;
}
p {
font-size: 16px;
line-height: 1.5em;
}
footer {
font-size: 16px;
line-height: 1.5em;
}
SASSY: Mixins [down]SASS contd
Mixins (arguments)
@mixin default-type-size($color) {
font-size: 16px;
color: $color;
}
p {
@include default-type-size(#333);
}
footer {
@include default-type-size(#eee);
}
p {
font-size: 16px;
color: #333333;
}
footer {
font-size: 16px;
color: #eeeeee;
}
SASSY: Mixins() [down]SASS contd
Mixins (more arguments)
@mixin type-size($size, $color) {
font-size: $size;
color: $color;
}
p {
@include type-size(16px, #333);
}
footer {
@include type-size(14px, #eee);
}
p {
font-size: 16px;
color: #333333;
}
footer {
font-size: 14px;
color: #eeeeee;
}
SASSY: Mixins() [down]SASS contd
Extends
%default-type-size {
font-size: 16px;
line-height: 1.5em;
}
p {
@extend %default-type-size;
}
footer {
@extend %default-type-size;
}
p, footer {
font-size: 16px;
line-height: 1.5em;
}
SASSY: Extends [down]SASS contd
Extends contd
%default-type-size {
font-size: 16px;
line-height: 1.5em;
}
p {
@extend %default-type-size;
}
footer {
@extend %default-type-size;
color: #eeeeee;
}
p, footer {
font-size: 16px;
line-height: 1.5em;
}
footer {
color: #eeeeee;
}
SASSY: Extends more
Great for Buttons and Messages [down]
SASS contd
Nesting
nav {
ul {
margin: 0;
padding: 0;
list-style: none;
li {
display: inline-block;
}
}
}
nav ul {
margin: 0;
padding: 0;
list-style: none;
}
nav ul li {
display: inline-block;
}
SASSY: Extends more Great for Buttons and Messages [down]SASS contd
@import & Partials
// _reset.scss
html,
body,
ul,
ol {
margin: 0;
padding: 0;
}
// base.scss
@import 'reset';
body {
font-size: 100% Helvetica, sans-serif;
background-color: #efefef;
}
/* base.css */
html, body, ul, ol {
margin: 0;
padding: 0;
}
body {
font-size: 100% Helvetica, sans-serif;
background-color: #efefef;
}
SASSY: @import & Partials [down]SASS contd
Sass while powerful can be misused. You can create brittle, inflexible, and unmaintainable CSS with Sass as with vanilla CSS.
What you need is an architecture that is modular and scalable.
SASSY: Conclusion [next]SMACSS
Scalable and Modular Architecture for CSS
By Jonathan Snook a web developer and designer, formerly at Yahoo!, He worked on the redesign of Yahoo! mail
learn more at smacss.com
Getting SMACKY: [down]SMACSS contd
At the very core of SMACSS is categorization
There are five types of categories:
Base Layout Module State Theme Getting SMACSS: [down]SMACSS contd
Base
Base rules are the defaults.
html, body, form {
margin: 0;
padding: 0;
}
input[type="text"] {
border: 1px solid #999;
}
a {
color: #039;
}
a:hover {
color: #03C;
}
Getting SMACSS: Base
Essentially, a base style says that wherever this element is on the page, it should look like this.
[down]SMACSS contd
Layout
Layout rules divide the page into sections. Layouts hold one or more modules together.
#article {
width: 80%;
float: left;
}
#sidebar {
width: 20%;
float: right;
}
.l-fixed #article {
width: 600px;
}
.l-fixed #sidebar {
width: 200px;
}
Getting SMACSS: Layout [down]SMACSS contd
Module
Modules are the reusable, modular parts of our design. They are the callouts, the sidebar sections, the product lists and so on.
.pod {
width: 100%;
background: #ddd;
}
.pod input[type=text] {
width: 50%;
border: 1px solid #666;
}
Getting SMACSS: Module [down]SMACSS contd
Module contd
.pod {
width: 100%;
background: #ddd;
}
.pod input[type=text] {
width: 50%;
border: 1px solid #666;
}
.pod-callout {
width: 200px;
}
.pod-callout input[type=text] {
width: 180px;
}
<div class="pod pod-callout"> ... </div>Getting SMACSS: Module [down]
SMACSS contd
State
State rules are ways to describe how our modules or layouts will look when in a particular state. Is it hidden or expanded? Is it active or inactive?
.tab {
background-color: purple;
color: white;
}
.is-tab-active {
background-color: white;
color: black;
}
Getting SMACSS: State [down]SMACSS contd
Theme
Theme rules are similar to state rules in that they describe how modules or layouts might look.
/* in module-name.css */
.mod {
border: 1px solid;
}
/* in theme.css */
.mod {
border-color: blue;
}
Getting SMACSS: Theme [down]Contributing to an Open Source Community
Goals
- Empower designers and developers
- Enable them to easily change colors and branding.
- Enable them to dig in deeper and make substanial changes.
- To avoid this scenario.
.maintext {
color: #333333;
}
[...]
.maintext {
color: red !important;
}
Contributing to an Open Source Community [down]
It doesn’t matter what system you use but that you use a system. What you want to create is a consistent system that is approachable to others. The goal is to empower developers where they aren’t forced to just add counter styles to the both of your stylesheet.
Contributing to an Open Source Community
People will generally be supportive of your efforts.
- Get on the mailing list: get a sense of the community
- Read the FAQ and look through their documentation
- See if there’s a post on their bug list or issue queue
- If you need help; check to see if your question has been asked and answered before
Contributing to an Open Source Community
Not a developer? You can contribute in many other ways.
- Usability testing
- QA testing
- Documentation and writing
- Community organization
Contributing to an Open Source Community
Four Levels of Engagement with the Community
- Implementation: Add your code
- Evangelism: Tell people about it
- Documentation: Explain it
- Support: Answer question and fix bugs
Bringing Innovation to a Risk Averse Culture
People demand innovation but without change.
It's a long process
Bringing Innovation to a Risk Averse Culture: [down] It took an additional year to get the new User Interface into production. As the original deadline approached and QA work was well underway. The plug was pulled on adding the new UI to the project. The pilot had been a success. The full migration was underway and within in 3 months of the project‘s final deadline. The heads of the project were nervous and were afraid of changing things at the last minute. The wanted to tie a neat bow on the project and throw the wrap party. This to say the least was difficult for me. I had put a lot of work into the new UI and really believe it was going to be helpful and solve problems that I knew our users faced. Fortunately, I had taken a UX leadership course with Kim Goodwin. I knew that change is not easy and doesn’t happen overnight. Kim stated that it can take 3-5 years to get an organization to change. but that it’s takes a long time but it’s vital to get one project out there that can be an example to others of how UX works. I knew I had to persevere and no take no for an answer. Kim had talk a lot about culture and how this was a vital part of change. The university was a clan like structure. Lots of little groups that want to have their say and need to be listened too. It took about a month to get an outline of the concerns that the project leads had. They were wary of changing things and upsetting the users. They outlined a number of steps that needed to be done for them to see this project through. I suggested that we follow the example of Google and Facebook and have a opt-in design preview. An ability to toggle between the new and the old interface. Allowing users to look at the new design in a time of their choosing and allowing them to submit feedback.Getting the new UI into Production
Or the 12 tasks of Hercules...
It's was a very long process!
- Design review with the group responsible for the University’s Branding and Design
- Two technical reviews:
- with the internal front-end developers
- with the community — Gonzalo Silverio the original Sakai portal developer — asked for the work to be committed back to Sakai.
Getting the new UI into Production
- Two rounds of informal usability testing for fine-tuning
- A formal A/B usability test
- Two reviews with the faculty’s User Advisory Group. – They contributed a number of valuable suggestions that were implemented.
- Two rounds of Quality Assurance testing by the NYU Classes service team
- Two rounds of CSS bug fixing.
In Conclusion
Why you need to do a Usability Test!
- Insight Into Understanding the Problem
- Focus on the Users Goals not the Technical or Aesthetic Issues
- Observed User Behavior Instead of Opinion
- Creates Awareness of Issues to Stakeholders
- Builds a Consensus to Solving the Issues
In Conclusion
After you've Done a Usability Test!
- Communicated the Results: Both Problems and Solutions
- Quick Wins are Best
- Focus on the Most Serious Problems First
In Conclusion
- Where Possible: do More
- Embrace Open Source
- Contribute Back to the Community — in Your own Way
In Conclusion
- Change is Hard and it Takes Time
- You Need to Bring People to Your Side
- Test Your Changes: Proof is Vital
- Communication is Key!