Pivotal Labs

Main menu

Skip to primary content
Skip to secondary content
  • About
  • Case Studies
  • Team
    • Executives
    • Locations
      • San Francisco (HQ)
      • Boston
      • Boulder
      • Denver
      • London
      • Los Angeles
      • New York
  • Community
    • Blogs
    • Tech Talks
    • Events
  • Careers
    • Lifestyle
    • Principles & Practices
    • Benefits
    • FAQ
    • Apply
  • Contact
    • Press Room
    • Press Releases
    • In The News
    • Press Kit
  • All
  • Labs
  • Standup
  • Tracker

Monthly Archives: May 2012

Jonathan Berger

FOWD Day 3: Designing for the Rise of Social Networks of Devices – Bill Buxton

Jonathan Berger
Wednesday, May 16, 2012

Bill Buxton has been a computer science visionary for almost 30 years, and shares his thoughts about what the next 30 years—or 5 years, or 10—might look like, and what web designers and developers ought to be paying attention to. Notes are after the jump.

Ubicomp

  • The idea is that computing will become transparent.
  • Who’s got a car with a motor in it? Two motors? Three?
  • Our cars all have 100s of motors: to run the windshield wipers, the automatic windows, etc. Motors are transparent.
  • In the mature world, you’ll know no more about the computers in your appliances than you do about the motors.
  • If you know there’s a computer there, that’s a failure of design.
  • Getting computers out of your face is the ultimate interface.

    spider

  • Who’s the spider? Who’s the center of the web?
    • The cloud? No.
    • You? (Yes, you.)
    • So? Figure out who’s in your immediate vicinity, and word from there.

Whaddyagot

List of gear from the audience

  • camera
  • slate
  • brain
  • mobile phone
  • fitbit
  • watch
  • laptop
  • ipad
  • etc.

Ink Browsers

  • aka, paper
  • Keep a diary: for 24hrs, track every interaction you have with paper. Size? Content? Purpose? Who put it there? What else is around them?
  • BB argues: everywhere you see a piece of paper, one day you’ll see something electronic.
  • The diversity of web browsers tomorrow will match the diversity of ink browsers today.

It’s about architecture

“Thoughts exchanged by one and another are not the same in one room as in another.” – Louis I. Kahn

  • A few years ago, $20k 42′ screens replaced one-sheets (advertising posters) at movie theaters.
  • A few years later, a (gimmick) newsstand issue of Esquire had an cover with an e-ink display.
  • In 2009, Entertainment Weekly released a magazine with a (postage-stamp size) color video display. 40m video, 6 hour replay.
  • The web will be everywhere we see print ads.
  • Those $20k screens are now $500. What happens when they’re $50?
  • At first, in the Vienna subway, they didn’t know what to do with projectors: they thought it was TV. They didn’t think about the use case. They tried to use video.
  • Coca-cola vending machine with touchscreen display. http://www.youtube.com/watch?v=mCcb87b6vjA

  • Porn drives all tech for the web, advertising follows, and then there’s the rest of us.

  • Yahoo has touchscreen billboards at bus shelters in SF. It’s not just about pulling out my cellphone. This is public (my body doesn’t shield it) and collaborative.

Ubicomp + Society of Devices

  • The list of devices we have today shape our thinking and drive our projects forward.
  • The things we just talked about weren’t on our list, so they’re not on our mind.
  • William Gibson says “the future is already here, it just isn’t evenly distributed.”
  • We have to become comfortable and confident with things that haven’t happened yet*—as confident as we are with things that do exist—in order to design for the web.
    • “haven’t happened yet” is Gibsonian; they exist in the world, just not for us. We need to go out and look for them.
  • Long Nose of Technology: every technology takes 20 years to mature into a $1b industry. Its like the long tail, reversed. Most of that early stuff stays below the radar.
  • Any new thing that’ll be a $1b industry in 10 years is already 10 years old. In 5 years, it’ll be the 15-year-old technology. If you’re not looking 5 years ahead, business-wise, you’re nuts. Are you looking at 15-year-old tech?

Homogenous Networks

  • We’re surrounded by devices that don’t know about each other.
  • BB’s first touched a computer in 1971, when the miracle was “it worked!” to know, when we can do anything.
  • The social networks of devices are as important as the social networks of people.
  • They can make connectivity transparent. Design them properly and they become far more clear.
  • NintendoDS does a good job of this.
    Scrabble
  • Games lead the way: iPad / iPhone scrabble.
  • These are all ad-hoc networks right now.
  • Heterogeneous networks of devices
  • Scenario: point a celphone at a bus station display ad, and get to use the screen to visualize the bus map, using the phone as a control surface.
  • There can be an ad around it.

  • This turns pop-up ads on their head (i put up with an ad in order to get stuff for free): this is a pop-up application on an ad.

Economics

  • Transaction Cost (Ronald Coates). Every transaction has a cost, and the cost has changed most dramatically. Not always dollars and cents; sometimes emotion, time, happiness, attention, etc.

  • Designers: what are the trans costs? What are the currencies? Where do we get the best cost-benefit analysis.

  • E.g.: automatic doors in supermarkets lower the transaction cost of opening the door. Kinnect 1.0!

  • standard objections:

    • but there’s nothing new!
    • you can already do that!
    • why would I pay extra for something I already have?
  • Apply those objections to a TV’s remote control. All the objections are the same, but the transaction cost is much lower.

  • Who would buy a TV today w/o a remote?

  • “You can already do that!” is an objection that you can always respond to with “At what cost?” in any currency. If you change the cost by an order of magnitude, that’s a big deal.

  • When the iPhone came out, every mobile phone company said “there’s nothing new here”.

  • When the remote control came out, the TV networks synchronized their commercials so people couldn’t surf.

  • TV editing got much faster.
  • Cinema editing got faster in response.
  • Therefore: “redundant” controls => new cinematic aesthetic

Conclusion

  • The effects of the web are wildly more influential than changing a channel.
  • Design the social networks of devices and cost structures, and the opportunities are enormous.
  • We don’t have to make these decisions today, but we will need to deal with them soon. Channel the decisions you’re making today to be in concert with where we’re going.

Q&A

  • “I can’t stand futurists who aren’t historians.”
  • Q: what’s the master/slave relationship going to be? Which OS will I use?
  • A: MIDI kind of solved that. It’s not about any particular configuration; the hard part is figuring out the transitions from one to the other. It’s all about the transitions; that’s why the iPhone is so awesome. Nothing’s new on the iPhone; how you moved is the difference.

  • phone convo in car => pick up the handset uses totally different technology (speakers, synth). It was as seamless and transparent as hopping from cel tower to cel tower

  • different contexts require different interfaces

  • Q: how do different processing power and cloud computing fit into everything?

1984 touchscreen watch

  • A: if you’re aware the crowd exists, it wasn’t properly done and you shouldn’t be using it. The only processing power that matters is between our ears. In 1984, for $100, you could buy a Casio watch with a touchscreen that recognized gestures with a fraction of current processing power. A watch today should be a remote interface for the phone in my pocket.
  • 0 Shares
  • Share on Facebook
  • Share on Twitter
Justin Richard

5/15/12 Standup – setting the template in database.yml

Justin Richard
Tuesday, May 15, 2012

Interesting Things

You may need to specify a template in your rails database.yml to use the rails connection to create a Postgres database via your rake scripts that has your preferred configuration.

Specifically, a team found they needed to specify a template (template: template0) in their database.yml to create UTF8 encoded databases for their project running on Ubuntu 11.04.

Note that your milage may vary here, since the settings on the template database will vary by platform, config and compilation. You might not get the same results using template0, but its interested that you can set it since it wasn’t obvious that it was even available.

  • 0 Shares
  • Share on Facebook
  • Share on Twitter
Jonathan Berger

FOWD Day 2: Notes On Design – Brendan Dawes

Jonathan Berger
Tuesday, May 15, 2012

Brendan Dawes, hacker and interaction designer, trawled through his sketchbook to deliver an inspiring opening talk about his work, what inspires him, and some Rules for making. Full notes after the jump.

“It should remind you of something you’ve never seen before.”

  • finding beauty in the mundane

Paper clips from several countries.

  • BD collects paper clips: made from the same material, do the same job, but communicate different aesthetics

Life’s too short to own an ugly pencil

Obsess about the tools you use

I hate that phrase “A poor craftsman blames his tools”. I’d like to find who said that and bash him in the face with a beautifully-made hammer.

Blackwing 602: L30 on ebay. Chuck Jones used these.
Palomino Blackwing
Dixon Ticonderoga. Rahl Dahl wrote with these.

When you care at that level, you’re going to care about the things that come forth from these tools.

Innovation / Iterinnovation

Iteration as a craft or as a way to see new things. Instagram was an iteration on photo sharing, not an innovation.

  • Saul Bass titles for Vertigo in 1958. John Whitney created oscillating art that looked computer generated using Lissajous Curves.

  • BD started iterating on these. only 0.1 difference between each one. Sometimes you’ll go from an ornate design to a circle in one step. Lissajous Curves

  • Occasionally we’ll make beautiful things out of this iterative process.
  • This showed BD the importance of continuously making things.
  • What about the n+1 iteration? You’ll always run out of time and budget at some point. That’s a design constraint; embrace it.

Comma. Semicolon. Full stop.

Well designed objects are all imbued with good use of punctuation.

  • This includes physical objects, apps, whatever.
  • BD was designing packaging for a physical object. He got the box back and it opened too easily. By re-engineering the box so that there was a short pause in the opening, the experience of opening the box was enhanced. It was a 10mm engineering change.

Subtract to Add.

You know something’s finished not when there’s nothing left to add, but when there’s nothing left to take away.

Why can’t things be perfect at version 1? Why are we never done with things?

Created the accidental news explorer: search for a term, read an article, discover Related News, spiral out, end up somewhere you didn’t expect to be.

Spent two weeks adding a feature: suggested starting points (headlines). Usage increased 2%. Was it worth it? BD felt compelled to do an update because people feel as if an app is dead if its not being updated.

Make [pencil]. Make better [eraser].

I make for me.

Using lots of tools: altoids tins, keychain laser pointer, chumby, calipers, pencils, arduinos, breadboard.

Memory Box
His wife asked for L200 Christian Dior face cream for her birthday. He gave her a box that with an ardiuno and a small LCD screen that played back their text messages. Physical container for digital things.

Data by itself is not enough. Data needs poetry.

What if one button did one thing?
Laser-cut wooden box with an arduino and a display of the weather that peeks through the transparent button.

happiness machine
Device to print for happy thoughts on the internet.

Be Naive.

One of the makerbot founders said “If we were mechanical engineers, we would have known this was impossible and never tried it.”

BD has a makerbot and made a lot of crap. He also made some useful stuff: egg cups, headphone wrap to contain cord.

He doesn’t use a visual interface; it’s done all in code: OpenScad. Write code and it spits out a model.

Own what it is that makes you different (Aimee Mullin)

  • Aimee Mullin: fashion model, athlete, double amputee. Her story was featured on the Moth, “True stories told live, without notes”.

  • BD learned Bring to projects what makes you you, and celebrate that.

  • Watch this (don’t read the author):

  • Once you know who it is, it totally makes sense.

It took me a long time to get to the top of the Empire State Building. I was uncomfortable. I wasn’t happy. But all that was forgotten when I saw the view.

  • 0 Shares
  • Share on Facebook
  • Share on Twitter
Jonathan Berger

FOWD Day 2: A Closer Look At Accessible Mobile App Design – Robin Christopherson

Jonathan Berger
Tuesday, May 15, 2012

“My name’s Robin, and I can’t see.”

This is one of the most moving talks I’ve ever seen at a technology conference. Robin talks about the history of assistive technology for the blind during his lifetime, and the dramatic change that the iPhone wrought. The blind have an old joke that asks “How many blind people does it take to cross the street?”, and the answer was “Two: one to push the shopping cart full of devices for car-watching, curb-finding, direction-mapping, etc. And another to ask a sighted person for help.” An affordable pocket computer with motion sensors, an accelerometer, a camera, and a thriving app ecosystem has changed all that. Robin went on to detail what specialty apps he uses, which mainstream apps are (and aren’t) optimized for accessibility, and showed us the nitty-gritty of how technology changes his life and empowers him every day.

With technology came opportunity

  • In the 1980s, the PC revolutionized opportunities for disabled people in the home and workplace. This is how Robin got through his education.
  • Stephen Hawking Technology and adaptability allowed for great contributions from people like Hawking.
  • All you need is a single moving body part or the ability to make a sound or puff into a tube, and you can control a computer.
  • An iPhone changed the game: inclusion, power, and price. Now this power is in peoples’ pockets.

  • [* Robin plugs audio-out into computer*]

  • NB: One nice thing about being blind is that if you ask for assistance at the train, they always let you sit in 1st class.

  • Another is that I don’t know what people look like; their physical appearance has no impact on me. I don’t know whether they’re old, young, whatever.

[Video of Joshua Neely, blind].

  • single iPhone replaces multiple devices
  • two ways to navigate iphone:
    • touch item on the screen (and voice announces icon)
    • swipe left or right for previous or next
  • Once it says an item, it’s selected. double tap anywhere on screen to open it up.
  • Compass will announce direction. This is really useful for blind people who are disoriented with regard to direction, espcially in wide-open spaces like parking lots or fields.

Before iPhone

  • Specialty products at specialty prices.
  • Talking GPS was £700, talking notetaker was £2500.
  • You can get an affordable Braille bluetooth display for use with iOS devices.

Specialist Apps

  • [Robin's now using his iPad ]
  • Adjust speech rate with two fingers moving clockwise
  • Turn screen off and double battery life
  • Light detector app: there’s no talking ovens, so this is how you tell if the oven’s on.
  • Money Reader App: he’s waving a bill under the iPad camera and it announces “20 pounds”. It takes a few tries for him to get it; usually, he does this on the iPhone (better camera, flash).
  • LookTell Recognizer: similar treatment; wave objects under the app and it’ll announce.

Mainstream Apps

Apps vary wildly in their accessibility.

  • Skype: Robin can access the dialpad, contacts, calling. All of the actions speak and can be navigated by touch (without sight).

  • Adobe Connect (Skype competitor): none of the objects are exposed to accessibility. He has no idea what’s going on.

  • Pages: a working word processor, fully accessibility-enabled. It reads text, tells him what’s selected, meta information, screen content. Voice will let him navigate, read content. New iPad will allow dictation. He’ll use a bluetooth keyboard; various multi-touch gestures are available via keyboard shortcut. It’ll read his deletions and meta information around what he types. Very accessible. iPads are the tools of choice for schools in the US.

  • Facebook: lots of accessibility shortcomings. There’re other apps that do similar things to FB, but some apps capture the audience; he can’t find his FB friends anywhere other than FB.

  • Lanyrd (app for conference planning): totally non-accessible. Can’t even sign in.

  • iBooks: Everything is exposed and accessible.

  • Kindle: Lots of unlabeled images. Listen to the text. Very little meta information. There’re other Kindle readers for the blind (and the Kindle hardware is fine) but the iOS app doesn’t work.

Siri Envy

  • Accessibility is great, but its much slower than what sighted people can do. That sort of inefficiency is multiplied when you have to jump from email to calendar and back.
  • Siri lets Robin send a tweet really quickly. He just sent https://twitter.com/#!/USA2DAY/status/202360450736865280 from stage.

Evie

  • Alternative to Siri. Also available on android(?)
  • Geo search on Siri is limited to the US.
  • Ask a question, it’ll answer.
  • Answers can be rated up or down.

Accessibility on iPhone

  • This is available in the accessibility settings on iOS. Triple-click the home button to turn on the voice.

  • iOS Developer Library has an Accessibility Inspector which can help you make your apps accessible.

  • There’re lists of helpful apps, as well as non-accessible apps.
  • Android accessibility isn’t as well-developed. Large portions of the OS and many apps aren’t accessible. Blind Android users have to buy supplemental software and hardware.
  • Windows Phone 7 is a non-starter for accessibility.
  • Carsonified is doing great work at Treehouse with accessibility tutorials.

  • Mobile accessibility in mobility: using a robotic exo-skeleton to walk:

  • Claire Lonas walked the london Marathon in 16 days with a bionic suit after being paralyzed from the waist down.

  • Las Vegas is the first place that Google’s Driverless cars are legal. Steve Mahan, a blind user, gains independence. Here’s a video of Steve driving to get a taco, picking up his dry cleaning.

  • AbilityNet: consultancy, training, accessibility audits, disabled user testing, workplace assessments. robin.christopherson@abilitynet.org.uk

  • “Thanks to these tools I was able to move to where I live, meet my wife, have my two beautiful children. I owe everything to the technology.”

  • 0 Shares
  • Share on Facebook
  • Share on Twitter
Jonathan Berger

FOWD day 2: Art Direction Vs The Web – James Fenton

Jonathan Berger
Tuesday, May 15, 2012

James has an fascinating and insightful take on how Art Direction—a concept from the print world—works in new ways on the web. He shares his thoughts about how to manage a brand across large groups of independent teams, as well as several really interesting implementation ideas and hacks. Head past the jump for the full notes.

Intro

  • Art Director at Tribal Group, an education services & technology co with ~2500 people.
  • Used to be UI Designer, was promoted to Art Director after a shake-up.
  • Now his brief is to tend to the brand across an agency split into hundreds of small agile projects.
  • His predecessors were from the worlds of Print or Marketing.
  • He didn’t want to hover or reduce his team to pixel pushers. http://hoveringartdirectors.tumblr.com/
  • He wanted briefs to be more defined and guided rather than saying “make it pop”.
  • He didn’t want Art Direction to be another level of management.
  • “Art Direction” is a traditional term from advertising and branding. We also have it in film, publishing, etc.
  • Print seems to be the most aligned with Art Direction on the web. Writing is coupled with visual content.
  • [VENN DIAGRAM]: Written content <=> Art Direction <=> Visual Content
  • In the Print world, constraints are all on the cost of production: printing costs, design time.
  • In the Web world, constraints are all on user: usability, different browsers, accessibility.

Affordances

Looking at the same article in AFAR magazine in both Print and Web.

  • In print, the first page is a huge photo with a hed and a lead paragraph.
  • On the web, its a single column of text.
  • On the web, images tend to be supplementary rather than complementary.
  • The only thing we can control on the web is based on semantic information
  • rather than working most closely with photographers and producers, we have to work most closely with developers.
  • John Naughtton wrote Graphic designers are ruining the web, complaining that ~300 HTTP calls for a single article because of images and other junk.
  • JN prefers http://norvig.com/ because its raw and suggests a return to basic HTML, a la Craigslist.
  • Flaws in his argument: he already knows this content. This won’t work for discovery.
  • Another flaw: he thinks graphic design is just pretty pictures and decoration.
  • http://rainfall-daffinson.com/ is a counter-example: minimal, light, but easy to read.

  • Veroique Vienne: “The role of art direction is literally to direct attention.”

  • This is curation: it’s a space to view content. Make the space as neutral, non-distracting, as possible. Let the focus be on the content.
  • That’s not to say that we don’t direct the user through the space. We do that with signposts and wayfinding.
  • Pinterest typifies this notion of curation on the web.
  • It’s very literal (photos) with minimal navigation
  • is similar to pinterest
  • This sort of personal Art Direction is possible on a small scale: portfolios or small projects. How to do it at scale?
  • At Tribal, many agile teams are focused on their individual projects at all times; not focused on the brand.
  • Traditionally, Brand Guidelines have tried to serve this role.
  • Tools: colors, fonts, backgrounds, use of imagery preferences (e.g. “no posed photos” rule).
  • Also collateral: business cards, stationary, annual reports.

Static Brand Guidelines

  • Created a web color palate. When he got there, they only had RGB and CMYK. He added hex.
  • The ugly side to Brand Guidelines: brand police.
  • Brand Guidelines are static documents.
  • Often the Brand Police are charged with enforcing the guidelines even if they don’t understand the motivations for the guidelines.
  • Companies born on the web tend to have more fluid brands, e.g. Google’s whimsical logos, the MIT Media lab (”in NY”!) has a generative logo with 40k variations.
    MIT
  • He started looking at more flexible approaches: creating different logos as brushes in Illustrator, which could then be used in different ways.

Making Brands Dynamic

Brand Toolkit

  • Created a Brand Toolkit rather than Brand Guidelines.
  • A consistent look can be achieved across sites by focusing on the plumbing: common elements most sites require. Therefore, JF create a Brand Toolki Collection of Icons (for common activities like wayfinding, sharing, etc.).
  • This allows for a consistent experience across sites without heavy-handing top-down brand-policing.
  • Started w/ 25 icons, and it’s grown over time. Icons for globe, window, chart, document, trash, youtube, paper clip, linked in, test tube, ruler, etc. etc.

Sprites

  • To manage this duplication of work, they started using image sprites for logos and brand elements like the icon set. This is really useful for the product suite because they can share the sprite across projects.
  • If they re-brand or tweak the icons or even change the logo, they can change them everywhere as long as they keep the sprite coordinates constant.

Design Etiquette

  • Started with Photoshop Etiquette.
  • How to share source files in a way that lets others use them easily?
  • These are editable, living documents that will be repurposed.

UI Pattern Library

  • Dev teams work in silos and then need to share more, so they started using Yammer to facilitate communication among the teams. 2500 people in Tribal(!)
  • Pattern library helped share.

Code Snippets

  • Sharing HTML and CSS snippets across the brand.
  • Don’t have to re-invent the wheel.

Tribal Design Principles

1. Define a vision, through clear guidance and a brief.

They created a structured brief, which evolves over time, but allows them to have a common starting point.

2. Be flexible, and embrace the change that comes.

Don’t set rigid structures; as technology and media changes, we can adapt.

3. Aim for consistency in the quality of experience.

Rather than uniformity across all products and platforms, aim for consistency for the user.

4. Share the assets, patterns, and ideas

They use Sharepoint (which is kind of clumsy) and are looking for something better.

5. Democratize the design process.

Involve all the people and get their input. This isn’t design-by-committee, this is inclusion of the team: client, product owners, everyone.

  • 0 Shares
  • Share on Facebook
  • Share on Twitter
Justin Richard

Standup 5/14/12 – Watch your SafeBuffer

Justin Richard
Monday, May 14, 2012

Interesting Things

ActiveSupport::SafeBuffer do not work with all the features of #gsub. Mind your strings, or fix this bug in ruby!

# normal:
1.9.3-p125 :004 > "foo".gsub(/(?<my_string>.*)/) { $~[:my_string]*2 }
 => "foofoo"

# broken:
1.9.3-p125 :005 > "foo".html_safe.gsub(/(?<my_string>.*)/) { $~[:my_string]*2 }
 => ""

# round trip, back to working
1.9.3-p125 :006 > "foo".html_safe.to_str.gsub(/(?<my_string>.*)/) { $~[:my_string]*2 }
 => "foofoo"
</my_string></my_string></my_string>
  • 0 Shares
  • Share on Facebook
  • Share on Twitter
Ken Mayer

Deploy strategies for HerokuSan

Ken Mayer
Monday, May 14, 2012

Deploy Strategies

If you look at the network graphs of heroku_san on github, you’ll see a number of branches where the only change is the deletion of the following line from the deploy task:

stage.migrate

If more than a few people are willing to take the effort to fork a gem just so they can delete 1 line, something smells. The reason is that these forkers were using something other than Rails+ActiveRecord+SQL in their project. Some were using Sinatra, others were using Rails, but with CouchDB.

The raison d’être for the heroku_san gem is to make Heroku deploys dirt simple. So, if people are making whole forks to customize the deploy task, we should make it less painful.

Enter strategies

Strategies are an object oriented programming pattern for creating pluggable execution control. Now, there is a new class of objects that inherit from HerokuSan::Deploy::Base. These objects control how deploys are executed for you. The Rails strategy, HerokuSan::Deploy::Rails does exactly what HerokuSan has always done:

  • push to git@heroku.com
  • call rake db:migrate
  • restart

On the other hand, the Sinatra strategy, HerokuSan::Deploy::Sinatra does nothing more than the base strategy:

  • push to git@heroku.com

You can create your own strategies and then configure HerokuSan to use it instead of its default:

Rails 3 projects

Amend your Rakefile:

require 'heroku_san'

class MyStrategy < HerokuSan::Deploy::Base
  def deploy
    super
    # call my own code to do something unique
  end
end

HerokuSan.project = HerokuSan::Project.new(Rails.root.join("config","heroku.yml"), :deploy => MyStrategy)

Sinatra (and other Rack based apps)

Amend your Rakefile

require 'heroku_san'

class MyStrategy < HerokuSan::Deploy::Base
  def deploy
    super
    # call my own code to do something unique
  end
end

config_file = File.join(File.expand_path(File.dirname(__FILE__)), 'config', 'heroku.yml')
HerokuSan.project = HerokuSan::Project.new(config_file, :deploy => MyStrategy)

load "heroku_san/tasks.rb"
  • 0 Shares
  • Share on Facebook
  • Share on Twitter
Jonathan Berger

FOWD Day 1: Tapworthy Mobile Design – Josh Clark

Jonathan Berger
Monday, May 14, 2012

Designing for Touch with Josh Clark

Day 1 of the Future of Web Design was a fantastic workshop on designing for mobile with Josh Clark aka @globalmoxie, fellow Brooklynite and author of Tapworthy, a sharp guy, and a great speaker. Hop below the fold for the full notes.

§1: Mobile Context

Intro

  • Early assumptions about designing for mobile may not have been right
  • JC wrote “TapWorthy: Designing great iPhone Apps”. More of a general touch-ui specific book than exclusively iPhone.
  • Q: “What’s your favorite app?” A: uhhhhh…they all drive me crazy? Maybe MindSnacks. Discuss w/ yr neighbor.
  • Software used to be very grey and dry, but it’s tough to get you to stop talking about your favorite app. It’s an engaging question. First the web, and now especially mobile, have made software much more human and lovable and fun.

Anthropology

  • We’re all anthropologists here.
  • Though we design monolithically, there’re lots of mobile cultures.

Myths

Myth 1: Mobile users are rushed and distracted

Mobile isn’t actually mobile anymore. It’s on the couch, in the kitchen, on the 3 hour layover. We have time. Mobile != Desktop Lite

  • Example: alibris (amazon competitor) left its main differentiating feature (rare book sales) off the mobile app.
  • 28% of US mobile web users mostly use the web on mobile
  • 25mm people only see the web via a phone
  • Making all content and features is a “civic responsibility”. Mmm…

Myth 2: Mobile == Less

  • Jacob Nielson recently advised a separate, feature-reduced site for mobile. JC does not agree.
  • Don’t confuse context with intent.

Myth 3: Complexity is a dirty word

  • Complexity is good. It’s powerful.
  • Mitigate confusion, not complexity.
  • Figure out what the user needs.
  • Example: “Do I need an umbrella”? app is perfect for JC. For his Weather-Channel-watching father in law, it’s condescending.
  • It’s not that ‘less is more’; it’s that ‘just enough is more’.
  • Original Facebook iOS app was desktop-lite; users were incensed. “No comments?! No photos?!” It’s since grown to include ~90% of the desktop feature set, and it the most-used FB interface.
  • Don’t manage complexity all at once; manage it through give-and-take.
  • Don’t confuse clarity and density
  • “Every screen should have a primary task”.

Myth 4: Extra taps and clicks are evil

  • We’re not on dial-up modems anymore. A lot of “minimize clicks” ethos had to do with mitigating the effects of latency.
  • “Every tap should deliver satisfaction”: more information, a smile, whatever.
  • “Progressive disclosure”: give a little bit at a time, as its asked for.
  • An interesting opportunity for phones is that there’s probably only one user; you can train a specific user. E.g., twitter was hiding some controls. To educate the user, they opened the screen w/ hidden controls visible, and then hid them after 250ms. Later, they turned off the animation once the user triggered the “Show more controls” button.
  • “Mobile == More“
  • How can mobile do more? It’s got cameras, microphones, gyroscopes.
  • Start with a basic site, use feature-sniffing javascript to discover what the client can do.

Myth 5: Gotta have a mobile website

  • You need a great mobile experience, but a mobile website? Maybe not.
  • There is no ‘mobile web’. Don’t silo by device.
  • if “www.mysite.com” redirects to “mobile.mysite.com”, you’re doing it wrong. URL == Uniform resource locator.
  • We only know device context, not user context.
  • Ideally, there should be One Web.
  • The mobile site shouldn’t have less stuff than desktop because there’s a smaller screen. It should have less stuff because most of the stuff on desktop is crap.
  • Luke W.’s whole “mobile first” point is that small-screen design constraints are a useful filter for everything.
  • Content runs the show. Your interface is a collection of apps plugging into the wellspring of content.

Myth 6: Mobile is about apps (or websites)

  • We tend to focus on a single container (e.g. apps or websites)
  • An app isn’t a strategy; it’s an app.
  • Your product isn’t an app, or a website, or a feed, etc. These are all containers. You’re product is your content.
  • We have to pull back from our obsession with presentation and think about content.
  • Civilians (not just geeks) are beginning to expect their content to be available on every device.
  • Some people have all the devices (laptop, tablet, phone), others only have one.
  • We’re also beginning to expect that this content is integrated: when I put down my Kindle and start reading on my phone, or I pause a Netflix movie on the TV and pick it up in bed on my iPad, it picks up where I left off. With iCloud, this is happening with the content we create.
  • We’re all iCloud developers now.
  • Every native app should be a web client. The browser’s a native app, btw.
  • Some thoughts on this stuff: http:futurefriend.ly

Myth 7: CMS and API are for database nerds

  • We all need to think about this stuff.
  • Structured content is going to allow us to design for multiple platforms.
  • “Metadata is the new art direction.” Ethan Resnick, @erd_ux 19-yo NYU student(!)
  • Ergo, we have to drive our design skills further down the stack.
  • Traditional editorial judgement often disappears when we go mobile, e.g. newspaper layout (reflects editorial judgement about what’s important) vs. many digital interfaces (often simply reverse-chronological order).
  • Let the robots do it: e.g., the Guardian parses InDesign .indd files to gauge importance and reflect that on the web.
  • Repurpose design content.
  • Create content and design strategies that aren’t tied to a particular container.

Summary

  • Mobile != rushed
  • Mobile != less
  • Complex != complicated
  • Tap quality > tap quantity
  • No such thing as ‘mobile web’
  • Focus for all platforms
  • Don’t think ‘app’; think ‘service’.
  • Metadata is the new art direction

Everywhereness is a design nightmare

  • It suggests infinite possibilities and therefore infinite priorities.
  • “Simplify before we suppress.” – Ethan Marcotte

Contexts we tend to design mobile against:

Context #1: I’m microtasking:

  • Capture lost time: waiting on line, when your dining companion leaves for the bathroom, etc.
  • identify lost tasks
  • Find the primary task for an app and make it available everywhere (e.g. todo apps should have an ‘add task’ icon on every screen).

Context #2: I’m local

  • Mobile is the primary device not because it’s always with you (though that’s important), but because it knows the most about you: sensors, personal data
  • change context, not content:
    • Shopper: shuffles your shopping list depending on where your geolocated in the store, e.g. produce aisle, dairy, etc.
    • Word Lens: point camera at a word in a foreign language, see translation.
    • IntoNow: foursquare for TV that listens (like Shazam) to identify season and episode.
  • Save input effort on these devices because they’re not that good at traditional input.
  • Table Drum: map table taps to drum kit sounds. WANT! Transforms your environment into an interface.
  • How can we use the superpowers of the device for input?

Context #3: I’m bored

  • It’s not so much “i’m bored” as “i have attention to spend”.
  • Software isn’t just for work anymore: fart-apps might be frivolous, but they represents a shift from software-as-business-tool to software-as-distraction and entertainment for civilians (not just geeks).
  • Exploration is a common theme for escape apps (reading, games, etc).
  • Work apps have a lot of untapped potential for exploration; quantified life apps are video games for narcissists.
  • Don’t just optimize for the fastest interaction; give them a chance to slow down and explore.

How do we use these?

CHART: usage of device (mobile, tablet, desktop) vs hour-of-day usage of device (mobile, tablet, desktop) vs hour-of-day.

  • iPad use explodes after 6pm or so; it’s the return of the evening newspaper.
  • Phone is mobile, tablet is portable.
  • iPhone: very active browsers, more willing to buy, skew older, wealthier, more educated, have more sex than other mobile users.
  • NB: eBay == 25% of US mobile commerce
  • Ads are a good proxy for how companies think of themselves and their customers
  • Apple ads for Facetime: Louis Armstrong, parent seeing child, grandparents seeing graduate. Sentimental.
  • When people get these devices for the first time, they’re surprised at how emotionally attached they are
  • Verizon droid ad: sci-fi alien cyborg. It’s about the technology.
  • Android skews techy, users customize their phones more (wallpaper, ringtones), skews more to straight communication. Apps are tools, not media. Skews younger, less affluent.
  • Windows mobile: formerly MS + Symbian were 80% of market. Slaughtered by iPhone.
  • Metro interface is helping MSFT come back. Very interesting UI. Aiming for a specific user (young, mobile couple, very plugged into social media). Incorporates personalization.
  • No clear winner right now.
  • 46% of US adults have smartphones. There’re still a lot of people on feature phones.
  • 75% of US adults use text message. Teens do about 8 texts / waking hour(!).

§2: Finger-Friendly Design

What do you wish your phone could do?

Brainstorm a quick list of apps to work on.

  • Collate tour recommendations into an offline touring app
  • Allow me to make calendar appointments / decisions and communicate them via email in a non-shitty way
  • Turn objects on the table into a drum machine
  • capture 3D panoramas
  • capture panoramic workspaces, eg capture my whiteboards and foamcores in virtual space and let me view windows into them

Group suggestions

  • Family intercom app so I don’t have to shout to my kids acorss the house
  • Find the nearest open burger king; the Junk App aka Junkfinder
  • dictophone that translates into mini notes for music
  • universal remote for home
  • on-the go IDE
  • customize your phone
  • home automation app
  • integrated augmented reality app
  • organize work by client or project on the go
  • touring recommendations
  • calendar & comms on a single screen
  • aug-reality whiteboard

Winner: integrated home automation (coffee, lights)

Consider the physical affordances of the device

giant swiss army knife

  • Huge physical load, but also huge cognitive load
  • clarity trumps density
  • handheld => industrial design. how do your pixels feel? In one hand?
    • one hand, tapping with thumb
    • two-handed, tapping with thumbs
    • hold with one hand, tap with the other

Thumbs are awesome

  • one-handed, tapping w/ thumb is the most common

Thumb Tapping Hot Zone

  • Top-vs-bottom is the main axis of emphasis; don’t worry about left vs right.
  • In iOS, edit buttons tend to go top-right; available, but not risking accidental taps

Occlusion

  • Traditional physical design tends towards control at bottom, content at the top.
  • How to keep fingers from occluding content?

Placing Controls

  • It’s a bad idea to stack controls on touch devices, especially on the bottom of the screen. Lots of opportunity for mis-taps.
  • Primary system controls are good at the bottom.
  • Tabbing works a little better at the top for Android, bottom for iOS.
  • Position:fixed is really poorly implemented on mobile browsers, especially for Android. It’s hard to get position:fixed to work right.
  • Apps like LinkedIn overwrite native scrolling in javascript to do things like pinning controls to the bottom.
  • Ad Age uses a “MENU” button on the top right, which is an anchor link to the full-screen nav located at the bottom. HTML 1.0. Quick, clean, DRY, universally implemented.

Placing Navigation

  • iPhone: screen bottom
  • Android: screen top (don’t compete w/ primary hardware buttons)
  • Native web: page bottom

Tablets

  • Avoid putting controls on top-middle of screen.
  • Put controls in the top-corners.
  • UNLESS you need to preview the effects in the main window above, in which case controls need to be on the bottom.

Targets

  • Apple suggests 44pt is the minimum target size for tap targets.

INTERLUDE: Pixels vs points

  • Now that screen density varies widely, measure in points: 1/96th of an inch.
    Ceci n'est pas un pixel

  • Android: “Density-independent pixel (dp)”

  • iOS: Point (not to be confused w/ typography points)
  • CSS: “Pixel”. D’oh!
iPhone
  • Originally 320×480.
  • Retina doubled it to 640×960. How to deal w/ legacy screens?
  • Introduce points: Retina: 2px == 1pt.
  • Other displays: 1px == 1pt.
  • iOS knows that image@2x.png (100×100) is the retina version of image.png (50×50).
  • Design in vector, beware half-pixel divisions.

Back to Pixels vs Points

  • On the web, its a little uglier: <img width='50' height ='50' src='image@2x.png'>. Now we’re shoving hi-res images down the pipe even for screens that can’t handle it.
  • Responsive image serving is a hard problem w/in the context of HTML.
  • grigsby responsive images
  • argument for changing HTML
  • CSS
    .className { background-image: url(image.png); /*50 px square */ }
    @media only screen and (-webkit-min-device-pixel-ratio: 2)
    .className { background-image: url(image@2x.png); /*100 px square */ }
    .className { background-size: 50%; /*50 px square */ }

Targets!

  • Mobile touch is not only an interface for the hand, but of the hand.
  • 44pts (~7mm) is a useful touch target (size of the fingertip)
  • 44px is close enough on the web.
  • e.g. iPhone keyboard is 44pt high.
  • You can squeeze the other dimension as low as 29pt and it’ll still work, so 44×29 or 29×44 are ok.
  • iOS uses 44pt heights all over the place (key size, row height, top and bottom nav); it becomes a regular element of the graphic system, almost like a grid. Home icons are 88pts.
  • Android standardizes on 48dp (~10mm), because there’s enough variability in the hardware that they need a little margin for error.
  • The closer the buttons are together, the larger they have to be.
  • Hardware detection area accounts for occlusion (the target is a little below the visual), so smaller targets where you’re really concentrating and trying to be precise are actually harder to hit!
  • Touch targets tend to be larger than the visual area implies.
  • If you do have to take tap-risks and jam things together at the bottom of the screen, do the extra work and rebuild the bottom nav so the touch area isn’t that huge.
  • It’s ok / desirable to make your tap targets larger than they appear.
  • Don’t just make it easy to read; make it easy to touch. Clarity trumps density.
  • Don’t just design in Photoshop; put it on the app and test.
  • Glance test: put it on the phone, hold at arms length, and see if it makes sense.
  • Bite-size content (e.g. a weather app) should eschew scrolling when possible. Single-screen makes the app feel more solid, almost like a physical object.

Review

  • You’re designing a physical device.
  • Where do fingers and thumbs sit? (hot zones).
  • Varied rules for phones (iOS: controls at bottom. Android: controls at top).
  • Tablet: push to edges and corners.
  • Big fat touch targets: at least 44pt.
  • Progressive disclosure: clarity trumps density.

Building: Layout

Design the main screen

  • Featured content
  • Primary Tasks
  • Secondary Tasks
  • Navigation to other views

Remember

  • Make use of the sensors
  • Create room for exploration
  • Capture lost time

Design w/ team!

§3: Navigation

  • Remember Choose Your Own Adventure books? Tangled navigation paths.
  • Paths should not cross.
  • Paths should be predictable and unique.
  • It may seem that multiple paths give more convenience, but they’re harder to model mentally.

3 models:

Flat Pages:

  • Good for casual browsing, focused content, or discovery.
  • Good for variable screens, custom content.
  • Easy to swipe between pages.
  • Very little interface chrome; good for saving space, but not a lot of inference.
  • It’s flexible: typically let ppl change order, add cards.
  • Downside: can’t jump to a specific screen.
  • Limited to 20 (practically, ~10) cards; past that, there’s no more room for the navigation!
  • Works best for homogenous content; when the cards are different, it’s tough to remember which screen is which.
  • Works best for no-scroll screens. It feels like a card, like something physical. We’re not that good at scrolling in two directions.

Tab Bar

  • Very familiar; this is where people start to design by default.
  • Easily allows for heterogeneous content.
  • Constant advertisement / reminder for what the app can do.
  • iPhone is limited to 5 tabs; add more and you’ll automatically get the “More” tab.
  • DO NOT use the ‘More’ as a junk drawer.
  • Have the discipline to leave things at 5 tabs on iOS; if you need more, go to Tree Structure.
  • If you’re on Android, drop to 4 tabs.
  • Android Ice Cream Sandwich introduces the Action Bar: show one tab, with 1 or more tools (depending on screen size and orientation).
  • Order: righties will have the leftmost tab in prime tab position, vice versa for lefties. New convention is to have the prime action being the center. How to draw attention? Make it a little bigger (a la old instagram or new foursquare).
  • Path: interesting vertical tab structure with invoked tabs, but a little weird and tough to discover.

Toolbar vs Tab bar

  • Toolbar: usually light background. Act locally (on the content on the individual screen).
  • Tab bar: usually dark background. Think globally. (change to show whatever tools you need to affect that content.)
  • Don’t show both at once.

Tab Bar Pro’s:

  • One tap access to all main features.
  • Clearly labeled menu advertises features.
  • It’s always there.

Tab Bar Cons:

  • Limited to four (five?) buttons.
  • Committing a lot of screen space.

Tree Structures

  • Scales to a ton of content.
  • Familiar mental model.
  • Direct interaction w/ content: the word or picture you want to use; it removes abstractions.
  • Nested folders, a lot like column view in Finder.
  • Allows longer and more customizable menu options.
  • Often a list.
  • But sometimes you’ll see springboards (facebook) or galleries (photo albums).
  • Not much room for a way out or ‘back to home’. Leads to a lot of ‘back back back’ garbage taps. It’s not easy to switch branches.
  • Work-around: combine w/ tab bar.
  • It would be nice to have a gesture to go back. “Swipe across the top” is becoming the norm.
  • As designers, we need to protect users from actions that will do them harm. Gesture Jiujitsu can help, e.g. using swipes (easy to do, hard to do accidentally) for undo or Return To Home.
  • One of the great things about touch is that it removes mediation; you deal directly w/ what you want.
  • Cons:
    • Main categories available only from top.
    • Inefficient to switch branches.
    • No standard for returning to top level.

Popovers

  • iPad is a monster in the tablet space (although Kindle Fire is coming on strong in the US).
  • It’s too big a screen to be switching pages all the time. Often the phone’s “card-flipping” model doesn’t work as well.
  • Long-hold is the right-click of gestural interfaces.
  • Pop-overs are ok for quick interactions.
  • Use popovers to act on content.
  • Use popovers for quick peaks.
  • Avoid popovers for exploration or navigation.

None of the above: new interfaces

  • Design the personality of your app at the outset.
  • A personality will emerge no matter what; if you don’t design it, you’ll be at its mercy.
  • Simple things like backgrounds can change the personality greatly, even while sticking to the same design patterns.
  • Emotion is a design element.
  • Q: do you like skeumorphism? At worst, it can be kitschy, but at best it can show you how to use the app. What does your metaphor propose? and what does it promise? If it looks like a book, I should be able to turn the page (I’m looking at you, iPad contacts). Be true to your metaphor when you go skeuomorphic.
  • Skeumorphism often takes a strong point of view, which can be good or bad.

Metaphorically speaking

The Dark Art of Aping Real Objects

  • Some clones are the same size: Guitar tuner, apple remote. Sounds and animation can enhance that illusion. You’re absorbing all the industrial design thought that went into the original, though you may lose some ergonomic affordances.

  • Minitures (Chess, GarageBand’s piano) are a bit different. The interface loses its ergonomics.

Voice capture app is eye candy, but not functional.

  • Sometimes it’s just eye-candy. (E.g. voice capture app w/ its microphone).
  • Lots of shelves these days. Its just a dressed-up tree structure, but we love collections. It’s fine for things that belong on a shelf (e.g. books), but you’ll lose emotional resonance when the objects can’t really be on shelves and the metaphors break.

  • When contemplating metaphors:

    • Is this a problem that can be solved with built-in, native tools?
    • Are you being too clever? Is the metaphor complicating the mental model?
    • Is your metaphor appropriate to the device? Phone OS’s are card-based; bringing windows in gets weird.
    • Do you have more interface than you need?
    • Don’t be different to be different, be different to be better. Different means I have to learn something new.
    • Creative interfaces can be joyful. See: BeBot (robot synth app).
    • Ask: am I going too far? Am I going far enough?

Gimmicky presentation

  • “The sin of pridefully obvious presentation”: Ed Tufte.
  • The NYT app quacks a lot like a newspaper. Why so boring?
  • Apple asked NYT to build a demo for the iPad, just before the iPad was announced. Three young designers / developers were brought in: two weeks to do it, no contact with home base, no cell phones. “You’ll be demo’ing to Steve, make us proud.” Eep!
  • After 2 days, they built a Deck-based version. Realized it was wrong; went back to what became “NYT Editors Choice”. “Strong if conservative first effort”.
  • Sometimes you can impress most by doing it quietly.
  • NYT App: “Yawn. It looks like the NYT”. Flipboard: “HOLY CRAP! It looks like the NYT!!!”
  • Old conventions aren’t necessarily old-fashioned.
  • Feature the content, not the interface.

Gestures

Multitouch with Two Hands

  • Uzu app for iPad: multitouch manipulation of particle generators.
  • The utility of keyboard shortcuts comes from being able to do them w/o looking. Gestures provide a similar opportunity.
  • Gestures that begin at the edge should be OS-level gestures: android, WebOS, Meego all did this. Apple used to, but recently has been breaking edge gestures by taking them over.

  • Buttons require cognitive and physical effort.

  • Gestures ~= keyboard shortcuts.
  • Use entires screen as a controls.
  • Standards are emerging: tap, swipe, pinch/spread, long tap.
  • Model content as physical objects.
  • Explore multitouch gestures.
  • Follow the toddlers; they’re better at this than we are. They haven’t been spoiled by 20 years of desktop interactions.
  • Make a 3 yr old your beta tester. She won’t understand the content of the app, but she can use the interface and navigate.
  • “NUI”: Natural User Interface

Haptics

  • Shake is a powerful gesture, but can be gimmicky. It takes the focus off the app, and onto the device.
  • Younger people are more inclined to rotate the phone; older folks stay with portrait.
  • Landscape tends to be more engaging: both hands are occupied, and the aspect ration is closer to our biological field of view.

Conclusion

  • The more backward-compatible (accessible) your app is, the more forward-compatible (future-proof) it’ll be.
  • Mobile’s a great wedge, because it’s got everyone in a panic right now. We’ve been building websites the wrong way for 15 years.
  • We’ve got the most exciting job in the world!

Tweets

  • When designing for mobile, don’t confuse context with intent. – Josh Clark
  • clarity trumps density
  • 0 Shares
  • Share on Facebook
  • Share on Twitter
Ken Mayer

From customer requirements to releasable gem

Ken Mayer
Sunday, May 13, 2012

One of the many pleasures of working at Pivotal Labs is that we are encouraged to release some of our work as open source. Often during the course of our engagements, we write code that might have wide-spread use. Due to the nature of our contracts, we can not unilaterally release such code. Those rights belong to the client. And rightly so. So, it is an even greater pleasure when one of our clients believes in “giving back” to the community, as well.

One such example is this modest gem, attribute_access_controllable which allows you to set read-only access at the attribute level, on a per-instance basis. For example, let’s say that you have a model Person with an attribute birthday, which, for security purposes, cannot be changed once this attribute is set (except, perhaps, by an administrator with extraordinary privileges). Any future attempts to change this attribute will result in a validation error.

e.g.

> alice = Person.new(:birthday => '12/12/12')
=> #<Person id: nil, attr1: nil, created_at: nil, updated_at: nil, read_only_attributes: nil, birthday: "0012-12-12">
> alice.attr_read_only(:birthday)
=> #<Set: {"birthday"}>
> alice.save!
=> true
> alice.birthday = "2012-12-12"
=> "2012-12-12"
> alice.save!
ActiveRecord::RecordInvalid: Validation failed: Birthday is invalid, Birthday is read_only
> alice.save!(:skip_read_only => true)
=> true

Setting this up is trivial, thanks to a Rails generator which does most of the heavy lifting for you.

rails generate attribute_access Person

After that, you need only know about one new method added to your class:

#attr_read_only(*attributes) # Marks attributes as read-only

There are a few others, but this one, plus the new functionality added to #save and #save! will get you quite far.

And if that’s all that you were looking for when you stumbled across this article, then there’s no need to read any further. Go install the gem and have fun (and may your tests be green when you expect them to be).

From customer requirements to releasable gem

On the other hand, if you are interested in how we got from the original customer story to a releasable open sourced gem, read on. The source code for the module is a mere 34 lines long. It implements 2 new methods, a validator and (gently) overrides #save and #save!. Being good Test Driven Developers, we wrote our specs first, and since we wanted this behavior to be included in several models, we wrote our specs as a shared behavior as well. The spec clocks in at 44 lines, slightly longer than our implementation. All in all, tiny. The whole commit was less than 100 lines of code.

AttributeAccessControllable
  it should behave like it has AttributeAccessControllable
    #attr_read_only(:attribute, ...) marks an attribute as read-only
    #read_only_attribute?(:attribute) returns true when marked read-only
    #read_only_attribute?(:attribute) returns false when not marked read-only (or not marked at all)
    #save! raises error when :attribute is read-only
    #save!(:context => :skip_read_only) is okay
    #save is invalid when :attribute is read-only
    #save(:context => :skip_read_only) is okay

In order to get to something “releasable” we needed a few more things, which we put on our To-Do list:

To do

  1. MIT License
  2. A gem specification
  3. Basic documentation in a README file

The list got longer as we fleshed out both the documentation and the integration tests, as you’ll see in a moment, but first, let’s talk about

Getting the legal issues resolved

Pivotal’s open sourcing policy is straightforward and simple to execute; We don’t touch it. We write code for our clients, it’s their code to do with as they please. My particular client liked the work we did for them and thought it would make a great open source gem. The Director of Engineering signed off on the idea and I paired with him to create the github repository during a lunch break. The first commit was tiny, just a basic directory structure and the existing code. I don’t think the tests passed because they lacked a proper RSpec infrastructure.

Creating the gem

bundler gem DIRECTORY

is your best friend. It set up the layout for us, including an MIT License and a gem specification. It had a boilerplate README, too.

Writing the documentation for the code you wished you had

Next, we wrote a draft of the README file which documented what we knew: You needed a migration to create a column called :read_only_attributes and you needed to include the module into the class. Then we started thinking about the pain points of using our code as is. Wouldn’t it be nice if we could create the migration automatically? Rails generators do that sort of thing, how hard could it be? (Famous last words…) It became clear that we needed to test drive out some new features of the gem that supported the actual module.

To do

  1. MIT License
  2. A gem specification
  3. Basic documentation in a README file
  4. Integration test

I am not a big cucumber fan, but…

Really, I’m not. I used to write Cucumber features all the time, but nowadays, I use a combination of RSpec and Capybara to get most of my day-to-day integration testing done. There is, however, one sweet spot for Cucumber that I’m finding more and more useful; A very high-level document that describes essential features in a way that a reader will say, “Ahhh, so that is how it is supposed to work!” Here’s a copy of the spec I wrote:

Feature: Read only attributes

Scenario: In a simple rails application
  Given a new rails application
  And I generate a new migration for the class "Person"
  And I generate an attribute access migration for the class "Person"
  And I have a test that exercises read-only
  When I run `rake spec`
  Then the output should contain "7 examples, 0 failures"

You probably won’t find any web-steps out there to handle these lines. I use Aruba to handle the dirty work of executing shell commands in a safe sandbox-y way. The step definition file hides most of the ugliness. Even so, most readers could figure out what to do, by hand, for each step.

To do

  1. MIT License
  2. A gem specification
  3. Basic documentation in a README file
  4. Integration test
  5. Generator

Big generators

This gem was my first attempt at writing a generator, so it was awkward. I still don’t understand Thor properly. Fortunately, I happened upon Ammeter, which helped me write out test specs for the generator. If you’ve got good specs, then you can sometimes stumble along until you learn enough to get it right. Alex Rothenberg’s original blog post about the gem was quite informative, as were the test cases from the Devise gem.

I have to admit; constructing the generator was more complex than the original module! There are more “moving parts;” templates, usage files, specs, in addition to the generator itself. So there is a certain amount of overhead that might overwhelm the original content. On the other hand, I learned quite a bit, and the gem is far more useful.

require "spec_helper"
require 'generators/attribute_access/attribute_access_generator'

describe AttributeAccessGenerator do
  before do
    prepare_destination
    Rails::Generators.options[:rails][:orm] = :active_record
  end

  describe "the migration" do
    before { run_generator %w(Person) }
    subject { migration_file('db/migrate/create_people.rb') }
    it { should exist }
    it { should be_a_migration }
    it { should contain 'class CreatePeople < ActiveRecord::Migration' }
    it { should contain 'create_table :people do |t|'}
    it { should contain 't.text :read_only_attributes'}
  end

  describe "the class" do
    before { run_generator %w(Person) }
    subject { file('app/models/person.rb') }
    it { should exist }
    it { should contain 'include AttributeAccessControllable' }
  end

Some interesting things to note; you must require the generator, since it is not pulled in by default. The subject of each suite is a file, not the class AttributeAccessGenerator. The migration_file helper prepends the TIMESTAMP onto the migration file for you. If you need to set up more things for your test, destination_root is a helper with a path to the temporary directory. It remains after the tests have run, which makes it useful when debugging.

Here’s something else that I did not know, but it might help new generator writers; the order in which you define your methods in the generator class is significant. I don’t know how this is done, but each “method” in the generator class is executed in turn. This is important for my generator; the model class definition must exist before I inject the new content that mixes in the module, so I had to write the generate_model method before the inject_attribute_access_content method. I was scratching my head over that one for quite awhile.

require "rails/generators/active_record"

class AttributeAccessGenerator < ActiveRecord::Generators::Base
  source_root File.expand_path('../templates', __FILE__)

  def create_migration_file
    if (behavior == :invoke && model_exists?)
      migration_template "migration.rb", "db/migrate/add_read_only_attributes_to_#{table_name}"
    else
      migration_template "migration_create.rb", "db/migrate/create_#{table_name}"
    end
  end

  def generate_model
    invoke "active_record:model", [name], :migration => false unless model_exists? && behavior == :invoke
  end

  def inject_attribute_access_content
    class_path = class_name.to_s.split('::')

    indent_depth = class_path.size
    content = "  " * indent_depth + 'include AttributeAccessControllable' + "n"

    inject_into_class(model_path, class_path.last, content)
  end

To do

  1. MIT License
  2. A gem specification
  3. Basic documentation in a README file
  4. Integration test
  5. Generator
  6. Shareable tests

Yo, I hear you like tests in your tests

Lastly, we want to share the testing love. The gem consumer should not have to write tests to drive out the same feature that we have already tested. That would not be very DRY. So, in order to make our shared behavior, er, um, shareable, we moved it into lib with a few wrappers, namely, the spec_support.rb file, which you can include in your own spec files to test drive adding the module to your own classes.

Which is where And I have a test that exercises read-only comes in. You can see this in the steps.rb file:

require 'spec_helper'
require 'attribute_access_controllable/spec_support'

describe Person do
  it_should_behave_like "it has AttributeAccessControllable", :attr1
end

To do

  1. MIT License
  2. A gem specification
  3. Basic documentation in a README file
  4. Integration test
  5. Generator
  6. Shareable tests

Don’t be afraid to release v1.0.0

I am a strong believer in semantic versioning. I simply can not understand why some core ruby tools are still living in version zero land, even after years and years of development and use. So, after a couple of internal commits, we released v1.0.0 of the gem, and less than a day later released v1.1.0 and then v1.1.1! (You probably shouldn’t use anything less than v1.1.1)

An interesting mix

In summary, we used a lot of tools and techniques to go from a simple commit to a shareable gem:

  • Rails generators
  • Cucumber
  • Aruba
  • Ammeter
  • RSpec shared behaviors
  • Integration tests
  • Generator tests
  • Module tests

I encourage everyone to release as much of their work as possible because it raises the state of the art for us all. There are limits, of course, but that still affords lots of wiggle room. Small gems like attribute_access_controllable won’t change the world, but they ease the pain of staying DRY and we all get to learn a little something.

Thanks

To Social Chorus for choosing to open source this code. And to Pivotal Labs for encouraging a better way to do software engineering.

  • 0 Shares
  • Share on Facebook
  • Share on Twitter
Jonathan Berger

The Future of Web Design in London

Jonathan Berger
Friday, May 11, 2012

I’m very excited to head to London next week to speak Code Literacy for Designers at the always-excellent Future of Web Design Conference. Working at Pivotal Labs, I’ve learned a lot over the last few years about how Agile software development and design interact, and I’m really looking forward to engaging in the conversation in one of my favorite cities. If you’ll be at FOWD, please come check it out at 11:15 on Wed! And if you’re in London and want to talk UX, drop me a line!

From the talk description:

Do you spend half your day on mockups in Illustrator and the other half on Javascript in a text editor? Know anyone who does? The way we work is changing. Rigid, traditionally defined roles like “Designer” and “Developer” are being displaced by interdisciplinary skillsets and a culture of collective product ownership. In this talk, we’ll investigate how treating Coding as Literacy can affect the way decisions are made and work gets done, describe how varying levels of literacy among teammates facilitate effective agile design and development, and discuss how designers can get literate in technical topics.

  • 0 Shares
  • Share on Facebook
  • Share on Twitter

Topics

  • agile (778)
  • rails (113)
  • testing (86)
  • ruby (83)
  • ruby on rails (70)
  • jobs (62)
  • javascript (53)
  • techtalk (44)
  • rspec (38)
  • activerecord (29)
  • productivity (29)
  • gogaruco (29)
  • ironblogger (29)
  • git (28)
  • nyc (27)
  • rubymine (25)
  • mobile (21)
  • cucumber (20)
  • bloggerdome (19)
  • process (19)
  • pivotal tracker (19)
  • design (18)
  • jasmine (18)
  • ios (18)
  • webos (17)
  • objective-c (17)
  • android (16)
  • palm (16)
  • "soft" ware (16)
  • fun (15)
  • tracker ecosystem (15)
  • ci (15)
  • cedar (15)
  • rails3 (14)
  • performance (14)
  • gem (13)
  • bdd (13)
  • selenium (12)
  • css (12)
  • goruco (12)
  • bundler (12)
  • tdd (12)
  • meetup (11)
  • railsconf (11)
  • nyc-standup (11)
  • capybara (10)
  • mac (10)
  • mojo (10)
  • chef (10)
  • rubygems (9)
Subscribe to Community Feed
  1. ←
  2. 1
  3. 2
  4. 3
  5. 4
  6. 5
  7. →
  • About
  • Case Studies
  • Team
  • Community
  • Careers
  • Contact
  • Labs
  • Events

Contact Us

contact@pivotallabs.com
+1 415-77-PIVOT
TwitterLinkedInFacebook

Pivotal Tracker

Tracker is the award-winning agile project management tool that enables real-time collaboration around a shared, prioritized backlog.
Visit pivotaltracker.com >