Support Forum

[ValPot]

Вопрос, конечно, тянет на провокацию, однако. Реализация всего пользовательского интерфейса приложения на Java, вызывает у меня, привыкшего к десктоп приложениям, противоречивые чувства. Однако, если идти другим путем, типа:

http://www.runaware.com/disclaimer-hots ... otspot1435

то можно совместить, привычный для некоторых интерфейс с Web доступом, причем не вместо, а в дополнение. Необходимо "только" на существующую БД TS надеть привычную десктоп оболочку. Кто видит объективные технические или экономические сложности такого подхода? Мне, как диалетанту, это кажется простым и естественным решением доведения отличного продукта компании до более широких масс потенциальных пользователей ТS.

[admin]

Вопрос, конечно, тянет на провокацию, однако. Реализация всего пользовательского интерфейса приложения на Java, вызывает у меня, привыкшего к десктоп приложениям, противоречивые чувства. Однако, если идти другим путем, типа:

http://www.runaware.com/disclaimer-hots ... otspot1435

то можно совместить, привычный для некоторых интерфейс с Web доступом, причем не вместо, а в дополнение. Необходимо "только" на существующую БД TS надеть привычную десктоп оболочку. Кто видит объективные технические или экономические сложности такого подхода? Мне, как диалетанту, это кажется простым и естественным решением доведения отличного продукта компании до более широких масс потенциальных пользователей ТS.

А у нас есть desktop-клиент (писался как пример использования SOAP API). Но,
- он довольно некрасивый
- тормозной
- есть известные глюки.

Судя по тому, что за последние 2 года не него была _1_ жалоба, никому он не нужен (или в таком виде никому не нужен).

[ValPot]

А у нас есть desktop-клиент (писался как пример использования SOAP API). Но,
- он довольно некрасивый
- тормозной
- есть известные глюки.

Судя по тому, что за последние 2 года не него была _1_ жалоба, никому он не нужен (или в таком виде никому не нужен).

А можно чуть подробнее:

1. На чем написан?
2. Как ознакомиться?
3. Есть ли у Вас рабочая модель работы с ним в Web?

Ну и конечно, не мне Вам рассказывать о первых блинах.

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

[admin]

1. На чем написан?
2. Как ознакомиться?
3. Есть ли у Вас рабочая модель работы с ним в Web?

Ну и конечно, не мне Вам рассказывать о первых блинах.

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

Написан на Java, попробуйте зарегистрироваться на сайте и скачать/поставить TrackStudio DevPack. Можете попробовать присоединится к TS Host:
host.trackstudio.com/TrackStudio

По поводу вопроса 4 - думаю, что проблема не в сложности интерфейса, а в сложности концепций/приложения. Просто интерфейс - это первое что видят пользователи, поэтому ему больше всех достается

Например, видит пользователь систему в первый раз и хочет багу создать. Где кнопка "Create a bug" - непонятно, где dropdown с выбором проекта - тоже. Но во всех остальных системах были, значит и тут должны быть, а раз не могу найти/неочевидно где искать - значит интерфейс сложный.

[vadimk]

Proshu prosheniya sa yasyk - pishu s laptopa bes russkoy klaviatury.

Sloshnost' koncepcii ne snimaet otvetstvennosti sa usability. Desktop
programmy namnogo bolee udobny chem Web based dashe s AJAXom. Takshe nokotorye koncepcii ne stolko sloshno skolko khlopotny, i Web interface dobavlyaet k khlopotnosti.

Neskolko mest i primerov gde eto osobenno sametno (spisok daleko ne polniy).

1. Administration, osobenno permissions, possible values dlya spiskov.
2. Context switch. Navigaciya typovoy dekstop programmy - okno so spiskom i pop-up (modal ili modeless) okno s vybrannym elementom. Typovaya navigaciya v Webe - stranica so spiskom, perehod na stranicu s elementom, vosvrashenie na stranicu so spiskom. Primery problem v svyasi s podobnoy navigaciey:
a) Nahoshus' v sadache. Svyasyvayu sadashu s drugimi. Nushno posmotret' detali svyasannoy sadashi. Stoyu pered vyborom - ili otkryt' paralleno drugoe okno TS i vruchnuyu snavigirovat' na nushnuyu sadachu, ili poteryat' tekushiy context.
b) Imeyu 140 sadash v liste raskidannye na 3 stranicy po 50. Nushno sosdat' neskolko novyh i porabotat' s sadachami 135, 138 i, dopustim 98. Delat's specialniy filter dlya etoy raboty smysla net - cheres pol chasa ya budu rabotat' s sadachami 121, 100 i 36. Idu na stranicu 3, vibirayu 135, rabotayu, (otdelnaya problema - net vosvrata sa isklucheniem vybora roditelya v puti ili vybora "Edit" chtoby vybrat' "Save and Go to Parent"), vosvrashayus' v sadachu-roditel' - prvilno na stranicu 1 i nado idti opyat' na stranicu 3 dlya sadachi 138. V desktop modeli ya by mog otkryt's neskolko sadach i ne teryal by tekushee mesto spiska.
c) Peregruska ekrana. Situaciya: sadacha dolshna proyti cheres neskolko sostoyaniy. V idealnom mire - developer vypolnil deystvie, pomenya sostoyanie, i t.d. Eshe esli nad sadachey rabotayut neskolko developerov, eto kak-to rabotaet, a tak k koncu raboty prihoditsay prognat' task cheres neskolko sostoyaniy podryad (inigda eto polesno, tak kak na hodu mosho sametki sdelat'). A k relisu nabegaet horoshee kolichestvo takih sadach. AJAX vesh horoshaya, no do isvestnoy stepeni: IE s TS sanimaet 75M+ dashe dlya togo chto keshiruetsya, a pri smene sostoyaniy ekran peregrushaetsya, trebuetsya vremya na novoyu stratnicu, ona vosvrashaets v sostoyanie soobsheniy - ochen' neuyutno i khlopotno.

Web interface delaet systemu bolee mobilnoy i dostupnoy, desktop interface delayet rabotu bolee udobnoy i proisvoditelnoy.

Dlya developerov ya by ostavil Web interface - oni ne delayut massirovannih ismenenii v sisteme i , i mne ne nado dumat' ob ustanovke novoy versii, oni mogut rabotat' remotely i t.d, V to vremya dlya menya (i kogda budut - dlya managerov) situaciya naoborot - nam nushno ochen' udobniy intrerface, v to vremya kak nash environment podgotovlen pod rabotu my delayem - s tochki sreniya konfiguracii.

[admin]

1. Administration, osobenno permissions, possible values dlya spiskov.

Permissions переделываем, а что с возможными значениями списков ? Неудобна перегрузка страницы после добавления каждого элемента?

2. Context switch. Navigaciya typovoy dekstop programmy - okno so spiskom i pop-up (modal ili modeless) okno s vybrannym elementom. Typovaya navigaciya v Webe - stranica so spiskom, perehod na stranicu s elementom, vosvrashenie na stranicu so spiskom. Primery problem v svyasi s podobnoy navigaciey:
a) Nahoshus' v sadache. Svyasyvayu sadashu s drugimi. Nushno posmotret' detali svyasannoy sadashi. Stoyu pered vyborom - ili otkryt' paralleno drugoe okno TS i vruchnuyu snavigirovat' na nushnuyu sadachu, ili poteryat' tekushiy context.

TS без особых проблем переносит открывание ссылки в другом окошке. Т.е. можно по shift-Click открыть другое окошко, там перейти куда надо и посмотреть, потом закрыть окно и в исходном окне указать что требуется.

b) Imeyu 140 sadash v liste raskidannye na 3 stranicy po 50. Nushno sosdat' neskolko novyh i porabotat' s sadachami 135, 138 i, dopustim 98. Delat's specialniy filter dlya etoy raboty smysla net - cheres pol chasa ya budu rabotat' s sadachami 121, 100 i 36. Idu na stranicu 3, vibirayu 135, rabotayu, (otdelnaya problema - net vosvrata sa isklucheniem vybora roditelya v puti ili vybora "Edit" chtoby vybrat' "Save and Go to Parent"), vosvrashayus' v sadachu-roditel' - prvilno na stranicu 1 i nado idti opyat' na stranicu 3 dlya sadachi 138. V desktop modeli ya by mog otkryt's neskolko sadach i ne teryal by tekushee mesto spiska.

Предлагаю такое решение:
- выводим список с нужными задачами через окно поиска в правом верхнем углу, там можно вводить вещи в духе 1-5, 135, 138.
- открываем каждую задачу в отдельном окошке/tab-е браузера, после редактирования и записи окошко закрываем.

c) Peregruska ekrana. Situaciya: sadacha dolshna proyti cheres neskolko sostoyaniy. V idealnom mire - developer vypolnil deystvie, pomenya sostoyanie, i t.d. Eshe esli nad sadachey rabotayut neskolko developerov, eto kak-to rabotaet, a tak k koncu raboty prihoditsay prognat' task cheres neskolko sostoyaniy podryad (inigda eto polesno, tak kak na hodu mosho sametki sdelat'). A k relisu nabegaet horoshee kolichestvo takih sadach. AJAX vesh horoshaya, no do isvestnoy stepeni: IE s TS sanimaet 75M+ dashe dlya togo chto keshiruetsya, a pri smene sostoyaniy ekran peregrushaetsya, trebuetsya vremya na novoyu stratnicu, ona vosvrashaets v sostoyanie soobsheniy - ochen' neuyutno i khlopotno.

Есть 2 идеи:
- а что если сделать message type "superclose", доступный только админу и который бы позволял закрыть задачу из любого состояния ? Тогда проблема прогоняния задачи через несколько состояний решается.
- если нужно добавить message type к нескольким задачам (например, закрыть их), то лучше всего использовать bulk processing tool.
http://www.trackstudio.com/documentatio ... Tasks.html
Очень полезная штука если нужно собрать, например, все старые задачи и по всем ним вынести какое-то решение (закрыть, отправить на доработку и т.п.).

Web interface delaet systemu bolee mobilnoy i dostupnoy, desktop interface delayet rabotu bolee udobnoy i proisvoditelnoy.

Dlya developerov ya by ostavil Web interface - oni ne delayut massirovannih ismenenii v sisteme i , i mne ne nado dumat' ob ustanovke novoy versii, oni mogut rabotat' remotely i t.d, V to vremya dlya menya (i kogda budut - dlya managerov) situaciya naoborot - nam nushno ochen' udobniy intrerface, v to vremya kak nash environment podgotovlen pod rabotu my delayem - s tochki sreniya konfiguracii.

Да, во многих системах админский интерфейс именно desktop-ный, но он обычно локально-десктопный (т.е. предполагается что система и админский интерфейс работают на одной машине, либо идет подсоединение к удаленной СУБД через DBMS-ные протоколы).
В TS админский интерфейс получился web-based по нескольким причинам:

1) Так достигается большая гибкость, т.к. пользователь сам решает что будут делать админы, а что - обычные пользователи. Скажем, если настраивать workflow в пользовательском интерфейсе скорее всего не надо, то редактировать правила подписки - почему бы и нет ?
http://www.trackstudio.com/documentatio ... nefits.pdf

2) В TrackStudio пользовательские и админские задачи изрядно перемешаны. Скажем, редактирование проектов - это админская задача, а редактирование багов - пользовательская, но сейчас для них используется один и тот же интерфейс.
Положительная сторона и у этого момента есть - мы используем один и тот же код (весьма оптимизированный) и для проектов, и для багов. В большинстве систем работа с багами обычно более-менее ОК, но если у вас 200+ проектов, то багтрекилка может выглядеть ужасно или просто тормозить. Обычно для проектов нельзя сделать кастом-поля, workflow, даже отфильтровать их по-человечески нельзя - ведь для этого придется писать отдельный код, отдельные экраны интерфейса, отдельную документация и система распухнет очень быстро.
В качестве примера посмотрите codehaus, а ведь у них не так много проектов:
http://jira.codehaus.org/secure/Dashboard.jspa

3) Упрощается создание managed admins, которые должны иметь админские функции, но для каких-то отдельных задач, а в остальном они обычные пользователи.

Но вообще причины у всего этого исторические - TrackStudio начиналась с TrackStudio Host и тогда главная проблема была такая: как обеспечить чтоб 1000+ админов могли работать с одним экземпляром системы не очень мучаясь с desktop-клиентами, их обновлениями, firewall и прочим. Т.е. для нас клиентами изначально и были админы, а задачи которые нужно манагерить и организовывать - это не юзерские баги, а их проекты

TrackStudio Enterprise появилась где-то через год, но унаследовала все плюсы и минусы TrackStudio Host. Сейчас мы потихоньку отказываемся от несильно важных для Enterprise версии фич в пользу большей простоты системы (в 3.5.x исчезла иерархия юзерских групп, в 4.0 нельзя будет через web-интерфейс редактировать скрипты и e-mail templates, уже убрали поддержку кластеров).

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

В этом смысле показателен пример со всякими extreme programming, test-driven development и т.п. - большое количество организаций предпочитают не автоматизировать свой имеющийся процесс, а потом постепенно доводить его до ума, а взять что-то изрядно чуждое текущей культуре, но работающее, и попробовать внедрить.

[vadimk]

Да, во многих системах админский интерфейс именно desktop-ный, но он обычно локально-десктопный (т.е. предполагается что система и админский интерфейс работают на одной машине, либо идет подсоединение к удаленной СУБД через DBMS-ные протоколы).

1. Доступ к адаленной базе с десктопа - не сильно уникальная ситуайия, и я думаю, что все базы, с которыми вы работаете, это поддерживают.

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

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

Bulk tool - предполагает массовые одинаковые изменения. Как правило перед релизом мне приходится сидеть с TS изрядно, но к сожалению делать разные изменения. Также bulk processing через фильтры - есть что-то не натуральное в этом - исторически это мог быть шаг в эволюции фильтров, но с токи зрения пользователя - это не там, где бы я эту функциональность искал. По моему небольшому опыту с этой функцией, еслт у меня есть 10 даже 15 задач, проделать вручную (со всеми текущими неудобтсвами) все равно бытсрее, чем через bulk processing tool. Опять-таки, этот инструмент предназначен для пользователей, но предполагает серъезного планирования действий и хорошего глубокого понимания системы, что обычно присутствует не у пользователей, а у администраторов.

а что с возможными значениями списков ? Неудобна перегрузка страницы после добавления каждого элемента?

You bet - в точку: оченб неудобно!

TS без особых проблем переносит открывание ссылки в другом окошке. Т.е. можно по shift-Click открыть другое окошко

Хорошая идея - не заменяет десктоп навигацию, но поможет.

выводим список с нужными задачами через окно поиска в правом верхнем углу, там можно вводить вещи в духе 1-5, 135, 138.

Идея хороша сама по себе, но предполагает подготовку номеров заранее. Также породит проблемму постоянной перегрузки фильтров.

открываем каждую задачу в отдельном окошке/tab-е браузера, после редактирования и записи окошко закрываем

В отличие от десктоп программ, где каждое окно специализировано, подымать TS окна с полной оконной навигацией, путями линков, меню и т.д. произведет хаос. Это и сейчас возможно - как было посоветовано через Shift-Click - но это требует помнить, как заходить в окно задачи, что не очень практично - если надо специально помнить пользователю как нажимать кнопки в конкретной комбинации условий - система неудобна. Опять таки - TS удобна, когда надо выполнить пару отдельных дейтсвий в системе - для тестера, для девелопера. Неудобтсва начинаются, когда нада побегать по системе в течении продолжительного времени для разных действий - руководство проекта, администратор.

Думаю, что многие наши проблемы со сложностью системы из-за этого - вместо отдельного интерфейса админа, программиста и клиента, TrackStudio предполагает что админ сам все настроит как ему нужно.

TS должна ориентироваться на групповое использование. При этом, как ни парадоксально, администратор - не часть этой группы, кто должен использовать этот инструмент для управления проектов. Админитратор должен настраивать систему для нужд группы, при этом он будет под постоянным стрессом от каждого участника этой группы пользователей, которая не однородна: руководство должно иметь возможность выполнять разнообразные действия и регулярно - 5 лишних кликов на действие могут стоить несколько часов в день; я у себя не предполагаю, что программеры открывают задачу, до тех пор, пока им не надо сделать изменение в статусе - но при этом они часто работают со списком заданий, те действия, которые им надо сделать в системе должны быть достаточно натуральны для них, иначе они (люди) будут лениться и отлынивать от ее использования; интрефейс для тестеров и суппорт персонала должен быть оптимизирован под быстрое создание дефекта и под роботу со списком.

Поэтому TS и сложно в настройке - она должна иметь достаточное количество настраиваемых параметров для пользователя, группы пользователей, для категории задач и проектов, чтобы обеспечить пользователям возможность применения системы без лишних компромиссов между системой и процессом. Поэтому и подымается вопрос не функциональности (великолепний набор функций! ), а вопрос легкости и натуральности в использовании.

[admin]

1. Доступ к адаленной базе с десктопа - не сильно уникальная ситуайия, и я думаю, что все базы, с которыми вы работаете, это поддерживают.

Да, но там бывает специфика с настройкой (Firewalls, security, etc), обычно внутренний протокол работы с СУБД не сильно оптимизирован (т.е. через медленное соединение с базой не поработаешь особенно). Плюс ко всему TrackStudio часто использует много мелких запросов для доступа к данным, поэтому по сети все будет очень тормозить. Скажем, нынешний SOAP-клиент локально работает нормально, но если подсоединится к TS Host через ADSL - жуткий тормоз.

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

Это понятно, но если десктоп-версию для программиста сделать относительно несложно (не так много действий он должен выполнять и меняется она относительно редко), то с интерфейсом администратора все по-другому: там и разных объектов больше, и API сложнее, и меняется все очень часто. Ну т.е. полезность десктоп-клиента я в принципе понимаю, но заняться его написанием мы сейчас не потянем.

Bulk tool - предполагает массовые одинаковые изменения. Как правило перед релизом мне приходится сидеть с TS изрядно, но к сожалению делать разные изменения. Также bulk processing через фильтры - есть что-то не натуральное в этом - исторически это мог быть шаг в эволюции фильтров, но с токи зрения пользователя - это не там, где бы я эту функциональность искал. По моему небольшому опыту с этой функцией, еслт у меня есть 10 даже 15 задач, проделать вручную (со всеми текущими неудобтсвами) все равно бытсрее, чем через bulk processing tool. Опять-таки, этот инструмент предназначен для пользователей, но предполагает серъезного планирования действий и хорошего глубокого понимания системы, что обычно присутствует не у пользователей, а у администраторов.

Да, не очень интуитивная фича и находится она не там где ждут (массовое изменение задач имеет мало отношения к фильтрам). Что делать - пока не очень понятно, но язамечаю что для более-менее сложного bulk processing-а пользователи склоняются к CSV Import, он существенно гибче.

а что с возможными значениями списков ? Неудобна перегрузка страницы после добавления каждого элемента?

You bet - в точку: оченб неудобно!

Хорошо, а что если вместо input line для ввода нового значения сделать textarea, тогда туда можно будет вставлять много значений сразу, причем методом copy/paste ? Так будет нормально ? Можно ли это для заполнения чего-то еще использовать ?

Опять таки - TS удобна, когда надо выполнить пару отдельных дейтсвий в системе - для тестера, для девелопера. Неудобтсва начинаются, когда нада побегать по системе в течении продолжительного времени для разных действий - руководство проекта, администратор.

Странно, мы ориентировались как раз на админов и думал что для админов TS удобнее многих других систем (наследование настроек, делегирование части админских функций другим пользователям, доступ через web).

TS должна ориентироваться на групповое использование. При этом, как ни парадоксально, администратор - не часть этой группы, кто должен использовать этот инструмент для управления проектов. Админитратор должен настраивать систему для нужд группы, при этом он будет под постоянным стрессом от каждого участника этой группы пользователей, которая не однородна: руководство должно иметь возможность выполнять разнообразные действия и регулярно - 5 лишних кликов на действие могут стоить несколько часов в день; я у себя не предполагаю, что программеры открывают задачу, до тех пор, пока им не надо сделать изменение в статусе - но при этом они часто работают со списком заданий, те действия, которые им надо сделать в системе должны быть достаточно натуральны для них, иначе они (люди) будут лениться и отлынивать от ее использования; интрефейс для тестеров и суппорт персонала должен быть оптимизирован под быстрое создание дефекта и под роботу со списком.

1) Мы оптимизировали первые версии TS под кол-во кликов для совершения действий, но сейчас мне это не нравится:

- админы многие действия выполняют редко. Если админ захочет через год использования создать новый workflow, то пусть он лучше лишних 20 кнопок нажмет, чем будет вынужден лезть в документацию чтоб вспомнить как это делается. Я по себе замечаю - во всяких фотоаппаратах/видеокамерах я не использую кучу сложных функций (типа picture-in-picture, настройки выспышки и т.п.) т.к. в меню их настройки нет, а как пользоваться "быстрым" доступом через кнопки я уже не помню.

- обычный пользователь часто про систему вообще ничего не знает и читать документацию не собирается, лучше он нажмет лишние кнопки, чем напишет нам в саппорт что система too complex for use

2) А можно подробнее про работу со списком и что от него нужно ? У нас это выглядит так - у программера висит список "его задач", он их делает по-одной, добавляет message = "resolve" и опять переходит к списку через go to the parent.

Поэтому TS и сложно в настройке - она должна иметь достаточное количество настраиваемых параметров для пользователя, группы пользователей, для категории задач и проектов, чтобы обеспечить пользователям возможность применения системы без лишних компромиссов между системой и процессом. Поэтому и подымается вопрос не функциональности (великолепний набор функций! ), а вопрос легкости и натуральности в использовании.

Да, я отлично понимаю, поэтому мы сейчас фокусируемся именно на простоте настройки.

Главная наша проблема такая - пользователь скачивает TS, смотрит на нее день, не может разобраться с чем-то и забивает с оставлением сообщения в feedback form типа "too complex for use". Возникает вопрос - а с чем именно он не разобрался и почему ?

1) Просто вообще ничего не понял ? Вряд ли - есть 2 демо-проекта (один из них полностью готов к использованию), есть flash-демка где показано почти все.

2) Permissions ? В самом деле, матрицы выглядят страшновато, переделаем в следующей версии. Но и у конкурентов Permissions - не самая простая часть системы, почему это там не приводит к таким проблемам и почему нельзя для начала использовать проект itadmin, где уже все настроено - непонятно.

3) Что-то еще ?

Мне кажется, что те упрощения что мы обсуждаем (bulk processing, редактирование списков) - это все правильно, но большинство пользователей до них не доходят.

[vadimk]

Чувтсвуется глобальное понимание проблеммы - и это хорошо. Я попробую понаблюдать за своим и своих ребят использованием системы, и попробую выразить проблеммы usability попробнее.

Как обобщенный коментарий, система задумывалась как системы для администраторов и она достигла хорошего уровня гибкости (понятно, улучшать можно до бесконечности). Но она никогда не задумывалась с точки зрения семантики пользовательского интерфейса - для usability. Один из критериев usability - количество нажатий для выполнения одной задачи. Другой критерий - время на выполнения задачи - learnability - если это время не уменьшается с повторным использованием системы, интерфейс не интуитивный. При этом этот анализ надо применять к каждой отдельной группе пользователей - админы, руководители, тестеры, программеры, поддержка, техподдержка и т.д.

Могу, кстати, привести в пример подход Microsoft (из их блога о новом Оффисе) - они регистрируют все действия пользователя - не только какие команды выбираются, но и чем эти команды включаются (меню, тулбар, клавиши), и в каком порядке и в контектсе каких задач. Понятно, что этот подход не для каждой организации - у них силенок побольше. Но что-то вы проанализировать сможете - через хостет версию и даже в Enterprise. Также подготовьте опросник (многопутевой - чтобы не испугать тех, кто подробно не хочет, но со всеми вовросами для тех, кто готов помочь больше) и разошлите по емайлам текущих клиентов. Я думаю, что затраты на такой анализ окупятся лучшей системой.