Как неправильно писать UI или борьба с ветряными мельницами

[Sla]

Берем некий объект ограниченного доступа.
1. Пишем UI для админских нужд, естественно пихаем "кнопочки и бимбочки"
2. Даем права на выполнение объекта юзеру
3. Забываем проверять доступность "кнопочек и бимбочек" юзеру.

Что видит пользователь?
Правильно. Кнопочки и бимбочки
Что делает пользователь?
Угадали.
Жмакает на кнопочки и бимбочки

Что пользователь получает взамен?
Ну... Вы ребятки умные - сами догадались
"У вас нет прав на выполнение операции. Обратитесь к администратору"

Но это некая часть беды.

Создаем форму для запроса
Куча полей, галочек, точечек
На заполнение формы уходит около минуты (особенно если в первый раз)
Тыкаем на кнопочку "Запустить"

Как вы думаете, что произойдет?
Ну... тут возможны два варианта (а может и больше - пока вижу два) и оба некорректные
1. "У вас нет прав на выполнение приложения. Обратитесь к администратору"
2. Выдать пустой отчет.

Если с 1-ым еще как бы можно согласиться - ну нет прав и фиг с ним. Но соглашаться не хочется. Право на запуск приложения должно проверяться при инициализации онного, а не при выполнении.
Но второй - это убитое время. Раз пустой отчет => не правильно натыканы галочки и точечки- надо перетыкивать, еще время, и еще.

Как после этого икается разработчикам

[Finch]

Sla,

Как после этого икается разработчикам Жаль

Спокойно икается. Так как затем можно выпустить еше одну версию, более улучшенную. А это время. И можно преподать как новую фичу

[Джон]

Слав, я не понял? Это крик души?

А серьёзно - этож прописные истины. Не думаю, что тот кто производит такое ПО может называться разработчиком ПО.
У нас в конторе с этим очень строго - если я нечто подобное сделаю, то в лучшем случае буду исправлять "за свой счёт".

[Sla]

Слав, я не понял? Это крик души?

Типа ДА!!!!!!

и в продолжение
Мышинная возня
Ненавижу GUI, в котором не предусмотрен клавиатурный эквивалент
Ползанье мышью, типа Файл, открыть, или Обновить, или Фильтр и т.д и очень долгое щелканье мышей

Да я по клаве быстрее стукаю.
Я как-то поцапался с разработчиком(разработчицей) по этому поводу.
Аргумент был не убиенный - "А пользователю нравится!"
а то что от этой возни время уходит - пусть быстрее мышью щелкает.

А у нее учитель был. А у него замечательная фраза - "Минимум трафика - максимум удобств". Плохо учил

[Джон]

"А пользователю нравится!"

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

[Finch]

Сейчас начал читать книжку http://www.mini-soft.ru/book/tech_prog/index.php Там правда объясняются внутрениие ошибки. Но почти в тему

[Finch]

Sla, В твоем случае. Просто она не считает это удобным (юзать кнопки). Слишком много пальцев нужно. Второй вариант, ей на все пофигу. Она сделала свое дело как бы как. Денешку получила, И No problem. Как это будет работать дальше.

[Sla]

Джон, у нас тобой диалог в двух темах

Написал, ответил, а тут еще собеседники подошли

Дело в том, что я с этой разработчицей в одном месте работал, только я в суппорте

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

Как программер тетка замечательная, алгоритмы у нее были заглядение.
Но "трафика"

[Sla]

Кроме всего, но это могла бы быть другая тема
Иногда у разработчиков компы стоят на порядок мощнее юзеров
И софтину они пишут под себя, в результате - Там не вмещается, там медленно, там ....

Тестеры есть, но они тоже сидят на аналогичных машинках
и не создают вручную 30 договоров

[Джон]

Тестеры есть, но они тоже сидят на аналогичных машинках

У нас стандарт тестовая система PIII 700MHz.

Для отдельных случаев LapTop P90 8MB память

и не создают вручную 30 договоров

ЭТо делают автоматические тестовые системы. Тестеры пишут сценарии.

[RXL]

На мой взгляд, вопросы алгоритмов и UI (что чаще всего означает - GUI) сильно разняться по своей сути и, следственно, ими должны заниматься разные разработчики, а не один. Пользовательский интерфейс не менее трудоемкаяемкая вещь, чем алгоритмы и базы.

Недавно прочуствовал на свое шкуре, что такое возмущение пользователей и экстренная правка программы без понимания происхождения проблем: нужно было пересобрать проект BC5 на BC6, а, как оказалось, некоторые компоненты GUI круто изменили манеру поведения. Главные траблы запатчил, но общее неудобство остается. Спрашивается - где взять время на доводку GUI, если нет своего штата программисто и тестировщиков? Напрашивается вывод, что надо лучше проектировать - потом меньше править.

[Sla]

Джон, автоматическая тестовая система проверит только на возможность ввода данных, но никак не удобство ввода
RXL, 100% согласен, и кто ж это  кроме нас "несчастных" поймет

[Джон]

Sla,  а я и не гворил, что проверяется удобство ввода. Я только объяснил каким обрахзом делаются объёмные тесты, те 30 договоров вводятся, но не вручную.

Тут не надо ещё один момент забывать. Если тестер (а это ОЧЕНЬ квалифицированные специалисты) будет ручками набирать 30-50 текстов для поверки, то "За чей счёт этот банкет? Кто будет это всё оплачивать? - Во всяком случае не мы." (с) Выходит за счёт клиента. В конечном итоге программа будет для него "золотая". Поэтому устоявшийся способ, наиболее быстрый и наиболее дешёвый: сделай попроще и побыстрей, дай поиграться клиенту, получи фидбэк от клиента и сделай точь в точь как ему надо и нравится. Причём всё это документируется, и в случае если он через полгода позвонит и скажет - "херню сделали", то его просто тычут носом и говорят "видишь, что написано? - сделать херню. Кто написал? Ты написал. Так что голову не морочь, а если не нравится, то давай сделаем по другому - это называется change request". Вот и всё. Со всременем они к этому привыкают. Тоже своего рода дисциплина

[nikedeforest]

А не боитесь, что клиент к конкурентам уйдет?

[RXL]

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

[nikedeforest]

Ну, у кого-то может быть политика умасливать клиента, тогда держитесь

[RXL]

nikedeforest, при продвижении на новый рынок или ради получения выгодного заказа конечно идут на уступки, но рано или поздно это прекращается (когда клиент уже сел на "иглу").

[Джон]

А не боитесь, что клиент к конкурентам уйдет?

У нас это немного по другому делается. Когда клиент ищет исполнителя устраивается типа конкурса среди разработчиков ПО. Кто-то его выигрывает. Те клиент сам выбирает "товар". В конкурсе решающую роль играют в первую очередь предложения выполнения заказа и репутация. Первое понятно, тут главное запросить не много, но и не мало. А вот второе, пожалуй даже самое главное. Поскольку один раз облажался - меняй профессию. Закон такой.
Больше к тебе никто не придёт. Поэтому новые клиенты спрашивают (и ессно получают) рекомендации других клиентов. Ну и, конечно, клиенты понимают, что лучше иметь постоянного партнёра, все плюсы и минусы которого известны, чем постоянно изыскивать новых. Как правило это происходит только в случае, если ПО разработчик серьёзно облажался. Так например было с предыдущими исполнителями одного из наших теперешних клиентов.
Ну и как я уже неоднократно говорил, софта без ошибок не бывает - даже законодательно это оговорено. Это все прекрассно понимают, поэтому клиенты гораздо выше ценять способность быстро реагировать на ошибки, ну и плюс конечно - гибкость в исполнении договора. Те в сложных случаях (клиент выяснил, что заказанная фича ему не нужна, или нужна в другом исполнении) не быковать, а охотно идти на компромис, либо оставаясь в рамказ бюджета, либо при незначительных изменениях бюджета. Клиенты остаются очень довольны. Особенно это касается именно UI.  Ну хотели они кучу кнопок, а дерево лучше, или наоборот.
В новом софте всегда трудно предугадать конечный результат (в плане удобства).
ПОэтому переработки тоже учитываются, и как я уже говори, сначала делается "quick and dirty" - так сказать бета интерфейса, а потом доводится до ума, подгоняется по месту.

[Sla]

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