Support Forum

[a-b-c]

На мой взгляд, сам инструмент достаточно интересен - коллективный взгляд на желаемые фичи + обратная связь от Вас. Я думаю, что тут нужен правильный дисклеймер - со ограничением срока жизни каждого предложения (навскидку - не больше года, если срок прошел - вывод - сделаем в таком-то релизе, не сделаем), с указанием, что данный список фич имеет рекоммендательный характер, и в любом случае как развивать продукт - будете решать Вы и только Вы (это довольно очевидный факт, странно, что он так плохо воспринимается пользователями).
Фич реквестов в любом случае будет больше, чем можно реализовать, и отказ в реализации (в разумных рамках планирования) я считаю вполне нормальным отношением к клиентам. Откажись Atlassian в 2004 от этой фичи - было бы проще всем.

Теоретически да, а практически - вот:
http://jira.atlassian.com/browse/JRA-3821

Atlassian сегодня прикрыла еще одну задачу с комментарием "не будем делать в ближайшем будущем", посмотрите комментарии за 25 августа.

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

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

Без такого инструмента сложно представить, что будет с TS в течение года.

Я и сам сейчас не знаю. В ближайшее время планируем заниматься багами и мелкими улучшения, потом сайтом, потом будем думать над "большой идеей" для следующей версии. Для 4.0 "большой идеей" было упрощение интерфейса, по поводу следующей версии пока ничего не могу сказать - еще не думали на эту тему. Один из вариантов - замена RDBMS на какой-нибудь NoSQL движок (Neo4j?)

Я тут подумал, на самом деле и простого roadmap'а хватит, чтобы решить этот вопрос. Чтобы он был актуален и отражал Ваше видение развития продукта на ближайший год. В этом способе нет проблемы пользовательского "давления", поэтому для Вас он даже лучше, чем голосовалка по фичам.

[admin]

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

На самом деле 8 лет
http://jira.atlassian.com/browse/JRA-38 ... ent-139565

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

Я тут подумал, на самом деле и простого roadmap'а хватит, чтобы решить этот вопрос. Чтобы он был актуален и отражал Ваше видение развития продукта на ближайший год. В этом способе нет проблемы пользовательского "давления", поэтому для Вас он даже лучше, чем голосовалка по фичам.

Да, понятно, но пока никакого roadmap у меня нет. Сейчас мы правим все что можем исправить по запросам клиентов, если это не требует модификации базы или серьезного изменения архитектуры. В 3.5 основная проблема была с юзабилити, поэтому в 4.0 в основном правили интерфейс. Какая проблема будет доминирующей в 4.0 - пока сказать сложно. Думаю, какая-то определенность тут наступит через полгода или около того.

[a-b-c]

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

[admin]

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

Ну, мы просто старались устранить наиболее популярные проблемы в 3.5, вроде:

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

- убрали настройку прав в виде больших матриц, тоже были проблемы с пониманием.

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

По поводу web 2.0 - есть положительный опыт использования GWT/GXT, но еще раз переписывать интерфейс пока не хочется, и так в каждой версии переписываем. Вторая большая задача - отказ от реляционной СУБД и кеширования всего в памяти в пользу нереляционной СУБД (все равно мы от реляционности почти ничего не используем). Но если сделать то и другое, то от нынешней TrackStudio вообще ничего не останется.

А чего именно в плане web 2.0 не хватает ? Возможно, это какие-то частные проблемы на отдельных страницах ?

[a-b-c]

- убрали настройку прав в виде больших матриц, тоже были проблемы с пониманием.

Эх, с 3.5 не работал, как раз хотел предложить использование матриц Сейчас не очень удобное представление всей картины в целом, для понимания, что происходит в процессе в разрезе "операции-роли" приходится либо обходить все операции, и для каждой настраивать может ли видеть/выполнять/быть ответственным для ролей, либо обходить все роли, и для каждой настраивать, что может видеть/выполнять/быть ответственным.

Жаль, что не оставили оба варианта, для новичков - текущий способ, для более продвинутых - матрицы.

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

[admin]

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

А это было в TrackStudio 2.0-3.0 В смысле, вверху была шапка задачи, а внизу - subtasks или view/edit task + messages. Жаловались, что слишком много всего на одном экране и вообще непонятно.

[a-b-c]

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

А это было в TrackStudio 2.0-3.0 В смысле, вверху была шапка задачи, а внизу - subtasks или view/edit task + messages. Жаловались, что слишком много всего на одном экране и вообще непонятно.

Нет-нет, всё на одной странице и частичное смешивание (по ситуации) - это разные вещи.
Пример: по умолчанию вижу список задач, выделил задачу - задача из одной строки развернулась в целую секцию, в которой доступны все основные поля + допполя. Справа напротив каждой - доступные действия в виде иконок. Нажал - тут же втиснулась или появилась поверх задач секция выполнения операции, "выполнить" - тут же состояние задачи поменялось, продолжили со следующей.
Я вижу потенциал для увеличения в скорости работы в том, что можно сразу загрузить весь интерфейс, и затем подгружать лишь данные (например, в XML или JSON), без лишнего груза в виде его оформления.

[Petr]

а скорость работы это все равно не увеличит. все тормоза связаны с проверкой секъюрити. а web 2.0 только удобства добавит

[a-b-c]

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

[Petr]

да логично. но тут большая работа должна быть по поводу что делать через ajax. Да и возможно что интерфейс будет переписыватся на gwt gxt, но это еще очень не скоро.
А пока можно обсудь, что хочется видеть через ajax. если правки не сложные можем сделать.