Outlook™ & Web Apps
Cloud Computing
Many companies have taken advantage of the internet to create easily accessed, browser based applications aimed at businesses and enterprises.Die-hard Outlook Users
A big percentage of the target audience for those applications turn out to be die hard Microsoft Outlook™ users. They have invested years in learning how to get the most from Outlook, and don’t want (or don't need) to change right now.It’s a different world
So companies are having to think about how to integrate their web based solution with Microsoft Outlook™. Developers who spend their lives developing for the web take one look at the Outlook APIs and realise it’s a very different world.Davton can help!
That’s where we can help. Our developers speak ‘Outlook’ fluently, as well as all the other languages necessary to create an add-in and interface with a web application. So rather than asking your web developers to learn a foreign language with all it nuances, talk to Davton about creating an add-in for you.Considerations for Developing
Add-ins for Outlook™
Davton have been developing add-ins for over 6 years. Here are some of the considerations when starting the process of
developing an add-in for Outlook.
1. The user interface
The user interface is probably the most important element in any application. Outlook offers options to add buttons to toolbars, and to add custom panels and forms, but options and features. vary between the various Outlook versions - Outlook 2003, 2007, 2010 (32bit), 2010(64bit). So a key first question is which versions you will support?Several methods of creating add-ins limit the solution to one version of Outlook. Third party applications such as Add-in Express have created infrastructures which get around this limitation. The requirement for most add-ins is to support at least Outlook 2007 and 2010, but there are surprisingly large number of Outlook users who are still using 2003.
If we just consider supporting the user interface for these three versions - Outlook 2003 uses Toolbars for both folders and items in folders, Outlook 2007 uses the Office Ribbon Bar for items in folders but Toolbars for folders, and Outlook 2010 uses the Ribbon Bar everywhere. Toolbars and Ribbon Bars use completely different methods for creating and tracking. Just supporting toolbars and ribbons in multiple versions of Outlook can get interesting!
2. Speed and Responsiveness
Many Outlook users spend much of their working day using Outlook. Any add-ins which cause Outlook to slow down (or worse), are not popular and may be quickly un-installed.The issue is centred around the fact that Outlook is a single threaded application. This means it is not possible for Outlook to do two things at the same time. . If you try to create a separate worker thread – you run the risk of crashing Outlook, so any work which needs to be carried out for the add-in happens ‘in process’. This means if the work takes a long time – Outlook will appear to be frozen. This is particularly an issue when carrying out functions like calling a web service. Delays which may be tolerated in a web browser are not welcomed in what is seen as a ‘Desktop’ application.
Davton’s solution is to utilise a local database separate from Outlook. A separate service program can carry out all the communication and synchronisation with any web services or other remote data. So when the add-in requests information, it only has to ask the local database and gets an almost instantaneous response. It also means that SQL can be used to provide very fast querying and filtering of the database, rather than searching for items in folders in Outlook.
3. The Outlook API.
Once you have solved the issues of multiple version of Outlook, and responsiveness, the real work of building the application can begin.Outlook has a mature and well documented API. In addition it is also possible to access MAPI - the underlying messaging system directly, or via third party add-ins such as Redemption. This makes it possible to retrieve more information, and to process some items of data an order of magnitude faster than via the standard API.
Each item type has its own quirks. Messages with recipients. Contacts with over 100 standard fields. Appointments with different types for meetings –and the dreaded recurring appointments with their exceptions. Tasks with due dates. Journals for recording meetings or notes. Each has its own message class, and a sub set of fields which are included.
4. Web Services.
Communicating between an Outlook add-in and web application is achieved using a Web Service. There is a choice between following the SOAP standard, using a RESTful architecture, or creating something else such as MailChimp’s 'XML-RPC’ format. No one method has a clear advantage over any other, so a choice can be made based on technologies already being used, and to a certain extent, developers preference.Our experience is that if the web service has not already been developed for the web application, then it is far better and quicker in the long run to write, develop and test it collaboratively. A web developer and an add-in developer each writing and testing an aspect of the Web Service API at the same time creates an efficient writing and testing environment. We find Skype, instant messaging and email, excellent tools for comparing notes, requesting changes and general collaboration.
5. Davton Build Add-ins for Outlook.
Davton have been working with Outlook for 8 years and developing add-ins commercially for over 6 years.We have discovered many of the issues with developing Outlook add-ins the hard way – and solved most of them through trial and error. We believe it is quicker and ultimately cheaper to hire our services to develop your add-in than to try to build it in-house, or to use a more generalist software development house.