Session Notes: Tapping into the power of user narratives [Drupalcon 2012]

Presenter: Michael Keara, MyPlanet

What is a user interface systems architect?

  • equal parts listener and software developer
  • Listens to users and finds pain points
  • Understands software and how to build the technology
  • Focus: how to bridge the gap between the two.

Two doors:

  • The user happy place, where they understand the user interface they’re dealing with
  • The development environment, where people need to understand how to make the system work
  • Opening both doors opens new conversations, and leads to new insight

Three UX Fundamentals

  • Usability is a lack of suffering on the part of the user
  • Usage context: Functionality has no meaning outside of a usage context
  • Primary questions:
    • Who is the user?
    • What are their tasks?
    • These are “simple” questions, but very difficult to answer.

Case study: a registration system for music exams in US and Canada

  • Two websites, two separate usage context
  • Examinations are key to their business model
    • Registration must be easy
    • Multiple types of users involved in the system
  • Design and testing
    • Started with “pilot” for US school
    • Prototyped the solution in a rich HTML prototype, then created a testable site
    • In user testing, discovered:
      • Structural issues: how to improve the location and function of key components
      • “Language” issues: issues around the language being used to navigate around

User narratives:

  • Role-oriented UX design
    • Is about supplying the right tools at the right time
    • Don’t throw all the tools the user will ever need into one space
    • Provides a way to trace the path from end user to the engineer
    • Roles = a set of tasks
    • Tasks require specific elements on the screen to facilitate completion
    • Has an impact on:
      • Layoute
      • Information Architecture
      • Data Retrieval
      • Data Structure
    • Connecting the dots
      • Handle idioms/terminology used
        • Different cultures have different terms they’re used to
      • Handle roles (mindsets and usage contexts)
        • Student
        • Parent
        • Teacher
      • Applications and tools try to mimic mindsets, but it doesn’t always work out
      • Role-oriented designs handle mindsets comfortably
  • idioms (language beyond “language”)
    • Unfamiliar terms don’t fit
    • Generic terms have rough edges; don’t resonate
    • Familiar terms are comfortable; help achieve “invisibility.”
  • Real-life narratives
    • Life is a sequence of roles, and those roles need tools
      • I’m a cook at breakfast {stove, toaster}
      • I’m a commuter {train, car}
      • I’m an emailer {computer or smartphone, fingers for typing}
      • I’m a [insert role here]
  • How words get to the screen
    • String: set of words that arrives on the screen
    • We all have words that resonate with us in terms of different roles, tasks, mindsets
    • Thoughts come in clusters; so do the words that describe those thoughts
    • Drupal thinks of strings individually and not in clusters
  • Drupal excludes UX designers
    • Drupal defines “roles” differently (as a set of permissions that’s fixed depending on roles)
    • Doesn’t support the ability to express things idiomatically
  • Organization of words for UX
    • Strings have two lives:
      • The ones the user can’t see (internal code)
      • External ‘user’ strings (human names, what users see)
      • Code strings should never change unless there’s some kind of functional change intended by the developer
      • User strings should adapt to users
    • All of the strings (user, internal code) exist in code!
    • The t() function handles user-facing language
      • You can find them and change them, but not to role or idiom-based terms
      • Translation (from English to German, etc.) is there, but not when thinking in terms of different idioms within the same language
  • Inclusive alternative approach
    • Have to go beyond the t() function to fix this issue
    • Extract the user-facing strings from the code using semantic keys
      • ‘name’=>$sm->t(‘LABEL_BLOG’)
      • $_string_array = array ( ‘LABEL_BLOG’) => “Blog entry”
      • Role oriented key: $sm->t(‘LABEL_BLOG__’.$role)
      • $_string_array = array ( ‘LABEL_BLOG’) => “Blog entry” LABEL_BLOG__STUDENT’ => “student’s blog entry”
    • Do this through the user narratives module
      • It’s about organizing strings
      • Takes a custom “adapter” module (uses form API) and routes it through the user narratives module into a different place that the uX designer can evaluate and change to accommodate new needs/mindsets

Session notes: Designing for Media platforms [Drupalcon 2012]

Presenters: Dave Leonard and Samantha Warren, Phase II Technology

What does it mean to design for media?

  • Designing for a site that is meant to reach a large audience with a daily content cycle
    • Newspapers
    • high-traffic blogs, etc.
  • What makes it different is the sheer amount of information
    • Photos
    • Videos
    • Lots of body copy
    • Organizing lots of information in a way that works for the user
    • ADVERTISING
  • Designing for a frequent publishing cycle
    • How do you design for content creators?

Case studies

  • Take Part
    • Digital media organization and cause services agency that provides content, products and services that inspire, empower, and ignite people to take daily action in making the world better.
    • Visual Design goals
      • Exhibit great storytelling
      • Compel users to take action, get involved in the community
      • Promote sharing: make sure the content doesn’t just live on that site, but belongs to the entire internet
    • UX Goals
      • Take action in the context of a story
      • Support the ebb and flow of topics
      • Make sure that editors have a good UX too!
        • Too many designers don’t take into account the process that editors have to deal with; focus too heavily on end users.
    • Visual Design process:
      • Conduct interviews with stakeholders about their brand and needs
      • Thematic Analysis: find adjectives
        • Engaging, action-oriented, personality
        • usable, present, depth, spacious
        • circulate, community, editorial, content focused
      • Use style tiles to help establish visual priorities
        • Offer one that’s “specifically what they’re looking for”
        • But also offer ideas that speak to the adjectives and themes you’re hearing.
    • UX Process
      • Content strategy
        • Types of content
        • Clasification/tagging
        • Embeddable content types: Put one node in the body of another node
        • Curation requirements: What are the requirements for analyzing and curating content? Are there expiration dates?
        • Curation capacity: What staff and other resources do you have to manage the requirements?
        • Campaigns of varying scale
      • Pair wireframing
        • Flush out misinterpretations early
          • How much fidelity do we really need?
          • Are we being over-specific?
        • Minimize revision cycles
          • Style tiles are done concurrently with wireframes
          • No conflict between UX and visual designer
        • Avoid over-designing
  • Washington Examiner
    • Regional newspaper that covers news, politics and sports in the DC area. The logo was created by William Randolph Hurst and it has a rich patriotic brand.
      • Visual Design goals
        • Feel modern
        • Stay true to history of the brand: wide and loyal readership
        • Promote ease of use: Readability is major; need content to shine through
      • UX Goals
        • Demonstrate breadth and depth of coverage
          • Section based
          • Cover a lot of local news for DC metro area, but also very respected nationally for political coverage
          • Set hierarchy; not all sections are the same
        • Promote top-quality curated content
          • Provided challenges in image handling
          • Challenges in creating hierarchy and ratios
        • Showcase the talent they have in house
          • Challenge: many sources of content coming into the system
            • Feeds
            • Direct to Drupal
            • Imports from AP
          • Need to define how authors are treated depending on where content is coming from
      • Visual Design Process
        • Adjectives:
          • Local, political, regional
          • Opinionated, scrappy, speedy, focused
          • ease of use, decluttered, visual balance, simplified,
          • polished, clean, fresh
          • Flexible, dynamic, Interactive
        • Had done a smaller site project beforehand; had some data on what the client liked and didn’t from the first site.
        • Work elements of the paper (print edition) within the website.
      • UX Design process
        • Sketch session: group brainstorming of UX concepts for a project
          • Got the entire team involved
          • Timeboxed to an hour
          • HAND-DRAWN sketches
          • Come up with ideas, no matter how “crazy”
          • Alleviates the “where do I start?” feeling
        • Wireframes were more high-fidelity because of the collaboration
          • heavily annotation of wireframes to make notes of interactivity, content, etc.
  • Common themes
    • Design a system, not individual pages
      • Clients think in terms of pages; it’s really easy for designers to think of things in pages as well
      • Because of the way Drupal (and other content management systems) handles media, content, etc. you have to think in systems rather than individual pages
      • Create style guides for clients to use and adapt as the site grows
    • Dealing with the author experience
      • Authors can be Drupal users, or they could be organizations
      • Have to consider how different types of authors will need to be treated or highlighted
    • Cross promotion of content is a common theme when designing for media
      • Want multiple page views
      • Make sure people can see additional or related content
      • Helps users find related info; helps the organization get more views on their content
      • How to distinguish between “articles” and “actions” — what’s the different treatment between requests for action and related articles?
    • Lifecycle of Topic
      • How to build a set of tools that lets editors evolve the content and its treatment/important on their own without needing extra developers
    • Commenting
      • Drupal core commenting vs. Disqus or FB comments
      • How to make things visually consistent with third-party integrations?
    • Advertising
      • Designers often have a fear of advertising; it “ruins the layout”
      • How to make it part of the design, and find subtle ways to make it less obtrusive?
      • You can’t get around the need for advertising; it’s the bread and butter of the media industry
      • part of our work as designers is solving problems, and this is part of it.

Session notes: View Modes—the many faces of your content [Drupalcon 2012]

Presenter: Tim Cosgrove, Phase II

View modes:

  • Help you theme faster
  • Write less PHP
  • Create easily reusable layouts
  • Named ways of displaying entities within different context
    • “Full” — the actual node page
    • “Photo Teaser” — photo with title
    • “Dated Teaser” — date on top, summary
    • “Subtitle Teaser” — photo with summary, title
  • View modes are in core
  • View modes are NOT in Views
  • They’re built into all Drupal 7 entities
    • Nodes
    • Users

Bad themer habits:

  • Too many .tpl files/custom templates
  • Too many functions in template.php
  • You use Views to do theming.
  • In D6, we needed these things, but NO MORE! D7 brings us View Modes!

How to use View modes:

  • In Manage Display, “default” and “teaser” are built in by default
    • “Full” — how to display the full page
    • “RSS” — how to display RSS feeds
    • “Search Index”
    • “Search Results” — how to display nodes in search results
  • To activate said view modes, click on custom display settings and activate the new ones you want; otherwise, default and teaser is it.
  • If you go into the view mode to edit, you can deactivate extra fields, or add new fields
    • This happens in code
    • You don’t need to do a new node–type.tpl.php for each type anymore
  • BUT, we need more custom view modes! How?
    • Entity View mode
      • Simple, lightweight
      • does what it says
      • con: keeps EVERYTHING in one variable (this means that Features might get stuck if you use it with this module)
    • Display Suite
      • Has a better way of exporting view modes
      • Extremely powerful way of dealing with this
      • Con: it does A LOT OF THINGS. If you want that, great, but if you just need to add a couple of View modes, it’s a bit much
    • Doing it in code.
      • Just need a little bit of code
        • use hook_entity_info_alter( )
        • change $info[node] and create a new machine name and array with qualities
        • add it to a module and throw it on your site.
        • Now it should show up in your view mode display panel.
  • Exporting view modes
    • Throw them into Features when you export your content types; they’ll come back in when you import the content types into a new site
  • Use cases:
    • Node reference: add a custom view mode to the User Content page
  • Why not use Views for this stuff?
    • it’s messy and complicated
    • takes significant time
    • too many templates, customized for each View
  • View modes actually make using Views much easier!
  • Other ways of using View modes:
    • Customizing search results
    • Customizing search index: offer more information to search index than is generally available to the index.
    • Create custom blocks with related content at the end of an article.
      • Big win: you don’t have to theme, as long as someone sets up the display for that content type’s block with “subtitle teaser.”
  • Changing view modes:
    • make one change and it populates across things
  • Issues
    • Consistent design is key to using view modes
      • Make use of repeating elements
      • Use grid systems
      • The more you can use reusable elements, the better.
        • Save time & money
        • Look for inconsistencies; those will add to the dev time.
    • Also doesn’t work with tables
    • Won’t work with outputting fields from multiple entities at once, e.g. multiple content types or nodes.
    • Theming issues
      • Consistency is good, but boring sometimes
      • You might have to give a bit in order to get a design that the designer will be happy with.
      • Sometimes you might have to make a separate template, or preprocess something.
      • The way we were forced to do things in 5 and 6 forced us to do all these extra things.
        • We don’t need to do this by default anymore; we can save it for when we actually need it.
  • bit.ly/view-modes (http://www.treehouseagency.com/learn/view-modes)
    • Learn more about View modes
    • download the code to make a new View mode module
  • BEANs (custom block entities) BoF (Thursday 2:15; room 506)

Session Notes: UX design for every screen [Drupalcon 2012]

Presenter: Aaron Stanush, Four Kitchens

How 4kitchens has been doing websites for the past decade:

  • Requirements and planning
  • Site maps, user flows, wireframes
  • Comps
  • Implementation

The new way:

  • Requirements/planning
  • Content strategy (mobile first!)
  • Design systems > Comps
    • You can’t spend time doing comps for every single device anymore; it’s not an effective use of your time.
  • Prototyping is KEY
    • You can leverage design systems within prototypes to enhance the mobile experience.
  • Build. Design. Iterate. Design. Build. Iterate.

Major changes:

  • There is no more “page”
    • Layout/template are consistent across devices
  • Comps are no longer golden
    • Don’t need one for every single page/screen
  • Elements are no longer static—they adapt to different devices
  • Prototyping happens much earlier in the process
    • Helps define the vision; helps client get it sooner
  • Designer and developers working closer together
  • Higher level of client communication
    • Some clients are skeptical, think there’s too much risk involved.

THE PLAN:

  • Future-friendly
    • http://futurefriend.ly
    • We don’t know what will be on the market 2–3 years from now;
    • want to provide advice and design that’s going to be sustainable.
  • Mobile-first
    • Luke W’s book: Mobile first (available on A Book Apart)
    • Focus on three things:
      • Growth = opportunity
      • Constraints = focus
        • Screens have different sizes, different needs
      • Capabilities = innovation
        • Tap the capabilities of the phone—GPS, location, etc.
    • “Designing the mobile app first forced us to strip down to the essentials”—Bill DeRouchey, Banksimple
      • Focusing on app first carried the focus of the project into the rest of the experience
  • User-first is content-first; THEN you worry about mobile strategy.

“Mobile Web”

  • Most clients seem to think folks are on mobile devices “on the go”—grocery store, bus stop, etc.
  • But honestly, that’s not true; people are spending more time on their phones, more time on the site through that medium
  • Mark Boulton: “Start designing from the content out, rather than the canvas in.”

Future friendly content

  • What are the types of content and why?
    • Video?
    • Text?
    • How will it be broken up?
  • Make it modular
    • Drupal makes this easy; you can leverage fields, etc.
  • What’s really important?
    • If something goes away, will users care?
    • If something gets smaller, will that change/decrease value?
  • How will the tool you’re using organize this stuff?
    • Drupal gives you flexibility to organize content in multiple ways.
  • Page tables give hierarchies
    • Title
    • Message
    • Secondary Messages
  • Design strategy
    • Workflows aim for best user experience; focus on task/behavior, not layout
      • Responsive is about providing the best experience, particularly when you focus on content.
      • These experiences can differ between devices; desktop may contain more information; mobile can contain more FOCUSED content.
    • Wireframes can help organize layout and convey content flow
      • Still needed
      • Focus on content, flow
    • Design systems save time, create patterns
      • Styletil.es (@samanthatoy)
        • Using texture, fonts, etc. to capture feeling
      • Build style guides/pattern libraries
      • Comps are probably still needed, but not for every page in every viewport.
        • ICANN: Created 3 comps, for 3 different viewports, AFTER creating and iterating style tiles.
      • Goal: get the design to the browser QUICKLY.
    • Prototypes help the team fail faster, to facilitate better solutions.
      • Provide client value; help them “get it” sooner.
      • We’re focused on much more complex problems now.
      • Clients can get really focused on comps; the browser is where the responsive magic really happens.
      • A “living” design allows richer convos between devs and designers.
        • Developers can talk about content flow and other design decisions
        • Designers have to understand more about how things will actually be built.
      • Fail fast. SUCCEED fast.
        • Agile/Lean
        • All about iteration and letting the team direct changes.
  • Best practices = Best experience
    • Not about convention; it’s about creating the best experience for users.
    • mobilewebbestpractices.com—library of best practices for mobile devices
    • Understand how people use their devices and why
    • Content > navigation
      • Users on mobile are generally coming in through a link; they don’t necessarily care about navigation.
    • Best experience doesn’t necessarily mean limiting choices
      • Stripping the experience down to just links/text isn’t the best experience
      • Users spend more time on their phones than you think; particularly reading.
    • Maintain clarity and focus
  • What makes a good experience?
    • Readable (font size, spacing, contrast)
    • Relevant (most valuable content first)
    • Keep forms to a minimum unless you’re dealing with commerce, surveys, etc.
    • Avoid modal overlays (lightbox, ads, etc.)
    • Make it snappy
      • People want to do stuff, and they want to do it fast
      • Performance management (reduce the amount of time for loading)
      • Get people to the content quickly
  • Layout
    • Design for screens, not devices = Breakpoints
      • You really can’t focus just on iPhones anymore; Android, Windows phone, etc. is growing
    • Be fluid, liquid, flexible
      • Think in proportions, NOT pixels
        • aligns with content strategy; focus on hierarchy
        • aids in fluid grid management
      • Think scale in media, text, images
    • Consider device orientation
    • lukew.com/ff/entry.asp?1514: Looked at a bunch of different mobile-to-desktop layouts; identified patterns for responsive layouts
    • Navigation
      • Starbucks changed their navigation; took a risk on an icon-only navigation with drop down box.
      • Don’t try to make drop downs a work of art; the OS takes care of things in their own way.
      • Put fixed toolbars at the top rather than the bottom.
        • The bottom is where the OS puts its hardware buttons; you don’t want users accidentally clicking the hardware buttons.
      • Consider OS and hardware buttons.
    • Responsive Images
      • How do your images scale for various widths and orientations?
      • Reduce the # of images if you can.
        • Not everyone has super-fast phones!
      • Be careful of using HUGE images
    • Mobile text
      • Make it readable
      • Consider text flow; long headlines might not scale well on smaller viewports
      • Be aware of typeface characteristics
        • Tall, skinny?
        • Short, fat?
        • Test performance with mobile devices; make sure that loading fonts isn’t slowing things down
    • Gestures
      • Buttons are a hack: they’re basically styled links.
        • globalmoxie.com/blog/buttons-inspired-ui-hack.shtml
      • Make gestures obvious.
        • Don’t make your users read a manual
        • There’s no such thing as “hover” on a touch site.
      • Do use visual cues like coach marks.
      • There is a need for universal conventions
        • Current conventions: tap and swipe (pull down?)
        • Consider competing OS/Browser gestures
        • Provide alternatives to gestures
          • All devices aren’t yet touch-enabled
      • Design for humans; embrace the physicality of touch
      • Size elements and space them appropriately
        • rule of thumb: size touch elements at about 40px
        • Remember: not every device is touch-enabled
    • Tools
      • Software isn’t necessarily the answer
      • Start with pen and paper
      • Fluid grids
        • Goldengridsystem.com
        • Github.com/davatron5000/Foldy960
        • csswizardry.com/fluid-grids
        • gridsetapp.com (coming soon from Mark Boulton)
      • Wireframing/prototyping
        • Whiteboard!
        • Pen/Paper
        • Axure
        • Balsamiq
        • Boston Globe used InDesign
          • handles both images and text
          • Can create patterns with paragraph/character styles
      • Responsive media
        • Images
        • Slideshows
        • Videos (fitvidjs.com—takes any embedded video and scales proportionately)
        • Text (fittextjs.com)
        • filamentgroup.com/lab/responsive_images_experimenting_with_context_aware_image_sizing
        • markboulton.co.uk/journal/comments/responsive-advertising
      • Media queries
        • @media screen and (max-device-width: 480px) { .column { float: none; }}
        • Media type: screen (desktop, phone, tablet)
        • Query for media feature: width, height, orientation, pixel density
      • Prototype frameworks
        • foundation.zurb.com
        • twitter.github.com/bootstrap
        • goldilocksapproach.com
        • html5boilerplate.com/mobile
      • Touch frameworks
        • jquerymobile.com: can create something that looks like an iPhone app within a browser
        • sencha.com
      • Test on REAL DEVICES
        • blackberry
        • Windows phone
        • Kindle fire, iPad2
        • Galaxy tab, etc.
      • Adobe Shadow: labs.adobe.com/technologies/shadow
        • Runs in the background, and has an extension on FF/Chrome
        • Make sure your devices are on the same wifi network; then you can browse on desktop and it shows up on all your devices.
      • Browserstack.com
        • will emulate any number of browsers inside one website
        • Just started adding mobile VMs.
          • Won’t get the same fidelity as an actual device, but you can get a general overview
        • Subscription is pretty cheap.
      • Blaze.io/mobile
        • tests mobile performance
        • Gives load time and other factors
      • mattkersley.com/responsive
        • Type in different websites, and it’ll show you how it looks in different browser widths.