iscrafmесть примеры не уступающих?
Те, которые не имеют Desktop-клиента вообще, т.е. практически любая западная платформа.

iscrafmТолько не таких, где уровень функционала опущен по уровня web-браузера...
Тут надо понимать, что в отличие от большинства других учетных систем, СЭД/ECM не требуют сколько-нибудь сложного интерфейса.
Да, это тоже учетная система, но управляет она объектами, которые имеют, в большинстве случаев, достаточно простые метаданные. Конечно, встречаются вырожденные случаи, когда на базе ECM реализуют фунционал бухгалтерии или чего похлеще... Но мы ведь не о таких?

Поэтому в большинстве случаев Web-интерфейса ECM хватает просто за глаза. Ну и некоторые идут дальше - организуют достаточно хорошую интеграцию с клиентами. Например, Sharepoint и MS Office - при правильной настройке я могу обращаться к интерфейсу Sharepoint только отдельных задач, а большую часть (открытие

простите, не дописал... нажал "отправить" раньше

(открытие/закрытие документов, изменение их метаданных, управление версиями, поиск, ...) - все это можно делать из интерфейса клиентских приложений или Windwos Explorer.

iscrafmэто не корректное сравнение.
Почему некорректное?
Вы спрсили в каких системах web-клиент не уступает desktop. Я ответил: там где web - единственный клиент.

Я реально не знаю ни одной ECM системы, которая бы имела Web-клиент изначалаьно и начала бы разрабатывать desktop. И наоборот, почти все, имевшие изначально desktop-клиента либо выпустили web (но он почти везде уступает настольному, ибо требует серьезной переделки архитектуры системы и поддерживать и развивать его сложно), либо полностью перешли на web-клиент.

Единственное исключение - клиенты для мобильных устройств.
Но там есть особенности, с которыми приходится мириться и из-за придется или разрабатывать хитрую версию Web-интерфейса или разрабатывать свой специализированный клиент:
- ограничения поддержки некоторых протоколов. Например, настольная Windows поддерживает WebDAV со времен 98-ой, а в Windows Mobile/Windows Phone/iOS/(не уверен)стоковом Android - поддержки его "из коробки" нет.
- необходимость работы вне офиса (т.е., скорее всего по ограниченным каналам или вообще вне доступа к сети). Т.е. нужен режим off-line или что-то типа подобного.
- малые размеры и необходимость специализированной верстки интерфейса.
- отсутствие привычных клиентски приложений с которыми была сделана глубочайшая интеграция.
...

МихаилРчто понимается под "сложностью"?
Примерно так:
- наличие больших списков на множество столбцов,
- наличие форм с большим количеством полей и сложной логикой отображения,
- необходимость использовать какие-либо нестандартные контролы,
- необходимость использовать горячие клавиши, сложный Drag&Drop.

В принципе, сейчас даже большую часть из перечисленного можно с приемлемыми трудозатратами реализовать для Web-клиента. Но как я уже говорил, для большинства ECM систем это не нужно.
Ведь, что собой представляет типичный документооборот?
1. Хранилище документов (тел) с карточками. Карточки, в большинстве своем, простые - 10-20 полей (монстры тоже встречаются, но это вырожденный случай), часть полей - простые скалярные, часть - ссылки на справочники (контрагент, автор, ...). Справочники зачастую ведутся в других системах.
2. Манипуляция с телами: сохранение/извлечение, версии, ...
3. Навигация и поиск (навигация - обычная иерархия, поиск - по атрибутам и тексту).
4. Запуск/исполнение процессов (WorkFolw). Которые представляют собой форму на странте да несколько простейших форм на этапах выполнения.

Все остальное (т.е. именно создание контента), как правило, делается в клиентских приложениях. СЭД обеспечивает только backend - базу, логику, хранилище, движки поиска и Workflow, ...

Есть конечно и отхождения от этого правила: например, некоторые ECM имеют средства для создания контента в виде страниц сайтов (как многие CMS), блогов, Wiki, но вот честно, я пока не вижу в Enterprise для этого какой-то большой заинтересованности. А если что-то подобное появляется, то используются специализированные платформы, а ECM, в лучшем случае, служит только хранилишем или поисковым агрегатором.

iscrafmа зачем тогда браузер? Только для банального просмотра контента, если нет под рукой нормального клиента?
Ну почему...
Навигация по хранилищу остается в Web-клиенте, там же обычно и поиск (там, где нужен не просто текстовый а-ля Google поиск, а полноценный поиск по атрибутам). Если карточка все же имеет некоторую логику (например, банальные зависимые поля), её все равно не возможно будет реализовать на клиенте - средств таких нет.

Плюс всякие, не связанные непосредственно с контентом задачи:
- ведение справочников/списков (если они не синхронизируются извне)
- специализированные манипуляции над контентом. Например, регистрация документа или создание record, ...

iscrafmгде нет таких средств, не совсем понял? Это же банальная возможность любого смарт-клиента
Прошу прощения, не совсем корректно выразился.

Под клиентскими приложениями во всех своих комментариях я имел в виду приложения, которые используются для создания и редактирования контента: Office, Adobe (Reader), графический редактор, CAD, ...

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

А вот когда этого не хватает - нужен специальный клиент web или desktop/smart это уже другой вопрос.

antares0А можно пример "сложного интерфейса" учетной системы?
Я же вроде расписал тут 15009114 .
Примерно так:
- наличие больших списков на множество столбцов,
- наличие форм с большим количеством полей и сложной логикой отображения,
- необходимость использовать какие-либо нестандартные контролы,
- необходимость использовать горячие клавиши, сложный Drag&Drop.