Development – Minotaur Design

It’s Users All The Way Down

Sometimes in the process of defining your users, you’ll discover that, much like turtles, there are layers upon layers of them just waiting for their stories to be told.

Background

Joining a company late in 2014 as their new UX professional (and founding member of a growing team) has been an eye opening experience. Not only have I been able to finally practice what I’ve been preaching and learning the last few years, but I’ve been exposed to the healthcare industry – which is entirely new to me. Tons to learn = tons of fun.

Anyone in experience design must carefully consider their users’ goals, circumstances, capabilities and habits. This is one way for us to get out of our own heads and as far into our users’ heads as possible – avoiding the trap of designing for the users we’re most familiar with: ourselves.

Identify the users we’re serving is a great place to start. This sounds simple and it can be – but it can also be a complex puzzle (with all the edge pieces hiding and the corner pieces eaten by your dog.)

What my company does

At a high level, we provide a secure and efficient communication platform for the healthcare industry. The platform helps patients, practice staff and hospital staff efficiently contact physicians.

The problems we solve:

handling the bazillion ways that physicians within a hospital or practice setting need to be contacted depending on situational context.
sending information to a physician in a way that is secure and does not violate laws around the privacy of protected healthcare information (PHI).
maintaining a fine balance between the needs for privacy and accessibility on the part of the physician.

Who are our users?

User (Turtle) #1: Our external users

This group includes doctors, nurses, acute care staff and hospital / practice management. They’re the obvious answer to the ‘who is our user’ question – the system was designed to meet their needs and everything revolves around maintaining and enhancing the capabilities that our platform extends to them.

If we push out a buggy feature or misjudge the utility of an enhancement and sacrifice something more vital, these are the people who feel it the most. We should be in close contact with representative members of this group, testing things out and gathering feedback constantly. This group will (and should!) receive the highest prioritization when it comes to evaluating features, to doing user research and to planning and executing usability testing. That said, don’t stop here!

User (Turtle) #2: Patients

Our healthcare professionals are themselves serving another group of users: their patients at member hospitals and practices across the country. These are the folks that our external users are under oath to care for, and who they went to school for a dozen years to serve.

This is the group who pays the price for inefficient communication practices. It’s the folks who have seen their premiums and deductibles climb year after year and who in too many cases don’t have insurance at all. They pay dearly for any healthcare they receive. This is you and me, when we visit our family doctor or when we land in the emergency room after falling off the roof in an ill-advised attempt to save money on chimney repair.

While we can’t prioritize designing for this group over the others, we should always consider the impact of our decisions on these people.

User (Turtle)#3: Internal Users

We have another group of users not immediately obvious to the naked eye: our internal users. These are the folks that use a suite of applications to onboard new external users and that support their needs on a 24/7 basis, 365 days a year.

They don’t use the exact same set of tools as our external customers, but they’re touching the same data and hitting the same systems. Their needs are also much more diverse since they service every type of external user and must become experts in the task flows for those users. This is no small feat, as the training required for these folks to become proficient runs from a full week to a staggering 3 months.

When considering the needs of this user group, striving to avoid introducing further complexity is a big priority. Beyond that, a large part of your backlog might revolve around taking steps to reduce that complexity even further (and therefore lighten the cognitive load of using the system).

If you’re in this situation, your company’s bottom line could be affected nearly as much by internal facing changes as it is by changes that affect your external users.

User (Turtle) #4: Executive Team

You’d think we had all the bases covered, but there’s actually one more group of users to touch on. Let’s call it the owner/executive team, made up of company ownership and senior leadership in both your external users’ companies and your own organization.

The goals and tasks of this group tend to be pretty straightforward, and sometimes seem pretty far removed from what the other three groups of users are concerned with. That said, while I don’t recommend placing too much weight on designing for this group, I do believe it’s a mistake not to consider their needs. Pulling off a win-win effort that enables this group to hit their goals tends to be a self-reinforcing success for a company.

Wrap Up

If you only take one thing from this article, know that accommodating anything less than every group of users in your designs is a Bad Thing.

Imagine that your executive team has seen the effect that your team’s UX design and development work has had on the bottom line – and so they foster a culture that values and encourages such efforts on an ongoing basis. This belief is folded into the company’s core values, and soon the sales, support and product development teams are all on the same page.

Your external users consistently see improvements, enjoy using your product and feel that their feedback is valued and acted upon. Inevitably these happy professionals pass those benefits on to their own customers . For our patients user group that manifested through cost savings, less time in the waiting room or waiting on a surgery date, and better quality of care.

Your internal users don’t have to jump through hoops to support the customers since the support tools they have been given are performant, intuitive and easy to use.

Wouldn’t that be a beautiful place to work? Are you ready to make it happen?

Design Constraints Are Awesome

While reading some material recently I was particularly struck by a correlation between the sentiment of “designing for monochrome first” (for color deficient users) and the design movement termed “Mobile First”.

In both cases, the designer aims to build their interface elements such that the largest % possible of users will have accessibility to the data, based on the real and perceived limitations of the environmental factors imposed. After baseline accessibility and usability you can worry about nuances and aesthetics.

Monochromatic vision strips the designer of color-based tools and techniques, forcing you to fallback to the use of shape, contour, contrast and pattern. The Mobile First design sensibility forces the designer to carefully prioritize what elements of the design are truly needed to accomplish the goal(s) of the product, framed within the limits imposed by a smaller display. You also have to consider the contextual differences in usage between a mobile device and a desktop computer, and within the vastly different feature sets of modern devices.

I often hear about project constraints in terms of drawbacks, of obstacles to building the perfect widget. It’s much more helpful to think of constraints as helpful wayfinding elements on the road to successful project definition. If you know what they are, you won’t waste time in rabbit holes and you’ll be able to focus your time and attention on crafting the best product possible – one that will meet the unique needs of your users, whether or not they can see colors and regardless of what they’re using to access your offerings.

Notes from CodeStock 2014′s “Regular Expressions” presentation

Brian Friesen’s talk on Regular Expressions was probably my favorite of the conference. You gotta admire a guy who builds a regular expression engine to properly demo and train folks up on the ‘devil’s language’ (as I and others I’ve known have called it)… Folks that hate regex and those that live and breathe the stuff all got something from the session. Good stuff.

Regular Expressions – now you have two problems

Brian Friesen
@brianfriesen

Works at Quicken Loans (side note, I used QL last year – hands down the best UX I’ve ever seen in a mortgage product/service)

github.com/QuickenLoans/RegExpose

Regexper.com

Regular-expressions.info

The Bible:
Mastering Regular Expressions by Jeffery Friedl
– can read the first 2/5 of the book and you have enough
———————————————————————–

1. RegEx are hierarchical

Root node = the whole expression

ABC would tree out like this:

ABC – root
A – character literal
B – character literal
C – character literal

2. RegEx do their thing sequentially

A RegEx will match if each of its child nodes matches in sequence
After a match, the RegEx engine will continue trying to find further matches until it has covered the entire string.

RegEx are by default case-sensitive

Character classes are surrounded by square brackets
– for a range, use a dash.
– if you need a dash in the match, put it at the beginning of your set within square brackets
– you can also include specific characters or numbers to match against
– can include a-z and A-Z, or you can pass an additional param to ignore case
– a negated character class = add a “^” carat character before a match. ie [^a-f0-9] would ignore a-f

Shorthand matches
– \d is the same as [0-9]
– \D is the same as [^0-9]
– \s matches whitespace chars
– \w is the same as any word character, meaning [A-Za-z0-9_]
– . matches any character, depending on options (ie except for new line character)

Alternation
(it’s a pipe dream)

| character means “or”
– linos|tigers|bears ‘lions’ would match, but regExp doesn’t know if its the BEST match, so it saves state (a breadcrumb) and moves to check the other choices.
– if a match hits on the last option in a set of choices, no state will be saved, no breadcrumbs etc.

Quantifiers (quantifiers are always AFTER)
(Because sometimes, quantity trumps quality)

Greedy Quantifiers (greedy means quantifier always wants more, ie. will keep going)
——————
– ? = optional
– * = will match zero, will match many
– PO*P would match “PP” as well as “POOP”
– + = must match at least once to succeed
– NO+! would match “NO!” as well as “NOOOOOOOOOOO!”
– {} = match a specific number of things
– \d{3} = this means match exactly 3 digits
– \d{3,15} = this means match at least 3, but up to 15
– \d{3,} = this means match at least 3 with no high end limit

Ultimate lazy quantifier: .*

Causion against using “*.” – can lead to a match failing since the greedy ‘any character as many as possible’ matching could lead to skipping more specific matches after the *.

Lazy Quantifiers – will only match as much as is needed, without going overboard
Once a match is made it will pass control to the next match paramater until it’s needed again…
—————-
.*? = Lazy
{3,5}? = also Lazy (in this case, once 3 digits were matched, the next node in regexp would be matched)

– ab.*?cd would match “abc12345cd” with the lazy quantifier returning to the ‘c’ character repeatedly before going back to the next number character

More alternation
—————-
(?:white|dog|brick) house
– match against “dog house”

Quantifers + grouping
———————
(?:NaN)+
– match against “NaNNaNNaNNaNNaN”

Notes from CodeStock 2014′s “Angular Is Awesome” presentation

Josh walked us through building a simple Angular app, using the lessons learned from Wintellect’s recent dev and launch of a global enterprise software app.

Angular is for AWESOME!
Josh Carroll
@jwcarroll
technofattie.com

The code
github.com/jwcarroll.ng-contacts

directives – typically an attribute on an element
————————————————-
ng-app
ng-init (used to inject a title in his demo)
– ng-init=”contacts=[bob1,bob2,bob3]”
– plugged it in with {{title}}
ng-model
– he bound an input to the ‘title’ var he had leveraged in the injected title
– ng-model=’title’
ng-repeat
-ng-repeat=”contact in contacts”>{{contact}}
ng-search
– “searching by ‘{{search}}'”
ng-if
– truthy comparison results in rendering the stuff
– empty string resolves to 0 so nothing would render

ng-controller – find the controller, and hand off DOM control to the controller by adding ng-controller to an element (ie a containing element)
– ng-controller contactListCtrl as ctrl (do a one time all inclusive effort to make $scope aware of all your controller’s functionality)

ng-view (a new html tag by virtue of angular)
– ala

ng-animate – a way to harness css3 animations

General
pipes (|) are filters. (think gulp)
– takes in something and returns something
– example was var AgeFilter (which returned a function as the filter)

$http as a param passed to function
– this.$http.prop etc.
– _this.$http.get(){
.success(callback) //this is a promise
}
– same for delete, etc

Modules
– used an IFFE function
– a module is a container holding the stuff related to the application

Controllers – just a JS object
$inject = a way to tell NG you need a component (used with $scope)
– $scope being where the data binding happens

Lodash (_. prefix)

Services
– must register a service
– can inject a service into a controller

Routing
– ngRoute (out of the box routing within angular)
– colon (:) is a routing parameter
– as in /contact/:contactId?
– routing as SPA method.. each route can be passed a different controllers (essentially a path-specific template) etc.

Handling when a route fails (ie error handling)
– he made a new js file: routeError.js (again, directive is a new html tag)
– which contained a new directive

Notes from GiantConf 2014′s “Building a Whole Team UX Design Team” presentation by Phillip Hunter

In his presentation on day two of GiantConf 2014, Phillip Hunter talked to us about “Building a Whole Team UX Design Team”. Here are my notes from his talk.

Phillip Hunter – Building a Whole Team UX Design Team
@designoutloud
http://www.minotaurdesign.com/blog/wp-login.php

His belief is that in the UX community, team building is much like early days in baseball scouting.

The focus on stereotypes:
on rock Stars in the industry…….
(is that a person w/ diseases and who trashes hotel rooms? lol)

On Ninja’s….
(is that the person who kills people in the night? lol)
Focus on design mishmash – (beanie/knit cap and glasses, lol)

– Stereotypes don’t help us build better UX teams. Avoid them.

(slide of the major pieces of most companies) – All these people are ENABLING the user experience.
– most of us are in Product development team.
– so it’s silly to think of one small piece of the org as wholly responsible for the UX of a company

4 primary capabilities (as a grid):
– engineering leading technology
– maintaining strong teams
– running a successful business
– enabling great experiences

The practice of creating experience is a SERVICE – look to service design for cues

Strategy means defining and inspiring before hiring

Hiring a dev, designer, tester because you need to developer, design and test is premature.

Context + capability to help you know the best way to create that holistic UX mindset.

OAQH- Orient, Assess, Question, Hypothesize

Setting the team-building CONTEXT:
– what are our goals, values, constraints and principles as a corp?
– what do we need to get done?
– why?
– how much/how fast?

Setting capability requirements:
– What do we need to be god at?
– How good? How will we know?
– What are our priorities?
– Not who…. (yet)

Liz Bacon’s infographic on her definition of user experience design
– pie chart of sorts
– ranked herself within each facet

Building effective structures within the company:
– Complementary strengths vs homogeneous development
– Breadth and depth of skill across people
– Increase participation

Beyond hiring and skills:
Shape align and inform with biz goals
Aim for impact, scope, scale, diversity, resilience, sustainability

Crazy list of necessary skills (all of which mapped back to the grid of 4 above)

Atomic elements of necessary high level skills

Have the right project members been identified?
In what areas will augmentation be the best thing?
What kind and from where?

Building Your list of necessary Skills
Skill name
-skill 1, 2, etc becomes `> color, line, shape 2. Latent need identification, ebrand integration, prototyping, etc.

Gathering list items:
Ask your UX leaders and ICs, your UX enthusiasts, your Product owners, your Execs and sponsors.

(ranking 1-5 etc)
Skill name – Current Level – Desired Level – Priority
– – – –
– – – –

Perceived skill gap
– gap value on its own wasn’t that compelling/illuminating
– Gap value multiplied by Priority – this really surfaced the true GAP in context

Conversations that can come out of the above types of analysis?
Who does that already?
How can you get them involved?
What do your colleagues want to be good at?
X is how we need to craft our job description for HR!!!

sixboxes.com
framework for aligning people’s desires with their roles, and ultimately their ideal internal path that also benefits the company

– issue challenge to add UX to everyone’s job
– Let people find their point of contribution

HIRING (since sometimes you just have to…..)
– understanding and implementing the strategic framework from above
– involve the team to determine fit and talent
– Hire the inspired

Phillip’s slides (Thanks, Phillip!) – http://www.slideshare.net/philliphunter/building-a-whole-company-ux-team

Notes from GiantConf 2014′s “Embracing the Suck” presentation by Chris Harrison

In his presentation on day one of GiantConf 2014, Chris Harrison talked to us about “Embracing the Suck”. Here are my notes from his talk.

Chris Harrison – Embracing the Suck – 10:45a Thursday, June 12

@cdharrison
cdharrison.com

Embracing the Suck: Military phrase meaning to make the best of whatever situation you’re in..

Background:
– Weight loss – 529 to 377
– weight gain due to being depressed, hating what he did, etc.
– Making sites since 1996.
– Former fulltime freelancer
– now: frontend dev for Morris Communications (magazine division)

2013 state of the workplace
30% engaged and inspired
18% actively Disengaged – sabotage their coworkers (cost 450-550 million a year)
52% permanent case of the mondays – do just enough not to get fired

Sometimes you just gotta suck it up.
– Consider the alternative – it could be worse.

– dan willis, “great takes work”
– choose your battles and spend your energy wisely

Negativity is a cancer! (this could be a talk topic!)

Sometimes complaining takes more effort than just getting things done.

Don’t fear new. New = opportunity. (he was told he’d be doing all joomla and drupal work. This was not happy news)
– learn on the companie’s dime
– doubtful he could have learned this stuff as a freelancer (no time/money in it)

Everything you do is a learning process for everything.

– thomas edison’s quote about opportunity and how it looks like work.
– fabio at mailchimp, lead html email designer. was hired to do ui/ux, but they approached him to do HTML emails.
– we know as an industry that html emails suck.
– when he heard this, he embraced the challenge.
– 5 years later he’s an innovator in a field where it was thought there was no room for innovation left.

Opportunity opens doors…

Help your team…
– concept of jumping on hand grenades (someday you’ll need help from the person you help today)

Small wins are still wins. (make it something awesome despite the scope)

Make learning a priority
– learning about sass etc and givng talks about it.
– things suck less when you share what you know with your coworkers
– codeschool etc. as good options for continued learning.

“Sneak” new technology/techniques into projects, but strive to get buy-in from your coworkers (if not management)
– Demonstrate the benefits of incorporating these new techs into an existing workflow

Find creative outlets
– draw more.
– starting doing illustrator avatars for friends
– take pictures! (vader, ninja turtles)
– lilvaderadventures tubmler

Scratch your own itch – side projects rock
– itembrowser.com – his first responsive project
– learned media queries, etc.

Start using your powers for good
– jingle jam (10k) benefiting safeHOMES charity
– design + development + marketing
– someone could really use your talents!

Happiness depends on ourselves – aristotle
Even sucky work can make you happy. Give it a chance.

Notes from GiantConf 2014’s RWD workshop with Brad Frost

In his RWD workshop this last weekend at GiantConf 2014 Brad Frost plowed through the history, current state, best practices and possible futures of the RWD philosophy/approach. Here are my notes from his talk.

June 14, 2014

His experience: web on mobile for 4+

Responsive Design Patterns
ThisIsResponsive.com website and github (http://bradfrostweb.com/blog/web/this-is-responsive/ & http://bradfrost.github.io/this-is-responsive/index.html)
(older site) – Mobile web best practices
WTF Mobile Web (what not to do)
Cosigner of Future Friendly Manifesto
Worked for R/GA at one point…showed the company logo slide to illustrate that no one knows what they’re doing.

General Landscape

i6bb mobile subscriptions
in america, 91% of americans have a mobile… 56% of those are smart phones.
1.5 mm android activations a day
1/3 americans have an ereader/tablet
20% of ALL internet traffic is mobile
68% of americans access the web via phone
33% of those ONLY use the mobile web
Mobile web pictogram –
157mm users ONLY use FB from their mobile
What are we sharing from mobile on social? (text photos videos and LINKS)
51% of referral traffic to media sites came from FB mobile
blog.cloudfour.com – good status on mobile – a comprehensive guide

Approach – Options

Do nothing. (rant: cultivating a nation of slide swiping screen surfing zombies)
Make an APP!
- App glut
Links don’t open apps
pros and cons of course
Separate Design Experiences (Nielsen’s advice, to build two sites and cross-linking to make it work.)

more dedicated, optimized, catered experience
no need to adapt
potential to be more performant
url redirection (getting a mobile version of a site on your desktop due to a link given to you)
content parity
content governance
device database
SEO issues (better to keep your links under the same single site)
Continuity issues
The Space Between (kindle fire, etc.)

Strategy

Build a barebones mobile responsive site, and grow it over time.

eventually kill the old clunky desktop site

Responsive retrofitting a site

j spool’s ‘escalator of acquired knowledge’ (people hate when you completely tear down and rebuilt their beloved sites)

Mobile First (progressively enhanced, future friendly, awesome)
Piecemeal approach: “our responsive header is almost done”
- seen on really huge sites in recent times. footer, header, module by module
- acclimatizes the user
- he’s only seen it in large companies, but he thinks it could work very well for small

Foundations

Ethan Marcotte @2010 in ALA
Fluid Grids, Media Queries, Flexible images
the Fluid grid should do most of the heavy lifting! (don’t go crazy with media queries!)
Context is needed
- Adaptive is a bigger container than responsive, and itself contains responsive
There are other parts, but RWD is what stuck.

Feature Detection
Server side components*
interdevice communication
performance, etc.

Principles of Adaptive design

ubiquity (this is for everyone, for anyone, for us all

diversity is not a bug, it’s an opportunity) – step reiger
mobile users will do everything desktop users do, if it’s accessible.
Content parity
Context
- Quantitative
- Qualitative

flexibility

embrace the squishiness

performance

71% of mobile users expect mobile sites to load as fast or faster than desktop sites
you have 5 seconds of someones time…

Future friendly – Invest in your content. -> Make APIs, not war

Frameworks

Bootstrap, Foundation by Zurb, etc.
Jetstrap/Bootkit
- these are all well and good, but lead to look alike issues
- One-size-fits-all
- Potential for bloat/unneeded stuff
- might not do what you need
- integration issues
- have to subscribe to someone else’s decisions
Tiny Bootstraps, for every client. – Dave Rupert
Front end style guides
promotes consistency cohesion
easier to test
better workflow*
creates a shared vocabulary
useful reference
Lots of front end style guides coming out (started with starbucks. starbucks.com/static/reference/styleguide)
problems with these:
- Time consuming to create
- treated as an auxiliary project
- often too abstract
- often seen only as a designer/development tool
- created after a project launches
- often incomplete, only serving present use cases
- often lack a clear methodology

Atomic Design

josh duck’s periodic table of html elements
@dmolsen
Abstract ————————-> Concrete
Creators ————————-> Clients
Atoms, Molecules, Organisms, Templates, Pages
Reference, Build, Build, Build, Reference

the pattern

ATOMS (input field)
Molecules (search module)
Organism (site header)
Templates (site header bundled into a whole page template) -focus on content structure (reference to mark boulton.co.uk – content strucure first, not required to have content first)
Pages (the pouring in of real & true representative content to see if it all works)

validate or invalidate the atomic design thus far
you test variations of the template at this point (still the same template though!)
does it scale? (content length, list item length, etc.)

pattern lab

@dmolsen Dave Oldsen and Brad created it
Open source project
What is it?
- It’s a design system BUILDER
- designed to help you execute a design system
- a custom component library
- a pattern starter kit
- a practical viewport resizer
- an annotation tool

It’s NOT:

a UI framework
Language, library, or style dependent
Incredibly rigid
“just” a pattern library, but also not a prod ready static site generator
..like Jekyl

moving parts

builder
viewer
- ish (gives you a different value every time (small button gives you a smallISH value)
- Lets you rapidly preview random and different layout scenarios
- displays the size of the display currently in view.. as px and ems. Annotations
- his issues with wireframes in general… long assed annotations, iXds are working in a layer of abstraction
- The annotation tool couples numbers with an overlaid layer of annotated description
- Annotations with JSON
- Lineage
- Shows off what components make up a particular component, and where its applied.
  - ‘X pattern contains the following patterns’
  - ‘x pattern is included in the following patterns’

Other stuff

code view
pattern status
auto refresh
page follow
Future: plugins
idea of checking your performance budget whilst developing with Pattern Lab

What’s the hardest aspect of responsive web design?

design/dev or people/process (overwhelmingly process/people)
Entertainment Weekly
you have to sell people that RWD is the right thing
- using data (showing conversions, improvement metrics – hockey sticks)
- SHOWING not TELLING is a lot easier to sell through to clients
- talk about the simplicity of the 3 pillars (flex grid, resp images, media queries)
- why RWD matters, selling to Tiffany in his R/GA days:
  - He took a representative page from their site… (their desktop site), and demoed how it COULD be if set up properly
    - It took him half a day…
    - they then took a crapload of devices and spread them out on a long table… two tabs open on each device one for now vs possible Set Expectations
  - Don’t sell websites like a painting. Instead, sell easy and sexy access to content, agnostic of device, screen etc.
  - Kill the waterfall! IA->VISUAL->DEV = no good Interface Inventory
Much like a content inventory, but more specific
pick out, cluster, and inventory the buttons, inputs etc. – this illustrates the differences, similarities, the scope of the current interface situation
This helps you gauge LOE on a redesign!
Document your interface
Promote consistency
Establish which elements will be challenging to translate into RWD
lays groundwork for future style guide/pattern library
Evernote for Interface Inventories – Aaron Gustafson

Establish Direction

before too long, you can design for the content structure you KNOW will exist
use of style tiles for visual direction – more specific than a mood board, but not getting too far down into the weeds
use of Typecast for brainstorming and playing with potential typographic treatments

Rolling up your sleeves

build out basic patterns based on design sketches
moving into element collages (still not full comps)
often start with header and footer
often end up with odd states.. ie a finished header and footer but very rough main content well – this requires frequent communication with client so they know how the process is flowing
A traditional comp might not happen until nearly the end of design process …and might be a coded comp vs a photoshop comp

Responsive Patterns

he collected design patterns, in b&w & very barebones. (thisisresponsive.com)
created to avoid re-explaining patterns again and again Layout

Grids

Which grid system should i use? (he doesn’t care 😉
Css tricks.com don’t overthink it grids
Future of CSS Layout
Grid Layout
Flexbox (see solvedbyflexbox.com)

Media Queries

avoid desktop-first styles (don’t set defaults only to have to overwrite them!)
mobile first styles start from the perspective of small (using min-width vs max-width)
the absence of support for media queries is in fact the first media query. – Bryan Rieger
Let CONTENT, not screen size, determine breakpoints
Start with the small screen first, then expand until it looks like shit. Time for a breakpoint! – stephen hay
HAY mode in Ish (in hay’s honor)
use of EMs in media queries – no longer a strict best practice, but a matter of preference
Still recommend using relative units (he has no pixel values in his styles)
Use major AND minor breakpoints (minor being a component level breakpoint or page level breakpoint)
don’t overdo it
??? about localization and media query usage (german text is longer….)
option 1: use the longest localization by default (his recommendation)
option 2: apply a differentiator (addl class on the body tag etc.) and add/modify german specific styles Multi-Device Layout Patterns

Mostly Fluid patterns

The Column Drop
be careful that the stuff in the sidebars isn’t necessarily related to the main content (due to content hierarchy concerns)
The Layout Shifter (brad voids these if possible, preferring simplicity)
ie a complex, unique layout that really changes across breakpoints
Tiny Tweaks – ie very little changes..
minor font size or margin changes
The Off Canvas (jason weaver – jasonweaver.name/lab/offcampus)
stuff hangs out off screen until needed
Content Choreography
content folding (ie folding ads in between articles)
could use flexbox (jordanm.co.uk/lab/content)
could use AppendAround: a responsive Markup Pattern
from Filament Group
Don’t use this all the time, but it could help solve certain issues

Layout considerations

When users scroll on mobile we are moving backward through time
moving through a list
deep dive into content
All these instances are scrolling through a singular content type
don’t mix up your content types when you put stuff into a single column with RWD.

Conditional loading:

given the % of sites that push the same heavy content to mobile as desktop…
Aggressive enhancement (nice term)
The Thing (a) beside and above NOT The Thing
Instead, include links to the “not the thing”s by fragmenting out that content
put these fragments behind a lazy load and a user opt-in (via accordion for example)
old browsers treat as links to different pages
newer stuff fetches via ajax and drops it into the expanded module
Larger format views display the whole thing by default
(24ways.org/2011/conditional loading for responsive designs)
Boston Globe does this with their weather widget
either drives to a different page OR
displays inline via async call How to do this?
Matchmedia.js (has polyfills too)
enquire.js
Conditional CSS (adactio)
Progressive disclosure as a term http://en.wikipedia.org/wiki/Progressive_disclosure
Scanability vs capability is a balance
It’s ok for different users to get a different experience as long as functionality remains accessible
Screen size is just ONE variable.. (touch capability, etc. are others)
Large screens do not always mean fast connection !!
you can generalize somewhat
you can TRY to detect bandwidth but it’s complex
things like Boomerang test bandwidth by pinging all the time (hard on batteries ouch)
Just design a fast experience!
be mindful of the # of http requests
look into server-side optimization

RESS ala Responsive Design + Server Side Components

lukew.com ‘s article
described as a scalpel
if on a mobile device, don’t load (this annoying thing)
if on desktop, DO load (this crazy thing)

Touch (ala accommodate for meat sticks)

hybrid devices make things complex (windows tablets, Chrome Pixel, etc.)
assumptions around touch targets, margins must be questioned
keep everything touch friendly by default
same issues on phablets (save for tests for touch etc.) Touch considerations
don’t rely on hover states (don’t put important stuff there)
if the info isn’t important, defer it (ie to a product detail page)
or have it toggle display via touch.. BUT
touch implies intent, so you can run into trouble here
touch to toggle content is anticlimactic if users were trying to DO or GET something vs just exposing content
Patrick Lauky – good source for touch related experimentation
Look for opportunities to provide enhancements for touch devices, such as swipe gestures
but be careful. careless touch input can result in unwanted effects or false positives.

Navigation

Navigation should be like a good friend… there when you need them, but cool enough to give you your space.
don’t make users scroll through lots of nav to get to content Tactics
Do nothing (leave nav as is)
doesn’t scale for larger navigations
Footer Anchor
nav clicks drive user to footer via named anchor (no js used)
somewhat disorienting (might be a good baseline pattern to be enhanced further)
The Select Menu (ie. the drop down menu)
good for non-primary navigation
The Toggle (the current go to best practice)
Content slides down and exposes navigation
elegant
keeps users in place
relies on javascript
The overlay (variation on the Toggle)
does not drop content down
unwanted link navigation on older devices (ie click goes to lower stacked element anchors)
unwieldy (he tries to keep things on one plane)
The nav flyout
pro & con: Able to display LOTS of nav items
the go to for content-heavy sites
consider content inventory/strategy if you’re having to deal with a super long flyout menu
The Priority + considerations approach
Partial exposure of nav based on priority, with ‘…more’ link to expose the entire nav
not a fan, but considers it worth exploring
The HIDE and CRY
no nav on mobile (ack) that comes close to desktop experience
muy mal “mobile users don’t do/need that…” Complex Navigation
The Multi-Toggle
ie. nested accordions ad infinitum
behavior variations with touch devices.. (primary nav no longer can drive to a page, but must expand the subnav as only choice)
Solution: add another item “all x products” effectively acts as the click through for touch that desktop had.
Right to Left (nav panes slide left or right based on clicking nav arrows in nav)
follows nav convention of drilling in/out
right = deeper, left = shallower
sony did this, but is no longer using it
Skip the Subnav
on small screens, just drive to the nav item’s landing page and then expose the sub navigation
the main downside (but not a huge one) is you are forcing a full page refresh to get to desired destination

Navigation considerations

Find the balance between nav access and obtrusiveness
Test!
Be explicit about the nav icon (as much as you can)

IMAGES

avg 1.78mb page load —- 1.12mb of that are images. Images are a huge issue.
various screen sizes
growth of high res screens
varying bandwidth
need for art direction ie diff crops, etc.

background images

these work as advertised, ie they behave properly in media queries
ie multiple backgrounds aren’t downloaded
use mobile first background images
don’t include large by default, introduce them in a media query block
Icons
many times they don’t look good on hi-res screens
use of ICON fonts is growing, and becoming a best practice
IcoMoon – quickly choose or build your own libraries and generate your own iconFont
Web Fonts (including Icon fonts) are NOT supported in a couple key browsers
Opera MINI – a proxy browser preloaded on many feature phones and smart phones
(proxy browsers end up taking very little bandwidth)
Older Windows Phone devices don’t support them.
Grumpicon converts images or svgs as data
can also use png image fallbacks
Grunticon output
important stuff -> All icons inline in the css as vector svg data urls (better support)
all icons inline in the css as PNG data urls
All of the icons referenced externally as png images, which are automatically generated from the source SVG and placed in a directory alongside the CSS files

Image Considerations

Vectorize all you can
use HTML special chars
use icon fonts, but with fallbacks (SVG)
If you use sprites, consider making a hi res sprite sheet
Semantically important images
preserve aspect ratio (brucelawson.co.uk preserving aspect ratio)
Avoid text as images!!! (duh)
Responsive image considerations
Ensure content is legible on small screens
Larger dimensions, higher compression rate (blog.netvlies.n/design-interactive/retina-revolution/)
Looks great on hi res screens and regular screens
repainting the canvas is expensive performance wise (affects any fluid image)
still doesn’t’ provide art direction (example: obama at car factory – crop needed for mobile view)
only make 1 image request per asset
load the small image asset by default
consider server-side detection
WHATEVER you do, make sure it’s easy to swap out. It WILL be deprecated 🙂
Art Direction
Focal point cropping: – designshack.net/articles/css….
HTML5 Picture element is solidifying (finally)
uses Jehl’s picture fill as a fallback?:
accessible text
SizerSoze.org (what is the cost of your non-responsive images?)
calculates the savings if you were to use the above solution in your site
SRC SET:
<.img src="small.jpg" srcset="large.jpg 1024w, medium.jpg 640w, small.jpg 320w" sizes="(min-width: 36em) 33.3vw", 100vw" alt="a rad wolf" />
One beef was that it wasn’t using media queries (at one time)
but it’s a nice quick easy way to explain multiple sizes of an image
check out Coyier’s article on SrcSet vs Picture element

Video

Srcset
fitvidsjs.com (by coyier)
some sites have good examples how..
vimeo, etc
embedresposively.com

Maps

brad’s adaptive-maps badfrostweb.com/blog/post/adaptive-maps
apps hijacking the user’s attempt to browse for a navigation (not a bad thing, actually)
using Google’s maps API via a link from the page’s representation of the map
if screen scan accommodate the EMBEDDED map, instead just load the embedded map (example, min-width: 700px )

Lightboxes

example of a non-scaling pattern on Mashable
not all desktop patterns scale to the small screen
example of FB’s ‘create event’ dialogue on mobile/vs desktop
Conditional Lightbox
link to the raw image or chunk of content
detect screen size
ensure content is legible on small screens
if screen is big, inject the lightbox functionality
Magnific Popup – free responsive jquery lightbox plugin (also works with Zepto)

Data Tables

Table to name/value pairs
Table to List
Priority Columns (the important data persists, others get pushed into a ‘display more’ collapsed state)
Horizontal overflow (locked column approach)
Test lots! (some android devices don’t support this)
Consider using combinations of these to meet needs
Considerations for tables
What the data is like matters
how closely linked is the data’s display format to its semantic value?

“Modules”
Carousels

make sure you actually need one
runyon found that the % of folks that make it to panel #2 (of interactive carousels) is less than 5%
shouldiuseacarousel.com (rounds up the numbers on usage and effectiveness)
cycle through items that are similar (vs disparate item types)
only load what you actually need
be CLEAR about your carousel’s functionality ( “…” is not enough)
suggest more content to users
provide gestural hints (content overhang off screen)
opera mini; doesn’t support touch events
by default, provide fallback navigation (and replace it if touch is supported)
Types of Carousels
The Reveal (as screen space goes up, they expose more products in the carousel)
takes great advantage of larger screens, avoids the ‘stark & empty’ effect

Accordions

Tabs to Accordian: codepen.io/sturobson/full/xgfel (converts tabs to an accordian)
Accordion to Full: each section/subsection becomes an accordion section (ie collapses)
when there’s enough room, it displays in full

Forms

Label alignment shifts (top labels for small screens, left for full screen)
he prefers keeping them in the same place
Float Label – animated floated label that kicks in when default text is overwritten by user input
Float Label Form Interaction on Dribble
Internal labels: pros and cons
the field itself becomes a button/field.
saves lots of vert real estate
not so good accessibility
you lose field context when you enter text (since you’re overwriting)

Form Considerations

subtract as much as possible
use proper input types
chunk stuff up (multiple input phases allowing users to save progress (ie 1/4… 2 of 4, etc.))
use input types (number, email, url, tel) – this is the lowest hanging fruit here
they all fall back to text if not supported
Provide hinting
be careful with inline labels
validation but not too aggressive
Opting out of RWD
css-tricks.com/user-opt-out-responsive design
don’t use fixed positioning
very buggy on older browsers
just really goofy
burns up valuable real estate
Position: Fixed considerations
If it must be used, fixed headers are more reliable as they degrade more gracefully
avoid JS solutions
be mindful of orientation change. use media queries to disable fixed for landscape orientation
conditionally introduce fixed positioning when screen space becomes available

Development

Viewport metatag – tells browser to ignore its zoomed out state
viewport in CSS
@0webkit0-viewport {width: device-width} — etc.
don’t disable the user’s ability to pinch and zoom
only introduce the viewport meta tag when you’re sure the content is mobile-optimized
CSS
Border:
SASS
plain css is inefficient
nesting is awesome in SASS
variables are amazing
putting media queries into SASS vars is a fav of his
Nesting media queries
changed his life forever
.module { margin: 0 0 1em; padding: 1em; @media all and (min-width: 50em) { float: left; width: 50%; }
Getting Sass to help with legacy IE -> nicolasgallagher.com
respond.js by Scott Jehl

Device Support

what should i support?
iOS
Android
repulsive yet relevant
ie mobile, blackberry, silk, nokia etc.
There is a difference between SUPPORT and OPTIMIZATION – focus on accessibility
Redux: Ubiquity
our responsibility to make content accessible across the world, across economic and social spectrum

Testing

remote testing tools (browserstack)
viewport resizing tools
Test on actual devices
truly test a design’s performance
Device capabilities
Form factor
Pixel Density
Impact of the network
Device Criteria
your traffic, form factors etc. budget
test w/o breaking the bank – brad’s post from bradfrostweb.com
OpenDeviceLab.com

Optimism in Designers, Developers and Managers – Part 5

If you’re just joining us now, be sure to check out Part 1, where we explored the inherent optimism of designers, developers and managers, and what specific elements of our professions increase our sense of optimism. In Part 2 of this series we talked with real people in development and management roles to learn what leads them to feel optimistic about their work life and projects. Part 3 continued our exploration of optimism as we checked in with some designers to see what makes them feel hopeful about their projects and day to day. Part 4 covered the dark side – how people feel and act when faced with the factors that discourage optimism rather than foster it.

Walking the Walk
So until now we’ve only talked about optimism, right? Let’s put it into practice. How do you cultivate a positive attitude when dealing with the hectic pace, stressful situations and the shear distraction of today’s lifestyles? Glad you asked!

1. Take inventory
Stop, breathe and make a list of all the good things about your life. One by one, focus on what makes your job worth doing, what brings you joy at home, and the people inside and outside work who inspire and support you. What milestones are you looking forward to, and which have you already achieved? Sometimes it’s easy to forget how good you really have it, and a simple and honest review of your circumstances may clear the fog and reveal a pretty nifty landscape indeed.

Next, list out all your grievances. Add to the naughty list that client who never listens to your ideas, and write down the many ways Joe from accounting chews too loudly. Don’t edit yourself here – if it bugs you, jot it down. This list is more useful than you might think in building optimism. It’s what you’ll reflect on in a moment, gazing through what I like to call the ‘first world filter.’

2. Reach Out
Humans are a communal species. By and large we do better with others around instead of going it on our own. Empathy is a powerful tonic, and sharing your tales of wonder and woe (ie. the good and bad, the ups and downs) with other folks has several built-in rewards. You’ll build better relationships, get some perspective when hearing about the challenges others face, and hopefully inspire someone else who’s slogging through their own Fire Swamp, battling Rodents of Unusual Size.

3. Harness Your Little Green Monster
It’s normal to be envious of coworkers and friends who achieve great things or seem to live a charmed life. However, it’s not healthy or productive to dwell on it, thinking how lucky they are and how you’re not as fortunate/connected/blessed.

Instead of living in a jealous fog, channel your energy towards building your own success. Envious of your pal who’s winning awards or making bank with their new novel? Write a book! Can’t fathom how your coworker has 10k Twitter followers and you have 200? Learn how to better market yourself, how to network and grow your personal brand.

Use your friends and neighbors as the higher bar you strive to reach.

4. Listen Up and Look Around
It’s amazing what you hear when you start to pay attention. For example, there was a time I grew frustrated with what I perceived as a lack of opportunities to be creative. (crazy, I know!)

I resolved to open myself up to anything that presented itself, regardless of how it might fit what I envisioned for creative outlets. WHAM! Suddenly it seemed I had opportunities coming from all directions – I had too many to participate in and had to turn some down. Did the creative forces of the universe turn on a dime? No, of course not. I simply started paying attention to what the universe what trying to tell me.

5. Accept that you control your destiny
It’s absolutely useless to blame anyone for your circumstances in life. Sure, that cabbie who didn’t stop for you this morning and made you late – that’s his fault right? Well, no. You could have gotten up earlier, or set up a carpool, or well… bought a bike.

Choices you make every day, either consciously or unconsciously, define who you are and the world you create for yourself. Make good choices.

6. Be happy
Consciously see the world through a positive lens. Practicing this single step will make an astounding difference, even if you’re challenged in making process via other methods. Seriously, it’s that simple an effective – give it a shot.

It’s my belief and sincere hope that you’ll find value in practicing these habits, and that you’ll find yourself experiencing a brighter outlook in your day job and at home as a result.

Stay on the bright side…

Rich Lee

Note: Also published on www.giantux.com.

Optimism in Designers, Developers and Managers – Part 4

Now let’s visit the dark side…
In reflecting on my own experiences and while talking with the designers, developers and managers on the topic of optimism in the workplace, a funny thing kept happening: folks would have trouble describing what made them optimistic. Instead, they initially (and with apparent ease) listed out the things that did NOT make them optimistic.

Instead of “I love having clear requirements” they would begin with “I hate it when requirements aren’t clear.” Rather than “I love being able to build something that lots of people will use and love” they’d say “I hate building things no one in their right mind will use just because that VP of BizDev thought it was special.”

This is in direct response to being asked about OPTIMISM, people. What the heck? Are we so entrenched in our work and trapped in habitual pessimism that we can’t see the lining of our clouds any more? So it would seem, but let’s dig deeper.

In my own experience, there are a few things that have me thinking like Mr. Edgar Poe. It’s discouraging to be told that due to a particular situation, a given design can’t be used–even if it’s a better solution–due to uninformed (or just plain wrong) beliefs held by stakeholders. It’s one thing to consider options and make an informed decision, and quite another to make a choice based on misinformation or prejudice.

When a project gets canned part of the way through, and sufficient rationale is not provided – that’s a morale killer. When you’ve poured your time, energy, and (let’s be real here) love into a website, application, process, or team – it’s devastating to have it cut off at the knees and not have closure into why it’s been done.

Last, it really gets my goat when assumptions are made about the capabilities of an individual or team. Just because someone is a designer doesn’t mean they don’t have the desire and skills to develop or manage. Assuming a developer cannot think visually or doesn’t have valuable feedback about user flow is a huge mistake. Concluding that a manager has no hands-on skills is downright silly. These mistakes are costly, preventable and senseless.

Let’s hear what our folks in the field have to say

Jeff:
“What I find crushing of dreams, spirits, etc., is writing code that is only good for today. Code that¹s written to get a single job done and doesn¹t need to be well done. Code that¹s not thought-out and generally, in the grand scheme of things, doesn¹t matter, as long as the project eeks by without a major failure. The rushed, ‘just make it work’ kind of stuff.

“Another frustrating thing to deal with are designs that don¹t translate well to code and/or UX…Those cases where a design is harder to code and doesn¹t produce a better outcome (and often causes a worse outcome) due to certain specifics about the design that could easily be tweaked to make the end result much better.“

Matt:
“A concern I have is the lack of language that developers possess to explain what they do to other technologists, much less non-technical people. This lack of understanding seems to make it difficult for non-programmers to appreciate and understand what our profession does. This both adds to the insularity of programming as a profession, often relegating programming to a task instead of culture or ecosystem in many domains.

This lack of language also makes understanding the risks and reasonable limits of technology out of the hands of most people — c.f. the healthcare.gov debacle. Having reasonable, stable systems as public goods will require something to be done here and I’m not sure there is adequate time or effort being made to do this.”

Robert:
“There are cultural challenges with… large companies… and we’ve got some process and workflow challenges that appear to be changing for the better, but it’s happening slowly. Companies can sometimes seem slow to adopt new process ideas and we often fall back into old patterns we know don’t work, because of resourcing/budgeting constraints.”

Hannah:
“If you want to kill my buzz, the easiest way to do that is to…accept mediocrity. I detest laziness, and I have no time for people who aren’t willing to try new things. This can be a double-edged sword in our line of work because implementing new technology and ideas in a large company takes eons when the rest of the world seems to be moving at lightning speed.”

Ask Yourself
Are you doing the work it takes to live on the sunny side? Because let’s be real–it DOES take work to see things in a positive light, or at least from a neutral perspective. It’s far easier to dwell on the dark side, play the blame game and have a portfolio of excuses handy as to why you’re wearing that floor length black trenchcoat instead of the Rainbow Brite sweater from your aunt.

What is it that keeps YOU from feeling optimistic about your work? Think on it, and let’s compare notes in the next and final installment of this series.

Note: Also published on the amazingly rad UX destination GiantUX.com

Optimism in Designers, Developers and Managers – Part 3

Personally, I’m most optimistic at the beginning of a project – the sky’s the limit and anything is possible. Both the scope and the quality of the end product are big factors in my overall mindset. It’s more thrilling AND challenging to be responsible for the look and feel of a site or product that will be seen and used by millions than it is to design that “mom & pop” brochure site (which ends up only being used by Mom and Pop). Building something with clip art and last year’s recycled content is a world away from being given top shelf photography, video, typography and content.

Similar to a developer’s happy place (and perhaps a bit counter-intuitive to non-designers), many designers thrive on being provided up front with the comprehensive constraints and affordances of a project. If design is solving challenges, it stands to reason that knowing what you have to work with is essential to devising a solution.

Having clear insight into the underlying strategy of a design challenge is rewarding, since that can shift the conversation from “Let’s make it green – green is my favorite color” to “how can we encourage users to interact with this component and its deeply rewarding awesomeness?”

Being able (and ideally encouraged) to make the design one’s own is a surefire way to kindle true passion. I, like designers and artists of all kinds, strive all my life to develop, maintain and grow my own personal style. When allowed a little bit of leeway to do so in projects (within project constraints!), I guarantee the results will be noticeably more effective and ultimately fulfilling for designers and the users alike.

Let’s hear from some other designers to get their perspective:

Hannah:
“The thing that makes me most optimistic as a designer are the new possibilities I am constantly finding. I’m a pretty old-school style artist, so when I started working with web-design, I basically thought it would steal my soul. Instead, I’m constantly discovering ways for the new technology on my iphone or desktop to enhance the things I make by hand and vis versa…

…I really love getting a project with pretty strict requirements and then finding ways to iterate and brainstorm mixing and matching different types of media until we find the best possible solution.”

Jeff:
“Good design solves problems. Great design enriches people’s lives…Finding ways to enrich people’s lives is our optimal goal.

It’s the note between the notes, it’s the implied lines of a drawing, It’s the way a coffee shop meticulously roasts and serves its coffee. None of these things are easy, you have to work at it and learn from it. But once you achieve it, the payoff is that much more rewarding.

That’s why as a designer I get up every day and do what I do — I don’t stop at solving problems, I seek to inspire, to put a smile on someone’s face, to truly enrich people’s lives. And when you focus on these things the negatives fade away and become non-issues.“

Jason:
“I feel optimistic when a project is going smoothly (new ideas, reasonable timeline, making deadlines, portfolio piece, etc.) – when there’s room for creativity (hello there, client. Here’s what you asked for – but I also thought about this, that and these) – when trying something new or learning something new – when the team gels (the larger project team not just other designers.)”

One shared sentiment from these discussions that resonated with me is that a project’s scope and restrictions can make or break how the project affects one’s overall sense of optimism. An assignment can be seen both as a crazy cool gig or as a tortuous chore, depending simply on a few details. A limitation isn’t a bad thing – it can drive creativity!

As designers and as managers, striving to keep the excitement and creativity of a project intact isn’t something you can leave to chance. Ensuring the requirements are clear and the tools or assets required have been provided is often what separates a great team producing top-notch products from that same team churning out mediocre designs..

Next time, we’ll explore the flip side to this optimism thing. What makes us pessimistic and hopeless? What makes us bang our heads against the wall and groan in frustration? Stay tuned to find out.

Note: also published on GiantUX.com