Remember IRC?

Email is evil. This isn't news. It's an information black hole that sucks away at your company's IP. The perfect organization doesn't use email at all. Kind of like the mob.
But seriously, email stinks out loud. So what can we use instead?


I've recently been struggling with this issue. Gigantt uses Google Apps for emails, calendars, some documents, and, well... that's about it. Okay, SSO as well. Google is pretty dominant as a single-sign-on provider. But I digress. I was certain Google had at least some reasonable solution for internal company discussions. Probably just have to search the Google Apps Marketplace and choose one. 


Nope.


Turns out the offerings are slim. Why is nobody doing Exchange "public folders" for Google Apps? This is begging to be implemented.


So we gave Yammer a shot. Yammer is nice. Hopefully it'll stay nice even after being acquired. Come to think of it, Microsoft might as well turn that into it's public folders 2.0. But right now it's just not that useful for discussion boards. It's more about being able to like the fact that somebody brought cake to work or released a stable version of something. It certainly has it's place, but it's not where you want to keep your precious, precious corporate discussions.


What about Google Groups? Google Groups just doesn't work well with Google Apps. Don't ask me why. I sure wish it did. But I could not for the life of me create a new Google Group with my Apps account. And besides it's really just a different way of labeling email, when you think about it.


So strike two.


Then I stumbled upon grove.io. They'll host a private IRC server for you. Real easy to get started. In all honesty it's almost just as easy to host your own server on some cloud machine, where you'll have a bit more control over things, but who has time? 

So - IRC. Remember? Gosh, it's been years. But apparently some isolated internet tribes have been using this ancient tool all this time. We gave it a try. And you know what, it's pretty f-ing great. 

Our organization is distributed. That's another way of saying we're not paying for offices. Or, more accurately, our employees are the ones paying for office space by working from home. The challenge when working from home is to walk the fine line between feeling close to each other, like you could knock on someone's office door and pop-in for a question, and still each having his own space and the ability to get work done. Also, I find it critically important to be able to listen to WHAM occasionally at high volume. Working from home accommodates this need. 


But email is horrible and way too offline/async. Chat is evanescent, ephemeral, fleeting and various other synonyms. It's just as bad at sucking away information as email. Once the chatters quit you basically have no idea what the chat they were chatting about. And it's pretty low-tech, too. Chat has like two features - send a message and set your status. That's it.


IRC, on the other hand, is a dream. You've got channels. Channels are by and large public (within the organization). You can search them. You can archive them. Everything is preserved. And you've got commands. Delicious, delicious commands. It's really programmable, configurable, hackable chat. You can make it behave a certain way when you're away, you can tell it which keywords should draw your attention with an audio "bing!" and which can be quietly ignored. You can mash it together with your source control to get commit notifications. Whatever. The point is it's a platform. But above all it just feels cool to be able to hang out in an old-school, ASCII environment. 


I realize I sound like a total newb lamer extolling all these virtues that many people have been taking advantage continuously since I last used IRC like 17 years ago, but I can't help it - I'm excited. IRC is just fun. Nostalgia is part of it, I'll admit. But I'm really optimistic about adopting this tool as a core piece of corporate gear. The baseline is a solid, tested, simple way to discuss things in real time. That, by itself, is quite a lot. But on top of it you can tweak and hack the hell out of it with your own bots and your own inner jokes and rules. I really feel I've been missing out for quite a few years. 


So go give grove.io a try. You might end up installing your own IRC server, but that first quick taste of that familiar IRC flavor is just a sign-up away, so take a shortcut and try it out (free 30 days trial).

/away playing Song Pop

Team Invites, Time Estimates and More

We're very excited to share with you three pieces of big news today.

1. Registration is open

If you haven't already you can sign up for Gigantt right now. No more waiting list. 

2. Invite people to join you

Starting from today you can freely add team members and resources to your organization.

You can assign tasks to any resource. A resource that's really a coworker can also be invited as a collaborator. This person will then be able to edit your plan alongside you.

Read more about adding people and resources.

3. Flexible time estimates

You're no longer forced to choose an estimate from a fixed set. Now you can just type your own estimate.

Go sign up.

What's New in Gigantt

We've focused on just one thing in this release - usability. After getting tons of feedback from new users we decided to put new feature development on hold and make the existing ones easier to use.

All New Design

The new look is much cleaner and more compact:

We've gotten rid of a few buttons that users didn't really need. Now there's tons of space for actually viewing your plan - space that used to be occupied by various panels and toolbars. And of course shiny new buttons for everything.

"The Bubble"

Gigantt is all about fast keyboard shortcuts for rapid editing, but over time we've really been neglecting the mouse, and it turned out that quite a few users aren't big fans of keyboard shortcuts. So we've really streamlined the mouse. Now a simple drag operation can both create tasks and draw arrows between them.

Here's how it looks in action:

Mac Support

Gigantt is now officially supported on the Mac and is tested on both Safari and Chrome.

There isn't much difference between the PC and Mac versions, except for the keyboard shortcuts. If you're a mac user you can print out the keyboard cheat sheet.

Tons of Small Improvements

Lots of stuff that you've been asking for and we've finally implemented. Here's a very partial list:

• You can change the estimate of several tasks at once.
• New keyboard shortcuts
• R: Assign to a new resource.
• T: Change the time estimate.
• N: Add a note to the task.
• Double-click outside any task (on the white space) to zoom-out.
• Double-click on an arrow to "split" it (insert an intermediate task).

If you haven't already, go sign up.

Cracking a Safe with UX

Your mission, should you choose to accept it, is to figure out the four-digit code of this safe with just one try:

With only four keys being schmutzed we know whoever punches in the code touches only 2, 5, 8 and probably 9. With four options we have just 256 codes to try.
However, since it's pretty obvious that digits aren't repeated in the code (otherwise we would not see as many as four dirty buttons), the number of combinations drops to just 24. 

But can we use our UX expertise to crack this code in less than 24 tries (at most)?

First, the rules should be made clear. In this keypad you have to first press the key button, then the four-digit code, and then the key button again. Now let's have a crack at it.

Which digit is first? That's actually really easy to guess using Fitts' law.

Fitts' law is about ergonomics - how people use machines. Specifically it's about pointing. What it says sounds almost trivial: the bigger and closer the target, the easier it is for us to point to it accurately. So if a button is bigger, it's easier for us to point to it. The same goes if a button is closer to our finger - the farther it is, the less accurate we are at pointing to it.

We can deduce from Fitts' law that the larger the dirt circle around a button, the more the finger had to travel to get to it. The button with the biggest circle of dirt is clearly 2. This means the finger that presses 2 travels the farthest distance from its initial location. Because the distance is so great the finger usually misses it quite a lot, hence the large dirt circle. So its likely that 2 is the first button pressed. The finger has to start from the key button, then travel the greatest distance to 2, and then continue to some other key. 

Great. 

Code thus far: 2 _ _ _

We're down to 6 possible combinations. But can we narrow it down even more?

Which button is next? If 8 were the second digit, followed by 9 or 5, we would expect to see a bigger dirt circle around 8 than around 5, right? Because the distance from 2 to 8 is greater than from 5 or 9 to 8. Clearly, then, the next key is 5. And now there are just two left.

Code thus far: 2 5 _ _

So which is the 3rd button: 9 or 8? 9 has the smallest dirt circle around it, so it stands to reason that the finger travels a very short distance in order to get to it. This seems to suggest that we need to press 8 and then 9. But if that's the case then why is the circle of dirt around 8 bigger than around 9? Both are pressed after adjacent buttons, after all, so shouldn't we expect them to have the same sized dirt?

Time to think about ergonomics some more. Since the key pad is mounted on a door we need to raise our hand in order to tap on it. Now it's a bit easier to move your finger sideways in this position than up and down. Why? In order to move your finger vertically you have to move your elbow, which requires your shoulder muscles to go to work. Those are some big joints. In contrast, move between horizontally adjacent buttons your elbow can almost stay in place, with only the rest of your arm moving. Try it. I'll wait for you.

See? So vertical moves are harder, and therefor we can expect buttons that are pressed after horizontally adjacent neighbors to have smaller dirt circles than those pressed after vertically adjacent neighbors.

So it's 8 and then 9.

Code: 2 5 8 9

Just one attempt.

Conclusion: Fitts' law works all over the place, not just in computer GUI.

Also: clean your damned keypads.

We used Fitts' law when we designed our new Bubble Menu interface:

The buttons inside the bubble are relatively big and since the bubble opens up wherever you start dragging from the buttons are always close to the mouse's cursor. Close and equidistant. 

So go sign up for Gigantt. Active beta users will enjoy a lifetime discount when Gigantt leaves the beta phase.

Feature Sneak Peak - "The Bubble"

We don't normally do this, but "the bubble" turned out so cool we wanted to share it with everybody even before it reaches production.

Have a look.

Why geniuses are overrated in software engineering. Knowing that > knowing how.

Knowledge is underrated in software engineering. We value problem solving skills and quick learning a bit too much by comparison. Let me explain what I mean.

Being smart means you can pick up any programming language in no time. You can get to know new technologies quickly and do a good job at using them. But that's not enough. In fact, since learning how to do stuff is so easy these days you don't really get to accumulate a huge advantage over others in this way. Everybody knows how to google, and these days googling takes you 90% of the way to learning anything you need to learn. Sure, smart people learn faster. But how much faster?

Let's see.

One constant (sort of) is the time is takes to read up on something. Even a genius has to actually RTFM, and if the manual has a few hundred pages then it's going to take a bunch of hours to read it. No getting around that. This genius would probably understand it all immediately and realize the implications and possibilities of this new knowledge in a deeper way, while us ordinary folks would struggle a bit. True. Maybe we would need to find a better written text - something that's easier to understand. Maybe we need a few more examples. The bottom line, though, is that it's going to take a non-genius three days instead of one day to reach roughly the same level of knowledge. 3x as fast. That's about it.

Put another way, geniuses are real good at learning how, and that makes them more effective. But the reality of software engineering is that we don't spend the entire day every day learning how to do new things. Most of our time is spent applying this knowledge, you know - actually creating software. So being 3x as fast at learning new stuff probably means you get the job done 15% faster over all. (Why 15%? Whatever, the point is it optimizes a smaller portion of the total work-time as an engineer).

So how come we value IQ so much when we evaluate software engineers? Most of us aren't doing rocket science. There's a minimal brain span you need to have so you don't make stupid mistakes and you can actually understand what you're doing. But beyond that it seems that all this brain isn't really making a difference.

Here's the reason. I think.

What googling doesn't really help you with is knowing that there's something you need to know. It boils down to search being a function that takes a parameter - you search for something. If you have no idea that something even exists then you can't really search for it. To learn that something is possible you need to engage in active exploratory learning. You need to be curious about stuff, talk to people, go outside your narrow field of work and generally fill you brain with facts about the possibility and existence of things.

In short, knowledge, not just know-how, is key. And the kicker is that knowing about something isn't that hard. Don't need to be a genius to remember that you read about somebody who did something. Then you just need to look it up and apply it. This sort of superficial, broad knowledge makes a ton more difference than know-how. Why? Because so much time is wasted trying to solve problems that have already been solved. Being a genius can really be a hindrance to productivity in this sense. Brainiacs often underestimate the difficulty of problems, or just seek out challenges because they're getting bored. This is costly. You don't want a genius reinventing new kind of scalable database for your terabytes of data. You want somebody who's heard of Cassandra or CouchBase and follows the High Scalability Blog. That's the guy you want.

Bottom line, I would value someone who's heard about every new technology or technique much more than someone who would be able to utilize it 15% more efficiently. When the playing field for learning how is pretty much flat, thanks to Google, we can differentiate ourselves and compete by accumulating knowledge. Sounds a bit trivial when put this way, but  really this sort of broad knowledge is just not something that hiring managers are focusing on these days. The mantra seems to be that smart people could learn anything, so why bother testing their knowledge - that would be like evaluating a new car model based on where this car has been driven. Kind of pointless, right? 

No. It's not like that. It's not just about how fast you can learn - it's more about how much you have learned. It's not just about how deep your knowledge - it's more about how wide it is.

Speeeeeeed!

Today's release of Gigantt is all about performance. Navigating inside plans, zooming in and out - it's all real snappy now. Try it out: http://www.gigantt.com

Flash Optimization

So what did we actually do? Programmers, read on. Humans, feel free to skip the rest of this post and move straight on to trying it out.

Our recent releases have been focused on adding functionality and the whole thing just got very heavy and bloated. Memory was leaking because apparently Adobe Flex isn't really meant for creating thousands of recursive controls over and over again. The worst part was the latency - if you've navigated into a task that contained many sub-tasks it would take them a while to load which was very frustrating and it slowed you down. That dog won't hunt. We learned that one of the slowest things you can do in Flex is to add and remove elements from the display list. So now we don't. We recycle and hide unused elements instead of adding/removing them. That also took care of the memory leaks, since apparently we cannot rely on Flex to properly dispose of unused objects (even [sigh] when the Flex Profiler itself shows no paths to those objects from the GC root). 

Rendering tiny zoomed-out sub-tasks was rewritten in lower-level Flash graphics (as a C++ developer it sounds odd to me - "low level Flash"... but I'm getting used to it). This approach worked great when we implemented Team View so we adopted in the other views as well.

So how noticeable is the difference? Quite noticeable. We measured how long it takes to drill down from the top of a large plan to the bottom-most "leaf" task and it took about one third of the time. So roughly 3x as fast. But that's mainly because the built-in animation simply takes its time (about 400ms) - without it navigation just seems jumpy and weird. When we profiled just rendering time we saw a 10x improvement. 

Hopefully you'll notice this too.