Today was my first visit to a different Pivotal office. I’m on personal travel in Los Angeles at the moment, so I spent the day today working out of Pivotal’s Santa Monica location. I was delighted to find that people so far from New York would have such a direct connection to what I was working on.
I was remoting with my pair in NY and we were fixing a regression on our usage of the data-presents pattern, which has served us quite well on my current project. Turns out we attaching behaviors to DOM elements using their IDs generated by the simple_form gem, and those generated IDs had changed out from after us when we updated to the latest version of simple_form.
It turns out that two feet to my left was Patrick, who had made the commit to simple_form that changed the IDs that are generated. And across the table from me was Jonathan, who had worked quite closely in San Francisco with Rajan, who had created the data-presents pattern on our project. Jonathan told us how it should be used: rather than using classes or IDs from the DOM, it was better to bind it specifically to data attributes to keep the data-presents pattern as loosely coupled as possible.
With such unexpected experts so close at hand, we had the regression tested and fixed in no time and it was cause for a celebratory game of ping-pong, just like home. And that’s when the next important discovery of the day was made:
I had no idea that bending over to pick up ping pong balls is a thing of the past! Our Pivotal New York office manager will be receiving a request to purchase one of these devices in the very near future.
I look forward to a continued exchange of ideas as this week continues. Thanks to everyone in Pivotal Los Angeles for making me feel so welcome.
I’ve often been in situations where people see user stories in Pivotal Tracker as just a punch list of to-dos, line items for snippets of code we can write that does one little thing in a product owner’s head. Even that much is useful for its prioritization and clarity, but thanks to a great chat last week with Lean User Experience wizard Josh Wexler, I’ve found myself paying closer attention to the reason they’re called User Stories in the first place: the users.
Complicated business logic becomes much easier to grok when you have a clear scenario in mind for the person who’s using it. I was recently working on a piece of particularly thorny logic with a new client developer for Case Commons. It had to do with subtle requirements for when and how to get permission to update a foster family’s license. We read and reread the story and the explanation, but it was hard to communicate why we were doing the thing we needed to do. We were talking in circles, and as soon as that happened, we knew we were doing it wrong.
So I pulled out the blog post I wrote a month ago, and it turned out that my friend’s family and newly adopted children were in an almost identical scenario to the one we were working on. I pulled up pictures of my friends and their adopted kids to show to the guy I was pairing with, and described the social worker, Tania, who had connected them with their new family. From then on, it wasn’t some abstract user we were talking about, it was Tania. My pair and I discussed what would happen if my friends became able to adopt more kids, the process Tania would have to go through to make that happen, and where that information would go on the physical, printed foster family license we were implementing. Having faces and names to go with our code made all the pieces click together, when we see as the story title in tracker: “Foster Family Licensing worker sees checklist only if capacity has changed”
I’m looking forward to putting more users into more user stories to make them come to life. When each story is complete, what new awesome thing will that person be able to do, and what need of theirs will it fulfill?
When it comes to user metrics, what should you log when you don’t know what to log?
When you’re first getting an MVP site off the ground, you don’t know quite what you might want to track. And might not have time to think about it.
If you log everything your users do, however, then weeks or months of data will be there for you when you need it most, to answer your questions right away. That’s why I’m excited about companies like Heap are doing, logging every single user click.
For those without Heap invites, or if you’d prefer to use Kissmetrics, I wrote a simple gem to do the same with KissMetrics, for all your user clicks that hit your web server: km_everything. It logs all controller actions by default, but you can set up a whitelist to give them more meaningful and product-manager friendly names, or a ‘blacklist’ to prevent certain actions from being logged that aren’t meaningful and would use too much of your KissMetrics event quota.
Excited about our brave new world of meaningful ad hoc analytics with reams of user data, powered by ubiquitous metrics. This data will then show us how to make our sites even better for our users.
I took a day off of work recently, and learned more about what I was working on than in several months of coding.
My current Pivotal client project is CaseCommons, using web technology to modernize child welfare and foster care so social workers can spend more time with kids and families. We’d just completed a large set of work about court hearings, and now I was attending one. I went to see my friends finalize their adoption of two little boys they’ve been fostering, with their wedding to immediately follow.
Everything I’d done and learned paled compared to seeing the judge and social worker speak about how the kids’ lives improved in my friends’ care. One of the boys was in a wheelchair a year ago, and now here they were joyously laughing and running in circles around their new parents as the adoption was completed and wedding vows were spoken.
I talked to the social worker at length and learned things I hadn’t yet come across, like how most adoptions are with extended family members, my friends were the exception. I also saw the clerk entering the details of the court hearing into their computer system, which looked like it hadn’t been updated since the 1990s but it still was blazing fast. They’re not using our product yet, which is much more streamlined. But they’ll expect it to be equally responsive.
Now, whenever I’m doing a feature or fix for social workers, I see Tania’s face as she hugs the children and speaks with my friends about the kids. When I work on court hearings, I see the clerk navigating so quickly to enter in all the many details.
I won’t always get to work on helping people help kids. But when I move on to my next Pivotal project I can’t wait to set aside some time much earlier on, to look users in the eye and truly understand how what we’re building will make their lives better.