Sprout. We Are Mammoth's technology, software, and business blog.

DoneDone Tip: Defect or Enhancement?

2010-08-30T08:00:00.002-05:00

During our client testing phases, we get a good percentage of issues assigned to us which really aren't defects or problems at all. They're requests to have things built differently. It's inevitable that certain features of a product will be met with varying degrees of satisfaction, so it's important as a development team (in any industry) to stand your ground and help your stakeholder team distinguish the difference between "this is built wrong" and "this is built right, but I think it should ...".

One way DoneDone can help is with tags:

Make sure testers tag all new issues as "defects" or "enhancements" (http://screencast.com/t/Y2M0MmEw).
Next, set up (and save) custom searches for each tag to help prioritize tasks (http://screencast.com/t/NTViZGUzZ).
Finally, when an issue is assigned to a developer, but not tagged correctly, the dev can edit the tags themselves to get them in the right queue (http://screencast.com/t/ZDVlNmQ1M2U).
As for the conversation between the developer and the tester to point out the difference? Sometimes you need a guy like this to help with the smooth talk.

Have a good week, DoneDone'rs

DoneDone Tip: Linking between issues

2010-09-06T08:52:00.001-05:00

To link between issues in a DoneDone project, use the pound sign (#) followed by your issue number, as in "#132". DoneDone will automatically check if the issue exists, then create a hyperlink for you.

The syntax: http://screencast.com/t/YzVjNDNlNjIt
Next, the results: http://screencast.com/t/OTEzNGVkZj

Have a productive week DoneDone'rs.

We Are Mammoth is 4 years old. This is why.

2010-09-02T12:25:00.003-05:00

Yesterday, September 1st 2010, We Are Mammoth turned 4 years old. Thanks. Thank you very much.

However, we're still not driving Ferraris. We're also not funding private sector space programs. Nor are we so culturally relevant that we're strong-armed by governments to allow access to decrypted customer data. We are, however, in possession of something I'd attest to being harder to attain, and harder yet to keep possession of. The ability to design.

We first set out to design a better work environment for ourselves as programmers. Amongst other things, it required that we design better software to deal with ever changing client requirements. We were so proud of our process that we designed a better tool for organizing a development team. And yes, we built several fantastic websites along the way.

It sounds simple. But lacking the true power to design is the biggest hurdle working "somewhere else". You get lost in the echoes. Our greatest opportunities? The power to design technical harmony within our team. The modesty to design transparency with our clients & customers. It's yielded real quality in our transactions with one another. And quality makes everyone feel good.

So what's the next four years have in store for us?

More of the same, I'm thinking. Our mission, above all, is to continue to design. Design tools and work flows which encourage better collaboration between people. Design a straight line, not a jagged one .... it's shorter. We're a software and web development company, yes. But who cares what the end of the voyage brings if the only road to get there was paved with hot coals.

Long live We Are Mammoth. Long live the human.

Road traffic management for your life.

2010-08-31T10:57:00.000-05:00

An interesting article this week about the ways researchers are trying to solve the ever growing problem of traffic congestion. The brutal truth? So long as the economy and population expand, so will congestion despite new roads, technologies and controls.

Commuters have altered their behavior to deal with the problem. Some get up early and leave early. Some, the other way around. So, what happens when new lanes or roads are installed to deal with congestion? All these people give up the altered times and join the herd again, quickly filling the excess capacity. More money, more cars. More roads, more traffic. China was the focus of media attention over the past couple of weeks for this problem precisely.

The same thing happens in business. Add employees to meet demand. Then get too busy again. Rinse, repeat. A never ending cycle, until there's a recession. Also at home. Got too much stuff, get a bigger house. Move in, get more stuff. Funny enough though, this week also drew light to the "end of the mcmansion era" - smaller houses are being built to match changing consumer values.

What'd happen if we just maintained what we had, and kept those behaviors altered, like, forever? Fewer roads, but better ones? Smaller houses, but smarter ones? Fewer businesses bent on growth, and more focused on quality? My hunch is the fear that China, India and Brazil will steal our milk money is simply too great to find out. Sip, sip. Grunt, grunt.

Get Tusks: We need a Front-end developer (XHTML/CSS/JS)

2010-08-18T08:00:00.014-05:00

Well, look at that. We Are Mammoth needs some help. It's true.

A couple of us are database and backend experts (SQL, C#, .NET MVC, LINQ, to be specific). A couple of us are front-end integrators (Flex/Flash Actionscripters who can also be dangerous in .NET). We are a lean, well-oiled machine. All true.

But, we're missing a big component. We need a true HTML/CSS/JavaScript lover who also blends into the wonderful world of .NET programming.

So, we're hoping:

You love Javascript. More specifically, you love jQuery. You think jQuery selectors are God's gift to HTML.
You have a compulsion for clean, skinny, simple-as-possible-but-no-simpler code.
You've solved problems like "How do we implement site-wide modal popups, make it still work with Javascript turned off, and also be SEO-friendly?"
You have a clear opinion on how Javascript and HTML should be written and ensure that standard is upheld.
You work as well individually as you do in a small, collaborative team.
You can take existing, HTML-Strict compliant templates and integrate them to server-side code and Javascript.
You can maintain an HTML code-base and CSS cleanly. When there's a big feature addition down-the-road, you've got a clear-minded plan of attack on how to add it without the need for extra-strength duct tape.
You absolutely despise IE6, but you know the usual workarounds.
You spend 80% of your time on the front-end, but occasionally dip into server-side code (C#, .NET) to tweak and modify code as needed.
You love problem-solving. For instance, you can connect all 9 dots in this picture with just 4 straight lines, without lifting your pen: http://bit.ly/zn8mh

These are great additional bonuses:

You have experience with Flash and Flex, and some animation skills to-boot. If javascript is the new actionscript, it'd be great if you knew all the usability pitfalls.
You are articulate and love to write (words not just code).
When you speak, people feel warm and fuzzy inside

Have ya got it? Really? Then, if you're NOT a staffing service, please send a nice introduction of yourself along with your resume to Let.Me.In[at]wearemammoth[dot]com

This is a contract (and possibly to hire) position, and we'd prefer you be on site.

Simple design ideas: A better bill presenter

2010-08-25T11:13:00.002-05:00

I have an idea for a restaurant bill presenter design that would save me minutes a year.

DoneDone'rs : Critical, 13% of the time

2010-08-20T15:45:00.002-05:00

Here's a historical breakdown of how issue priority labels have been used since the beginning of time (2009):

24% low / 31% medium / 32% high / 13% critical

Have a great weekend DoneDone'rs,

- The DoneDone Team

DoneDone Tip: Good Issue Ettiquette

2010-08-16T08:00:00.005-05:00

Even though DoneDone has an issue status called "Need more information", it'd be ideal if it was never used in 90% of all cases. Help the developer get you a fix by providing the quick facts you know they need.

Provide a screenshot and/or link to the page where the issue is happening
Which browser, browser version, and operating system did the issue occur in?
Detail the prior steps and clicks you took to recreate the bug.
Were you logged in as a test user when the bug occurred? What were the credentials of that user?
Finally, only log one problem per issue. Here's why: http://codebeef.com/one-issue-per-ticket

If you're tired of typing "IE 6 on PC, duh" then create a Tag for that browser/OS combination.

The little bit of time it takes to provide this info will go a long way towards getting everyone home in time for dinner. Let there be pizza.

DoneDone Tip: Basecamp or DoneDone?

2010-08-23T13:11:00.002-05:00

A few customers have asked when the best time to start using DoneDone is during a project, and how it works best alongside Basecamp.

The best example I can think of is how we use it here at We Are Mammoth. Afterall, we built DoneDone for our team originally, then thought the rest of the world might be interested in a simpler way to get through the most stressful phase of a project.

Here at We Are Mammoth, Basecamp is used from day one of a project and kept around for as long as that site or application exists. We use it whenever group collaboration is necessary: Production-related messaging, sharing files, managing development calendars, server information, etc. It eliminates the bottlenecking of information, and brings clarity to client projects where emails, meetings and phone calls fall well short.

DoneDone on the other hand gets folded in about two-thirds of the way through a project, when testing begins. At this point, the team needs an explicit way of telling someone 'something' needs fixing, and an effective way of managing that something until it's fixed. ToDo items, excel sheets, and email do nothing more than keep inventory of unfinished 'somethings'. DoneDone helps the cause by cutting down on the herd mentality, making responsibilities more clear to each individual.

If you're using Basecamp ToDo's to manage your development team during testing instead of a real issue tracker, there's a good chance at least one programmer would like to drag you along behind a herd of wild horses.

If ya have any more questions about how DoneDone might help you out, please leave a comment or email us at admin[at]mydonedone.com.

Have a good week everyone.

- The DoneDone team

On creating something from nothing

2010-08-24T09:47:00.001-05:00

"...with a respectable body of work under my belt, I finally understood that the ability to imagine and then build where nothing had existed before was an ability worth valuing"

- Eric Smith, from his nytimes article The Healing Power of Construction Work

DoneDone's Weekend Warriors

2010-08-18T08:00:00.011-05:00

Correction: 'Tim' correctly pointed out that the start dates for both sets of points actually are different weekdays. I stand corrected. And slightly flushed. So, read on if you'd like to live in my dream world. If not, might I suggest reading about my kinda calendar.

Original post:

Heres a month-over-month snapshot of DoneDone usage. The blue line has dips on the weekend. The green line (representing the previous month's activity) saw greater usage during the weekends.

Weekend warriors, we salute you.

Refactoring in jQuery: ID-happiness to code happiness

2010-08-16T15:32:00.004-05:00

Most jQuery advocates will agree that the single most powerful component of jQuery is its ability to query elements from the DOM. Power means freedom. It means you can do how you please. But, with anything that powerful, there’s a flipside to the story. It’s too easy to write unwieldy jQuery code without some basic constraints. That’s where we need to think of some simple conventions to make sure we are painting pretty pictures with our code.

ID-happy

Whenever I need to do something substantial in jQuery, I usually start by getting too "ID-happy." The thought-process is simple and lazy: I want to make this button change this element when you click it. Simple. Let’s give it a unique ID and then write a quick click handler for it!

$('#my_unique_button_28').click(function() {
/*Make something happen!
*/}

I can write this kind of code quickly, throw it at the end of my quickly expanding $(document).ready()function and move on. I can get something running and working on the order of minutes.

But, this is where the freedom can hurt. Do this enough and you’re left with a host of event handlers applied to elements without giving much thought to what or who or why this page behaves the way it does. In the end, you’re only looking at the trees and not the forest. You end up with what amounts to a laundry list of "things-just-happening" without seeing the greater connection.

$('#my_unique_button_28').click(function() { doThingA(); }
$('#my_unique_button_29').click(function() { doThingB(); }
$('li a').click(function() { doThingA(); doThingC(); }
$(".some_random_class").click(function() { doThingD(); }

But, converting this chaotic mess into something more elegant is also very easy. That’s what really makes jQuery so powerful. I can take a "dust-settling" approach after I get things to work. That’s where you need to apply your own mental framework on top of what jQuery gives you.

IDs vs. Classes

Because I tend to be ID-happy, my jQuery code ends up being a laundry list of ID-specific events. I’ll notice that a ton of almost-the-same functional code lives in these various event handlers, and, like I’d do in any programming language, I find an opportunity to refactor. Take the common bits out into its own method, pass the differences in as parameters, and shrink your code accordingly.

But, I’m still left with a bunch of events on too many IDs doing the same things. That’s where I can take advantage of the polymorphic nature of jQuery - instead of tying similar functions to IDs, I can move them to classes.

When you get in the habit of doing this, the forest starts to come into view. You’ll find that many elements on your page have some common set of behaviors. This is functionality that should be represented by a class rather than an ID. You’ll also find lots of behavior that only applies to one specific element - that’s functionality that should be represented by an ID, rather than a class.

In jQuery, the class attribute should represent an inherited piece of behavior whereas the ID attribute should represent unique behavior or a unique identifier.

In other words, I find where my ID-happiness is really just ID-abuse, and where it makes sense. It's then a fairly clean exercise to add classes to the appropriate elements and apply the right event handlers to the right jQuery selectors.

That’s what makes jQuery so elegant - any two elements can share a similar set of behavior and have their own unique set of behavior. The polymorphic nature of jQuery selectors works perfectly with the medium.

A quick example

Let me show you a quick example. I'll focus solely on the thought-process that led me to the final code, rather than the code itself. In the end, this is a fairly pedestrian example but the process of getting to the forest is what I find valuable.

I recently built a simple panel rotator in jQuery:

The rotator has a series of X-number of divs with a chronologically-ordered naming convention for each div’s ID (e.g. "div_0", "div_1", "div_2", "div_3", and so forth). Here, the default div is just a picture of a divi-divi tree.*

* - I swear to you, it is only now as I write this that I realize the dual irony of (a) showing a tree after using the "forest-through-the-trees" cliché, and (b) showing a divi-divi tree.

Back to business. I set the CSS display:none for all but the one that should display (I set that to "display:block"). The navigation, where the meat of the jQuery work lives, is at the bottom. There’s a "previous" and "next" arrow along with a line of X-number of circular buttons. Clicking on any of the arrows or buttons swaps out the divs while also changing the selected state of the corresponding circular button.

I start as I normally do. I get ID-happy. Let’s start with the "next" arrow.

Step 1: Apply behavior to the "Next" arrow

I apply an ID to the "next" arrow ("next_btn") and write a click handler to swap the current div with the next div. In so doing, I end up adding a hidden input field that tracks the current div number.

When a person clicks the arrow, I increment the current div number, check that it exists in the DOM, and, if it does, I hide the current div and show the new div. Then, I set the hidden input field's value to that new number. Applying the same ID naming convention to the circular buttons, I can show the selected state of the appropriate buttons as well.

Step 2: Apply behavior to the "Previous" arrow

I apply the same process to the "previous" arrow. It gets an ID ("prev_btn") and a click handler. Knowing I’m doing mainly the same thing, I just copy-and-paste the code for the next arrow over as a start. I quickly see the only real difference is that the div I want to show is found by decrementing the hidden input value.

So, a quick refactor pulls the logic out into its own function (toggleDivs(show)). The function takes in the one differentiator - which parameter to show.

Step 3: Apply behavior to the circular buttons

With the circular buttons, it’s immediately obvious that they all share the same functionality, except that each one represents a different div in the rotating stack. In fact, they apply the exact same behavior to the panels as with the previous and next arrows. The difference is, each specific button shows its selected state when its corresponding div is displayed.

The dust-settles and the picture gets clear

Once we get the code to a working, despite ugly, state, we get to work on refactoring and taking advantage of the loose, polymorphic nature of jQuery selectors.

Taking a closer look, we’ve separated unique identification (ID) from common behavior (class). Take a look again:

All seven buttons have common behavior - they toggle the div stack. But each button individually reacts to the behavior differently. The previous and next arrows aren’t affected at all, while the circular buttons show their selected state if their corresponding div is displayed.

There’s a bit of adjustment to make to the prior statement, though. While all seven buttons have the same common behavior, they each toggle a different div. In my final code, I store the ID of that div in the rel attribute (There are probably more elegant, correct ways of doing this, but it suffices my needs right now). For the circular buttons, the rel value maps directly to their own IDs (e.g. Circle button 2 toggles to div_2 when clicked, and so forth). For the previous and next buttons, their rel values change each time any button is clicked.

I can then pull apart what ought to be represented as a class from what ought to be represented as an ID.

Behavior that should be represented by a class

So, what behavior should use classes? There are three I came up with:

All seven buttons share a common behavior - they all toggle the div stack. In my code, I create a toggle class and write a specific event handler for all toggle classes.
All five of the circular buttons share a common behavior - they may be affected whenever the div stack changes. I create a circle class. Then, in my click event for the toggle class, I can use $('.circle')to first set all circle elements to their unselected state before finding the specific circle that needs to be selected.
And naturally, all five of the circular buttons share another common trait - they may be in a selected state. I create a selected class and, in my click event for the toggle class, I can add the selected class to the appropriate circle.

Because I can apply multiple classes to any DOM element, separating behavior into specific classes makes the HTML changes really easy and semantically sensible.

Each circular button should have a class of both toggle and circle.
The "previous" and "next" buttons should have a class of toggle.
Whenever the div stack changes (because an element with a class of toggle is clicked), we should add the selected class to the relevant circular button, using addClass().

Behavior that should be represented by an ID

But each button also needs its own ID. We use the ID of the circular buttons so that jQuery can select the exact button to display as selected.

We also will use the ID of the previous and next buttons so that jQuery can modify their rel values after any button is clicked.

So there we have it. I start off ID-happy, writing functionality without really caring about elegance. Once the dust settles, I decide what behaviors fall under a class construct (because they are used by more than one element) and what behavior falls under an ID construct (because they represent something specific to just one unique element). I then just have to modify the ID and class attributes of the participating DOM elements. The refactoring is quick and easy.

As I mentioned earlier, I purposely didn't get into the code in great detail here. Instead, download this zip and run it locally. Take a look at index.html for the details, and notice how the IDs and classes are employed after the refactoring.

What my browser tab bar looks like 90% of the time.

2010-08-12T09:00:00.002-05:00

My 1-2-3 punch.

DoneDone'rs : Total issues closed by guys named Jason: 914

2010-08-13T14:59:00.001-05:00

That's an 81% hit rate, guys. Watch your backs, and stay out of the woods.

-the DoneDone team

Jared Spool's Facilitator

2010-08-13T09:00:00.000-05:00

The facilitator is a momentary leader. They step in and take over, with everyone's support and respect, to push through the group's next activity. Team members often take turns facilitating, spreading the effort around, giving everyone a chance to guide the team for that moment.

- Jared Spool in "Five Indispensable Skills for UX Mastery"

Gmail's Pixel Pruning

2010-08-11T09:56:00.001-05:00

An update from Gmail today ...

Relevant because it points to where the change has occurred. Friendly because they take the time to craft a pleasant message about it.

DoneDone Tip: Critical is the new Low

2010-08-09T07:00:00.001-05:00

Some testers tend to use an issue's Priority label to negotiate their way to the top of a developers list. More than likely, it has the opposite effect. DoneDone has an alert to help these testers give a little extra thought to the Priority they're assigning to their issues.

When a tester consistently labels issues with the same Priority, it gives them a quick prompt asking them if they're aware that xx% of their issues are of the same Priority. Hmmmm, could be, but I'll be they're not!

DoneDone'rs : 38,783 issues whacked.

2010-08-06T15:10:00.001-05:00

As of 3pm CST today 38,783 issues have been closed out. Have a good weekend, warriors.

A quote from Pascal.

2010-08-03T21:38:00.001-05:00

“I wrote you a long letter because I didn’t have time to make it shorter.” - Pascal

Noticed in a good post over at A List Apart

DoneDone Tip: Issue gatekeepers

2010-07-19T08:00:00.004-05:00

DoneDone Tip: At the onset of the testing phase, it's helpful to have your client assign issues to a single, designated person on the development team. This gatekeeper's job is to quickly route issues to the person best-fit to tackle the problem. Longer term, the client will get familiar with individual team members and their responsibilities. Doing this at the start though helps smooth the transition into testing and keeps a single member on your team aware of everything that's going on.

DoneDone Tip: Release Builds

2010-08-02T08:00:00.002-05:00

Using the “Release Builds” feature is a great way to notify your extended team that you’ve wrapped up work for the day. It sends emails to the entire team letting them know that their specific issues are ready for re-test. If you find yourself overwhelmed with new issues, not-fixed issues, emails, and constant banter about all the above, your team may benefit from using Release Builds. It creates a more cadenced fix/test cycle, putting everyone on a more predictable schedule.

How do you use 'em? Click "project settings" from your project's dashboard, scroll down, and click "enable release builds".

Read a bit more at: http://getdonedone.com/faq.aspx#projects_3

DoneDone users: 41% done as of 7/30

2010-07-30T17:26:00.001-05:00

As of Friday 7/30 at 3pm CT, the DoneDone community was wrapping up the week with 41% of it's issues closed out. Alas, next week is another chance to battle the other 59%

Want to see your own status report? Click the "Status report" link from your project's dashboard for a quick overview of where you're all at.

Have a great weekend, everyone.

-The DoneDone team

DoneDone users: 48% done as of 7/23

2010-07-26T11:07:00.001-05:00

As of Friday 7/23 at 3pm CT, the DoneDone community was wrapping up the week with 48% of it's issues closed out. Hope everyone's getting a good start on that other 52%. Keep on gettin' Done'r.

Want to see your own status report? Click the "Status report" link from your project's dashboard for a quick overview of where you're all at.

-The DoneDone team

DoneDone Tip: Screenshot tools

2010-07-26T08:00:00.004-05:00

Two indispensable and free screenshot tools are Jing and BugShooter. Jing uploads your screenshot to the web and copies the link to it to your clipboard so you can just share a URL in your DoneDone issue. Bugshooter integrates with DoneDone, so all you do is point, shoot, and tell it which issue to upload it to.

No more saving to your desktop, or using photoshop, or plopping into powerpoint. Bam.

Unexpected User Experiences: Help That Doesn’t Hurt

2010-07-23T14:44:00.009-05:00

Excessive UI makes computing a drag. I am emptying the trash, and yes, I'm certain.

But sometimes UI help is right on time.

I draw stuff. Sometimes lots of stuff.

I like Gliffy. I use it for UI sketches. I use Balsmiq too. They're both handy.

When I'm sketching with either tool I jump right to what matters - the interface itself. As you would expect, each time you draw something new, it’s placed in front of everything else.

When I'm ready to share my idea I create a window behind my UI sketch. I usually don’t draw the window first because I’m not sure how wide or tall it should be. And sometimes I just forget.

I was delighted by Gliffy because it automatically sends newly created window objects to the back. Controls in context, baby! The window object is treated differently from all other objects because it has a unique function. It's function is (usually) to sit behind everything else.

Is it the right choice every time? Nah. But it saves me a click 95% of the time and I appreciate that. If I need the window in front for some reason I can always bring it forward.

Good Catch, Gmail.

I’ve been That Guy who send emails with attachments who forgets to actually attach the file. Thankfully, Gmail does it’s best to save me.

If I’ve typed “I have attached” in the message but haven’t attached a file, I get a reprieve.

If you’re in the business of attaching things other than email attachments, like human arms, maybe it’s really annoying. I wouldn’t know because I have never seen this message unless I needed it and I’ve always been thankful when it pops up.

Jump in the comments and tell me about unexpected UI behavior, good or bad.