I had a small epiphany today while working on a new prototype for a client: “different stages of prototyping yield different levels of information”. I know I know, not much of a brainwave there, right? I was never one for writing headlines and there’s a lot of knowledge packed into that statement, so stick with me as I attempt to unpack it for you 🙂
The Gist
Those familiar with it will know there are some basic ways to prototype that progress upwards in terms of fidelity. At the lowest end of the fidelity spectrum people often start by drawing lots of boxes and arrows on paper. Next comes some of the static mockup tools that are popular today, like Balsamiq, Hot Gloo, Fireworks (and many more). Further up the fidelity chain comes prototyping in the Browser which has some interesting advantages over static prototypes; what struck me today was how much more I could learn from prototyping in the browser when I moved from static markup into interactivity. Each level of fidelity provides different things we can learn; at a high level this is how I think it breaks down:
- Paper Prototyping
- What I think the information architecture hierarchy should be.
- Static Prototyping
- How I think the information architecture hierarchy will flow from one area to another.
- Browser Prototyping (Static)
- How the information hierarchy actually flows from one area to another at different screen resolutions.
- How changes in typography, size, and placement affect the usability of my information architecture.
- Browser Prototyping (Interactive)
- How robust the information architecture and design are when considering user interaction.
- What things I should do first to improve my information architecture and design.
As I read through the list above I notice a few interesting things. Firstly, the value of the information I receive increases as I move to a higher fidelity prototype. In Paper and Static prototyping the information I get isn’t really all that useful; for the most part it is hypothetical. I can show it to others to get more feedback but it is still subjective; based on perception and varied interpretation. It isn’t until I move into prototyping with the Browser that I can actually play with the information, architecture, and layout and start to get concrete information that will help me approach what I need to change in my next iteration.
In Practice
The interface and interaction I have been prototyping the last two days is for a user creating a fitness challenge comprised of multiple activities for multiple participants. As I was working to take my browser prototype from static to interactive I discovered that even though I had a good idea of how the system I was implementing worked I found I didn’t have a great way to express the system thinking in a user interface that made sense to humans.
So often engineers have a great grasp on what the system requirements are for the interface they are building that they end up building the interface as if it reads like machine language. In the last two days I feel it was very valuable to repeatedly try to express the system constraints in “plain old english” as if I were a user trying to interact with them, but I didn’t come to that realization until I made the leap from static to interactive.
In my first pass at the prototype with static content and no interaction this is what I came up with. The interaction theory was that users would fill in basic details about the fitness challenge and be able to see a preview summary of what the challenge would look like before submitting to the server(you can see the summary at the bottom of the screen). During this iteration I came to the realization that that positioning the summary at the bottom of the screen does nothing to help users understand what it is they are doing; we ended up deciding on a new layout that positions the summary to be always in the users view in the following iteration.
In this iteration the idea for a “live updating” summary was the driver for the layout change. We thought that if users could see the results of their interaction taking shape live it would help to reinforce how the interface was affecting the output (challenge creation).
Because one of our design constraints was to attempt to make this page work for both desktop and mobile we implemented the twitter bootstrap responsive stylesheet so we could play with the layout and see how it felt. This is one of the biggest benefits of designing in a browser first and previewing the design in the iOS simulator really helped to further shape the layout. Up to this point we were still iterating with static markup and felt like we were making good progress with the information we had received from in browser testing. The next step was to start wiring up user interactions to see what else was revealed.
I’ve been using Backbone.JS for the last 18 months and it’s a wonderful tool for building prototypes with. We decided to add some simple collection backed views and flesh out the user interaction of adding Activities and having them update live in the preview. What this yielded first was a realization that our design didn’t account for all that many rules due to our fixed position summary preview. (note: the new affix plugin in bootstrap 2.1 is _great_ for this, but you should be aware of how tall your content could potentially be!)
Oops. You could say I should have encountered that in the static stage of in browser testing by adding more static data to test the layout, but I didn’t and I find that this is often the case with static prototypes. Adding interactivity to a prototype helps to uncover places your design breaks down. It was at this point I had a discussion with a teammate to demo what had been built so far and we both came to the realization that the tabular display under the activities UI was not user friendly. The interface for adding Activities seems to read like english (we arrived at that after a number of iterations) but the display of the data isn’t helpful to users at all and really mirrors how the underlying system stores the data.
Moving Forward
Our next step will be to prototype a layout where the summary preview _is_ the interface to eliminate the “system language” from the interface altogether. In conclusion, I don’t think we would have been able to iterate and refine our approach as effectively if we had not started in the browser and added interactivity to the prototype soon after prototyping with static markup. The things we can learn from interactive prototypes can really help crank out interfaces that are much more usable.
If you aren’t already prototyping interactivity in the browser I would encourage you to start as soon as possible, the earlier you start the earlier you’ll find out how to fix your interface! 🙂
I needed a break from preparing for my Stir Trek presentation next week and got a bluesy riff stuck in my head. 2 hours later here’s the rough track result.
Tools used:
– Macbook Air
– Garage Band
– Boss RC-300 Loopstation
– Pod X3 Live
– PRS SE25
– Ibanez Soundgear 5 string Bass
– Yamaha Compass Acoustic
Rough scratch track with some ideas I’d like to expand on later in higher fidelity. Done completely with iPhone 4S and an Acoustic Guitar. 🙂
Rough scratch track with some ideas I’d like to expand on later in higher fidelity. Done completely with iPhone 4S and an Acoustic Guitar. 🙂
I attended Software Crafstmanship North America in Chicago this weekend and came away feeling much differently than I thought I would. I tweeted a summary of my thoughts last night:
@dmosher: I find it interesting that the talks I agreed with most at #scna were predominantly against established “agile” principles … 😐
Twitter is a horrible medium for expressing ideas that are packed with meaning; this post is intended to unpack my tweet and experience at SCNA 2011 by focusing on the 3 talks I found the most valuable and how they formed a cohesive and powerful narrative in my mind.
Suitability vs Capability
Gary Bernhardt gave a wonderful talk entitled “Expansion & Contraction”. I think he should have titled it “Suitability vs Capability” but it was a brilliant talk and the one I considered the best of the conference. Here’s my best attempt at paraphrasing it:
Programming Language and Technology go through a constant ebb and flow of expanding and contracting over time. During expansion, these solutions are “Capability” solutions; that is, they are capable of solving problems but they are not yet suitable. Eventually there is a contraction that happens and “Suitability” solutions emerge.
Java first emerged as a Capability Solution during an expansion in the post C/C++ era. Time passed and a contraction occurred in which Java matured into a Suitability Solution for developing software.
A few times during his talk Gary mentioned that JavaScript and NodeJS are currently in the realm of Capability Solutions. At first this rubbed me the wrong way but I think that’s because I wasn’t really listening to what he was saying objectively. NodeJS is absolutely in the realm of Capability and not Suitability at the moment, but that doesn’t mean you can’t create something useful with it.
Thinking more about the heart of Gary’s talk I find myself glad that it was on Day 1 because I found that it framed my thinking for the rest of the conference.
Programmer Anarchy
Agile best practices are often framed as things we “must do” in order to be successful but I think it would behoove us to frame them in terms of suitability and capability.
Fred George gave a talk in the breakout room on Day 2 entitled “Programmer Anarchy”. His ideas might seem radical to some but I think they are an appropriate response based on an evaluation of suitability/capability for his specific situation. It’s important to understand that the following decisions derive from a company that is continually investing in new ways to make money by building very small applications. Here’s the gist:
Agile prescribes many best practices like Kanban, Scrum, XP, Pairing, Continuous Integration, Unit Testing… the list goes on.
In the waterfall era the power to determine how systems get built lies squarely with the customer. Up-front design docs and requirements specifications dictate how developers should build a system to achieve success. Through waterfall, systems are often built completely wrong. As a result customer trust is lower, developer happiness decreases, and success is not realized.
In the agile era the power to determine how systems get built is shared between the customer and developers but there is a gap in trust because of the past failures of waterfall. Agile is an attempt to bridge the trust gap by building things faster and with less bugs. Through agile, systems are also built wrong but they fail faster which mitigates risk and decreases the cost of change.
In the era of Programmer Anarchy the power to determine how systems are built lie directly with developers.
- non-developer roles like architects, project manager, scrum-master, team lead, delivery lead, hr people and tester are completely eliminated from teams
- developers are empowered to build software using whatever technology they choose and with whatever tools they choose
- applications and systems are extremely small (100-300 lines of code) so unit-tests, acceptance tests, and continuous integration are eliminated entirely
- teams are encouraged to write and re-write applications using whatever they want, including capability solutions (Clojure, NodeJS, Cassandra, Hadoop, etc..)
Fred talked a lot about his company and how they have a lot of trust in their developers to be able to turn ideas into money. The first thing they do on any project is write the business metrics code to be able to verify whether something they produce can be tied back to business value. This is an absolutely critical point that needs to be understood. Most of the time, my dissatisfaction in the work I do is related to not knowing whether something I build will actually have value. If I had metric and monitoring code in place that was able to tell me what I created is making money and can be considered successful my job satisfaction would increase greatly.
Unit tests weren’t suitable for Fred’s teams because they were writing such small applications, so they eliminated them. Traditional “Agile” roles weren’t suitable because he empowered developers to make decisions on what to use, how to use it and which developers would be best suited to building it, so they eliminated them. I think you can see the pattern.
I found it interesting that Fred’s teams got rid of things many in the Agile movement consider to be not only suitable but essential to building good software. It was also fascinating that he actively pushed his teams to use capability solutions like Clojure, NodeJS, Cassandra and Hadoop, which proved wildly successful.
Whether you agree with the decisions or not is irrelevant; Fred’s team made a judgement call about the suitability of all the typical “Agile” best practices and cut away all the things that weren’t suitable. Good teams find ways to eliminate waste by evaluating whether the things they do are capable and suitable and eliminating things that aren’t.
Propaganda, Indoctrination, Fanbois, and Education
I believe there to be a significant difference between a “Big ‘A’ Agile” and “Little ‘a’ agile”. The religion of “Agile” is often touted as the one single way to build software. The number of roles and processes prescribed by “Agile” is excessive, however, this is due to a failure to evaluate things in terms of whether they are suitability solutions or capability solutions for a given project/team.
It was probably surprising to people in the software craftsmanship movement that Zed Shaw was invited to speak, but his talk on “Propaganda, Indoctrination, Fanbois, and Education” was the most thought provoking talk at SCNA 2011. Here’s my translation:
Anyone who tells you that they have found the “one true way” to build software is a con-artist trying to sell you something.
If you aren’t writing code, you aren’t a programmer. Programmers build software, everything else is just marketing spin.
Indoctrination happens when you’re convinced to think something is the only way. Education gives you options and lets you make choices. Don’t be indoctrinated, be educated.
Agile and all the related buzzwordy ideas can be boiled down to these 3 simple ideas:
- Make a list of stuff to do.
- Do that stuff.
- Automate the heck out of everything.
(note: these things don’t have to be done in any particular order)
While he’s abrasive and rubs a lot of people the wrong way, Zed Shaw has done a lot of good for the software craftsmanship movement. He’s trying to put the focus back on learning programming instead of “Super XP Double Pairing Kanban Scrum Sauce” and all the rest of the “Agile” marketing spin. His “Learn Code the Hard Way” series is wildly successful and is actually teaching people how to program. Somebody at the conference asked him:
“So what do you think about Unit Testing and Continuous Integration and all that stuff then?”
His response was pretty down to earth:
I’ve worked for big consulting companies doing every one of those things in the past. I’ve written tests, done TDD, used pivotal tracker blah-de-bloo or whatever you’re using. Those things aren’t bad but anyone who is trying to tell you those things are the “one true way” to build software is a con-artist trying to sell you something. If you believe that stuff you’ve got a mind-virus. You don’t want a mind-virus.
I used to change my thinking drastically all the time. I’d go to conferences and experience a lot of hype and get infected with a mind-virus that led me to adopt ideas that I would later on discard. This isn’t a healthy thing to do. Nothing I experienced at SCNA 2011 was radical enough to make me change my thinking drastically, but what I did experience will help me to be much more objective about the things I let influence me going forward.
Where do we go from here?
It’s important to be objective. It’s important to question the value of things we do, especially when we do them because somebody has told us they will solve all our problems.
To me, the most important narrative of SCNA 2011, and the thoughts behind my tweet are these:
- Don’t buy into all the propaganda, don’t get indoctrinated. Get educated.
- Learn to objectively evaluate the tools, processes, and ideas we use in terms of suitability and capability.
- Let go of suitability solutions if they don’t give you any value.
- Embrace capability solutions because you might be surprised by their value.
I started working as an independent contractor for Pillar Technology over 6 months ago (Nov 1, 2010). At the time, I had no idea what was in store for me; looking back now I think I’ve hit a new point from which to grow in my career so it seems time to engage in a retrospective on the last year.
Some History
Prior to working with Pillar I spent just over 2 years working on a number of projects at VendAsta Technologies. I grew a lot in those 2 years but mostly in a technical capacity. Things like continuous integration, build configuration, and (briefly) unit testing were introduced to me. It was enlightening to get a taste of the technical goodness offered by those things but ultimately I felt like there was no one there who could guide me in the underlying principles that necessitate them. At the same time I was introduced to many of the core concepts of this thing people in the software development community call “Agile”. Coming out of VendAsta in 2010 I thought I knew what Agile was. I thought it was Scrum, XP, TDD, continuous integration and a whole host of other technical terms.
Looking back at where I’ve come in the last 7 months I don’t think I can say I know what Agile is even now, because it is an ephemeral thing that seems to be constantly evolving. What I can say is that I know a lot more about the core of what’s important in software development: delivering business value and earning the trust of those you work with.
Trust and Value over Working Software
My first 6 months with Pillar were served working on a client project for Gordon Food Services out of Grand Rapids, MI. I worked remotely for those 6 months out of an office in my basement that Tanys and I built the week before I started. A brief note on working remotely: it opened my eyes up to a key thing that’s required to be successful in life; self-discipline. I had my doubts about how effective I could be remotely but I decided it was worth the challenge and committed to myself that I would do what it took. Getting up at 7 am to make standup in the morning (hello, 2 hour time zone difference), pushing myself to keep lines of communication open, and pouring my heart and soul into building trust with the client; these are the things I did over those 6 months. And it paid off. I grew in my technical knowledge but also in my ability to cultivate good business relationships.
The people at both the client and Pillar have been great, providing much in the way of the mentoring and leadership around the principles of good software development that I had craved for such a long time. In 6 months working for GFS the team I was part of a team that produced software faster, with less defects, and with more value than any other project I’ve been on. The experience was energizing and opened my eyes to the power of building trust and constantly delivering value all while adhering to solid software craftsmanship principles.
Beyond TDD
Prior to joining Pillar I thought I had a pretty good grasp on the technical concepts surrounding “Agile”. 7 months later my eyes have been opened to how much more than technicality Agile really is. At its heart, Agile is a way of thinking that promotes accountability, integrity, quality, and value oriented thinking. I used to think writing tests was something you did after writing production code to verify the behaviour you had crafted. Now I understand that “The fundamental conundrum of software development: I can code fast when I have a good design but I can’t design until I’ve coded slowly.” (Kent Beck).
A good design is achieved by thinking out architecture by writing tests first. I’ve also learned that tests can act as documentation by example, so it’s important to continually curate test code so that it doesn’t grow stagnant. Most importantly of all I’ve seen the power of having a codebase with 95%+ test coverage and how that acts as a safety net to making change. This last point can’t be overstated; the freedom experienced through red/green/refactor makes change cheap and development incredibly enjoyable. At the core of my change here from 7 months ago is a paradigm shift in the way I think about developing: I don’t feel responsible writing production code until I have a failing test.
The Best Way To Learn
Something I’ve always felt positive about is my ability to teach. I feel I have the heart of a teacher, which means that I can empathize with people to understand the pain they feel. (I’ve felt the pain too, which always helps). In the last 7 months I’ve been devoting myself to studying more effective ways to promote craftsmanship in front-end development. One of those ways is to teach more. This has not been easy; front-end development has historically been treated as a second class citizen. (I could write a whole other blog post about that alone, but that’s a topic for another time). Breaking down barriers between front-end and back-end developers requires a certain amount of grace and poise that I didn’t have 7 months ago. Being able to effectively communicate solid engineering principles to back-end oriented developers requires empathy, compassion, and the ability to communicate using language they understand.
I’ve often had to put aside my idealism and promote compromise. I’ve also had to become humble and admit that sometimes the front-end is not the place where everything should live. (But I still think there’s a whole lot of logic on the server that shouldn’t be there. Again, another topic for another post). The benefit to engaging developers across architectural boundaries and striving to teach is that I’ve been able to learn a lot. I’ve learned how to effectively test drive JavaScript (/hattip @searls), how to build scalable, object-oriented CSS/HTML, how to achieve an appropriate separation of concerns on the front-end, and how to translate n-tier architecture principles from the server-side to my client-side code. Being at a company like Pillar has provided a rich environment in which to grow; it’s something I’m very grateful for.
The Path to Agility
Many of my co-workers attended the #pathtoagility conference in Ohio this week. I wasn’t able to attend but I think it’s fitting to end a post about my own personal “path to agility” with some forward looking thoughts that can help you (and me) to continue on that path. Software development is evolving and changing; set yourself up for success by being willing to evolve and change right along with it. Agility is more than process or technical solutions; it involves integrity, accountability and a fundamental paradigm shift in your way of thinking. Continue to look for ways you can shift your thinking. Be open-minded. Teaching is a powerful exercise in self examination and growth; try to spend time teaching those around you, it’s worth the investment.
Spent some time with the Alesis DM10 Studio kit I rented from Long & McQuade this past weekend. Didn’t do a whole lot of cleanup on the track (there’s some pop and hiss when recording via my X3 Live in Garageband that I can’t sort out). Anyways, this was about 90 minutes of playing around with the drum kit and my other instruments, here’s the full list of tools used:
- POD X3 Live
- Alesis DM10 Studio
- Macbook Air
- Garageband (iLife ’11)
- Ibanez Soundgear SR300M 4-String Bass
- PRS SE Custom 24 Electric Guitar
Hoping I can get some more time learning how to eliminate some of the pop/hiss but so far I’m pretty happy with the ability to record demo quality stuff with this setup 🙂
Andy and I spent about 30 minutes collaborating on this drawing in the Ink Pad app on my iPad. He was the “creative director”. I asked him what to draw and he said “snowman!”. Then nearing completion it was determined the art direction required an icicle sword and pirate hat to complete the vision. Who am I to argue with the creative director! 🙂
Even though I only have a first generation iPad i can still rock it out with garage band. What a cool little app, I put this together in about an hour just playing around. Super fun 🙂
Dave Mosher's Blog 