Since Backboard first launched red pen annotation, I’ve been amazed by all the creative ways to leave feedback.  Each member of the Backboard team expresses themselves differently: circles, underlines, big cross-outs, arrows; you name it, we’ve seen it.

Like Carlos, a new Backboard user that posted on our feedback Backboard last week, sometimes you need a little more structure to your drawing.  If you’re not into free form annotation, you can hold down Shift while you’re drawing to create a straight line or the Option (Mac)/Alt (Windows) key for an oval.  The perfectionists out there can use both for a perfect circle.

Lately, the Backboard team has taken annotation to the next level (whether it’s a level up for its creativity or a level down for its ridiculousness is up to you to decide).  After feedback is closed on team Backboards, small red-pen animals, vehicles and other doodles often show up.  Here’s a sample for your enjoyment:

And my personal favorite, TROGDOR the BURNiNATOR burninating the countryside.  On the original Backboard, this is an animation.  Mouse over the first part of the feedback and see TROGDOR brighten.  Mouse over the second part, and see his burninating.

We’d like to share the fun with the Backboard community.  Link me to the Backboard featuring your best feedback art (in the comments) by Wednesday, February 11.  I’ll set the best annotation artist up with a complimentary month of a premium Backboard account.

As the Backboard experience gets richer and richer, more of it moves to the browser from the server. It’s a win-win-win: Increo gets less load on our servers, you get better response time on your computer, and the team gets to write code in the awesome language that is JavaScript.

As such, we’ve spent a long time working on making it as consistent and manageable as possible. With apologies to Wil Shipley, some basic suggestions for maximum JavaScript happiness follow.

Use a JavaScript framework

If you’re still writing JavaScript without relying on one of the myriad open-source DOM-savvy Ajax frameworks, you’re wasting your time and effort. You have lots of choices:

• Prototype
• jQuery
• MooTools
• Dojo

Backboard is built on the (large and supple) shoulders of Prototype, but we hear they’re all pretty good.

Don’t host your own copy, though: use Google’s hosted version. That way, your whole app loads faster when your users don’t have to even download the JavaScript file because it’s already in their caches.

Use namespaces, or the next best thing

Sure, JavaScript is technically a language with a flat namespace, but since it’s prototype-based instead of class-based, you can just use objects. Instead of this:

function my_namespacer_hopefully_nobody_collides_runRequest(arg1, arg2) {
    return "Haha! This function has a really long name!";
}

you can have a simple “namespace” object of your own:

var MyStuff = MyStuff ? MyStuff : {
    runRequest: function (arg1, arg2) {
        return "So much better!";
    }
}

You may think you’re organized enough to keep everything straight, but once you start pulling in libraries and other people’s code, you’re going to be in a world of hurt. After all, you don’t want your next big app looking like PHP.

Employ some automated syntax checking

And by “some automated syntax checking”, I mean JSLint. We use the following set of options for our source code:

The face of Backboard (that is, the JavaScript that runs in the browser) is almost 1,300 lines of JavaScript. Running it through JSLint helps prevent dumb errors and bugs and it keeps all of us honest. Having an easy way to enforce coding guidelines makes it easier for everybody to work together and make your quality consistent.

Let your server deal with download efficiency

Shipley sez “Tiny code is always best”, but I’m pretty sure what he means is you should express yourself briefly, without wasting code writing extra methods you don’t need or class hierarchies just because you can.

Repeat after me: whitespace is okay. So are comments.

You’re better off writing beautiful, well-documented, understandable code and having your application compress it with things like JSMin or the YUI Compressor and mod_deflate.

Those 1,300 lines of JavaScript in Backboard started at 46 kilobytes; after running them through JSMin and mod_deflate, they’re 8.2 kilobytes. Having it set up to run automatically is an order of magnitude more worthwhile than any effort to minimize code size.

All of this leads us ever closer to JavaScript happiness. And, of course, that’s the whole goal, right?

Spam is a constant problem — I would guess this not news to you — and there are countless software packages and tools available to fight it with varying success rates.

One common technique is to use a temporary or disposable email address when signing up for online services so that it doesn’t matter if the company turns around and spams you or, worse yet, sells your address. You could use your old Hotmail address for this purpose or even a custom service like Mailinator.

Often, you have a better technique right at your fingertips that requires no extra effort on your part: plus-addressing.

Let’s say your email address is:

john.doe@gmail.com

You will also receive email sent to:

john.doe+anything@gmail.com

That is, you can add a plus sign and then any word to your email address, and it will still be delivered to you!

Next time you sign up for an online service, use a +servicename sub-address. If you start receiving spam at that address, not only can you hold the service accountable but you can easily set up a rule in your email program to delete it all.

Email providers vary in their support of sub-addressing and some (such as Yahoo) use minus-addressing instead (where the plus sign is replaced by a minus sign), but with a few quick test emails you should be able to figure out what works for you.

With Backboard, we promise to never disclose your email address to anyone and we have gone to great lengths to make sure you get the smallest amount of email required to make the service work.

If you want to test us though, sign up for Backboard with a +backboard sub-address and see for yourself!

Over at TechCrunch, there’s some interesting discussion about a recent decision by Nielsen to remove Reply All from Outlook for each of their 35,000 employees. It’s positioned as an efficiency play–too many people overuse Reply All, clogging their colleagues’ inboxes.

Sure, sorting through email is a time sink.  More of a time sink is discovering someone didn’t get a critical email, causing a whole bunch of new emails, duplicating effort, and letting something get out without all necessary eyes on it.

I would encourage Nielsen to give Reply All a second chance and take a look at lightening the email load with great new communication tools.  Select a few to deploy and educate employees about how and when to use them.  Think about corporate IM or Yammer for quick updates, Doodle or even Outlook for scheduling meetings, Xobni for inbox organization, and of course, Backboard for document review.

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.