Ex Machina: Jack Graham's Blog


The Worklife of a Software Business Analyst, Unlicensed Futurist, and Tech Wonk-of-all-Trades

Hiring Email Program Manager

<em>ms River Navigator</em> (2012 season)My employer, Vantage Travel, is hiring an email program manager. It’s a mixed metrics/analytics and vendor management role. We’re about to embark upon an enterprise-class ESP integration, so the successful candidate gets to participate in that process from day 1. Full time, permanent, at Vantage’s home office in Boston. Ping me @jackexmachina if interested.

Use Pinterest-friendly Photos on Your Web Site

Pinterest logoThis morning I was researching Pinterest, the wildly popular social media app that lets users set up pinboards of products & other things they find interesting. In doing so, I noticed something that a web designer would be wise to take into account: Pinterest users rarely re-post images with captions in them.

Sure, there are some. But by and large, Pinterest users are there for the pretty pictures. The app itself captions images and links back to the sites from which they were pinned, but you’ll see very little copy in the pictures themselves.

If Pinterest is an important social media channel for your company, having great quality photography isn’t enough. It should be re-pinnable.

Luckily, my employer’s site passes the Pinterest test. Check it out (click on the photo to zoom):

Vantage Travel web site on Pinterest (screen shot)

Pinning from my employer's web site

Because our captions are rendered using HTML & CSS, the big, pretty pictures that a Pinterest user would want do share (the first five from top left) have no ugly text on them. They’d look fine on someone’s pin board.

It would be nice if we had some tall, vertical images. Tall verticals and squares look great on a pin board. But the lack of copy is a great start.

Now compare to one of my employer’s competitors (again, you’ll want to zoom):

Goahead Tours web site (screen shot)

Pinning from one of my employer's competitors

It’s a mixed bag. There are some nice smaller photos that a Pinterest user could grab, but  the big, beautiful ones (like the castle shot at top left) contain captions. Pinterest users don’t want these on their pinboards. Designers like layering captions onto photos in Photoshop, because it’s easy to do text effects and get a clean font render. But they might be hurting their chances of being re-shared on social media in the process.

Note I said “social media,” not just, “Pinterest.” I think what Pinterest brings into relief that we haven’t noticed before is a more general fact about users’ habits in re-sharing the content we create. Users would rather share a photo without a big caption on it (unless it’s something like a cartoon or a meme). If we can rely on the user to caption the photo for us, and to link back to our site (as we can with Pinterest), it’s better to use CSS and HTML to caption photos. They’re more likely to get re-shared as a result.

What could make either of these sites even friendlier to Pinterest would be some tall, thin images. I think I’ll have to experiment with hiding tall images on a page specifically for Pinterest to find. I’ll be sure to post the results.

Five Useful Things I Read This Week

Groupize, a booking engine for large hotel room blocks (screen shot)

Groupize, a booking engine for large hotel room blocks

Groupize is a new travel industry tool. It’s a hotel booking engine. So what, right? Its cool trick is booking blocks of up to 25 rooms at a time, which no other hotel booking engine does at present. Awesome if you’re a wedding planner… and the UX is nice.

Facebook is making another design change. This time it’s to Facebook Pages, which are bread & butter for the social marketing community. This post on spottedsun.com has the skinny.

Microsoft, partnering with the government of the Balearic Islands, has established an innovation center specifically for tourism (site is in Spanish). The Balearics are an out of the way place to do this, but it’ll be interesting to see if this yields any fruit for the travel industry.

O’Reilly Radar post on the state of APIs and the directions in which they’re currently developing. As a web app guy, I found the bit about using APIs to drive analytics particularly interesting.

And one more Facebook-related article… This piece from Fast Company describes (puportedly) leaked internal Facebook documents that describe their future vision for online ads. Briefly, it looks like they want to drop display advertising completely in favor of social ads that show up as conversations. Will users go for that? A few years ago I would have said “no,” but they might be on to something with the  approach outlined here.

Tech jobs at Vantage Travel, Boston (updated 2/23/12)

photo: DS Vesteraalen (early Hurtigruten ship)Vantage Deluxe World Travel, my employer, has a number of reqs open for tech jobs right now. These are all in either the IT or Interactive Marketing Depts., and are full-time, on-site, in downtown Boston, Massachusetts.

  • Senior eCommerce Analyst
  • Information Technology, Help Desk Specialist
  • Interactive Producer
  • Director of Information Technology
  • Director of Data Management and Analytics

Update (2/23): We’ve just added a req for a senior print graphic designer, too!

Feel free to reply by comment with questions. You can apply here.

We do not work with recruiters.



Review: The Business Analyst’s Handbook, Howard Podeswa

The Business Analyst's Handbook (cover)

The Business Analyst's Handbook, by Howard Podeswa

I have to start out by confessing that The Business Analyst’s Handbook, by Howard Podeswa, might not have been the Business Analysis book for me. Software business analysis, like project management, is practiced in two ways these days: the documentation-heavy style necessitated by large organizations where hundreds of people touch a project, versus the looser style used by smaller, nimbler organizations. I mostly practice the latter, and as such, this book proposes a lot of BA deliverables that I’d never incorporate into my work.

That said, there’s much of use here, even if you’re doing analysis on a document-just-in-time Agile team. Podeswa and the colleagues on whose experience he draws know their trade, and while this book isn’t exactly fun subway reading, it does what it says on the tin. It’s an exhaustive catalog of BA best practices, suggesting whom you should consult at every stage of requirements gathering, whom you should invite to meetings, and what should go into the resulting documentation.

If you’re looking for a conversational introduction to the BA’s trade, run like hell  from this book. If you’re looking for a desk reference that you can flip open when you’ve got that nagging feeling you might have missed someone or something when setting up a work session, you might find it useful.

I say “might” only because of my main gripe with this book: awful organization. The information is useful, but ugly and hard to access. I can get useful but ugly off of the web (where at least I have the “Find” command to see me through).  A book ought to be better designed. The fault probably lies with the book’s publishers, Course Technology.  Specifically, much of the information in the book is presented in tables. This would be fine, if the tables were laid out in spreads together with the explanatory text so that you could easily tell what subject a given table covered, and cross reference between table and text. It would have cost them more page count to do this, as it would’ve created quite a bit of white space. Instead, it looks like someone just dumped a Word doc into inDesign with minimal flow control. For a $50 cover price, it’s fair to expect better layout.

Finally, although I may have given the impression above that I’m allergic to documentation-heavy analysis processes, what I’m really averse to is producing a document when it’s not needed. If you want a complete playbook of all the types of documents that might be useful, this book is great. It’s opened my eyes to some documents that I wouldn’t have thought to add to my process before, and given me names for some things that I was already doing on my own but didn’t realize there were standard terms for (like swimlanes). And if you love UML, you’ll be happy to see that many of the Handbook’s recommended deliverables are UML documents.

Overall a handy book, although I strongly recommend looking at a preview before you buy to see if the aforementioned layout problems drive you to distraction. Amazon’s discounted price ($28 at time of this writing) also works in the book’s favor.

The Unfashionable Truth about Online Collaboration

Potsdam Conference roundtable

The Potsdam Conference: Against all odds, we won World War II without Basecamp.

It was at hour 1.5 of the scrum that I began to suspect my virtual teammates of being asleep. Why was a scrum call taking an hour and a half?

Why the endless questions about topics already documented?

And seriously: was the bubbling noise on the one dev’s phone line just him finishing off a Big Gulp, or him hitting a bong? (My suspicion echoed the study of business professors Rockmann & Northcraft, who found that remote collaborators have difficulty building trust.)

All in all, I’ve decided that some skepticism regarding virtual teams is a healthy thing. Face time works. According to urbanist Edward Glaeser, that’s why we invented cities in the first place.

Cut to two weeks later. We flew people to Boston, locked everyone in a basement conference room, and spent a week having our own Potsdam Conference. Suddenly we all had to look each other in the eye each day. Suddenly, things were working.

This simple truth has gotten lost. A friend of mine worked in a model shop at a large handset producer where designers never left their desks, instead using bluetooth headsets to communicate — even with people sitting in the same room! I spent some time at a large Boston agency where the production manager two floors down looked startled every time I showed up in her doorway instead of calling or e-mailing.

At the same time, I’ve worked on virtual teams that performed very well.

The problem is cultural. If your organization isn’t ready for online collaboration, don’t use it. And don’t expect teams who’ve never met each other face to face to play well with each other. People lie more over e-mail, as one researcher found out.

Nowadays, it’s heresy to claim that online collaboration is a bad thing. The problem is that  organizations rush into it ill-prepared. But I found some rays of hope in this Standford Business post on time zone-spanning teams. Their suggestions boil down to:

  • Build trust. Question to ask: does your team have a bond of trust, and if not, how can you build it? (If the answer is ropes courses & trust falls, try again).
  • Have processes that correct for the limitations of online collaboration. Question to ask: do your workflows, meeting rules, and sign-off processes correct for missed non-verbal cues, large groups sitting together dominating conference calls with remote people, and the like?
  • Foster adaptation instead of throwing workers willy-nilly into virtual teams. Question to ask: is your team sufficiently savvy with the collaboration tools to be used? Can you suggest conventions of use that keep people from being overwhelmed by the new mode of collaboration?

I’ve promised myself never to have another scrum call like the one I describe above. There’s no reason you should, either. Prep your team before you commit to virtual collaboration. And if that doesn’t work, pull the plug, and show up in someone’s office.


Review: The Agile Samurai (Jonathan Rasmusson)

The Agile Samurai, Jonathan Rassmuson (book cover)

The Agile Samurai, Jonathan Rasmusson

Many are the books full of semi-useless sage device on how to manage software development. Few are those that, within a few chapters, empower you to call shenanigans on a buzzword-clad impostor. For the latter service, I’m most recently indebted to Rasmusson’s The Agile Samurai: How Agile Masters Deliver Great Software.

Agile, unfortunately, is a concept that’s been much abused by the aforesaid buzzword charlatans. It’s an idea that’s easy to pitch in an elevator but hard to do for real. And worse, it’s hip. No one wants to be a stuck-in-the-mud naysayer in tech circles (well, no one except for cranky old mainframe programmers — and they’re allowed).

The result is a lot of misinformation and misconception about what Agile really is, what type of projects it fits, and what kind of team you need to do it right. There’s also a basic failure out there to understand that you don’t use everything in Agile. It’s a toolkit, and some of its processes are best skipped in certain situations.

Rasmusson’s book applies the swift katana of justice to all this nonsense. Within a few chapters, I not only had a good grasp of what Agile is, but what it isn’t. He then spends the rest of the book on details of process and, most importantly, offering quick sketches of scenarios in which a given technique succeeded or failed.

As a business analyst, this book challenged everything I’d previously thought about how and when to document the results of my interviews with stakeholders. As a project manager, I walked away with a bunch of useful new tools (kanban boards & Agile-style burndown charts for the win!). As a sometime-coder, I learned some new concepts about good coding practice, which in turn has made me smarter about asking questions of the devs with whom I work.

I was a little suspicious when I picked up the book of the occasional cartoons, the large space given to some infographics, and the quirky sensei/student warrior dialogs that close each chapter. But at the end of the day, I’m a nerd; I love the semi-hokey samurai flavoring. Rather than making the book light on substance, they lighten it as a read, making it a quick book to get through over a series of lunch hours.

And so I will end with a hearty recommendation, and a quote from another samurai book, Musashi’s Go Rin No Sho (Book of Five Rings):

Know the smallest things and the biggest things, the shallowest things and the deepest things. As if it were a straight road mapped out on the ground … These things cannot be explained in detail. From one thing, know ten thousand things. When you attain the Way of strategy there will not be one thing you cannot see.

hiring an Adobe (Day) CQ architect

UPDATE: We’re no longer hiring for this position. Thanks to those who expressed interest.

My employer is in the process of integrating the Adobe CQ CMS. Once we go into maintenance mode, we’ll be looking for a qualified Java architect to take it over. Alternately, we’re open to discussing a retainer agreement with the right code house.

Key skills:

  • Java
  • JSP
  • Apache Sling (and preferably experience integrating it with the other technologies in this stack)
  • experience developing for Adobe (formerly Day) CQ, for another CRX-based web app, or for another JCR-based app (e.g., Jackrabbit)

RIM Tablet & TAT

I posted back on 12/29/10 that I was excited about seeing that The Astonishing Tribe (makers of really neat augmented reality software) had been acquired by Blackberry.

And then I read today that RIM’s new tablet, the Playbook, has been taking a drubbing from reviewers. Disappointing. Tablets are one of the most exciting delivery platforms for AR. I really hoping TAT’s talent doesn’t end up behind a losing horse.

Interesting piece of news

Blackberry is acquiring The Astonishing Tribe (makers of the Augmented ID facial recognition software). If you want to see more AR in mobile, this is interesting news.