Just under a year ago, we launched an API to allow developers to build new tools on top of Asana. Since then, we’ve seen companies and independent developers use the Asana API to integrate Asana and their internal tools, add features like time-tracking and reporting dashboards, and even build separate products.

But until today, the only way to grant another application access to your Asana account was to use your API key.

Today, we’re introducing a better way to authorize other applications to use your Asana account: Asana Connect.

What is Asana Connect?

Asana Connect is a way you can connect your Asana account with any partner website or app using a trusted authentication method, OAuth. Now, whether you’re signing into the partner app or granting the partner app access to your tasks, you can use Asana Connect to securely authenticate and connect to your Asana account.

Asana Connect is based on OAuth, which is an authentication standard supported by companies like Facebook, Twitter, Google, LinkedIn and many, many others. When you “Connect with Facebook”, for instance, you’re using OAuth to let another app access some information about your Facebook account to identify you and make requests of the Facebook API on your behalf.

Likewise, if you signed up for Asana with your Google account, you were using OAuth.

Starting today, developers can begin to write apps that will let you securely give them permissions to access data in your Asana account. You can either accept or reject this request with the click of a single button.

Revoking these apps’ permissions will be just as easy. You can click on your name in the lower left corner > Account Settings > Apps to see the Apps you’ve authorized with Asana Connect.

Why Asana Connect is better

Using an API key to give third-party applications access to your Asana account was functional, but it suffered some drawbacks.

• Applications would need to prompt you for the key, which you’d then have to go to the Asana app to locate, copy, return to the application, and paste in. This is not the smoothest experience.
• Worse, to enter the key on a mobile device you’d often have to actually type it out. The API key is long and full of different characters and numbers, which enhances its security but makes it tedious to enter on mobile keyboards.
• One API key was shared by all applications, meaning if you wanted to deauthorize just one application, you would have to reset your API key and enter the new one into all the apps you wanted to keep using.

Asana Connect makes those drawbacks go away.

The future soon

Of course, it will take developers some time to implement this new authentication method, but we hope that in the weeks and months ahead, you’ll see a lot fewer “enter an API key here” text fields and a lot more “Sign in with Asana” buttons. In fact, our friends over at Flowbs and Cloudwork already have Asana Connect up and running!

Developers can read up on all the technical details in the Developer Documentation, as well as check out some example code showing how to implement OAuth for Asana on Github.

Imagine if, with one click, you could answer the question “What work is due today for everyone on my team?” or “What are all the tasks that are more than a day behind schedule?” Wouldn’t it be amazing if you could get that information without having to ask for it, even if you hadn’t been on the original email threads?

Today, we’re excited to announce Asana Search Views – a powerful new way to manage the work you track in Asana. Search Views take the power traditionally found in more complicated, specialized tools and deliver it with the same focus on simplicity, usability, and design that we bring to the rest of our software.

A New View Of Your Team’s Work

Search Views let you slice and dice tasks in Asana in practically any way you choose. With a few quick clicks (or keyboard shortcuts), you can, for example:

• Search for all the tasks completed by one or more people on your team in the last seven days.
• Search for all incomplete tasks tagged with “Customer Suggestion” ever created.
• Search for all tasks that have attachments and are in a specific project.

Once you’ve created a Search View, you can quickly navigate between the tasks you’ve found to see their details, or select multiple tasks to change them all at once. You can sort the Search View by when tasks are due, when they were created, and how long it’s been since they’ve been updated.

And if there’s a Search View you expect to use frequently, you can quickly make it a favorite in the left pane, essentially creating custom reports that update each time you navigate to them.

Accessing Search Views

You can get to Search Views in two ways: For a simple full text search, type any word or phrase into the search box and choose “Search Tasks”. For a more advanced, structured search, click the arrow at the right of the search box.

In the drop-down, you can now specify any or all of the following: Assignee, Projects, Tags, Attachments, Completion Status, Due Dates, and more.

To quickly see how it works, click on any of the suggested searches to go to all of the tasks you created, followed, or assigned. From there, you can focus the search by re-opening advanced search and narrowing down to incomplete tasks, those with attachments, or the ones not assigned to you (choose ‘Not me’).

If you’ve created a Search View you want to use again, you can click the star next to the Search title to save it. You can rename it if you like.

SIDE NOTE: We’ve also brought the Tag list back. Just choose “Show Tags List” from the Workspace Settings menu and they’ll appear at the bottom of the left pane.

Using Search Views

Search Views are designed to be flexible, and there are tons of ways to use them. Here are a few:

Find Any Task Across Your Company

Full text search looks across the entire content of tasks, including the notes, comments, projects, and people, so you don’t have to try to guess what someone else named a task. Simply type in any keywords and we’ll do the rest.

Manager Reporting

Add your teammates to the “Assigned To” field, then filter by project or tag to drill down to the information you need. See at a glance when projects are falling behind or when tasks are slipping through the cracks, and take action immediately.

Bug Tracking

In building Search Views, we focused on building a search powerful enough to contend with the best dedicated bug trackers in the market.

You can now slice and dice your Asana tasks to find exactly what you want, from stale bugs to new and unassigned ones. The saved Search Views enable new workflows, like having the QA team watch for completed bugs that haven’t been QAed yet, or the customer service team watching the bugs they opened to see as they become assigned and then completed.

Another Step

At Asana, we envision a future where teams work together as seamlessly as a guitarist’s left and right hands. Since we launched, we’ve been meeting with teams, listening to customers, and improving Asana to expand the scope and complexity of projects that teams of can take on. We think Search Views represent the next big step towards that vision.

Today, we are releasing Kraken, the distributed pub/sub server we wrote to handle the performance and scalability demands of real-time web apps like Asana.

What problem does Kraken solve?

One of the key promises of real-time web applications is that users will see changes made by other users as they happen, without hitting reload or refresh. Many of the up-and-coming reactive web frameworks initially accomplish this by periodically re-executing queries against the database. When we were building the early prototypes of Asana, our reactive framework (Luna) was no different.

Unfortunately, most production-ready databases, from Mongo to Mysql, are unable to keep up with the query volume that even a moderate userbase creates when you frequently poll the database for changes. We recognized this problem early, and worked around it by designing an algorithm that incrementally updates queries in real time without putting any additional load on the database server. Key to this solution is the requirement that every query be notified about changes to objects that could potentially match, or stop matching the result set of each query.

That’s where Kraken comes into play. Kraken is responsible for routing data-invalidation messages between the processes that are running these queries so that they stay up-to-date.

Why is Kraken the right solution?

Before building Kraken, we searched for an existing open-source pub/sub solution that would satisfy our needs. At the time, we discovered that most solutions in this space were designed to solve a much wider set of problems than we had, and yet none were particularly well-suited to solve the specific requirements of real-time apps like Asana. Our team had experience writing routing-based infrastructure and ultimately decided to build a custom service that did exactly what we needed – and nothing more.

The decision to build Kraken paid off. For the last three years, Kraken has been fearlessly routing messages between our servers to keep your team in sync. During this time, it has yet to crash even once. We’re excited to finally release Kraken to the community!

You can get Kraken yourself at Github

This is the status quo at many a fast-moving startup: new engineers plunge into their positions bracing for a harsh reality. Fresh from an environment in which they were confident in their day-to-day work, they must hope to succeed in spite of gnarly legacy code, inadequate documentation, unintuitive raw tools and processes, and co-workers that help only reluctantly (if at all) because they are too busy. It is an awful first impression.

But paying careful attention to the on-boarding experience pays dividends, and is a key to transforming new engineers into strong, effective contributors. Positive patterns are easier to establish early on, not once the engineer has settled into a routine.

At Asana, we strive to build a culture centered on focus, productivity, growth and development—and that starts on day one, not some unspecified time when you become a “real” employee. We’ve put a lot of thought into our on-boarding process, which we’ll lay out below.

Minimize Chores

The first step is to remove as many rote tasks as possible from the new engineer’s list of responsibilities. We want him or her to focus on being a member of the organization, not on doing chores.

To facilitate this process, we have all of the components of their workstation acquired and set up ahead of time. We give them a $10,000 budget to customize it and then get them what they need before they show up. In the days before their first day of work, we set up their desk, install a standard disk image and run a standard setup script on their machine. All that’s left are the unavoidable personal customizations.

The goal of the whole operation is to ensure that the engineer doesn’t spend most of their first day “setting up their workspace.” We have much bigger plans for them.

My Buddy And Me

Those bigger plans start with a buddy. Each new engineer is paired up with a colleague with at least several months of tenure at Asana. For the next few weeks, this buddy will be be the primary person responsible for the new hire’s experience.

The buddy system provides benefit in two ways:

• New hires never have to wonder “who should I ask” and “is it worth taking this person’s time?” When we pair the new engineer with his or her buddy, we clearly communicate that we expect the buddy to spend a significant amount of time and energy on the onboarding process. Meanwhile, we give buddies the leeway they need to reduce their other commitments.
• It puts a single Directly Responsible Individual in charge of the new hire’s experience. Because buddies are invested in the process, they notice when the new hire is struggling with a problem. They facilitate discussions with experts on the team. They spend extra time pair-coding. Since someone is tasked with paying attention, it’s much easier to optimize the experience.

The buddy system also creates explicit opportunities for the new engineer to give feedback to the organization. New hires provide unique value: the ability to see the organization without the curse of knowledge. They cycle in new ideas and help prevent institutionalized biases. Valuing a new hire’s opinions early on sets the tone for their future contributions.

Adding Value On Day One

We have a rule at Asana that all new engineers must ship something on their first day. It could be a tiny product improvement, or a fix to a bug or a typo—anything. But it has to get out to production.

This practice is part of a commitment to continuous deployment and is inspired by other companies who have done the same. The rule serves multiple purposes:

• Demonstrates the entire lifecycle of a change to the software, from idea to launch.
• Provides confidence to the new hire around putting code in front of users. The worst that happens is something actually breaks, the code is quickly reverted, and everything’s okay again.
• Re-enforces the culture of continuous deployment within the organization, which has many of its own benefits.

Meet the Tech and the Team

A lot of what we accomplish together is grounded in trust and in our working relationships. Good tools (like Asana) facilitate these relationships, but are not replacements for them. We kickstart our fellow engineers’ effectiveness by seeding their relationships early on.

During the new hire’s first few weeks, the buddy schedules a series of learning sessions on various engineering topics, such as a walkthrough of our codebase, our cluster architecture, our datastore, reactivity, our testing framework, and so on. Each session is a one-on-one with another engineer.

Like many processes at Asana, the functions of these sessions are stacked, yielding many different benefits from one activity:

• The session leader and the new hire get one-on-one time to discuss something technical, establishing a relationship.
• The session leader gets to exercise being an authority, a component of developing leadership.
• The new hire gets high-quality information about a topic highly relevant to their work.

Of course, to scale our knowledge transfer across all employees (not just new hires) we also maintain a solid base of internal documentation. And each new hire is assigned one of the sessions that had inadequate written coverage, and cooperates with the expert to write up what they’ve learned. This process distributes the onerous chore of documentation, and helps us build our knowledge base over time.

The Starter Project

After a new hire has been exposed to an organization’s principles, tools, and and processes, there is often still a sizable gap between learning and synthesis. Many organizations are content to let this gap close incidentally, in fits and starts, wherever the engineer happens to be focusing their attention at the moment. While prioritizing learning based on needs is a passable default, we think introducing some core concepts in a safer environment can be more effective.

To that end, every new hire gets the same starter project: to build a small chat application using Luna, our in-house framework. They are expected to spend about 2-3 days working on it. The project is fairly open-ended, though the engineer is given lots of hints about things they can try building.

We designed the chat project to expose new engineers first-hand to many of the core concepts of building an application on our framework. The project’s open-ended nature allows engineers to direct their own exploration of the system. Since building a chat app on Luna is very similar to the day-to-day work on Asana, the skills the new engineers learn are directly transferrable. However, because the scope is much smaller and the environment more controlled, the engineer can learn the concepts more easily, without distraction.

Great Success

The benefits of our approach are real: our new engineers tell us that they were invigorated by their on-boarding experience, instead of exhausted, and they are excited by how quickly they become productive. Though our on-boarding process requires a lot of upfront energy, we’ve found that it pays to think carefully about how a new engineer is introduced to the organization, and how the experience might shape their mental model of the company.

They are, after all, its future.

Enabling “flow” is critical to the way we work. Flow allows us to have time to think, take new projects from A-Z, and to dive deeper into work without meetings or interruptions that may distract us from completing our goals. Once every episode, we run a hackathon at Asana. We set aside time and encourage everyone really dig into an unplanned project that really excites them. This gives the team space to tackle its most fun and even crazy ideas, to flow.

The idea is to allow for willful intention without attachment to results: if you want to learn a new programming language, design UI for the first time, or build something new, go right ahead. Learn that code, do that design, build that feature. If none of it pans out, no worries, we still ♥ you.

Normally, our hackathons last just a couple of days. This time, we decided to change it up a bit, and built a longer hackathon around Thanksgiving. For six days, from November 15th – 20, we held Thankshacking at Asana. This was the longest hackathon we’ve had since we first became a team.

Because of the hackathon’s length, we made sure to strive for a balance of work and play: we integrated more team bonding experiences, including a weekend feast with home cooked meals, a movie night (we watched “Sneakers”) and a board game night to break up the long work days.

We made it clear that working over the weekend was optional, but included a rock climbing trip and late night pizza to break up the hard work. It worked. As Alex Davies, one our newest engineers put it, “The flexibility and fun aspect is what made this hackathon more enjoyable and more relaxed.”

Here’s what we did to make the hackathon a success:

• We hosted a fun activity every night of the hackathon. This made our office an unusually fun place that week.
• We gave everyone on the team full autonomy.
• We made sure everyone understood there was no pressure to ship.

The results were great. This is what happened:

• Even though weekend work wasn’t mandated, a large percentage of our team, including non-engineers, worked over the weekend.
• I’ve never designed anything in my life, but the icons I designed for one of my teammate’s projects got approved by two of our actual designers.
• One of our engineers took his original project even further than he had planned and built a totally new feature. He said the total autonomy made him even more creative.
• One person on our marketing team mocked up a major new page for the website and another taught himself Ruby.

Hackathons are fairly common on the startup scene, and they usually go like this: the engineering team takes somewhere from 24-48 hours to work like crazy on (usually) unplanned features and/or new product ideas. Pizza, beer, ping-pong, and all-nighters are often involved.

But there are other ways to do hackathons. They don’t have to be 24-48 hour sprints. They can be easier on the body, yet more focused and intense at the same time.

Or, at least, we like to think so.

Many of you noticed that the Asana service was occasionally unavailable for brief periods of time, lasting less than one minute, on Thursday and Friday last week. We apologize for the inconvenience these connectivity issues caused, and want to let you know what we are doing to prevent similar issues from occurring again in the future.

Asana’s infrastructure runs almost entirely on top of Amazon Web Services (AWS). AWS provides us with the ability to launch managed production infrastructure in minutes with simple API calls. We use AWS for servers, databases, monitoring, and more. In general, we’ve been very happy with AWS.

A month ago, we decided to use Amazon’s Elastic Load Balancer service to balance traffic between our own software load balancers. We did this for two reasons:

Scale: To evenly distribute requests between our own load balancers.
Reliability: To ensure that a single server failure does not result in a percentage of requests failing until we fix the server.

The Elastic Load Balancer was accomplishing both of these goals for nearly a month when it suddenly stopped forwarding all HTTP requests to our servers. The issue lasted less than a minute, but it was long enough to trip our monitoring system and briefly disrupt the workflow of users who have come to rely on Asana to get work done.

The first time this occurred, we assumed it was a random hiccup that was unlikely to happen again. When it occurred a second time, we got in touch with Amazon for assistance. Amazon thought they resolved the underlying problem, but it re-occurred twice more later that night and early in the morning on the following day. At that point, we decided to replace the Elastic Load Balancer with DNS Round Robin. Since doing so, the problems have gone away completely.

DNS Round Robin isn’t without its own set of issues, but none of them should impact your ability to access our service. We hope to use the Elastic Load Balancer again in the future, but not until Amazon provides us with enough information to properly diagnose the problem and address it.

Today we are excited to share that you can now add and access Asana data programmatically using our simple REST API.

The Asana API lets you build a variety of applications and scripts to integrate Asana with your business systems, show Asana data in other contexts, and create tasks from various locations.

Here are some examples of the things you can build:

• Source Control Integration to mark a Task as complete and add a link to the code submission as a comment when submitting code.
• A desktop app that shows the Tasks assigned to you
• A dashboard page that shows a visual representation of complete and incomplete Tasks in a project

The API is available for free to everyone with an Asana account. To get started:

1. Get your API key.
2. Paste this curl command into your console, to test that you can retrieve your user info:
   export API_KEY=your-key ; curl -u $API_KEY: https://app.asana.com/api/1.0/users/me

You can find more details in our API documentation. There, you’ll see some example applications, including a Chrome Extension that lets you select text on any web page and quickly create an Asana Task.

If you have questions about the API, please ask them on Stack Overflow. We will be monitoring the site for questions and answering them promptly.

Thanks again to everyone who contributed feedback and waited patiently for the API to become available. We can’t wait to see what you create.

For more information, please visit our developer site: http://developer.asana.com

ReadWriteWeb recently published an article that Greg Slovacek, one of our software engineers, wrote about the power of real-time applications.

The advances in computing leading up to now have had a major impact on the software experience: richer and more powerful clients, access to more information and greater connectivity to other users. We now have the opportunity to get a desktop software-quality interaction experience combined with a Web-quality network experience, empowering us to build apps that are far better than the best of either of the two experiences alone.

As Greg explains, it’s a fantastic time to be a web developer, and we’re looking for awesome engineers to help us write the next generation of collaborative software. Interested? Read the full article here and send us a message at jobs@asana.com.

Many of our users are probably familiar with the “unique error phrase” that shows up whenever our application crashes in some way. These have a curious form, and we wanted to share the motivation behind them.

When diagnosing problems, it’s helpful to be able to associate a specific customer incident with information in the logs. Whenever our app crashes, we generate a unique ID for the incident, which is shown to the customer so that they may include it when they write in to us about a problem. This is not a novel practice—it’s actually fairly primitive—but given an ID our staff can jump directly to more technical information on the customer’s issue, letting us classify and respond to it more quickly.

What is novel in Asana is the form these IDs take. In most other applications, a customer-facing ID is usually a long jumble of numbers and/or letters. There are lots of small, subtle drawbacks to representing a number to a human this way, and so for the sake of curiosity—and to add a little levity to an otherwise frustrating situation—we tried something different.

Sentences from numbers

Imagine representing 32 bits of information (numbers up to 4 billion) as a sentence instead of a jumble of digits. Each sentence can have the same predictable structure, and the number will be used to choose words from a dictionary to fill in that structure—like Mad Libs.

One possible sentence structure can be: count + adjective + plural noun + verb + adverb, e.g. “6 sad squid snuggle softly.” We can divide the bit-space of the number like so:

• 5 bits for the count (2-33, so it is always plural)
• 7 bits for the adjective (one of 128 possibilities)
• 7 bits for the plural noun (one of 128 possibilities, which we made all animals just for fun)
• 7 bits for the verb (one of 128 possibilities)
• 6 bits for the adverb (one of 64 possibilities)

Now, given a dictionary containing words categorized in this way, we can generate 4 billion unique (and sometimes very memorable) sentences. In Asana, the ID used to generate the error phrase is random, so the same sentence is unlikely to occur twice.

Automatic issue tracking

Since we care deeply about providing users with a stable experience, we have put major effort into a system which records problems that occur anywhere in our application, whether on our servers or in customers’ browsers. It collects a bunch of useful information about the crash (stack traces, log snippets, application state, user and session information, etc.) and automatically groups similar problems and imports them into an internal Asana task list, pictured below.

Having all of the issues in Asana allows us to see aggregate information on each problem, such as the number of occurrences and different users it has affected. From there we can tag, prioritize, and assign it so it gets fixed. This system makes Asana a very effective issue tracker for us, as each issue has lots of important metadata associated with it—including, of course, a way to find it from a unique error message reported by a user.

So, in the event you experience a crash, rest assured it’s already on the list for our team to act on. And we hope you at least get a gem as a consolation prize. 12 soft kittens cuddle warmly. Or 8 mad orcs stomp loudly. Or .. you get the idea.

Last week, we were invited to talk at the Sunfire Offices in Mountain View to a packed room of developers. I gave a presentation on Asana’s approach to web application development and how our Luna framework uses three key ideas—Reactivity, Sync, and Cosimulation—to simplify writing very-fast browser-based applications.

Below is a video of the talk (dark, yes, but it was a tight fit!), and here are the accompanying slides. Hope you find it interesting!