Bright Matrices

Writings & musings of Mike Zavarello (a.k.a. brightmatrix), a "red mage" web developer.

Tag: UIE

Some Lessons Learned from Live-Tweeting the UIE Web App Masters Tour

I was lucky to attend the User Interface Engineering Wep App Masters Tour in Philadelphia this week. The event, arranged by Jared Spool and his talented team at UIE, starred luminaries such as Stephen Anderson, Jason Fried, Luke Wroblewski, Hagan Rivers, and Bill Scott. Since I’m a prolific user of Twitter, I decided to tweet throughout the two-day event to share quotes and key points from the presentations with my followers.

I learned a lot during my tenure as “citizen journalist” and would like to share some of my experiences and a few “lessons learned” that I picked up along the way.

Folks familiar with on-the-ground Twitter reporting call it “live tweeting”. You’re basically giving your audience a taste of what’s happening at the event; this can be quite helpful for those who were unable to attend in person. You may also decide to share your own opinions on event proceedings, give instant feedback to the hosts, or share related topics and links with anyone else watching your feed. The critical piece that connects these posts together is a common hashtag. This is either issued by the event organizers or crowdsourced into existence by the attendees. In this case, the hashtag for the App Masters Tour was #uiewamt.

On Day 1 of the event, I hit the ground running as soon as I was seated and hooked up. I let my followers know I would be tweeting from the Tour and blazed ahead. There was a lot of really good stuff the presenters were sharing; I estimated that, at some points, I was tweeting as frequently as once every 40 seconds. I got some complements on my reporting, both from folks at the event and those watching from afar.

Before lunch on Day 2, though, I was made aware that it was getting to be too much for some. One of my followers made a helpful comment asking those live-tweeting from events to use the conference Twitter handle at the start of each post to “reduce noise” in his account. It was a simple solution to put into play and I started to use it immediately. Those already following the conference hashtag could continue to read what I was posting, but my followers were now freed from my Twitter frenzy if they weren’t interested in the Tour. It was a great compromise.

There are two key advantages I see for the “quiet approach” to live-tweeting:

  • You spare others from being bored. If you’ve been chatty on Twitter, you’ve probably accumulated a decent collection of individuals over time. Not everyone may be interested in reading a blow-by-blow transcript of something that isn’t as near and dear to their hearts as you. If you become too boring to them, even for a few days, you might get dropped.
  • You reduce noise pollution. If your followers include you among others they enjoy reading for a diverse source of news and information, suddenly seeing nothing but you in your timeline could become annoying very quickly. I’ve stopped following people who seem to do nothing but retweet all day, every day.

The only thing you stand to lose with this method is the “discoverability” that would be gained from your followers seeing something at random whenever they tune into your posts. That could be fixed, however, by giving them a heads-up on upcoming proceedings (see the third bullet below).

Besides the “quiet reporting” concept, here are some other thoughts and suggestions I came up with for live-tweeting at events:

  • Monitor your frequency. See how often you’re posting once the first presentation of the day is done. If you’re pushing out updates more frequently than once every five minutes, it may be too much for your stream. Consider toning it down, or, if the information is too good not to share, switch to “quiet” reporting.
  • Take feedback, and graciously. Look to your mentions to see what your followers or others are saying about your reporting style and adjust accordingly. If they love what you’re putting out, or getting annoyed by the chatter, they’ll let you know either way. Whatever you decide to do, be prompt and polite about it.
  • Remind your followers about your “quiet” reporting between breaks. If you decided to run “quiet”, give your followers a heads-up on the next session. Drop the event handle so the tweet shows up in their timelines and share some details about what’s coming up next. That way, if they’re interested in that topic or presenter, they can pick up the hashtag and follow along at their own pace.
  • Check in with the event hosts. I haven’t heard of a situation where you’d run afoul by posting comments at an event, but checking in is probably a good courtesy if you’ll be running at full speed. I realized halfway through the first morning’s proceedings at the UIE Tour that I was tweeting two to three times more frequently than another person who represented UIE. If that person had been designated as the “official” source of information at the event, I might have diluted their efforts. Thankfully, the good folks at UIE were very gracious about the added contributions.

I’m looking forward to the next opportunity to live-tweet an event, and hope my suggestions will make the experience pleasant and informative for everyone. I’d like to thank the folks at UIE for, as Jared Spool likes to say, encouraging my behavior.

Have you live-tweeted an event and have helpful suggestions to share as well? Let’s hear about them and discuss; I’m always up for alternate perspectives. I also welcome feedback on my thoughts as well.

Update (8-3-10): Since I wrote this post, I’ve done further experimentation with live tweeting. I followed the advice of either an article or tweet I read earlier this year (and for the life of me can’t remember which it was) and stood up a unique Twitter account to handle live tweets: @noisymatrix.

My strategy so far is as follows:

  • Prior to the event, I’ll announce on my primary account, @brightmatrix, some basic information about the event and when I plan to start posting.
  • Once the event is underway, I’ll shift over to @noisymatrix and start tweeting. My tweets use whatever hashtag has been chosen for the event or seminar.
  • When the session is over, I encourage folks who enjoyed my reporting to follow my primary account.
  • Finally, I compile all of my tweets into a blog post and publish them within a day or so of the event. This way, folks can read the entire recap at their leisure. I’ll announce the blog post on both accounts.

I’ve only done this once so far (for a July 30 Radian6 event on open leadership in social media), but I think this method will be more successful. Stay tuned!

I Had More in Common With 37signals Than I Realized

This week, I was fortunate enough to hear Jason Fried, founder of 37signals, talk from “behind the curtain” about his work philosophies at the Philadelphia UIE Web App Masters Tour.

The talented folks at the Chicago-based web application firm run a tight ship. They work in teams of three to five, depending on the nature of the project (two developers and one designer for standard projects; one extra each for “stack” projects). They work in iterations, with each lasting about two months; at the end of each iteration, the work is either finished, or it isn’t. The teams are reassigned after each iteration so everyone gets to know everyone else’s skillsets (avoiding the “hit by a bus” scenario). Many times, the teams get to choose how and on what they’d like to work. There’s no paper prototyping, sketching (beyond broad, simple strokes with Sharpies), or Photoshop mock-ups; they dive right into interactive wireframes using HTML. There’s no user testing before a new build is launched. 37signals accepts feature requests, but they typically scrap them; most times, it’s only when a specific request or complaint keeps popping up that it gets attention. Overall, it’s an amazing and eye-opening process, particularly for those of us working in larger organizations, where such a culture would be challenging, if not impossible, to institute.

But the true take-away for me that day was this: I had more in common with 37signals than I realized.

For seven years, I worked for a medical publishing firm. I was part of a four-person web team: a director, two database developers, and me: a web designer and front-end coder. We worked on online versions of medical journals and image databases. Our process was generally effective but very informal: no product documentation, no project management, no user testing, no multi-year projects, and maybe two to three formal meetings a year. We knew what was expected, came up with our own solutions, and make fixes and improvements organically. Since there was only four of us, we developed overlapping skillsets so there would be coverage for vacations, sick days, etc.

I never really gave the work philosophy at my old job much thought, but this week it hit me: I’ve had a similar experience to the 37signals model.

I’ve been here before. This was an interesting revelation.

The organization where I work now has a much larger workforce and stronger hierarchy than 37signals. Meetings and project management are part of daily life. Much of what Jason preaches resonates deeply with my colleagues, who can feel burdened by day-long kickoff meetings, rounds of conference calls, and chains of e-mails. They see an austere, agile, and geographically-agnostic workplace, with its stream of consciousness projects and “meetings suck” mentality, as Nirvana.

OK, so I had a variation of their experience at my old job, but I’ve since moved on. What about now? Is the 37signals philosophy scalable in large organizations like mine?

Yes and no.

Sure, meetings can and do suck, but in order to get things moved along at my office, it’s often a necessary evil. You have budgets that span several years and strict accounting rules to follow. You have to be wary of risks to security, reputation, and authenticity. You have to play well with multiple teams from varied disciplines and management structures. It’s not that these things don’t exist in some form or flavor in the 37signals plane of existence, but they’re magnified significantly when the people, roles, and responsibilities carry the weight borne by large businesses. My organization can’t run on 2-month iterations or release new features and services without user testing; there’s too much at stake.

The key word here is the “organization”. The business model we follow is too massive for the 37signals way of life, but not the individual teams within it. That’s where the fast-and-loose lifestyle of the agile development firm can take root. I’ll take one example from Jason’s presentation to show how some of their attributes could be applied effectively and painlessly.

During the 37signals session, one trait quickly became clear to me: there was no e-mail between his teams. None. The folks who work on iterations don’t use it during development. Instead, they use an in-house product called Campfire that allows for efficient and swift teamwork. It’s a threaded, collaborative interface, where comments and features for a unique project are posted in a chronology. Team members can upload images and give feedback; everything exists in a proper order and context. There’s no “hey, did you get my e-mail?” nonsense chatter, crossed wires from team members sending messages over one another, or overflowing inboxes (which people don’t often keep well organized anyway). It lets the 37signals team get changes done on-the-fly, in real time, and with great speed. If individual teams in my company were to adopt Campfire or something similar, it could save countless hours of time spent wondering where everyone was in the development, review, and release of our projects. It would help my boss stay on top of our projects and simplify approvals. It’s less burdensome and not as obnoxious as typical help desk ticket systems. And, since every post is captured and recorded, there’s an automatic paper trail created as you work (which should satisfy the auditors).

Think about it. Wouldn’t that make your day so much easier?

We can’t all be like Jason Fried or 37signals. Obviously, not everyone or every organization can or should work the same way. However, there are a gold mine of innovative and efficient practices in their philosophies that, taken in smaller chunks, can translate into your universe. Replacing e-mail with a system like Campfire, for example, could be an easy victory, and one that I hope to discuss with my peers.

Do you work at a mid-size or large company? What could you take from 37signals that would work for you, or have you already done so? I’d love to hear your thoughts, findings, and stories.

© 2020 Bright Matrices

Theme by Anders NorenUp ↑