Pull to refresh

Comments 47

приятно, что в наличии версии для Linux и Mac OS X, будет любопытно пощупать продукт в живую.
Расскажите об архитектуре редактора, какие паттерны применяете, с какими трудностями столкнулись, какие удачные решения использовали. Будет крайне интересно почитать, особенно учитывая что вы разрабатывали с нуля.
Тэг «Сделано в России» радует глаз. Молодцы, так держать!
Главное что не «Наш продукт, производить будем на...»
Когда я увидел первый раз заголовок новости на мегамозге, я думал это новый Бабушкин, но чем больше читаю о МоемОфисе, тем болбше понимаю, что это действительно очень крутая вещь.

Перед нами не так давно встала задача совместно написать статью в журнал, с требованием что текст должен быть в две колонки. В Google Docs такой возможности попросту нет, а в Microsoft Office в браузере он позволяет смотреть в две колонки, но чтобы редактировать, он переходит в не-WYSIWYG режим, где колонка одна. Более того, если кто-то редактировал в оффлайновом Word, то изменения синхронизировались только при сохранении, и там было невероятное количество багов.
Поэтому несколько вопросов:
1. Позволяет ли МойОфис редактировать в браузере текст в две колонки? Ну и даже более общий вопрос — является ли редактор в браузере WYSIWYG?
2. Когда я редактирую в клиентах для конктерных ОС, а не в браузере, изменения видны сразу как я печатаю, или как в Word при сохранении?

И еще два вопроса — когда и на какие языки планируется локализация, и будет ли клиент для Windows Phone (из статьи не совсем очевидно)?
Судя по последним Release Notes о работе с колонками вообще речи пока нет, недавно маркированные списки появились
Спасибо, мы стараемся.

  1. Редактирования текста в две колонки пока у нас нет. Ориентируемся на весну 2016. Относительно WYSIWYG – да, в браузере все работает точно так же, как и в версии для desktop’ов.
  2. Все правки отображаются сразу.
  3. Русский/английский есть уже сейчас. Украинский, португальский, немецкий, испанский и другие языки будут появляться со временем, по мере предоставления сервиса в странах, говорящих на этих языках.
  4. Мы следим за развитием Windows Phone и за технологией Windows 10 Continuum. Разработка клиента для новой платформы может быть выполнена достаточно быстро. Но в планах на ближайшее время разработки клиента под эту платформу пока нет.

Техническая сторона решения интригует — свое ядро, архитектура, синхронизации. Пишите!

Но я никогда не понимал приложения «для совместной работы с документами». Расскажите, какой бизнес работает с документами? В моем понимании сколь нибудь серьезный бизнес работает с одной из двух систем — это CRM или логистические системы. Работа с клиентами или работа с товарами (или все вместе в случае ERP-решений). Любая из этих систем реализует функции бухгалтерского учёта и документарного сопровождения сделок. Вся остальная движуха цепляется к ним через REST API, SOAP, COM+ и прочие более древние технологии, максимально автоматизируя бизнес-процессы. Эти системы способны генерировать любые документы на основе необходимых данных. Если компания способна освоить хоть какой-нибудь задачник типа мегаплана — необходимость в текстовых документах, таблицах и внутренней переписке исчезает — проверено на своей шкуре.

Судя по сайту, вам два года. Наверняка вы задавали себе этот вопрос. Было бы здорово почитать об этом на мегамозге, например.
Если брать разработку, то это может быть ТЗ или руководство, например.
Примеров такой совместной работы достаточно много:
  • Большое и подробное техническое задание
  • Договор, который готовит команда юристов с привлечением нескольких сторон
  • Описание внутренних процедур и инструкций

Собственно и эта статья.
Это всё вспомогательные процессы основной деятельности. И на мой взгляд логично их организовать в там, где идет основная, или тесно связывать. Например, есть система управления проектами worksection, которая очень хорошо интегрирована с Google Docs. Есть формат wiki, который встраивается с переменным успехом в любую систему вообще, потому что OSS.

Приведенные примеры — это большие, хорошо структурированные документы. И формат отдельного файла для них мало подходит, также как и имеющийся функционал. Поэтому мне интересно почитать конкретные Use Case примеры для конкретной деятельности в виде отдельной статьи.
Здравствуйте.
Мы сознательно отказались от заимствования у open source аналогов и весь код ядра написали сами

Какие open source аналоги здесь имеются в виду?
Как минимум можно смотреть в исходники LibreOffice и редактора от TeamLab. Может, есть и какие-то другие.
OpenOffice/LibreOffice. Прежде всего мы оценивали возможность сделать полноценную совместную работу и возможность работы на мобильных платформах.
У Calligra хорошее качество кода, но небольшой функционал. Команда Tobias Hintze очень симпатичная.
Не пробовал поюзать платформу, но читая статью и глядя на скрины не покидает ощущение что пиктограммы слизаны с гугла и яши, только добавлена яркость. При всем яркость излишняя, глаз съест пока работаешь, хотя большинству нравится эта пестрота как у попугаев, современные тенденции как ни как.
А в общем радует что становится все больше хороших проектов от российского сегмента
Мы активно смотрим в сторону Material Design. Но если присмотритесь — все нарисовано с нуля. Мы обязательно напишем, как работали над дизайном, в том числе, отдельных продуктов пакета «МойОфис».
Молодцы. Правда, правда. За WYSIWYG редактирование нынче памятники пора ставить.

Вопрос если позволите: поддерживается ли RTL в редакторах? А TTB?

Про технологии и общее ядро…

Десктоп и мобильные use cases редактирования имеют приниципиально разные модели.
Если в десктоп editing unit это отдельный символ на который можно прицелить cursor, то на телефоне палец накрывает полный параграф (или там ячейку таблицы) — уж очень разные парадигмы редактирования. Да и не нужен на телефонах WYSIWYG в принципе — если пол экрана закрыто клавиатурой — то во второй части можно только plain text input какой разместить…

Т.е. на разных девайсах — разные потребности в редактировании. Поэтому как-то фраза «редакторы везде работают одинаково» вызывает определенные сомнения. Или я не так понял это всё?
Use cases конечно разные, они разные и между iPhone и iPad. Даже между iPhone6 и iPhone6+. Мы говорим о том, что ядро работающее с документами одно, оно воспроизводит документы одинаково на всех платформах. А дальше конечно совершенно разные подходы.
Полагаю тем, что это высокопроизводительный язык зная который на нем можно писать производительные и компактные приложения.
Это не совсем так, у нас кросплатформенное ядро на C++. На веб мы для UI естественно используем JavaScript. Для Windows/Mac/Linux для UI используем QT. На Андроид UI это Java/NDK. На iOS Objective C.
А ядро как в браузере запустить?
В чем преимущества по сравнению с Office 365? Ну и с корпоративным де-факто стандартом SharePoint / Office Web Apps / Exchange?
UFO just landed and posted this here
В 2013 году импортозамещение не было трендом. Наше преимущество – возможность размещения в частном облаке. Планируем делать подробные обзоры с сравнением продуктов.
как оно работает с большими документами?(OnlyOffice от Teamlab умеет,Google Docs — не умеет), вообще веб-версия работает на Canvas (как OnlyOffice) или добавляет текст как элементы DOM?
Если коротко у нас своя структура DOM, над ней есть Layouter и Renderer и далее на web отрисовка на Canvas, подробно будем писать отдельной статьей. Про большие документы это тоже вопрос для отдельной статьи — мы грузим и редактируем документы в 1000 страниц, которые не открываются в Google Docs.
А что используете для преобразования операций? Opencoweb/что-то еще/свое решение?
Это наша любимая тема :) Будем писать.

Для коллаборации мы используем Operation transformation — это целое семейство алгоритмов. В нашем решении мы
а) Мы скомбинировали ряд подходов, известных по-отдельности: клиент-серверная модель с подтверждениями, иерархическая организация данных с набором атомарных операций, tombstones.
б) Добавили некоторые принципиальные новшества, которые не встречали в других алгоритмах. Например: таблица, как узел в иерархичном дереве; возможности сохранения бизнес-логики модели путем изменения операций во время их выполнения.
Реализовано все самостоятельно.
ну да, operational transformation это и есть преобразование операций) Интересно почему не контекстная теория? Как с оффлайном? Отменой любой операции по истории назад?
А зачем менять операции во время их выполнения, если они преобразуются до?
Скоро будет статья про collaboration.
Хотелось бы про серверную часть почитать, если это возможно )
Подписывайтесь на нас, обязательно расскажем.
Когда статья «цепляет» электронный документооборот — это интересно, сам нахожусь в этой сфере разработки более 10 лет. Под этим термином и правда сейчас понимают больше «автоматизацию бизнеса», чем классику (автоматизация канцелярии). Но, как только мы ступаем в бизнес-процесс оказывается вот что:

1) общаясь с клиентами (заказчиком), я понял что рядовые сотрудники часто должны быть связаны по рукам и ногам, чтобы не сделать лишнего. Например, человек может создать документ, и отправить его по маршруту Пете-Васе-Коле-Оле. Но, зачем сотруднику это держать в голове? Раз — и используем жесткий маршрут, который заложил еще администратор, и все 100 сотрудников его используют. Это бюрократично, но это и есть «бизнес» — когда правит порядок а не разгильдяйство. И это разгружает голову людям — например, проще нажать одну кнопку и быть уверенным, что «Договор» пройдет сам нужные этапы, чем думать, кому и как его послать.

2) разработка систем такого рода на общей платформе — хорошо, но нужно сразу закладывать возможности по расширяемости. К вам придет крупный клиент, попросит доработать модуль, и т.п. Такие возможности серьезно удорожают разработку для вас, одно дело — законченный продукт «в коробке», который предоставляется как облако и никто не будет никому подключать ничего нового.

3) Какой командой вы создаете свой продукт, если не секрет? Например — «руководитель проекта — 1, программисты- 2, технический писатель -..., дизайнер......?»

У нас сейчас начался большой проект, в котором кастомизацию с одной из систем документооборота делает интегратор. И в дальнейшем будем придерживаться такого же подхода. С крупными игроками ведем переговоры, как с классическими типа DocsVision, так и с новыми, например с Bitrix24. Тот же принцип — встраиваться в корпоративные решения. SDK планируется, в частности plugin для Chromium.
Если оставить в сторону эскплуатацию, то:
— около 80 программистов, включая team leads
— около 30 QA
— 6 человек в UX
— 4 руководителя проектов
— 6 product owners
— 7 scrum masters
— 7 devops
Оплата труда такой команды за один месяц уже сама по себе впечатляет. А уж за год-два… Уверены что «отобьете» такие вложения?
Тем более что мы платим «вбелую». Не были бы уверены — не начинали бы.
как вы можете быть уверены в этом? Сейчас это огромные расходы
Когда можно будет увидеть рабочую версию, чтобы посмотреть и сравнить с имеющимися аналогами?
После того как вы пиаритесь на tv и cnews, хочется уже щупать, чего не получается. Пока больше это похоже на пустой звон, с постоянными переносами и на классическое российское шапкозакидательство.
Планируем до конца года предоставить доступ всем желающим. Переприотизация была связана с тем, что с начала года мы ускоренными темпами делаем десктоп-версии.
Прикольно, интересно. Только инвайт до сих пор жду…
С вами свяжется команда поддержки, как только будет открыт доступ к тестированию для всех желающих. Пожалуйста, подождите немного :)
Дизайн на пятёрочку. Вижу сколько труда вложено.
Sign up to leave a comment.