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.
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.
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.
One of the thornier problems in our workflow is knowing when assets are delivered from the designer and keeping them in sync with our application as they change. We used to use e-mail, Skype or sticky notes. The trouble is that the designer's file naming and directory structure were never quite the same as the application's /public/images directory, so direct comparisons were impossible and we ended with a lot bookkeeping to make sure that we didn't lose any changes. Our solution is to clone the project's git repository into a folder inside a shared Dropbox folder.
Dropbox is cheap, if not free, available on all platforms, and synchronizes easily across most network connections. git is, well, awesome version control. We already had a Dropbox account set up for the project, and all team members had accepted invitations to join the share. We then made a git clone of our application source code in the Dropbox folder;
cd ~/Dropbox/MyProject
git clone https://github.com/myproject/myapp git-repository
We took a minute or 2 to show the designer how to find the images directory, and our basic rationale behind naming and directory structure. That became her "new" assets folder. We did not show the designer how to use git, nor do we need to. As far as she is concerned, it is just another folder. /public/images is even a familiar place for designers.
Here's where the fun starts: We add the Dropbox/git-repository as a remote to our main project repository.
cd ~/myapp
git remote add dropbox file:///Users/me/Dropbox/MyProject/git-repository
Now, as far as our main project is concerned, the Dropbox folder is another remote, just like github.
During our daily workflow, whenever we need a new asset, or to look for a changed one, we cd over to the Dropbox folder with the git repository, change into the /public/images directory and look for what we need. We then use git add to stage and commit only those assets that we need. Back in our main project, we then
git pull dropbox master
from the Dropbox remote and voila! New images! Later, if the designer makes changes, we can simply run git status to see what's changed, re-run git add, commit and pull. The only really gotcha is training our fingers not to type git commit -am '...'
We have found this to be a very fast, lightweight, way of integrating new assets into the project and keeping track of old ones. The designer is no longer worried about getting out of sync with our project, nor are we worried about missing design changes. As a bonus, there's a history in the git logs, so we can review changes and even revert if necessary. All this without the designer ever learning a single git command, nor us worrying about our project directory getting accidentally clobbered.
I believe it was in a conversation with Janice Fraser that I first started talking about DRY Documentation. It was certainly she (among others) who goaded me into actually writing this blog post. So I'm taking a moment on my WiFi-free (and generally amenity-free) United Airlines flight to SXSW to put pixel to screen.
DRYness is an age-old concept in the Agile space (to the extent that that's possible in a space that's only 10 years old itself) and it's elegant in its simplicity. DRY simply stands for Don't Repeat Yourself. The idea is that you should only do any one thing in code in only one place. If, for example, you are doing an interest rate calculation, don't copy and paste the code from one place where you need it to another: instead, move that responsibility to an object that reasonably should be responsible for such things, and do that interest rate calculation only in that one place. The reasons for this being important are manifold, but perhaps the canonical reason is so that it's easy to change: When the interest rate calculation changes, you don't have to go digging through your code to find all the places you do it, and make sure you change them all consistently. Instead, you change the code in only one place.
Hopefully this is old hat for most coders now, and hopefully you, gentle reader, will forgive me my oversimplifcations and conflations. The point is one of simplicity.
So now, let's shift focus to design documentation. The idea I'm trying to express when I talk about DRY documentation is one again of simplicity, though the drivers are perhaps a little different.
The mental model for truly DRY documentation is one in which every pixel on the page tells you something you didn't know before. Of course, like DRY code, it's worth being pragmatic. There are times when greater clarity can be gained by a certain amount of contextual restatement. But as a theoretical goal state, it's still quite useful to picture a body of documentation in which every last line tells you something you needed to know about what you're trying to build, and something you didn't know from looking at any other line in the documentation.
What would we notice about a set of documentation that adhered to these principles? Well, first, and most obviously, it would probably be a lot shorter than the documentation we're used to seeing. And that in itself is a benefit. Why? For a number of reasons. First, shorter documentation is in general easier to digest, and it's generally easier to find the relevant bit of documentation in a shorter corpus, all else being equal. (And of course, document structure and readability play just as big a role in a short document as they do in a longer one.)
Shorter documents are also easier to revise and maintain. And it's easier to find changes between versions, all else being equal. I talk sometimes about the 500 page PRD we got when we were developing one product, complete with two sets of revisions, also 500 pages each. Guess how easy it was for the developer to find the 2% of information that changed in each revision, and understand its implications to for the site? Guess how easy it was for the designer to be sure she'd changed everything consistently? In a DRY design doc, changes are more obvious, and more meaningful. Things jump out when they're inconsistent. And they tend to be more consistent, because the designs implied are applied more consistently across the product in question.
This brings me to another favorite topic: Principled design. DRY documentation is a lot easier to develop (and it's a lot easier to tell when your documentation is DRY) when your design is motivated by specific principles. For instance, when you decide, in the banking app you're designing, that all checking account features will use Cerulean Blue for their accent color, and all savings account features will use Prussian Blue, a lot of nice things happen. First, design questions become much easier to answer. The new Maximizer Account we've just added is a kind of savings account. Great! We know it's going to be Prussian Blue. (Or we can make a better informed decision that there should be a new point in the color family.) Second, it suddenly becomes a lot easier to document this fact. A one page style bible can capture this information, and when some new feature is implemented, it doesn't take any intervention from the VxD to make sure the new bits have the right color choices. Third, when some new feature comes along, developers roughing it out can come up with a reasonable early approximation of what it should look like, because they have principles to apply, instead of PSDs to pore over, looking for a non-existent visual treatment for the new thing they're just embarking on. This lets said VxD (and the IA) spend time tuning something that's close, rather than restating the design principles they've got in their heads, in the form of some new PSD file.
A fourth virtue is that suddenly all these color choices (or typography choices, or IxD choices,) have consistency, a consistency that our dear End User can actually pick up on. They don't end up feeling lost in a jumble of pretty colors, but start to associate the Prussian Blue with savings accounts, the Cerulean Blue with checking accounts, and, assuming the designer goes in this direction, that blue in general means cash accounts; green, stock and security accounts; reds and oranges, loans and credit accounts, or similar.
They may not be able to articulate why they know this, but they will perceive a solidity and purpose in the VxD, one that makes them feel safe and comfortable, and one that helps them use the application more effectively.
When coupled with a good domain model and a good information architecture, it suddenly gets a lot easier for the whole team to keep the design princples top of mind, and answer basic questions without having to consult a 500 page document, or even a 20-30 page set of wireframes and interaction designs. Hopefully they can answer most questions from a one or two page style bible, and by consulting the wireframe describing their grid system, and the one for the kind of module they're working on.
Again, the point is not to pursue this ideal to an absurdist end, but rather to continually ask oneself: Could this documentation be simpler? Did I cover this already? Could an existing design concept apply to the new area I'm covering? Restatement in the service of clarity is always to be lauded. Unfortunately, in practice, most restatement in the form of long design documents is just waste: Waste in that the documentation must be produced; that it must be maintained; that it must be read; that it must be understood; and waste in that it tends to obscure the princples of the design in favor of the surface of the design.
And of course, another agile principle comes into play: Refactoring. Often a second use of a given design treatment exposes new boundary cases and new pressures on the design, and the initial design needs to be modified slightly to accommodate both the new and the old use case. This is usually a simplfying force, and one not to be resisted. Let the documentation live, and reflect the deeper underlying principles of the design you're trying to express. Applied well, this rigor will help you to simplify and clarify your designs, and expose their essence.
When practiced well, DRY documentation will set you free, give you control and clarity, and communicate your design vision efficiently and clearly. It will also free your development team to do things more or less right the first time, and give them more time to work on the bits that need more love and attention.
An example of a one-page style bible, describing text treatments, spacing, backgrounds and grid structure in one digestible page.
This Friday at Pivotal Labs Boulder, we're hosting an evening of food, drink and discussion, to bring some of our learnings around Lean User Experience to the larger design community, and in particular to attendees of the annual international IxDA conference.
We, in this case, is a group of smart folks I've had the privilege to work with over the past year, a working group called the Balanced Team. This particular event is the result of the hard work of people at Cooper, Hot Studio, LUXr, SideReel and Atomic Object.
For the past year, we've been sharing ideas and discussing new ways to approach design and product development, to create better products, make happier customers, and reduce waste. We've been doing this while creating better integrated, more collaborative, more responsive teams. In that time, a number of us have been getting together on a regular basis to really sit down and discuss what works and what doesn't, and to try to distill these ideas into principles and techniques that are repeatable and practical.
We've been itching to engage with the larger design community to start to break down the culture of Big Upfront Design, the Cult of the Rockstar Designer, and the culture of necessary infallability; to fight the blind application of Waterfall and to disrupt the antipatterns we've found so antithetical to effective collaboration with agile development teams; to encourage patterns that allow designers to embrace early customer feedback, and to test hypotheses quickly; and most importantly, to foster a deeper collaboration with the very folks who have the biggest impact on what we build. We've seen over and over that, when done correctly, a light-weight process gives designers more control, not less.
It's out of this series of discussions that I first arrived at a framing of the problem space that I talk about in Enough Design, and it's also through these sessions that we've found a growing community of designers, product people, enterprises and other developers who are working to develop better techniques for integrated product development. We've found the conversation immensely valuable in our practice, and we hope to learn and share with more of you.
If you're a designer in Boulder for IxDA, or just someone who cares about usable techniques for bringing Lean principles into the development of compelling User Experience, come join us on Friday for deLUX. This is a free event, but space is limited, so please RSVP through http://pivotallabs.com/landing/deLUX.
Renowned design firm Cooper hosted a panel discussion at Pivotal Labs where founder Alan Cooper joined other senior members of the firm to discuss the challenges of integrating user interaction design work with the agile development process.
The entire panel discussion is posted to our podcast and the talks page of our website.
Interesting Things
- Web based sprite generator - here
This also makes the generated sprite really small which is great if you care about page load times. A Ruby+ImageMagick sprite generator might also be a good thing to build.
- Cool way of detecting if a file is UTF-8 enconded using Ruby+IConv - here
Ask for Help
"Is there an onReady() for AJAX events?"
- onAJAXReady() ?
- JQuery Live Events might do the trick