We’ve used a lot of project management (PM) apps over the years, and one thing has consistently been true. They’re slow.

All of those things that they do to make them user friendly in the beginning eventually get in the way of you doing your work. It’s as if they don’t trust us to have information density on a screen. From the homepage of the most popular web based PM app on the market you’re:

• 5 screens away from creating a todo.
• 3 screens away from uploading a file.
• 3 screens away from posting a message.
• 5 form fields away from saying “Yeah, -great idea!”

If any of this strikes you as weird, we think we’ll have something interesting to show you soon.

We’ll be inviting a few select people to our private beta of Staction in the next few weeks. If things go well, we’ll broaden the net. We’ll be setting up a site soon to start collecting emails for the first round of beta testers. We’ll let you know when it’s on…

Jumpchart is really a communication centric tool. It’s designed to be quick for developers to live in, but easy enough for clients to be actively involved in collaboration. If you’re not directly inviting clients to participate in your Jumpcharts you’re missing out on the best part of the process.

When clients can be engaged in the process of defining how their site will work, they’re more likely to be happy with the end product. They feel included in the decision making process, so they have ownership of the site in a way that other planning apps can’t provide. Client involvement in the planning phase leads to:

• Less scope creep
• Less revisions
• Quicker development
• Easier organizing (No digging through email to find where to put stuff)
• Clients who defend the site as their own

That last one is a big one. Defending the site. People have a way of escaping out of controversy. If you deal with clients who have boards of directors, and committees it’s important to have a reliable person on the inside. Someone who defends the work, because they took part in it. Otherwise it’s just another project that nobody is emotionally invested enough in to fight off the corporate nonsense that ruins great websites.

So while Jumpchart is a great tool for individuals to plan websites within the walls of their own office, -you’re missing out on a whole lot of benefit if you’re not involving clients in the process.

We got a support email the other day from a guy who thought Jumpchart was way off base. Usually we don’t take the bait, but we decided to send him a courteous response saying how we respectfully thought he was wrong. Mostly, it was the same arguments we usually get:

• The wireframes aren’t descriptive enough visually
• No way to segregate navigation
• It doesn’t deal with “user experience”

We’ve never argued against any of this for Jumpchart. We tend to believe that the beginning document of a website should be very simple, and not illustrative of divisions of space, but rather what content goes where within a site. The web development industry has a lot of blurry lines between types of specialization. 37Signals thinks that designers should do mark-up. We think that most small studios blur their own lines according to strengths of their staff. Which means there is a diverse set of methods for building websites to appeal to. In our opinion, this means the simpler starting document you have, the more agreeable it will be to individual workflows that can shape it to their own methods. That’s why Jumpchart has the simplest non-descriptive layout imaginable for its wireframe preview.

With Jumpchart, we try to appeal not only to the developers, but to the clients as well. We believe that website planning is a collaborative process. We believe that it should be based around telling the unique story that the client has to offer. Which brings us to the quote from the support email that led to this blog post:

“The process of collection all the information before the information architecture is created is, to my mind, slightly backwards. My view is that information architecture is routed not in the actual information but on the task associated with the information. How the information fits in context with those tasks is where the site IA comes from in my view. IAs, ultimately, are not librarians but architects not organsing each book but creating an environment where those books can best be found and used. That’s the first major philosophical difference I can see.”

Which makes our heads twirl… The idea that the practice of organizing information for websites has advanced to a level where we can ignore the information we’re trying to organize is baffling. Creating a system for the content before you see the content, and then trying to shoe-horn it into place is a recipe for a pending redesign. Jumpchart is about exposing the information that the website needs to present. Doing it in a very simple collaborative way, and doing it quickly. Allowing you to change your mind easily and often, and ultimately getting to the build phase. -Which means getting the “what goes where” approved by the client…

We hope that Jumpchart users are enjoying the freedom to organize content, create navigation, and envision their sites without needing to draw little boxes, or think about whether it’s a 2 column, or a 3 column layout. First thing is first, – and in our opinion, content is king.

It happens a lot during app development… disagreement over some feature. One person thinks it ought to be “on” by default, the other “off.” Things have to feel right from the start. It’s worth sweating, and it’s worth fighting over(not physically). When an impasse occurs people tend to reach for the old stand-by: The Preference Setting.

Preferences are a really important part of application design. They let people customize the way they use an app. They let people feel ownership of their environment. It sounds like a great idea; Whenever you’re not sure, just give someone a preference to choose for themselves. -It’s the cheap way out, and it’s usually a bad idea.

There are lots of legitimate reasons to put preference toggles into your application. Not being able to decide on a feature, or not wanting to hurt coworkers feelings shouldn’t be one of them… Preference settings should be the last resort.

If fights break out in your group over small things, or if feelings get hurt over details, your group dynamic is busted. Your dynamic is equally busted if people don’t speak up enough to say what they think. Next time you get to a sticking place on a feature for your app, do yourself a favor. Don’t just put yet another pref. in, talk it out until a decision is made.

We’re currently building our second app with a contextual sidebar. In modern web apps, the sidebar is an important tool. While in commercial websites the sidebar is mostly about auxiliary navigation, in web apps, it’s about relevant tools. As our industry gets smarted about involving ajax in our applications to avoid page loads, it makes sense that the sidebar would change form dynamically as well.

We typically divide sidebar tasks between input/review. The sidebar has one function when first loading the page, and surveying what it has to say, and another when the content is being edited.

Even better, the contextual sidebar can have the ability to learn about what you’re doing as you do it. As you drop in and out of different roles, the sidebar can get better at making it’s usefulness accessible. So “contextual” starts to mean not just “what” you’re doing, but “when” you’re doing it.

We can’t tell you that every app we ever build will have a contextual sidebar, but it’s tough to imagine a scenario where it’s not a useful technique.

One of the first times it occurred to us to build this new app is when we were discussing the types of information people swap in groups. It might seem strange, but there are actually very few types. Because of this, project management apps on the market today differ more in how they look than how they work.

All of the PM apps try to give some context to bits of information that somehow relate to some relevant category, -usually a project. In most cases, each bit of information is categorized, and located with bits of information similar to it. Like a to-do on a page with a bunch of other to-do’s. But what is a to-do?

That’s maybe the question that started us on the line of thinking we’re currently chasing after. Every bit of information that other PM apps make you hop from page to page to see are identical, except the context.

• A to-do is a bit of text with a toggle for completeness.
• A time entry is a bit of text with a quantity associated.
• A message is just a bit of text.
• A file is a bit of text with a file associated.

The rest is just context, or meta information. We realize that small discovery isn’t really rocket science, but it led us down an interesting path. What if we make the bit of text the focus, and the rest secondary.

While other apps force you to keep switching context by moving from page to page, our app pretty much disposes of context in a physical page concept… In fact, our new app pretty much does away with multiple pages all-together. Chronology is the context, and the rest is just meta info that describes a bit of text and it’s relation to workflow as a whole.

It sounds weird maybe at first. Things that are new always sound a bit weird at first. Despite it sounding weird, we think you’ll get it when you see it. So far, we’ve found that:

• We’re more in touch
• We use less email
• We enter our time more diligently
• We’re not missing waiting on new pages to reload in our old PM app.

We’re really excited to show you all the hard work we’ve been doing. We think you will like it.

We’re really enjoying using our new app. Still a lot of loose ends, but it’s feeling good… It’s nice that it’s finally to a point where we can use our app to finish our app… Funny…

What’s great about apps like Twitter is how they allow conversations to spring up naturally. Chat applications require a certain amount of dedicated concentration. Twitter lets you answer when you have time. It’s a small thing, bit it’s powerful. We’ve been thinking a lot about productive workplace communication. Thinking about ways to let people get information out while still getting work done.

There’s a real gap we’re trying to fill. There are great chat apps that do a crap job of integrating to workflow. There are great management apps that do a crap job of focusing on communication.

We think there’s a sweet spot right in the middle… Not project management, – people management.

Not literally of course, – but our app is starting to feel like home. We’ve been “living” in the new version for a few days now, and thankfully we’re settling in nicely. If you read our previous article, you know that wasn’t the initial reaction to the last version.

So as we continue working on a functional version for beta testing, what have we learned? Nothing new really, it’s just always unfortunate when it happens. Measure twice; cut once, move fast, be lightweight, check yourself, be specific… admit failures. The last one is the hardest. it’s better to have a bruised ego than a bad product. The quicker you can put yourself in the position to make the decisions, the better, -after that just trust your instincts.

We’re looking forward to getting this one out in the wild. Hopefully other people will find this new app as comfortable as we’re starting to.

We won’t be opening up our new app to beta testers this week. Funny, -because it’s basically ready to let people in.

We’ve been using our new app, code named Staction, internally for a while now. It’s been… weird. Staction is a collection of ideas, and some really smart ways of thinking about our daily work process. At times it’s been more of a study in psychology than in interface design. Entering the project we knew what we felt was broken with current group collaboration, and project management apps, -and we thought we knew how to fix them. Short story is that we guessed wrong on some pretty major pieces.

What do you do when you don’t like your own app?

A couple Fridays ago was about the worst day we’ve had on the project so far. It was the day we realized that some things had to change with the app before it felt natural to us. It was a realization that some challenging and tough work was going down the drain. It was a realization of lost time…

A few lessons re-learned:

• There are several levels of immediacy to group communication. Granting access to immediacy is a bad thing more often than not.

• A flexible system is an advantage to the experienced user. A novice user needs walls to be suggested. The app needs to be committal on how you should do things but be tolerant of customization.

• No matter how fast your ajax is, and how smooth your interface, -switching from mouse to keyboard too many times slows down your activity in an app. Novice users need hooks to use the mouse. The advanced user wants to stay on the keyboard as much as possible.

• Part of interface design is teaching. You have to think about how people will improve their skills within your app. It’s great if on day one your users understand your app without reading the manual. An app that you live in daily must provide a way to become faster and better within the same interface. Watch someone who is really great at Photoshop, -it’s like a different app exists within the first…

Today, with some distance and perspective, we’re more hopeful than ever about the project. We needed that first run to quantify our assumptions. We needed for it to be right. We need for it to be good. So it will be a bit longer before anyone gets to have a peek at our work. Nobody is more anxious than us to show it off.