FeyFre wrote:Ваша точка зрения "я привык к менюшке у трея и хочу это же здесь" ясна.
Только отчасти. Вот правильный ответ:
[Yustas.NeO] wrote:существует юзабилити, интуитивная понятность
Можно конечно делать попугаиный интерфейс, как у KMPlayer'а или функциональность, но нелогичность/непривычность TagScanner'а... Так вот, чтобы такого не было и существуют негласные (не удивлюсь, если есть даже литература) правила написания приложений, а также проектирование ПО.
FeyFre wrote:Меня убеждать нужно оно Вам или нет...
Но не ждите что "Юзабилити" для него самый приоритетный приоритет.
Заметьте, Вы меня убеждаете и опять указываете мне, что мне делать (не делать), а я сам знаю что мне делать
Тем более, что я не просил совета по этой теме.
Так что лучше - воспользуйтесь своим же советом:
FeyFre wrote:Совет - забейте.
А сделает что-то Инструктор или осознаю что-то я, Вас ни коим боком не должно волновать, т.к. тема не Ваша и предложение адресовано не Вам.
Если я не согласен с чем-то предлагаемым, я просто пишу, что против, и высказываю свои аргументы. А Инструктор услышит и разберётся как-нибудь сам. Думаю, уж как-то справится с этим, не так ли?
По сообщению чуть выше:
FeyFre wrote:А я и не говорю что у нас в документации всё есть. Но когда есть, а уроды не читают, а хнычат в трубку "а почему нету рюшечки?" то мне плевать на остальные факторы.
Это говорит об одном - у вашей организации нормально не отстроены отношения с заказчиками. Сотрудники Заказчика, звоня, не должны спрашивать о том, "чего нет" или "где это найти", т.к. эти вопросы решаются на местах: Справка (при условии, что оно написана правильно, т.е. не для себя а для обычных людей - простым и понятным языком) или помогают местные "корифеи" (админы, местные продвинутые юзеры, которые обучаются по более расширенной программе и т.п.). Максимум, что сотрудники Заказчика могут спрашивать, это "почему у меня это не работает", и то, только если они прошли всех своих корифеев (продвинутые юзеры, затем админы, а потом уж к нам). Да и то, не "спрашивать, почему не работает", а констатировать факт (в чём во взрослых системах нет необходимости, т.к. логи об ошибках отправляются разработчику раньше, чем юзер успел сообразить позвонить...)
А предложения по "доработкам", если таковые имеются, должны аккумулироваться у руководителя проекта со стороны Заказчика, согласовываться с фирмой-разработчиком на совещаниях не чаще раза в месяц, и уже потом только согласованные должны официально передаваться фирме-разработчику.
Вся эта механика отстраивается приходя в организацию Заказчика (приказами или положениями), на этапе подписания документов о начале работы.
Не буду Вам говорить, кого нужно поблагодарить за положение вещей в вашей организации по той же причине, что и сам не люблю, когда мне чего-то настоятельно пытаются "объяснить" без моей просьбы. Мораль проста:
"Не говорите что мне делать, и я не скажу куда Вам пойти" (c)
