Под пользовательским контентом в этой статье мы понимаем любой текст на странице, автором которого является пользователь. Чаще всего это комментарии, пользовательские записи «на стене» в микроблоге, информация «о себе» в профиле и все в таком роде. Задача не то чтобы очень сложная, но требует внимательности и хорошего понимания основ верстки. В этой статье сделана попытка собрать воедино то наиболее важное, что нужно знать о верстке, включающей пользовательский текст.

Работа с заданиями — это, пожалуй, наиболее часто используемая функция системы электронного документооборота. Казалось бы, что может быть проще — доставить документ исполнителю и получить реакцию на его обработку, но практика показывает, что задание — один из самых сложных объектов в СЭД. Российские СЭД имеют мощные средства управления заданиями. Расскажем, как реализованы задания в Docsvision, и какие есть особенности их реализации.

Про модель «СЭД в формате SaaS» сказано уже достаточно много. Напомним, примерно с 2010 года на российском рынке стали появляться игроки, создающие новые продукты и решения в таком формате. Они задали тренд. К 2011-2012 году на рынок вышли несколько крупных игроков с SaaS-решениями по проектному управлению, которые, в том числе, включали в себя элементы финансовых систем, CRM и системы электронного документооборота. Эти решения напрямую не являются СЭД в формате SaaS, но при этом частично решают задачи современных СЭД и даже позволяют в том или ином виде автоматизировать уникальные бизнес-процессы компании.

Вторым важнейшим компонентом приложения СЭД, помимо документов или карточек документов (в модели приложения, реализованной в платформе Docsvision), являются процессы. Если машина состояний, контекстно-ролевая модель и скрипты определяют поведение и логику отдельного документа в системе, то бизнес-процессы предназначены для реализации сложных сценариев маршрутизации, взаимодействия с внешними по отношению к СЭД приложениями, для обработки событий, не связанных с активностью пользователей, и другой серверной активности в отношении документов.

Представьте себе: ваш ребенок умирает от редкой и неизлечимой болезни. Его бьют посторонние люди, и он страдает от жуткой боли. В самом конце он усыхает до размера кошки, становится совсем серым и, наконец, умирает. А потом случается хеппи-энд: вы узнаете, что в роддоме произошла ошибка… Ф-ф-фу, напугал, дур-рак!

Поздравляю, вы познакомились с жизненным циклом прототипа обыкновенного.

Привет, друзья! Прототипы — это становой хребет продуктового дизайна. Я расскажу, почему мы в команде используем только hi-fi прототипы и отказались от всех прочих.

Ранее мы уже говорили про структуру приложений и определение принципов навигации. Кул. Но что со всем этим делать дальше? Не вопрос! Конечно, нужно разработать прототип. Прототип нужен для раннего тестирования MVP, для снижения рисков проектирования, для проверки пригодности предлагаемых решений, для показа акционерам, для краудфандинга и для экономии времени при общении с разработчиками. Отовсюду мы слышим стоны. Всем нужен прототип. Мы должны протянуть руку помощи, и мы ее протянем.
И тут у меня для вас 2 новости. Сначала хорошая: плохая новость могла бы быть намного хуже…

Привет, меня зовут Александр Волков, я проектирую интерфейсы в компании Docsvision. Цель этой статьи — помощь разработчикам сложных программных продуктов. Ключевое слово — сложных. Спроектировать сайт-визитку сегодня может даже пятиклассник прямо на своем смартфоне, и при желании можно скачать зип-архив с готовым шаблоном блога или корпоративного сайта. Однако если ваше приложение посложнее обычного интернет-магазина, то, вполне вероятно, строить структуру и определять принципы навигации вам придется самостоятельно, наступая на разбросанные повсюду грабли. Здесь может пригодиться наш опыт. Я опишу один из возможных способов проектирования интерфейсов, который успешно опробован в нашей компании. Это делается легко и просто (практически в полуавтоматическом режиме) при помощи программы FlyingLogic.

Важное отличие приложений СЭД от других привычных пользователю приложений (например, ERP-систем) в том, что документ СЭД – это объект с очень сложным и длительным жизненным циклом. Например, документ вида Договор — разрабатывается, согласовывается, утверждается, передается контрагентам, по нему ведется активная работа, к нему накапливаются приложения, создаются дополнительные артефакты, он архивируется, списывается и пр. Естественно, логика его обработки и права доступа к данным документа зависят от этапа его обработки. Но это еще не самое сложное.

В предыдущей статье Интеграция ASP.NET MVC c Sharepoint 2013. Part 1: High-Trusted provider-hosted APP было разобрано, как настроить SharePoint 2013 для SharePoint Apps (теперь Microsoft называет это SharePoint Add-in) и сделать базовую интеграцию приложения ASP.NET MVC с provider-hosted APP. В этой статье я покажу, как мы реализовали: поиск элементов SharePoint Site в MVC приложении, передачу элементов из SharePoint Site, App-parts и локализацию элементов SharePoint.

Чем грозит долгострой в разработке и с какими трудностями предстоит столкнуться на этом пути? Как бизнес-аналитик компании, которая 15 лет занимается разработкой и поддержкой одного продукта (СЭД), я решила поделиться своими мыслями и примерами из практики. Проблематика управления требованиями в любых программных продуктах с длительным периодом реализации – актуальный вопрос для аналитиков, руководителей проектов и владельцев продуктов. И, возможно, для непосредственных партнёров и заказчиков Docsvision, ожидающих выхода новых версий и заинтересованных в появлении новой функциональности.

Добрый день, меня зовут Сергей и я руководитель продуктового направления в компании «ДоксВижн». За время работы в сфере автоматизации электронного документооборота мне довелось участвовать в десятках проектов внедрения, причем в разных ролях (от инженера до руководителя проектного офиса), с разных сторон (заказчик, представитель компании-внедренца, вендор) и с разными системами (Docsvision и Directum). Своим проектным опытом я хочу поделиться с вами.

Зная процесс и набив кучу шишек, я даю в статье несколько рекомендаций, которые позволят подойти к проекту внедрения СЭД (как и любой ИТ-системы) подготовленными и более гладко его реализовать. Мой коллега уже давал советы ИТ-специалистам заказчика, ответственным за внедрение. Я взгляну на вопрос под другим углом и поделюсь рядом нюансов, которые стоит учесть именно компании-интегратору. Особенно, если вам предстоит первый проект внедрения. Надеюсь, статья будет полезна, хотя на многие «грабли» все равно нужно иногда наступать самостоятельно, и идеальных рецептов в проектной практике не существует.

Всем известно — чтобы что-нибудь продать, нужно это что-то или купить, или найти, или отобрать, или ИЗОБРЕСТИ! Вот это, последнее, мы сегодня и разберем. Для чего вообще нужно ставить разработанное программное обеспечение (ПО) на баланс? С чего начать? Когда остановиться? Какие есть пути продажи? Эти и множество других вопросов могут возникнуть у новоиспеченного изобретателя и его руководства. Меня зовут Марина Ремизова, я главбух со стажем работы в ИТ-компаниях, на балансе которых стоит уже не один НМА, и, открою вам тайну – все не так страшно. Изобретать было гораздо сложнее! Давайте пройдем вместе по этому пути.

Здравствуйте, меня зовут Наталья, я инженер по тестированию компании Docsvision.
Иногда, когда я просматриваю ошибки, записанные новенькими (а иногда и старенькими) тестировщиками, рука машинально тянется к лицу. В голове возникает только одна мысль:



«Что? Что я сейчас прочитала?»

В интернете много информации о том, ЧТО обязательно должно присутствовать в баг-репорте. А я решила поделиться с вами своими мыслями о том, КАК нужно писать баг-репорт, чтобы было понятно, о чём вы пишете.
В первую очередь, я писала это для инженеров по тестированию и инженеров технической поддержки, которые передают нам баги, присланные заказчиками. Также моя статья может помочь сформировать описание возникшей проблемы при обращении пользователя в техподдержку: корректное описание позволяет без дополнительных вопросов быстрее обработать инцидент.
Вообще её может быть полезно почитать всем членам команды разработки ПО, которые фиксируют своё общение в багтрекинговой системе.

Несмотря на кажущуюся очевидность утверждения «главный компонент приложения на базе СЭД — документ, а то, что оно автоматизирует – его «оборот», на практике оказывается, что под документом в приложениях могут иметься в виду самые различные сущности. Зависит это от типа документа и характера его «оборота», т.е. жизненного цикла обработки. Docsvision обеспечивает механизмы для реализации таких объектов. Связано это с тем, что даже для самых типовых приложений СЭД (например, для автоматизации задач классического делопроизводства) нам было необходимо моделировать в системе документ, который описывается очень сложной структурой данных и сложным жизненным циклом. Возможность моделировать такие сложные сущности как документ в делопроизводстве и позволила нам приобрести достаточную универсальность в реализации приложений для обработки документов различной природы. Держа в голове соображения, высказанные в предыдущей статье, попробуем описать модель сущности, которую мы называем словом «документ».

Среди разработчиков мобильных приложений B2C и B2B сегментов широко обсуждаются достоинства и недостатки альтернативных подходов к архитектуре клиентского приложения – делать его на HTML, нативным или гибридным (простой нативный клиент, открывающий встроенный браузер для обмена данными с сервером).
Одна из первых статей Microsoft на эту тему была опубликована на MSDN в 2012 году и не потеряла своей актуальности до сих пор (Choosing between a web and native experience). В этой статье мы рассмотрим использование гибридного варианта мобильного приложения для СЭД.

Вопрос о том, как ставить задачи и оценивать трудозатраты техписателей, поднимается почти на каждом вебинаре, конференции и встрече, посвященной документированию. В чем сложность? Почему, в отличие от оценки времени, затраченного программистами, тестировщиками и другими сотрудниками отдела разработки, именно трудозатраты документаторов постоянно вызывают дискуссии?
Попробую объяснить и показать, как можно избежать проблем в этом вопросе, используя систему управления задачами (как это работает — покажу на примере используемой нами системы Actionspace). Технический писатель, Лена Толмачева.

Этим постом я начну небольшой цикл статей, посвящённых различных аспектам разработки приложений в системе электронного документооборота. Сегодня все более или менее мощные и современные СЭД/ECM-платформы содержат набор компонентов и инструментов для их реализации, и именно приложения, создаваемые на базе платформы, позволяют автоматизировать все разнообразие рабочих процессов клиента. Я расскажу о модели приложения платформы Docsvision, о компонентах и средствах разработки (настройки) этих приложений, о том, какие проблемы возникали у нас при реализации инструментария для их разработки, и о том, чего ждём в дальнейшем. Это будет интересно не только тем, кто плотно работает с Docsvision, но и позволит почерпнуть опыт тем, кому предстоит внедрять или развивать свою корпоративную СЭД.

Здравствуйте! Меня зовут Елена Толмачева. В компании «ДоксВижн» я занимаюсь разработкой пользовательской документации.

В последнее время для создания разного рода руководств по эксплуатации сложных программных систем все более популярным становится использование технологии единого источника, предполагающей повторное использование в разрабатываемом комплекте документов каких-либо текстов или изображений. Не так давно для разработки справок и печатных документов «ДоксВижн» мы стали применять данную технологию, и в этой статье я хочу поделиться полученным опытом.

Системы электронного документооборота и ERP-системы представляют собой комплексные программные продукты, чаще всего состоящие из множества подсистем. Части любой системы работают как непосредственно в диалоге с пользователем, так и фоновом режиме, выполняя определённую часть задач на сервере.

Чтобы контроль производительности системы проводился в обоих направлениях, администратору системы нужны удобные инструменты для замеров, позволяющие вовремя найти слабое звено и предпринять меры по улучшению быстродействия. В этой статье я поделюсь своим опытом в том, как можно решить вопрос автоматических замеров показателей быстродействия системы на примере системы электронного документооборота*.
В отличие от других программных продуктов, для СЭД существуют определённые требования по быстродействию: это один из важных параметров, за которым необходимо следить.

*Статья будет особенно полезна начинающим администраторам Docsvision, но в целом изложенный опыт применим и для аналогичных продуктов.

Всем привет!

Меня зовут Денис и я работаю старшим разработчиком в компании «ДоксВижн». Этим постом я хочу начать цикл статей, касающихся разработки в области SharePoint 2013. Они затронут разные аспекты этой темы, начиная с возможностей базовой интеграции Web-приложения и заканчивая публикацией в магазине SharePoint Store. Знание нюансов и подводных камней, с которыми я столкнулся, может пригодиться тем, перед кем впервые будет стоять аналогичная задача.

Добрый день! Меня зовут Михаил. Имея многолетний опыт работы в проектах внедрения различных систем автоматизации (и документооборота, в частности), я часто сталкиваюсь с тем, что неготовность компании к проекту внедрения на самом начальном этапе влечет за собой существенные сложности его реализации. Хотел бы поделиться своими наблюдениями и дать несколько рекомендаций тем, кто планирует заниматься внедрением систем документооборота. Я бы мог дать ряд рекомендаций и компаниям-интеграторам, но сегодня сделаю акцент на другом: на что стоит обратить особое внимание ИТ-специалисту со стороны заказчика. Заблаговременное выявление слабых мест (несмотря на всю их кажущуюся очевидность) поможет вам избежать сложностей в дальнейшей реализации проекта.
Приведу ряд случаев из собственной практики (возможно, некоторые читатели узнают в примерах себя – но все совпадения случайны!)