В моем последнем посте я писал о том, как расширения браузера могут быть одним из самых быстрых путей к повсеместному распространению нового программного обеспечения.

Например, созданное нами расширение Chrome отображает информацию из нашего программного обеспечения непосредственно в HTML-коде Gmail, создавая условия, позволяющие нашим клиентам использовать наше программное обеспечение, ничего не меняя в существующем рабочем процессе. Однако наше расширение поддерживает только клиентов, использующих Chrome, в частности Gmail в Chrome. Хотя Gmail в Chrome является популярным выбором среди наших клиентов, большая часть нашей клиентской базы использует Outlook. В этом году мы расширяем наши продукты и добавляем в них надстройку Outlook365.

Для создания продуктов Office существуют две технологии: Visual Studio Tools для Office («VSTO», использует .NET или C #) и JavaScript API. Эти технологии не имеют абсолютно ничего общего, что делает невозможным переключение между ними, не начав полностью заново. По сути, мы знали, что как только мы выберем технологию, мы не вернемся (не сможем) вернуться.

Я много читал, а также обратился к друзьям, работающим в Microsoft, чтобы они помогли нам определить, какой путь выбрать. Поначалу дела с JS API шли не лучшим образом. Это более новая (читай: более глючная) технология, у нее меньшее сообщество разработчиков и меньше поддержки, чем у VSTO - в основном потому, что VSTO существует с каменного века Интернета. Но в конце концов, JavaScript API стал для нас правильным выбором. Вот почему:

1. Влияние на клиента

Примерно 10% наших клиентов, использующих Outlook, используют Office на Mac. Надстройки VSTO основаны на технологии, которой нет на компьютерах Mac. Выбор построения с VSTO будет означать отказ от поддержки клиентов, использующих Outlook на Mac (в любом случае, без создания надстройки с помощью JavaScript API). Кроме того, надстройка VSTO поддерживает только один продукт Office одновременно, а одна надстройка API JavaScript может поддерживать множество продуктов Office в различных операционных системах. Благодаря единой базе кода мы уже поддерживаем Outlook на Mac, Outlook на ПК и Outlook в Интернете.

2. Распространение

Я понял, что многие команды разработчиков программного обеспечения, которые решают создавать продукты VSTO, являются частью внутренней ИТ-группы, которая имеет прямой контроль над установкой своих решений с помощью файлов .exe на всех компьютерах с Windows, где они необходимы. Без возможности физического доступа к компьютерам наших клиентов для запуска установочного файла мы могли бы гипотетически распространять наш продукт VSTO, размещая кнопку установки в один клик где-нибудь в Интернете, отправляя нашим клиентам компакт-диск с установочным файлом (документация действительно рекомендовала это) или публикация обновлений через установщик Windows.

Учитывая тот факт, что мы запускаем новый код в производство несколько раз каждый день, ни один из этих вариантов не казался нам возможным. Мы не хотели заставлять наших клиентов загружать новые версии нашей надстройки VSTO, и давайте посмотрим правде в глаза - как часто мы все игнорируем установщик Windows? Создание с помощью JavaScript API позволяет нам распространять наш продукт через магазин Microsoft AppSource, и магазин распространяет обновления автоматически.

3. Технология

Изначально мы были обеспокоены тем, что Microsoft JavaScript API будет выводить базу кода C #, что по своей сути пугает, потому что фреймворки могут компилировать код неожиданными способами (просто спросите любого, кто использовал React Native для создания приложений для iOS и Android). Этот страх был быстро развенчан, когда мы узнали, что надстройки JavaScript API не имеют абсолютно ничего общего с надстройками VSTO. Мы также узнали, что сегодняшняя версия библиотеки Office.js имеет всю необходимую поддержку, чтобы полностью воспроизвести возможности нашего существующего расширения Chrome для Gmail (например, определить отправителя данного электронного письма). Кроме того, мы можем разместить HTML, CSS и JavaScript для нашей надстройки Outlook на серверах Python, на которых размещено наше веб-приложение, поэтому изменения кода для чего-либо, кроме файла manifest.xml (который находится в хранилище Microsoft AppSource), будут действовать как как только мы перезапустим наши серверы (несколько раз в день).

4. Команда

Наконец, если бы мы создавали продукт VSTO, нам нужно было бы либо нанять разработчика .NET / C #, либо поручить одному из наших существующих инженеров (вероятно, мне) научиться строить с помощью этой технологии. Набор навыков, необходимых инженерам для создания с помощью JavaScript API, включает JavaScript, HTML и CSS. Сегодня каждый инженер в команде 4Degrees владеет этими навыками.

В конечном счете, двумя основными причинами, по которым мы выбрали маршрут JavaScript API для создания нашей надстройки Outlook, были поддержка клиентов MacOS и автоматическое распространение обновлений. С API также казалось несложным в использовании, но ждите моего следующего поста, в котором я перечислю некоторые головные боли, с которыми я столкнулся на раннем этапе работы с Microsoft JavaScript API для Office. Если вы создаете надстройку для Office 365, я хотел бы услышать ваши комментарии о том, какая технология вам подходит.

Если вы хотите опробовать приложение 4Degrees Outlook, упомянутое в этой статье, загрузите его бесплатно из Microsoft AppSource store.