Almost everyone has experienced that point where you’ve worked for so long and have been thinking so hard that your brain is about to turn to mush. You just can’t possibly think any longer and you’re beginning to stress out. Once you reach that point you become ineffective at what you’re doing. Everything starts to take significantly longer. Maybe you start to watch the clock or you zone in and out of daydreams. It becomes clear that in order to finish the task you started, you need to take a break first.

Wii

In order to facilitate break-taking here at the office, I brought in my Nintendo Wii today.  Henry had an extra TV that he contributed and we plan on hooking it in a few minutes.  Part of the reason for the Wii’s success so far with non-hardcore gamers has been due to the many short and simple party games that are available.  This is also the reason why I think it makes for a great office system to facilitate break-taking.  Many experts recommend taking shorter breaks throughout the day.  Can’t think?  How about a quick race in Mario Kart?  It may seem counter-intuitive but I’m hopeful that having a release like the Wii will help keep our minds clear and make us more productive than before.

Over at The Apple Blog, I was debating what it means to collaborate on a document with some other The Apple Blog fans. In reference to Apple’s iWork.com, a reader remarked:

…the “collaboration” falls a bit short. True collaboration is online editing, something this service lacks.

It’s a common misconception that collaborating on a document can only mean group editing. In fact, as you consider the situations you or I encounter on a daily basis, very few call for group editing of a document:

• Asking your boss to do a quick once-over of an important client proposal — you want high level feedback, not a re-write of paragraph 3.
• Getting feedback from your peers on the design and contents of a product brief — the last thing you want is three people to move the screenshot to three different locations on the page.
• Obtaining the ‘ok’ from engineering that all the technical details in a report are correct — do you really want the engineering manager rewriting your carefully crafted prose?
• Getting feedback from a client on a contract, proposal or other project — like another commenter on The Apple Blog entry mentioned, you don’t want clients editing your work. It’s not easy to explain why you didn’t make their changes. After all they are hiring you because you can do a better job.

Even if the work case is a group of people equally responsible for producing a document, documents produced through “editing by the masses” are often inconsistent in style, tone, or even facts. There is a strong possibility some edits even introduce backward progress, undoing decisions made earlier. Even after the group finishes, a publishable document likely requires a large amount of post-production individual editing. There is huge value and time save in a gatekeeper, passing around each draft for comments or feedback and then making only the changes he or she deems relevant.

Group editing also demands significant time from those providing feedback. If you’ve ever been asked to provide feedback on a child’s report for school, you know exactly what I’m talking about. It doesn’t take much time to suggest a change in paragraph order or point out awkward sentences. The time consuming part is suggesting an example of how a sentence could be more clear or rewriting the introductory paragraph. In short, feedback is quicker than rewriting.

Effective, efficient collaboration is all about speeding up the iterative cycle, making it easy to get input and guidance throughout the development process. Group editing opens up the document to the inefficiencies of consensus, but feedback, using a tool like Backboard, provides the benefits of early-and-often input without the dangers of committee editing.

Every once and a while I dig out my all-time favorite video clip and remind myself of the magic of entrepreneurship:

“My naive and romantic belief is that if you make meaning you will probably make money, but if you set out to make money you will probably not make meaning and you won’t make money.” — Guy Kawasaki

Over at TechCrunch, there is an interesting conversation going on around Adobe Lab’s failed project to place contextual ads in PDFs.  The idea initially seems reasonable.  Why didn’t it work?

PDFs are an ingrained part of business processes, easy to create and consistent to view.  As a private means of transmission of pre-formatted data, PDFs are still a great solution.  In private exchanges of data, however, ads are often unwanted or inappropriate.

These ads would be appropriate and relevant on public PDFs, linked from a web page.  However, the concept of a public, downloadable PDF is quickly becoming outdated.  Why would you download something to open in Reader or Preview instead of simply reading it in a web page.

At Increo, we believe public PDFs are best embedded into a website instead of linked (you can embed your own at embedit.in).  Perhaps an ad offering around embedded documents may make sense, but as Adobe witnessed, an ad offering built around a out-of-date document delivery system (like downloadable PDFs) is destined for the deadpool.

About a year ago, before Backboard and Increo, I was working with a team to prepare a report on strategy recommendations for a specialized electronic toy manufacturer.

We prepared the original draft using a popular collaborative group editor, and one team member copied and pasted the current draft into a .doc file and emailed it out to the collaborating group for further review.

As it turns out, many changes were required to yield a presentable document, and I set to work correcting, using Microsoft Word’s Track Changes feature.  Two hours later, I was reasonably satisfied with my progress.

As I prepared to send the report back to the team, a message sat in my inbox with a new version of the report containing changes from two other teammates.  A few seconds later another version came in with page twenty-two almost entirely rewritten.

It wouldn’t do any good to submit my version of the report as is, so after I finished swearing under my breath, I emailed a warning to the group to stop editing and send me anything they had.  I undertook the painful process of merging the changes I had already made plus changes from my colleagues into the most recent version of the document.  Three hours later I had a more or less up to date document.

Time spent editing and merging: 5 hours
Total emails composed: 6
Outdated versions of the document: 4
People I wanted to sock: 4

I wish Backboard would have been available back then.  My teammate would have sent out his draft for review on Backboard and I would have spent time reviewing and indicating my requested changes.  So would the remainder of the group.  Once we had all voiced in, the original Backboard creator would run through the document once, updating it with suggested changes.

Time spend editing and merging: 2 hours
Total emails composed: 0
Outdated versions of the document: 0
People I wanted to sock: 0

Yesterday as a group we sat down over lunch to watch a pair of user testing videos.   These were two people who had never used Backboard before and were being asked to give feedback on a document produced by a “colleague” of theirs. The prompt follows:

Goal: You received an email from a colleague of yours asking you to review a document and leave your feedback. The email contains the following link: (some random link to a testing Backboard)

Both users were able to visit the site and (somewhat) successfully use the product to provide feedback. It is not in the successes that user testing is useful, but in the failures.  

When someone fails to perform a task that seems trivial you are forced to rethink the problem. They approached the task as an outsider and you must be able to put yourself in their shoes. We learned a lot from these tests and will continue to use them as a tool to understand how people view Backboard.  We have even incorporated user testing into our weekly routine.  They inspire us to continually view the product through a user’s eyes.

When we launched embedit.in last month, the focus was on simplicity. No registration required, no seven-step process, nothing. Just upload a file and click “Embed It!”

Of course, the back end isn’t quite so simplistic: it stores your file, converts it to be viewable in our player, and generates the code for you to embed on your site. That last step presented us with an interesting challenge.

The initial version of the code used the OBJECT tag, complying with HTML standards. It was short, it was simple, and… it didn’t work in Internet Explorer 7.

<object width="466" height="400"
    type="application/x-shockwave-flash"
    data="(url of flash file)">
    <param name="allowFullScreen" value="true" />
</object>

Much has been written about the best way to embed Flash in webpages, and the state of the art is that the EMBED tag is bad, and the OBJECT tag is good, but requires different sets of attributes based on what browser is viewing the page.

That leaves us, therefore, with a need to have different markup depending on the browser, so libraries like SWFObject were born. Every browser gets the correct markup using the OBJECT tag, the HTML standard doesn’t feel violated, and another angel gets its wings.

One problem: it relies on JavaScript being available in the browser and a library being loaded. For an app like Backboard, that’s totally reasonable, but when the entire point is to let people copy a single line of code in to their site, it doesn’t work. So where does that leave us? That’s right, partying like it’s 1999.

<embed width="466" height="400"
    type="application/x-shockwave-flash"
    src="(url of flash file)"
    allowFullScreen="true" />

Hey, look! It works in every browser, it’s just as functional, and the code is even shorter than before. Maybe it’s not standards-compliant, but it’s reliable, and isn’t that the point of standards in the first place?

On Tuesday, we mentioned the striking resemblance between Backboard and Apple’s new iWork.com. Soliciting opinions, we sent it out to a bunch of members of the Mac community for their input and feedback. The responses were interesting and varied, but this particular one, from The Apple Blog editor Josh Pigford, especially caught my eye:

Thanks for the link. Sure iWork.com “feels” like Backboard… but Backboard doesn’t integrate with iWork docs… which is precisely what iWork.com is for. It’s not for every document-using person on earth.

In your post you said:

“You don’t have to switch to Pages, Numbers, and Keynote in order to use Backboard to get feedback on your documents. Use Word, or InDesign, or OpenOffice.org! It all just works.”

That’s precisely why I want iWork.com…because I use Pages, Numbers, and Keynote.

Once Backboard has iWork integration, let’s talk.

Never to be one to back down from a challenge, we spent a couple hours with Mike Solomon’s excellent SIMBL and came up with something. Guess what, Josh! Backboard now has iWork integration.

How it works

Just install this software package and relaunch your iWork apps. In the toolbar, you’ll now have a new button right next to the iWork.com button:

Simply click it and you’re on your way. It’s also available from the Share menu, in case you want to assign a keyboard shortcut:

Try it out!

Download Backboard Plug-in for iWork ‘09 (163 KB, requires iWork ‘09 to be installed)

Always listening to feedback

Remember, Backboard is constantly changing and evolving in response to your requests; without the people who use it, Backboard wouldn’t be where it is today. In this case, we had a chance to implement something in response to one person’s feedback, and we’re always looking for more ideas.

Let us know what you think, and Happy Backboarding!

Every once in a while I’ll be writing and think of two or three ways I could approach a paragraph.  Or Jeff is designing an image and ends up with several possible options.  Multiple iterations are a positive thing, but deciding which to run can be a difficult prospect.

I could conduct an old-fashioned poll, asking for votes by email or survey and select the winner.  I’d run the risk, however, of the best option being none of my proposed choices.

Backboard is a convenient way to gather opinions from your audience while learning more about what motivated each vote and getting further feedback on the concepts at play.  A straightforward poll will never produce: “combine the squiggle from this logo with the text from the other” or “I love the first paragraph of this draft and the last half of the other one”.  Backboard will, and your work will be better for opening discussion up to more than just A, B, or C.

Just press cancel the first time Backboard prompts you to share, upload each option as a different version on your Backboard, and give them unique names.  Then press the “invite reviewers” button when you’re ready to share with your audience.

Here’s an example.

This morning, Apple launched iWork.com, their new document feedback tool. The screenshot looks eerily familiar:

If it reminds you of Backboard, you’re not alone:

We encourage you to try out both services, and in doing so, you might notice some advantages to using Backboard:

Nothing to install on your computer

You don’t have to go out and buy a $79 product in order to use Backboard. Everything runs in your browser, and feedback is just a simple upload away. You don’t even need a Mac, though we would suggest it for your own sake.

Backboard has live streaming of feedback

No waiting to see who shows up, no waiting for two minutes for new feedback to load in. Everything streams right away.

Read the rest of this entry »