In an upcoming scheduled update to DoneDone, we've tweaked the issue detail page interface a bit. There isn't any new functionality, and these aren't big changes, but they're important enough that I want to discuss why we did them.

What it looks like right now
Currently, when you look at an issue detail page, you see three basic sections:

• Issue information and next possible actions (in light blue)
  
• Comment box (in gray)
  
• Issue history (at the bottom)
  

We're finding alot of our users (and some of us) get distracted by the comment box. If you've been assigned an issue, more than likely your first move should be to change the status of the issue to "In progress", "Not reproducible", etc. Changing issue statuses is core to our philosphy - it moves that issue to the appropriate person's bucket. We want that to be the first step people take.

From your feedback, we get the sense that you see the inviting comment box and immediately want to type into it:

New comment: "Hey, I can't reproduce this issue on my browser. Are you using Mosaic again?"

Here's the problem. When you add comments, you're not changing the status of the issue. Really, this should have been a status change to "missing information" and the comment should go in the yellow box. Comments should only be used if you're just making a note about something, or adding to the issue without the intent of changing the status.

The other problem is, the exposed comment box is pushing the issue history further down the page. The comment box is simply getting in the way. We need it to take up a more appropriate amount of space relative to its general importance.

Our attempt at solving the problem
We're going to do two things to guide you a bit more.

First, we're hiding the comment box and showing a link to "add a comment" instead. The link just exposes the comment box.

Second, if you are assigned an issue, you'll see the "change status" dropdown and comment area open by default. Here's what the new version of the same page will more-or-less look like:

A follow-up thought on usability
While we like the changes, there are potential drawbacks. You now need to make an extra step to add a comment. It might take new users an extra few seconds to figure out how to add a comment.

But, these minor gotchas are risks we're willing to take. I don't think there should be golden rules in usability (less clicks is always better than more clicks, in this case). In our case, making something slightly harder or less obvious is, in turn, making the more-likely-to-be-correct-action easier and more obvious.

We hope this slight UI change makes sense and you think it's the right change. We'll likely be making the update sometime early next week. Comment back or hit us up on Twitter (@getdonedone).

Labels: DoneDone

We Are Mammoth is looking for someone(s) special. You are special because you want to work in a bootstrap environment, helping to build good software. You are special because you know your title isn't applying for a job. You like working in a building that looks like this.

So, what are we looking for? A project manager. What does this project manager do day-to-day for us? Excellent question.

• Operational duties as it pertains to new and existing business. Managing and consolidating estimates and drafting them into clean and legible statements of work. Got a change order? Great, work with the developers to draft the effort and get it pushed through with the client, signatures and all. Invoicing. Fairly straight-forward, right?
• Day to day project collaboration duties: Manage and document all internal and external project communications. You'll work with our developers to keep a flexible and open channel of updates flowing between them and our clients.
  
• Monitor project budgets and timelines. We're informal, and need a little help here. You'll keep tabs on our hours and our commitments. Because of the way we work, there's a lot of discussion around what we should do to meet our agreements, and what might be worth pushing back. You are the hall monitor in these parts.

Ok, so what qualifications do you need? Yes.

• We need you to be eager to work in an informal, non-corporate environment. We build fast and furious, but like an even-keeled approach to our client culture. We are cutting edge, but not bleeding for it.
• You need to take good notes. And be better organized.
  
• You need to have a minimum of 3 (proven) years of experience at an interactive agency or web development firm , having involved yourself specifically with software development.
• You need to be mature. We don't have an HR department. We're not going to make you sit in some conference room for 2 days of corporate ethics training. We are your brothers keepers. It's a close knit team, be ready to feel alive again.
• Oh, yeah. Computer skills: Microsoft Project, etc. We'd also really like you to type fast, as there's a lot to say.
• Nice to haves? A stable character with a maverick twist. A CS and/or XP/User Experience background.

You ready to ditch the corporate noose and hop on the Mammoth wagon? Send us an email at PictureMe*at*WeAreMammoth*dot*com and prove it.

This week, we released a simple status report page for all DoneDone projects. We want it to be a quick overview instead of a detailed report. We want you to glance at it for 15 seconds and know how a project's generally going.

To get any project's status report, click the "Status report" link at the top of a project homepage.


The status reports page answers the two questions we think are most important:

1. What percentage of issues have been completed?
2. How much is on everyone's plate?

The first answer is pretty self-explanatory. We just take all closed issues and divide them by all created issues to get a completion percentage. Nothing big, but knowing that 93% of issues are completed tells you that you're definitely looking downhill.

The second answer reinforces what we want issue tracking to be about. Who's responsible for what, right now? Who's waiting on what? Just like in your dashboard, a project's status report shows you a grid of each person's items waiting on them and items that they are waiting on. You can also click a box to go right to those issues.

If you have multiple companies working on a project, you can choose them in the dropdown to the right.


As always, let us know what you think! Twitter @getdonedone or post a comment.

Labels: DoneDone

Our good friend and corporate roommate, Colin Metcalf has released the 4th edition of Lemon (the Bowie addition). Lemon is a "magazine that stakes its claim at the intersection of 60s-70s Pop and 21st century hyper-culture." Besides that, it's a gorgeous piece of flippable art.

Buy your copy here.

Working all day in Web land, it's somewhat of a relief to stop by his desk and actually touch, feel, and smell things. Lemon feels great and has wonderful new-magazine smell!

We Are Mammoth builds horrible software. At least, the first time it's released for testing. The second time around, we have our redeeming qualities. The third, fourth, and fifth time, we become masters of our domain (yeah, I said that). Post-launch, we've almost always deployed an application which exceeded original expectations.

This certainly comes at a cost. Clients aren't always happy with "the way things went" during testing. And, it's often somewhat of a gray finish-line in terms of deliverables. We persist, however, because it's been a successful formula.

You see, it's impossible (and as such, infinitely boring) to account for 100% of an application's complexity at the onset of a project. We're not robots, I think.

Instead, let's plan for and build about 70% and give it to the user. Now that they've seen a living application (albeit, incomplete), let's start tackling all those sticky "I want to have this thing this way" scenarios. It leads to things like this. It's stressful, for sure. But so is creating a 75 page functional specification with nothing but wild imagination and thin air, and subsequently failing to live up to its standard.

So, how do we do it? Let me give you a nutshell.

Test early, test often. Plan less at the start. Then build less up front. Next, push it out to the client, so that we can all collaboratively decide what's really missing (shortly before the deadline!).

Is this really testing? Or just some perverted form of rapid prototyping? Timing-wise, it probably should be called testing. Client expectation-wise, it's tough to convince them we're 'testing' a final product. So, let's call it the "feature definition when it really counts" phase.

Craigism: "You might think you want a fried pickle. Then you get it."

So, get the product to a high-level place where lower-level decisions can be made from a sounder vantage point. Fine. This will save up front costs on blind functional requirements and catering to wild imaginations, right? Yep. Won't you blow that save once you start testing and realizing the additional effort? Not necessarily. Keep in mind, you're building only the necessities shortly before the project is due to wrap up.

Let's be clear on a few things though. Some online stuff shouldn't be full of holes. Our practice applies to a larger effort generally fitting the "rich web application" description. Got a straightforward portfolio site to build? Do it right the first time.

Also, one big pitfall of a somewhat 'loose' definition is that you'll seemingly get slammed with additional requests. For your sanity, make sure you work out some prudent fee arrangements. More importantly, be fair to your client. They're looking to you to be even-keeled at this point. Once either party feels the other is pulling tricks, the game gets tougher.

This goes for timing as well. A client who is acutely sensitive to a shifting launch date probably isn't going to be laughing heartily towards your end date. Make sure you've primed them on your process. In fact, print the following out on a big sheet cake and send it to them.

The "Just so you know how its going to be" Theory On Testing
The effort and complexity of the testing phase is inverse to that of the original requirements specification. Thus, it's safe to say that the testing phase actually begins at the start of the project and the effort thereof can be predicted as such. Read: If you want us to get started immediately, there's going to be some pay off down the road.

We find this process works best for us. There are several different approaches to User Acceptance testing. We happen to be a very small and flexible team of developers who build everything in house. We actually like our clients, and like speaking with them. That's why.

Outsourcing your code development to a nation far away won't fit this description - it implies that the software build is abstracted from the day-to-day interactions of the product designers and stakeholders. Protocol and specifications are more necessary in these environments - both legally, and procedurally. It also implies many more fluorescent lights and bitter, corporate coffee.

In the end, software doesn't make mistakes. That doesn't mean that the process of building that software is inherently sterile though. With reasonable communication practices, a good issue tracking tool and a robust framework and approach to building your software, a more conversational approach to finalizing functionality and testing will ensure the end product is tested against real humans, not an Excel spreadsheet.

Recently, Bug Shooting added support for DoneDone. Bug Shooting is a free download for Windows that lets you take screenshots, annotate them, and immediately upload them as part of a new or existing issue. Do note that we currently only allow file uploads for paid accounts.

Here's how it works with DoneDone.

Quick install and setup
After you install Bug Shooting, you need to set up DoneDone as a server. Right-click the bug icon in your desktop tray, and go to Options > Settings > Server. Choose DoneDone, and then enter in your DoneDone URL and credentials.


Say Cheese!
To take a screenshot with Bug Shooting, you can either double-click the icon in your desktop tray, or you can configure it to launch when you hit your "Print Screen" key. Bug Shooting will launch with your screenshot and let you draw and add text.


You have a couple options to post the screenshot. You can either create a completely new issue or add the screenshot as a comment to an existing issue. To make a new issue, leave the "New Issue" option selected. To add the screenshot to an existing issue, enter in the issue number (you'll select the project later). You can also add text into the "Comment" field, which will make it the title and description for a new issue, or a comment for an existing issue. Make sure you've picked the DoneDone server, and when you're ready, click the "Send" button.


Send 'er away!
Once you hit "Send", Bug Shooting will connect to your DoneDone account. You'll get a popup where you can select the project, priority level, and person to assign this issue to. Do note that only projects that have the API enabled will be selectable. Account admins can go to the project settings page in DoneDone and click the "Enable API Access" button.



Once you've submitted your issue, you'll get redirected to the issue in DoneDone.

Special thanks to Alexej at Bug Shooting for so quickly adding DoneDone support!

Labels: DoneDone

Now that everyone's tweeting, do we have time or even care about that really long form of published content called the blog? You know, that web thing that was so hot a few years ago because it replaced, in popularity, the really really long form of published content known as newspapers and books?

I think blogs are more important in business today than ever. Here's two examples:

Balsamiq (http://www.balsamiq.com/blog)
I won't ever use Balsamiq Mockups. I really don't like mocking things up at that high a level. I'd prefer to design the interface (fonts, margins, padding) as I'm coding. Mockups is an avoidable extra layer in my process.

But, for some reason, I'm rooting for the product. I like reading Peldi's blog when he tells me what he's doing to make the app better. When he talks about the minutae of changes that don't and won't ever effect me, I read it. When he tells me exactly how much money he's made (to the dollar) and how many products he's sold (to the unit), it captivates me. I'm completely interested in what he's selling and I won't ever buy it.

Wine Library (http://www.winelibrarytv.com)
Gary Vaynerchuk is rootable. At this point, with congratulations to Gary, there's nothing more to root for - he's got the 7-figure book deal and the press to ride for the next ten years. I've sat through a few of his wine shows and I find them interesting. Every red wine I've tasted and smelled tastes and smells just about the same. I don't smell burnt tire or Pez candy...ever. It smells like red wine. But, he talks in excrutiating detail about wine and business.

Why I root for them
In both cases, I'm attracted to their businesses because they are infinitely personal and infinitely detailed when they blog about their product. Blogging is still so important in this new age of tweets. We've become so enamored by the real-time-ness of a 10-word-tweet that we've forgotten what an impression a really personal blog post can make. It's hard to spend those hours writing or recording a blog post when we can just tweet something quick.


Here's the problem: Too many businesses are using Twitter to feign being personal. It's too easy to say you're done talking. I cannot apologize to a customer or explain why I don't agree or sympathize with a certain kind of genuineness in 140 characters or less. I can probably write 20 tweets @ 20 people I've never met and pitch my product. But, while it's real-time and direct, it's completely impersonal.


Blogs still hold the key to the business-customer relationship.
I spent nearly an entire work day trying to explain why we changed our pricing plan for DoneDone. And I hope when people read it, they appreciated how much we thought through and cared about what we were doing.

Then, I spent about 18 seconds thinking through this tweet....

"We've upgraded all instances of DoneDone and released a cheaper pricing plan! Read all about it here: http://bit.ly/12QhZr"

....brilliant! Dammit Ka Wai, how do you come up with that stuff?

I'm not saying don't use Twitter for your business. We do for both X2O and DoneDone. It helps us spread the word but not the message. It cannot be (and isn't) the focal point of how we relate to our customers. Email them directly with a well-written, thoughful response. Spend a few hours crafting a blog post or video about your business. I typically edit my blog posts a half dozen times after I post to make it read better. When I tweet, I couldn't care less (and they won't let me).

Being genuine and personal takes time. It's something you can still do with a blog.

(Oh btw, if you want to follow us, @getdonedone and @x2oframework, we'd love it!)