Pivotal Blabs

git reset -p for fun and profit

Kris Hicks — Wed, 16 May 2012 06:36:00 -0700

I've been using git reset -p a lot recently and I think it makes sense to clarify what it is that it does because when I first started using it I found it a little confusing.

I sometimes realize that an earlier commit contains some change that I don't want, so I want to remove it from the commit. This also works when not rebasing, so for simplicity I'll use an example where the commit to be modified is already HEAD. Previously I would have done:

git reset HEAD~1
git add -p
git commit -C <treeish>
git checkout .

Or, in English:

take off the HEAD commit, adding it to the working directory
add back the parts you want to keep
make a new commit using the message from what used to be the HEAD commit
throw away the changes you didn't want

With git reset -p this process is a little different. Here's what it looks like:

git reset -p HEAD~1
git commit --amend -C HEAD
git checkout .

Again, in English:

apply to the index the negations of certain parts of the HEAD commit
amend the HEAD commit with the negations
throw away the changes you don't want

How does this work?

In the second example you added -p to the reset command. This will reset only parts of the original commit, leaving it intact otherwise. That's worth stating a different way: When you reset -p, the original commit remains unchanged. The only changes are made to your working directory and index.

The trick is to know what you're doing when you're saying "y" to a hunk git presents to you for resetting. Say you added a line to the commit originally:

foo
+ bar
baz

But you want to get rid of it. When you git reset -p, git will ask you:

foo
- bar
baz
Apply this hunk to index [y,n,q,a,d,/,e,?]?

If you say 'y', Git will apply that hunk to the index. What you also get, however, is the original hunk (that added "bar") in your working directory.

To summarize, your working directory will have:

foo
+ bar
baz

While the index has:

foo
- bar
baz

While the commit (unchanged, remember) has:

foo
+ bar
baz

You now have a chance to tell git what you want to do, without having done anything to the original commit yet. In the example above, you wanted to get rid of the addition of the "bar" line. To do that, you want to take what's in the index (the negation of the addition of "bar") and apply it to the commit, making it go away:

git commit --amend -C HEAD

Then you still have in your working directory the adding of "bar", which in this case you just want to get rid of, so:

git checkout .

I like using reset -p because it makes it really easy to make small changes to a commit, removing something I added or putting back something I deleted.

reset -p allows you to more easily get a grip on the changes you've made and the ones you're about to make. It also makes much better use of Git, in that you can do even more interesting operations when in the resulting state, which I won't go into now as to avoid information overload.

And there you have it.

FOWD Day 2: Notes On Design

Jonathan Berger — Tue, 15 May 2012 06:41:00 -0700

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

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

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.

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.

Standup 5/14/12 - Watch your SafeBuffer

Justin Richard — Mon, 14 May 2012 18:03:00 -0700

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>

Director of Product Management at Sharespost

Ash Hogan — Mon, 14 May 2012 15:14:00 -0700

At Pivotal Labs, one of the services we provide our clients is helping them interview and hire. Pivotal Labs and our clients place a strong emphasis on Agile development and its many aspects: Pair Programming, Test-Driven Development, rapid iterations, and frequent refactoring.

Below is the job description for a Director of Product Management with Sharespost which is the only online platform that efficiently connects forward-thinking investors with late-stage venture-backed companies and their shareholders. They have the largest online network of private company investors ever assembled and the broadest offering of independent, third-party research. It’s all designed to make the process of managing secondary liquidity and raising primary capital easier and more transparent than ever before.

Sharespost is hiring - here's why you want to work there:

Job Description

Sharespost is looking for a Director of Product Management to work closely with senior management (especially the CTO and President/Founder) and the engineering team to manage the definition, prioritization, and development of our web application.

Responsibilities:

Work closely with the founders to translate the product vision into an actionable Product Roadmap and development backlog
Work hands-on with the development team to prioritize, plan, and deliver
Ensure the product meets the needs of Sharespost customers and employees (including Sales/Brokers, Operations, and Finance)
Work closely with outside design firm to shepherd the design effort and ensure timely deliver of designs and assets

Long term, the Director of Product Management will be based out of our San Bruno offices. We are currently engaged with Pivotal Labs for development services. The Director of Product Management will be based at Pivotal SF along with our CTO and dev team for the duration of the Pivotal engagement.

Desired Skills & Experience

4+ years of product management experience, especially with web products
Skilled at defining and prioritizing product ideas
Strong leadership and communication skills
Ability to collaborate well with engineers
Experience with Pivotal Tracker planning software
Previous success working with an agile development team
Domain expertise in financial markets is a plus
Background in design or software development a plus

If you’re interested in helping us build a great company in the fast-growing private capital market, please email your résumé and cover letter with the subject "Sharespost Director of Product Management."

Deploy strategies for HerokuSan

Ken Mayer — Mon, 14 May 2012 09:42:00 -0700

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. There's is now a new class of objects that inherit from HerokuSan::Deploy::Base. These objects now 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"

FOWD Day 1: Tapworthy Mobile Design

Jonathan Berger — Mon, 14 May 2012 05:56:00 -0700

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?

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

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

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.
Android: "Density-independent pixel (dp)"
iOS: Point (not to be confused w/ typography points)
CSS: "Pixel". D'oh!

iPhone

Originally 320x480.
Retina doubled it to 640x960. How to deal w/ legacy screens?
Introduce points: Retina: 2px == 1pt.
Other displays: 1px == 1pt.
iOS knows that image@2x.png (100x100) is the retina version of image.png (50x50).
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 44x29 or 29x44 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.

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

From customer requirements to releasable gem

Ken Mayer — Sun, 13 May 2012 11:42:00 -0700

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

MIT License
A gem specification
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

~~MIT License~~
~~A gem specification~~
~~Basic documentation in a README file~~
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

~~MIT License~~
~~A gem specification~~
~~Basic documentation in a README file~~
~~Integration test~~
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

~~MIT License~~
~~A gem specification~~
~~Basic documentation in a README file~~
~~Integration test~~
~~Generator~~
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

~~MIT License~~
~~A gem specification~~
~~Basic documentation in a README file~~
~~Integration test~~
~~Generator~~
~~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.

The Future of Web Design in London

Jonathan Berger — Fri, 11 May 2012 11:04:00 -0700

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.

Getting image data from a CarrierWave uploader into RMagick

Mark Rushakoff — Thu, 10 May 2012 12:43:00 -0700

Carrierwave has an RMagick module that offers a handy manipulate! method that takes a block where you can modify the image, and then it saves the changes to the image.

But sometimes you only want to interrogate the image, and there's no need to save any changes.

After spending probably 30-45 minutes trying to figure out how to read an image that may not necessarily exist on your local disk, the simplest solution we found was to call uploader#read to get the contents of the file as a string, and then pass that into Magick::Image.from_blob.

How GOV.UK keeps calm and carries on with Tracker

Ronan Dunlop — Wed, 09 May 2012 11:50:00 -0700

The courageous folk working on the GOV.UK website (an experimental ‘beta’ replacement for Directgov and the first step towards a single government website) have regularly written about their experience and their blog is a worthwhile read.

Their most recent article Delivering Inside Government, posted by Peter Herlihy, offers great insights and advice for agile teams.

Below is an outline of their article with point six detailing their use of Tracker and how making their stories public while scary at first proved to be a good move.

If it's hard to write a story, it's probably not as important as you think
If it's important you will remember it
Investing time preparing stories before sprint planning paid big dividends
Avoid the temptation to make the newest story the most important
Make sure you can tell when your objectives are met
Running our project in the open wasn't a scary thing.
Read the full blog post here