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: 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.

Session Notes: Webform—the survey tool for Drupal [Drupalcon 2012]

Presenter: Nathan Haug

Nifty stuff in Webform 3:

  • Webform-enable any content type
  • Download web form results as CSV, Excel
  • Multi-page forms
  • User-editable email templates
  • Save as Draft and Resume (only works for logged in users)
  • Save automatically between pages
  • Total and per-user submission limits (you can only submit X number of things total tracked by IP and cookies)
  • Tons of APIs for hacking; APIs like whoa
    • Means many additional modules that integrate
    • Rules integration is good
    • Panels integration also

NEW features:

  • added HTML5-friendly field elements (email, phone, etc.)
    • Important advantages for mobile devices
    • Also offers browser validation on latest versions of Chrome, Firefox
    • quirksmode.org/html5/inputs.html
    • Backwards-compatible: any browser that doesn’t get it treats it like a normal text field
  • Number component
    • Force users to input integers or decimals
    • Also an HTML5 element
    • Gives you a new keyboard on mobile
  • CONDITIONAL LOGIC
    • Can show pages, fields, etc. based on the value of another field in the form
    • UI isn’t great, but it is functional
    • Logic is currently limited to multipage forms
    • Webform Conditional (http://drupal.org/project/webform_conditional) offers functionality for single-page forms
  • Download range options
    • Can download a subset of results instead of all results
    • Remembers how many submissions you’ve downloaded since last time; only downloads the submissions you haven’t downloaded yet
  • FORM BUILDER INTEGRATION

Tips and Tricks

  • You can clone and export web forms
  • Only fields clone; results don’t copy over
  • Options Element (http://drupal.org/project/options_element) helps make it easier to create select boxes
  • Use hidden fields to display information that only administrators can see
    • e.g. track page they’re on when they send the form
  • Use %get tokens to set default values—can get information from the URL and set it as the default value of the field
  • Use MIME mail to send attachments and HTML emails with Webform

Session Notes: Native Mobile Application Development on Drupal [Drupalcon 2012]

Presenter: Kyle Browning, Workhabit

Why NOT native?

  • Options like Titanium/Appcelerator support multiple devices
  • Rapid prototyping: it’s easier to write JS than to do a bunch of memory management stuff
  • Native is not easy for development.

WHY native

  • Faster performance on the device
  • supported by the OS maker (can make support requests on iOS/Android forums)
  • Manage errors on the side of the stack
  • No waiting on API updates, release schedule
  • Game development
  • Personal prefs

Dev process

  • Start with getting your idea on paper.
    • Getting the idea on paper helps the entire process go more smoothly
  • Build wireframes/prototype
    • It’s easier to fail in wireframes and prototyping
    • Gather all the types of content you’ll be using
    • Lay out the app in a workflow (user flows, task maps)
    • Use tools like Briefs, Omnigraffle, Axure
    • Save time on development by failing early and learning as you go
  • Design (visual, UI)
    • WIll it need to support multiple devices?
    • What are the key tasks and how will those be called out
    • Attempt to create an experience users are familiar with: colors, taxonomy menu, etc.
  • Development
    • Figure out what features are pre-reqs for others
      • Will content come in as feeds? First build content, then feeds or vice versa
    • Build API communication file
    • If things are constantly changing, write unit tests
    • Tackle the larger, harder problems FIRST

Mobile stack

  • Mobile App
  • Services
    • Standardized solution to integrate external apps with Drupal
    • Service callbacks can be used with multiple interfaces like REST, XMLRPC, JSON, JSONP, JSON-RPC, SOAP, AMF, etc.
    • Gives you your connection into Drupal
    • Much time is spent messing around with Services
    • Servers
      • Defines Accept and Response types
      • Call Authentication Methods
      • Executes the actual function call
    • Authentication
      • Session based
      • OAuth both 2-legged and 3-legged
      • Singletons: You’ll have a user object that exists through the entire app; you want to make sure that only that object exists. Singletons help with that.
      • No need to re-login to the app when it opens.
    • Endpoints
      • A URL that a mobile app will hit
      • The bread and butter of Services
      • It’s a configuration object that has all the resources and servers/auth methods, etc. that you need to make Services work.
      • You can also work with versioning, access controls for new developers, etc.
    • Versioning
      • Helps keep things consistent
      • Won’t break apps when you build new features or functionality
    • Things to note:
      • Services Views is a bit wonky, but it works
      • There is potential to break if you change Views
      • Features allows you to take the View and put it into code so that it can’t be messed with.
      • Adding images inline within content
        • Services will insert unnecessary HTML tags instead of images
        • Working on a module that will strip out images and attach them as a file to the node
        • Use Imagecache to deal with image handling (it’s already in D7 Core)
    • Tools
      • Drupal iOS SDK and Dandy
        • Sits between Services and the mobile app so you can communicate with Drupal natively
        • Helps do user/session management
      • Services Log
        • hooks into services and logs everything that Services is doing.
        • You can see when you’re getting a 403, etc.—what is messing up and why?
    • Drupal
      • Holds and organizes content
      • Can be sent to mobile app through Services