Introducing add-in commands
Today we bring you the first in a two-part series of guest blog posts from Andrew Salamatov, a Senior Program Manager with our Outlook team. You can find the second part here. Enjoy!
Back at Build and Ignite, we announced a brand new feature, that we’re very excited about – Outlook add-ins (formerly called apps for Outlook) can now place buttons on the ribbon in Outlook! This simultaneously simplifies interacting with add-ins, as well as makes their presence more visible and engaging.
In a two-part series, we wanted to share our thinking behind why we invested in commands and how they work, as well as walk through a sample add-in with a command. This is the first post in the series.
What are add-in commands?
The idea behind commands came from your feedback! Users are demanding a fast, simple way to get to the actions they need most. Meanwhile, developers have been trying to make their add-ins stand out and feel native. As we thought about the various scenarios that were being built on the Outlook add-in platform, we arrived at three guiding principles.
First, add-ins must look and feel native to each Outlook client. Mobile Outlook is very different from desktop Outlook and Outlook.com. Yet users flow from one to the other throughout the day and expect the power of 3rd party add-ins to support them, wherever they are. On top of this, the clients differ in their UI and user interaction patterns, due to form factor limitations and use cases. The same UI entry point and experience will not work across all these clients. Instead, our platform must enable developers to integrate in a way that meets user expectation on each form factor.
Second, the platform must scale to support many add-ins. Whether a user wants to use 1 add-in or multiple, the entry points must scale. And this must be completely abstracted away from add-ins, so developers don’t have to focus on handling interoperability with other add-ins.
Third, the platform must be write once, run everywhere. It would be very expensive for developers to implement an add-in for desktop Outlook, then re-write it for Outlook.com and mobile. Add-ins would take years to develop and update with new functionality. Instead, the platform should provide developers with generic concepts and APIs, which may result in different UI or positioning across the different environments, but will behave the same way across all Outlook clients.
Applying these principles to scenarios where the user has to take an action on a message or appointment, it became obvious that the best experience would be to let add-ins place commands for users where users expect them. In desktop Outlook, this is of course the ribbon.
In this first release of commands, we support 3 different types:
A command which executes a function
This type of command is best suited for tasks which don’t require extra input beyond clicking a button. For example, “save to CRM”, “create a new issue in service issue database from this email”, “insert tracking pixel”, “archive message”, etc. It is important to communicate to the user whether or not this action was successful. This can be done via an infobar message, which is described in more detail in part 2 of the blog post.
A command which launches a task pane
A command which is a dropdown and shows a list of commands of either of the other two types
The dropdown command is best suited for when a user needs to make a choice from a set of options. For example, “remind me if no one replies to this email in 1, 2, 3, … days”, “assign classification”, “archive for X days or months”, “quick-order drinks, appetizers or heavy lunch for meeting”. This command has an advantage over the task pane, in that the options appear natively and instantly to the user, and the user doesn’t need to wait for the task pane to load, or even move the mouse away. This should be used over a task pane anywhere, where the choice is simple and no additional input is necessary.
Now that you’ve had a taste for commands, stay tuned for our next post, which dives into how to build them!