 | | | | |
| Создаем дружественный интерфейс |
Полный текст материала
Другие публикации автора: Сергей Дуплик
Цитата или краткий комментарий: | «... Почему одни программы нравятся пользователям, а другие нет? Почему с одними им удобно работать, а на другие они ругаются? Факторов здесь множество. Один из этих факторов – удобный и дружественный интерфейс. ...» |
Важно:- Страница предназначена для обсуждения материала, его содержания, полезности, соответствия действительности и так далее. Смысл не в разборке, а в приближении к истине :о) и пользе для всех.
- Любые другие сообщения или вопросы, а так же личные эмоции в адрес авторов и полемика, не относящаяся к теме обсуждаемого материала, будут удаляться без предупреждения авторов, дабы не мешать жителям нормально общаться.
- При голосовании учитывайте уровень, на который расчитан материал. "Интересность и полезность" имеет смысл оценивать относительно того, кому именно предназначался материал.
- Размер одного сообщений не должен превышать 5К. Если Вам нужно сказать больше, сделайте это за два раза. Или, что в данной ситуации правильнее, напишите свою статью.
Всегда легче осудить сделанное, нежели сделать самому. Поэтому, пожалуйста, соблюдайте правила Королевства и уважайте друг друга.
Добавить свое мнение.
| | | Содержит полезные и(или) интересные сведения | | [1] | 11 | 57.9% | | | | | Ничего особенно нового и интересного | | [2] | 8 | 42.1% | | | | | Написано неверно (обязательно укажите почему) | | [3] | 0 | 0% | |
Всего проголосовали: 19 | | | | Все понятно, материал читается легко | | [1] | 17 | 100% | | | | | Есть неясности в изложении | | [2] | 0 | 0% | | | | | Непонятно написано, трудно читается | | [3] | 0 | 0% | |
Всего проголосовали: 17 |
[Разработка пользовательского интерфейса. Эргономика.]
Отслеживать это обсуждение 
Всего сообщений: 8116-05-2009 14:52Статья поднимает вопрос, сильно влияющий на процесс и скорость внедрения. Но по сути вопроса информации мало. Пробелы дополняет обсуждение... Мои "пять копеек"...
Возникает масса ситуаций, когда желательно сообщить пользователю что-либо...
Просто сообщить...
Можно вывести текст в статус-баре или MessageBox-ShowMessage-MessageDlg.
Текст в статус-баре плох тем, что его мало кто замечает и читает.
Стандартные диалоги отлично привлекают внимание. Но...
Обязательно потребуют реакции пользователя - нажать "Ок", мол все прочитано.
И после первого раза, вылетающее перед носом уже известное сообщение, да еще требующее нажатий на кнопки или, того хуже, снайперского прицела мышкой...
Здесь очень полезно сообщение, типа хинта, не броское, но заметное, всплывающее где-нибудь в углу и не закрывающее основных полей и контролов, и ГЛАВНОЕ - само исчезающее через 3..5..10с (время можно задавать).
Был у меня подобный компонентик с двумя кнопками:
"Ок(5с)" - отображался обратный отсчет, по нажатию сообщение сразу закрывалось
"Задержать" - отсчет прекращался, пользователь мог прочитать текст не спеша.
Правда, выводился тоже в центре, и много чего мог закрыть.
Соберусь - сделаю хинт-"воздушный шарик", плывущий вверх и лопающийся через Х с.
По Хелпам от MS. Стоит у меня Access 2003 и Access 97.
Хелп от А-2003 использовать можно только для поиска по оглавлению.
Контекстный периодически показыает какую-нибудь лажу, а поиск в справке названия функций не воспринимает.
Справка А-97 гораздо удобнее.
Доводка интерфейса имеет еще пару аспектов.
1. Скелет интерфейса должен быть заложен еще до основной функциональности. Соот-но, требуется уже четко представлять все основные функции, и предполагать второстепенные. Т.е. д.б. качественный этап предпроектирования.
2. Завершать и полировать интерфейс можно после наполнения всей функциональности, т.к. сперва надо "научить ружье стрелять", а уже потом "ощипывать зайца".
Полировка может требовать времени больше чем отладка основной функции.
А времени всегда не достаточно, сроки часто съезжают. Да и оплачивать "лишнее" время заказчик хочет редко. |
|
23-01-2009 01:22>>> Все попытки его освоить провалились - интерфейс вызывает клаустрофобию
А Вы не задумывпались, какие чувства вызывает у специалиста по 3DS MAX интерфейс того же Винворда? ;-) К тому же, насколько я знаю, ни один профи по 3DS не жалуется на его интерфейс. |
|
22-01-2009 14:46 Надо сказать, что есть еще пользователи, для которых и горячие клавиши не чужды, и оформление должно быть красивым (я понимаю, что то, что красиво для одного, полное безобразие для другого; пример - "скины" разного рода). Положим, что красиво то, что гармонично.
Ни к чему делать визуально привлекательную, но практически ненужную прогу (тут в пример приводили определенный "класс" программ преобразования форматов). И наоборот. Сделали программу, которой "цены нет", так организуйте интерфейс прилично (об этом и речь, собственно :))!
Я, например, активно использую и горячие клавиши приложений, и всякую всячину типа Alt + Tab, Alt + F4, WinKey + M... :) При этом я всегда знал, что в Opera, IE и Firefox кнопки и все остальное рисуются по-разному, и меня нервирует Borland'овский редактор ресурсов (Borland Image Editor), т.к. в управлении он хуже paint'а + имеет ограничения по цветам.
Тут был упомянут 3DS MAX... Все попытки его освоить провалились - интерфейс вызывает клаустрофобию)
Всегда нужно руководствоваться постулатом лучше уж ни как, чем как-нибудь.
Вот это правильно на 100%!!! И не только во отношении интерфейса, а всей программы целиком!
Да, наклепав на скорую руку программу, которая как-то, но работает, можно опередить конкурентов, получить прибыль... НО! В сущности, именно такой подход рождает халтуру, которая копится повсеместно. По мере роста, программа оказывается в состоянии, когда нужно или начать все с начала и сделать по-уму, или продолжать катать снежный ком...
Не совсем по теме создания UI (может даже "совсем не"), но статья примечательная: http://www.inr.ac.ru/~info21/texts/2002-06-Aarhus/ru.htm (Н.Вирт)
P.S. to Денис Зайцев; самое первое сообщение в обсуждении (о размерах клиентской части окна относительно его общих размеров на разных компах)
Я делаю жесткое определение ClientWidth и ClientHeight при создании формы, и все хорошо... //Если я правильно понял описанную проблему |
|
19-01-2009 18:34| Сергей, если будете писать дальше, добавьте к дружественному интерфейсу Вашей статьи чек-лист в виде таблички, что распечатал, а потом по шагам проверил - сделал-не сделал. Удачи. |
|
12-08-2008 01:08Есть идеал, а есть возможности по реализации этого идеала. В идеале неправильно введенных значений быть не может. Грубый пример: все поля заполнены по умолчанию, интерфейсные элементы позволяют вводить только заведомо правильные значения (выбор из списков, спин-едиты с контролем диапазона для ввода чисел и т.п.). Когда это недостижимо (например, нужно вводить содержательное описание, для которого значение по умолчанию не подходит), лучше делать проверку допустимости кнопки при изменении каждого поля. Когда и это не подходит (например, в клиент-серверных технологиях, когда проверка правильности производится запросом у сервера, что долго), тогда проверяем корректность данных при нажатии кнопки.
>>> Но иногда бывает достаточно контролов и поместить пояснения уже некуда.
Во-первых, краткость -- сестра таланта. Во-вторых, если Вы делаете мастер, то никто не мешает Вам сделать в нем дополнительную страницу. |
|
11-08-2008 23:40Если мастер - ответ сам собой напрашивается: сделать недоступной кнопку "далее"
Я понимаю, такая категоричность адекватна при условии, что в мастере половину формы занимает описание, что и как нужно ввести в одно единственное поле на текущем шаге) Но иногда бывает достаточно контролов и поместить пояснения уже некуда. В этом случае ответ не так очевиден... |
|
11-08-2008 23:262 fd00ch
Если мастер - ответ сам собой напрашивается: сделать недоступной кнопку "далее". А в диалогах в зависимости от ситуации. К примеру пользователь вводит дату - имеет смысл при некорректном вводе выделить поле красным и дать ему фокус, выводить сообщение, по-моему, смысла нет, диалог на диалоге не есть хорошо. Но в любом случае дать возможность пользователю закрыть диалог (мастер).
Вчера: Я не большой знаток Excel'я. Позвали в бухгалтерию. Девушка попыталась скопировать содержимое листа в другой документ (как я понял), там довольно сложные связи были. Короче Excel заругался на неправильное имя ячейки (или еще что-то), при попытке закрыть диалог выводился другой, с полем и просьбой ввести имя, при отмене - опять первый. Ситуация безвыходная. Можно было открыть справку и почитать, но времени небыло, надо было СРОЧНО отправить этот документ. И что мне, обычному пользователю, оставалось делать? Правильно, послать Excel на три кнопки! Вот так, по-моему, делать не стоит. |
|
11-08-2008 22:56Уважаемые, а можно вопрос на засыпку? ;-)
Как по-вашему, лучше поступать в некоторых диалогах и "мастерах", где необходимо делать проверку вводимых данных:
- делать кнопку "ОК" ("Далее >") недоступной до тех пор, пока пользователь не забьёт/отметит верные данные (возможно, с пометкой звездочкой тех полей, заполнение которых обязательно);
- производить проверку введённых данных при нажатии кнопки "ОК" ("Далее >"), которая всегда доступна и при некорректных данных выводить сообщение (или пузырь, или выделение цветом - что лучше?)));
- другой вариант (почему то достойной альтернативы вышеизложенным двум я пока не нашёл)?
Что скажете? Желательно аргументированно... |
|
11-08-2008 02:28>>> Я знаю несколько коммерчески успешных продуктов которые следуют прямо противоположному принципу.
Как я понял, в публикации, которую здесь обсуждают, речь идет о разработке качественного интерфейча, а отнюдь не о достижении коммерческого успеха. А это несколько разные вещи ;-) |
|
07-08-2008 09:03
Всегда нужно руководствоваться постулатом лучше уж ни как, чем как-нибудь.
Я знаю несколько коммерчески успешных продуктов которые следуют прямо противоположному принципу. |
|
07-08-2008 08:39Выводятся по умолчанию только самые часто используемые менюшки. Хотелось бы знать - использует ли кто такой эффект в своих программах и если использует, то пишет ли это сам, или использует сторонние компоненты и если использует, то какие. На мой взгляд, эта "фича" весьма удобна. См. TActionToolBar, TActionManager, http://www.delphikingdom.com/asp/viewitem.asp?catalogid=1301
Не хотел уже продолжать здесь флудить, но всё-таки выскажусь. В начале знакомства с программой любой пользователь является чайником. Он не знает сочетаний горячих клавиш, не знает какие пункты меню вообще есть, какие кнопки что обозначают. Если он пользуется программой каждый день по 8 часов, то через некоторое время он может совершить фазовый переход в состояние опытного пользователя.
Который точно знает, какие возможности изначально заложены в программу, и что некоторыми из них он ни когда не пользуется, а некоторыми пользуется весьма часто. Такому пользователю действительно не нужны ни какие пункты меню, для которых есть горячие клавиши т.к. он уже их все выучил, всплывающие подсказки только раздражают. Некоторые частоиспользуемые действия возможно он захочет видеть в виде отдельных кнопок, а другие скажет вообще не нужны и на всех не угодить. Дальше какие-нибудь окошки со свойствами надо сгруппировать по всякому Drag-and-DOCK тут поможет. Чтобы что-то случайно не утащить эта возможность должна быть отключаемой. Если нет возможности на каком-то этапе сделать тщательно, то не надо и начинать. Силы будут потрачены, а пользоваться этим ни кто не будет.
Всегда нужно руководствоваться постулатом лучше уж ни как, чем как-нибудь. Drag-and-DOCK надо "готовить правильно", так чтобы окошко могло цепляться только туда, куда можно, а не куда попало. Переход по tab должен быть осмысленный, а не в том порядке в каком контролы кидали. Сочетания горячих клавиш тоже надо продумывать, некоторые уже давно устоялись. Короче см. полный текст материала |
|
07-08-2008 04:46| Предупреждая возможное неправильное прочтение предыдущего поста: я против не Drag-and-DROP (совсем даже за), а Drag-and-DOCK. |
|
07-08-2008 04:43Выскажусь против Drag-and-dock.
Я согласен, что docking как таковой - вещь удобная. Но если он автоматический, то как-то неуютно я себя чувствую, таская мышкой окно. Каждый раз опасаюсь, что оно неожиданно "зацепится" за другое окно (причём в данный момент невидимое). Или нажимая мышью на кнопке на "докнутом" окне, я промахиваюсь, система воспринимает это как Drag и выпихивает окно из дока. Ладно я - продвинутый пользователь, а что скажет непродвинутый? |
|
07-08-2008 03:14Хотелось бы знать - использует ли кто такой эффект в своих программах и если использует, то пишет ли это сам, или использует сторонние компоненты и если использует, то какие. На мой взгляд, эта "фича" весьма удобна.
Такое точно есть у DevExpress Bars. Правда я этим никогда не пользовался. (Cкорее всего потому, что у меня не так много элементов в меню, как у Office'а :) ). |
|
07-08-2008 01:13>>> На мой взгляд, эта "фича" весьма удобна
Эту фичу всегда отключаю. Я знаю возмоджнолсти, которые есть в том же Винворде. Но я не помню наизусть, как это называется и откуда вызывается. Если всегда показываются полные меню, то нужная команда отыскивается беглым просмотром. Если же часть команд скрывается, то приходится их сначала раскрывать (или дожидаться, чтобы они сами раскрылись). Лишние затраты времени. |
|
07-08-2008 00:18>>> Так вот там в процессе переразбивки диска кнопка "Отмена" не доступна
Кнопка выключения питания доступна :-) и рубильник у Чубайса... потому и рекомендуется оснащать машины бесперебойником. Правда, у меня бесперебойник реально только одну болванку спас, но это не повод от него отказываться.
>>> Какие кнопки/пункты меню надо - те и выводим
Это решено в кнопке Пуск и менюшках MS Office. Выводятся по умолчанию только самые часто используемые менюшки. Хотелось бы знать - использует ли кто такой эффект в своих программах и если использует, то пишет ли это сам, или использует сторонние компоненты и если использует, то какие. На мой взгляд, эта "фича" весьма удобна.
>>> Продвинутый пользователь вообще не знает
Э-э-э, кстати да. Только сейчас посмотрел, отличаются ли картинки в Opera, Internet Explorer, Mozilla Firefox. Оказывается, отличаются. Заметил (чесслово) только сейчас, когда обсуждение пошло. Раньше думал, что одинаковые кнопки во всех браузерах одинаково рисуются.
>>> У всех (у большинства) две руки, два глаза, одна мышь, одна клавиатура
Мой любимый Counter-Strike. Есть у меня один знакомый... у него тоже два глаза, две руки, две ноги... одна мышь и клавиатура... но заставит упасть-отжаться с одной пули из любого вида оружия. Есть вопросы, или намек неясен?
>>> чтобы ему были доступны из одного места двадцать операций
Угу. И чтобы с контролом, шифтом и альтом выполнялись разные вещи... и с разными комбинациями - тоже. |
|
06-08-2008 11:40По поводу удобства из личного опыта:
у одной из платёжных систем есть Windows-терминал для приёма платежей. Из плюсов - автоматическое определение провайдера по коду номера, минусов больше. Так вот, в среднем оператор на этой точке за день обслуживает 600-650 клиентов, большинство в определённые часы (очередь, грубо говоря). Действия, которые он должен делать:
1. Ввод номера - Enter.
2. Ввод суммы.
3. Несколько раз Enter (пропустить ненужные поля)
4. Мышью (!!!) нажать кнопку подтверждения
5. Выскакивает диалог с номером, суммой и надписью типа "вы уверены?" (это оператору, и по дефолту "нет")
6. Пробитие чека, мышью возвращаем курсор в нужное поле.
Так как с с нашим кассовым аппаратом этот терминал не работал, пришлось написать отдельную программу для пробития чека, заодно и переделал интерфейс:
1. Ввод номера (курсор автоматически перескакивает на поле с суммой). В случае ошибкаи - Esc - курсор опять на поле с номером, повторный Esc - очистить поле.
2. Ввод суммы - Enter. Сумма отображается на мониторе перед клиентом, в роли которого автомобильный телевизор.
3. После согласия - Enter - идёт пробитие чека, очищаются поля и курсор на поле ввода номера, пока идёт чек можно обслуживать следующего клиента.
Скорость работы возросла в несколько раз (это не преувеличение). До сих пор не могу понять, чем руководствовались программисты, делая нажатие только мышью и диалог подтверждения. Оператор набирает номер около 3х секунд (абонент дольше выговаривает), при том практически не делает ошибок, ведь он у него перед глазами! Так что нужно еще понимать, для кого интерфейс предназначен. |
|
06-08-2008 09:05>>> Это еще как посмотреть
Ну, просто Вы взяли один крайний случай, а я могу привести другой. Женщина предпенсионного возраста. Всю жизнь проработала в организации. В последние годы пришла авттоматизация, соответственно, теперь она данные записывает не на бумажку, а в специально подготовленную табицу MS Excel. Она знает, как открыть таблицу и как внести в определенные ячейки соответствующие данные. Никаких фкнкций, форматов и прочих возможностей она не знает. Даже если требовалось в две ячейки записать числа, а в третью -- их сумму, то она все равно считала на калькуляторе, а потом заносила руками (пока ей сын или внук не помогли). Но, тем не менее, она работает и зарабатывает себе деньги, используя Excel, значит она -- профессионал по одному из определений. |
|
06-08-2008 08:42
В данном обсуждении использовалось второе значение. Потому что я встречал людей, которые в своей работе использовали тот же Excel (в основной работе, за которую они получают деньги), но у меня язык не поворачивается назвать их провессиональными пользователями Excel :D
Это еще как посмотреть. :D Я, к примеру, открываю Excel один..два раза в месяц (бывает и реже), чтобы например сделать сумму по десятку чисел, потому что у меня рука начинает болеть если я напишу их в столбик и попытаюсь считать на калькуляторе. На этом мой экспириенс остановился. По сравнению со мной какой-нибудь бухгалтер или экономист, который зарабатывает деньги совсем другим, но использует Excel пяти раз на дню как инструмент для своей деятельности, безусловно является профессиональным пользователем Excel-я. По обеим категориям. Он с помощью экселя выполняет свою работу (в отличие от меня которому например надо составить смету ремонта квартиры или распилить расходы на пьяную вакханалию на озере), и он явно лучше меня знает разные экселевские функции, поскольку я знаю только "сумму". |
|
06-08-2008 08:30
На самом деле нет особой разницы между этими двумя категорями с точки зрения интерфейса. У всех (у большинства) две руки, два глаза, одна мышь, одна клавиатура.
При этом у всех мозги думают по разному, мотивация разная, моторика движений разная, опыт разный, одну и ту-же картинку они воспринимают по разному.
Если всякие разноцветные кнопочки превращают программу в венегрет, то она будет оставаться венегретом и в глазах чайника и в глазах самовара :) а если кнопки нарисованы в едином стиле со вкусом, то они одинаково будут радовать и тех и других.
Для проффи. должна быть предусмотрена возможность тонкой настройки: вытаскивание кнопок на клавную панель из пунктов меню, сочетания горячих клавиш, возможность изменения шрифтов, палитры т.п.
Дело не шрифтах, палитре и вытаскивании кнопок на панель. Дело в
a) логике работы интерфейса
б) распределении рабочего пространства
в) быстродействия интерфейса
г) доступной функциональности
д) ... прочая и прочая
Поясню на примерах:
а) При заполнении формы фокус попадает на строку ввода и под ней немедленно автоматически вываливается выпадающий список в котором содержатся некие строки.
Чайника такое поведение с легкостью вводит в ступор, более того его будет раздражать подобная самодеятельность. Профессиональный оператор напротив точно знает что выпадающий список ему понадобится с вероятностью 99% (за него уже сделали Alt+Arrow down), и что он на этот список попадет только один раз.
б) Производится работа с неким графическим объектом, пусть это будет растровое изображение. Возможно выполнение N операций из текущего интерфейса. Чайнику крайне важно иметь какие-то элементы управления с надписями и хинтами чтобы сделать хоть что-то. Профессиональному оператору важны качество изображения и максимальное использование экранного пространства под это изображение, а все операции висят на горячих кнопках и уже давно вырезаны в памяти оператора поскольку он использует эти клавиатурные комбинации сотни раз в день.
в) Быстродействие интерфейса. Ну тут всё должно быть понятно. Для чайника секундная пауза после нажатия какой-то кнопочки допустима, более того нехило было бы сделать курсор часиками. Для профессионального оператора пауза должна быть не больше времени пока он переносит палец на другую кнопку, а мырганье курсора его раздражает поскольку ему приходится глядеть на эту картину по тысяче раз в день. Для него скорость критична, это его деньги.
г) Иному профессионалу нужно чтобы ему были доступны из одного места двадцать операций т.к. он пользуется ими всеми, в это-же время чайнику нужно только 5, а остальные 15 не то чтобы не нужны а даже вредны. Наличие кнопочки с непонятным/ненужным для его работы словом вводит его в ступор: "Что это такое и зачем это здесть?" Случайное нажатие на кнопочку и выполнение какой-то операции о которой он даже представления не имел приводит его в ярость.
|
|
06-08-2008 08:13>>> крайне далекое от истины. Профессионалы это те кто зарабатывает себе кусок хлеба каким-либо трудом.
Слово "профессионал" в настоящее время имеет, как минимум, два значения: современное капиталистическое (человек, зарабатывающий этой деятельностью на жизнь) и старое социалистическое (хорошо владеющий предметом).
В данном обсуждении использовалось второе значение. Потому что я встречал людей, которые в своей работе использовали тот же Excel (в основной работе, за которую они получают деньги), но у меня язык не поворачивается назвать их провессиональными пользователями Excel :D |
|
06-08-2008 08:04Определение целевой аудитории вкорне неверно, там нет ни чайников, ни профи, потому что чайник - состояние временное, а профи являются исключительно программисты (обычные пользователи не стремятся ими быть)./Quote]
Утверждение крайне далекое от истины. Профессионалы это те кто зарабатывает себе кусок хлеба каким-либо трудом. В этой области труда он и отличается от чайников и любителей по уровню своих знаний и умений. Профессионалом может быть кто угодно, в IT их круг не ограничен только программистами. Программисты всего-лишь одна из категорий IT-профессионалов, которых тьма (администраторы чего-либо, инженеры по коммуникациям, маркетингу, дизайнеры/художники разных мастей, снабженцы и т.п.)
Этот вопрос очень хорошо описан у Алана Купера в книге "Психбольница в руках пациентов". Всем, кто не читал, советую ознакомиться, книга имеет прямое отношение к обсуждаемой теме.
Не читал. Но если выше высказанная мысль про то что "профессионалами являются исключительно программисты" из этой книги, то наверное это и хорошо что не читал. :-) |
|
06-08-2008 06:40
06-08-2008 06:36>>> Разводить флейм не собираюсь, больше впустую писать не буду...
А разве мы спорим впустую? По крайней мере, я -- нет ;-)
>>> Чтобы спорить с тем утверждением, которое я привел, нужно знать материал, на основании которого это утверждение построено.
Вы привели утверждение. Мне без разницы откуда Вы его взяли. Это утверждение вступает в противроречие с моим жизненным опытом. Я публикую возражение.
Вопрос: зачем мне читать книгу, чтобы определить, на основании чего автор сделал утверждение, которое не соответствует моему личному опыту? Возможных целей две:
1. Уличить автора в том, что он использовал нерепрезентативную выборку.
2. Показать, что автор неверно выразил свою мысль (ну, или переводчик некорректно перевел, хотя для этого придется прочитать еще и в подлиннике).
Все. Ни первое, ни второе не представляет для меня интереса, поэтому, извините, но пожелание сначала прочитать книгу отклоняется. Так что давайте будем споирть мы, а не авторитеты.
1. Вы не согласны, что существуют различные градации пользователей, которых можно назвать чайниками и профи (именно пользователей, а не программистов)?
2. Вы не согласны, что есть категории пользователей, которые навсегда остаются чайниками?
3. Вы не согласны, что у чайников и профи требования к пользовательскому интерфейсу могут различаться?
Вроде перечислил все возможные пункты для расхождения во взглядах. С которым (или с которыми) именно Вы не согласны? |
|
06-08-2008 06:06Я спорю не с книгой, а с тем утверждением, которое Вы привели
Чтобы спорить с тем утверждением, которое я привел, нужно знать материал, на основании которого это утверждение построено. Объем материала не позволяет его сюда запихивать целиком, поэтому я ограничился кратким комментарием.
Разводить флейм не собираюсь, больше впустую писать не буду... |
|
06-08-2008 05:59>>> То, что я его процетировал означает, что я с ним согласен
В контексте спора -- это одно и то же.
>>> А где вы видели, что это мое утверждение? Я же написал откуда это взято...
О, великий и могучий... Хорошо, я перестрою фразу, дабы постараться исключить двусмысленность. Я спорю не с книгой, а с тем утверждением, которое Вы привели.
>>> ps: Читать нужно не только Фаронова...
No comments |
|
06-08-2008 05:47Странная постановка: я спорю не с книгой, а с Вашим утверждением
А где вы видели, что это мое утверждение? Я же написал откуда это взято...
То, что я его процетировал означает, что я с ним согласен, но на авторство я не претендовал...
ps: Читать нужно не только Фаронова... |
|
06-08-2008 04:48>>> Расскажите, что в книге ошибочно или неверно (хотя бы в отношении классификации пользователей)...
Странная постановка: я спорю не с книгой, а с Вашим утверждением. Иначе я тоже спрошу, что неверно в Бхагавад Гите, и Вам придется ее всю перечитать, чтобы ответить.
Неверно то, что не рассматриваются градации пользователей. Впрочем, я процитировал то, с чем не согласен. Могу повторить, я не согласен вот с этим утверждением:
чайник - состояние временное, а профи являются исключительно программисты (обычные пользователи не стремятся ими быть)
Я встречал бабушек, которым рассказали, куда вводить текст и какую кнопку нажимать. А также встречал людей (пользователей), которых сначала сам начинал обучать, а позже бегал к ним за консультациями, так как они в отдельных вопросах разобрались (сами) лучше меня. Бабушку можно загнать в ступор просто изменрив картинку на кнопке, поэтому при разработке интерфейса нужно использовать как можно более стандартные кнопки. Продвинутый пользователь вообще не знает, что у него там на кнопках нарисовано. Ему важна эргономичность и компактность.
Это так... навскидку... для понимания. |
|
06-08-2008 04:15Вы, видимо, много работали с программистами, но мало -- с пользователями. А даже по отношению к какому-нибудь общераспространенному Винворду...
Интересно, а вы программы тоже пишите не изучив предметную область?
Я описал не домысел, а конкретный факт, который описан в фундаментальном труде. Чтение еще никому не навредило...
ps: Предпочитаю спорить конструктивно. Расскажите, что в книге ошибочно или неверно (хотя бы в отношении классификации пользователей)...
|
|
06-08-2008 03:17сообщение от автора материала За дерганье стопкрана в неположенное время (нет "угрозы жизни пассажира", например если родственники опаздывают :-)) берут штраф в размере 1500 рублей. Так что и за кнопку принудительного останова тоже придется отвечать... потерей ресурсов, оставленными "мусорными" файлами, может быть, чем-то еще
Согласен. Есть такая очень хорошая программа PartitionMagic. Так вот там в процессе переразбивки диска кнопка "Отмена" не доступна. А подумайте, что может случиться, если бы она была доступной... Откатить результат деятельности программы зачастую просто невозможно.
самая дурь начинается когда интерфейс представляется чайникам которые впоследствии должны стать крутыми профессионалами. Решение о приобретении и внедрении программы будет приниматься на основе их чайниковских впечатлений, но по мере роста своей квалификации им требуется именно профессиональный интерфейс
А вот здесь - да здравствует настраиваемый интерфейс. Какие кнопки/пункты меню надо - те и выводим. |
|
06-08-2008 03:12>>> Определение целевой аудитории вкорне неверно, там нет ни чайников, ни профи, потому что чайник - состояние временное, а профи являются исключительно программисты
Вы, видимо, много работали с программистами, но мало -- с пользователями. А даже по отношению к какому-нибудь общераспространенному Винворду можно построить достаточно сложную типологию пользователей. Что-то вроде:
Есть обычные пользователи, которые просто нажимают те кнопки, которым их научили, и этим ограничиваются. А есть продвинутые пользователи, которые постоянно изыскивают возможности, как конкретную стоящую перед ними задачу решить с помощью имеющихся средств наиболее эффективно. Есть пользователи "эстеты", для которых кнопочки должны быть красивыми, а есть те, которые и не сразу скажут, чем отличается по внешнему виду меню в MS Office 2000 и MS Office 2003. Они на эти графические эффекты и внимания не обращают. |
|
06-08-2008 02:452Ender:
Определение целевой аудитории вкорне неверно, там нет ни чайников, ни профи, потому что чайник - состояние временное, а профи являются исключительно программисты (обычные пользователи не стремятся ими быть).
Этот вопрос очень хорошо описан у Алана Купера в книге "Психбольница в руках пациентов". Всем, кто не читал, советую ознакомиться, книга имеет прямое отношение к обсуждаемой теме. |
|
06-08-2008 00:52
06-08-2008 00:36Интересный момент... Зашел к одному знакомому, копирую файл с расшаренной папки - винда выдаёт диалог (дословно):
- Скоприровать или переместить файл ... с этого ресурса? И две кнопки - "Да" и "Нет"
Долго чесал тыковку...
Так что вопросы пользователю надо тоже задавать с умом. |
|
06-08-2008 00:14Похоже, обсуждение следует перенести на Базарную площадь. Не знаю, кому как это покажется... пусть решает автор темы.
>>> жаль, на стоп-кране диалоги не выскакивают
Да, надо бы сделать так... как на терминалах самообслуживания.
>>> Не очень то это естественно
Ну почему? Вариант с испорченным диском - очень хороший пример. Только я что-то про него не вспомнил, запамятовал наверное. Спасибо за прекрасный пример. А пользователь и не должен знать внутреннюю кухню программы. Он должен догадываться. Например, про то, что если я поставлю в программе Nero кеширование файлов с диска и сети - куда они будут кешироваться??? Или куда будет распаковываться SFX инсталлятор?
Ну и еще добавлю несколько пунктов "хорошего" (по моему мнению) интерфейса:
- Проверка ввода пользователя должна быть ошибкоустойчивой. То есть не if MessageBox(...)<>mrNo, а жестко if MessageBox(...)=mrYes. Не думайте, что вернет диалоговая функция по умолчанию, если я закрою ее "крестиком", а не предусмотренной для этого кнопкой. Очень удобным для пользователя является вывод всплывающей подсказки над неправильным полем, или как минимум подсвечивание ячейки с неверной информацией другим цветом. В этом случае информация о допустимом вводе должна быть доступна через контекстную справку. Вспомните Delphi - когда мы видим ошибку, можно выделить ее и нажать F1 - полная информация будет немедленно доступна. Когда я работал с программой, скопированной с другого компьютера (а потому лишенной по неизвестной причине справкой) и диалоговое окно не хотело закрываться, поскольку считало, что некие данные введены неверно, но какие - не говорило, хотелось кого-то убить. Из дробовика 2-2.
- Используйте сообщения с таймаутом. Как сделаете - другой вопрос. Но поверьте, пользователь, оставивший Вашу программу на ночь очень обрадуется, когда утром программа порадует его вопросом: "Файл существует. Перезаписать?". Если сообщения критически важные (кончилось место на диске) - тогда имеет смысл выводить их в лог. Имеет смысл предусмотреть опцию "Завершать работу компьютера по окончании работы", если планируется, что программа может выполнять длительные операции. Если операции расчетные, должна быть предусмотрена возможность автоматического сохранения данных в какой-то файл. Впрочем, это касается не только расчетных операций. Моя программа сканирует локальную сеть на все расшарки и на данный момент основной претензией является то, что надо автоматически сохранять данные в новый файл, а не перезаписывать существующий. Такое пожелание также необходимо учитывать, храня последние 5-10-15-20 "временно-рабочих" файлов (можно по выбору пользователя).
- Если Вы пишете аналог программы, то не стесняйтесь сделать интерфейс максимально приближенным к оригиналу. Помните: грамотный пользователь выберет не раскрашенного павлина, но который не умеет делать даже половины того, что делал серый воробушек, а другого серого воробушка, но который умеет делать вдвое больше предыдущего. Хотя можно сделать ставку на непрофессионального пользователя, чем пользуются создатели тысяч конвертеров видео и аудио. Касательно меня, для конвертирования видео я использую VirtualDub, для аудио - консольный Lame и несколько bat файлов, автоматически выполняющих за меня всю работу.
- Старайтесь избегать использования TSpeedButton, TBitBtn. Они рисуются без учета темы Windows, потому выглядят в большинстве случаев непрезентабельно. Возможно, в последних версиях Delphi это исправлено, в Delphi 7.0 и ниже это было так.
- Не используйте абсолютные размеры шрифтов - относительные намного безопаснее. Если Ваш пользователь будет пользоваться КРУПНЫМИ ШРИФТАМИ, задание абсолютного размера может привести к тому, что более крупный (по задумке) шрифт будет казаться более мелким.
- Если Ваша программа работает в полноэкранном режиме, сделайте для нее настройки в обычном окне, которое либо будет запускаться в обязательном порядке перед стартом программы, либо после аварийного запуска (Unreal Tournament). Иначе рискуете, что пользователь не сможет запустить Вашу программу. Можно сделать главное (полноэкранное) меню в "мягком" режиме (Half-Life, Counter-Strike). Оно быстро запускается и не очень раздражает.
- Избегайте лишних подтверждений. Поверьте, серия диалогов: "Вы уверены, что надо удалить?", "Нет, вы точно уверены?", "Нет, ну вы АБСОЛЮТНО уверены?", приводит к желанию взять кувалду...
|
|
05-08-2008 06:01Есть аудитория пользователей - чайников ... На другом краю аудитория профессионалов На самом деле нет особой разницы между этими двумя категорями с точки зрения интерфейса. У всех (у большинства) две руки, два глаза, одна мышь, одна клавиатура.
Если всякие разноцветные кнопочки превращают программу в венегрет, то она будет оставаться венегретом и в глазах чайника и в глазах самовара :) а если кнопки нарисованы в едином стиле со вкусом, то они одинаково будут радовать и тех и других.
Для проффи. должна быть предусмотрена возможность тонкой настройки: вытаскивание кнопок на клавную панель из пунктов меню, сочетания горячих клавиш, возможность изменения шрифтов, палитры т.п. |
|
05-08-2008 02:25>>> Я как то плохо себе представляю чем должен отличатся профессиональный интерфейс от "чайниковского"
На самом деле, это уже, как бы, не совсем сюда. НО раз уж пошла такая тема, то...
Сравните интерфейс MS Word и 3D Studio MAX
В Ворде постоянно новые красивые картинрочки, эффекты кнопочек и т.д. и т.п. А в 3Д Студио как был основной интерфейс через стандартные едиты и кнопки, так и остался.
Только (повторюсь) не совсем понимаю, какое отношение имеет сранение интерфейсных решений в стиле "чайник" и "профи" к данному обсуждению. |
|
05-08-2008 02:082 Python
>>>При этом, естественно, остается файловый мусор в темпе, неосвобожденные ресурсы. Но пользователь за это в ответе - он сам дал такую команду.
Не очень то это естественно.
Ну вот откуда пользователь знает внутреннюю кухню Вашей программы?
Да и почему, собственно, он должен это знать?
Это ответсвенность программиста.
2 GEO
>>>А нужно предлагать готовое решение,...
Да, вот так в своё время выбрали программу (при прочих равных) |
|
04-08-2008 15:23Ender
Я как то плохо себе представляю чем должен отличатся профессиональный интерфейс от "чайниковского". Можно немного подробней об этом? |
|
04-08-2008 10:10Есть довольно крутая проблема в части целевой аудитории. У целевой аудитории есть два крайних случая.
Есть аудитория пользователей - чайников, для которых интерфейс должен быть предельно простым и понятным. Т.е. простота освоения и использования интерфейса ставятся во главу всего. Формы не должны быть перегружены функциональностью и элементами управления, везде должны быть разные хинты и развернутые подписи.
На другом краю аудитория профессионалов - это операторы, программисты, инженеры и т.п. люди для которых приоритетом является скорость, функциональность и гибкость интерфейса. Если для двух последних всё более менее понятно и просто, то в случае с операторами приходится проводить различные замеры на предмет скорости выполнения тех или иных операций, их частоты, логики и порядка выполнения этих операций. В результате этого интерфейс дающий высокую производительность может радикально отличаться от интерфейса для чайников.
Ну а самая дурь начинается когда интерфейс представляется чайникам которые впоследствии должны стать крутыми профессионалами. Решение о приобретении и внедрении программы будет приниматься на основе их чайниковских впечатлений, но по мере роста своей квалификации им требуется именно профессиональный интерфейс. |
|
04-08-2008 03:49Так что и за кнопку принудительного останова тоже придется отвечать... потерей ресурсов, оставленными "мусорными" файлами, может быть, чем-то еще.
Согласен. Если что-то серьёзное происходит, и остановка грозит потерей данных (или еще чем) - информируем пользователя, а продолжать или нет - его выбор (жаль, на стоп-кране диалоги не выскакивают :)). К примеру - пишу диск, в середине нажимаю "стоп" - вижу диалог, что если завершить сейчас, диск будет испорчен. Вдруг мне сейчас позарез нужен привод для других целей, и чхал я на этот диск? Или наоборот, я почему-то думал, что если сейчас остановлю запись, потом продолжу, если не выдать мне такой диалог, я долго буду вспоминать разработчиков не очень цензурными словами. |
|
04-08-2008 03:40>>> Проблема - когда требуется выделить, скажем, "красным" цветом сообщения об ошибках, "зеленым" цветом сообщения о номинальном режиме работы и "желтым" - нечто среднее
А вот тут я сразу вспоминаю первый раз, когда я увидел мышиный курсор в виде стрелочки. Гениальное решение: сам курсор белый, а граница черная. Он гарантиррованно будет смотреться на любом фоне.
К чему я это... Если требуется некое разноцветие, то нужно попытаться сделать некое нестандартное решение, некий компонент, который по краям имеет стандартное цветовое решение, чтобы хорошо стыковаться с остальной формой. А внутренность своя собственная.
Ну, и цветовый настройки, конечно же, не помешают. Только вот в одной старой-старой статье я когда-то прочитал такой момент, что с тех пор, как стало модно встраивать в свои программы кастомизацию цвета, народ перестал задумываться о грамотной проработке цветового решения своей программы. Лепят цвета абы как. Дескать, если пользователю не понравится, то оно потом сам сделает как надо. А нужно предлагать готовое решение, с которым даже при дефолтных настройках было бы более-менее приятно работать. |
|
04-08-2008 03:20>>> И не в коем случае не допускать зависания формы, чтоб её всегда можно было свернуть
Согласен. Потому я и писал выносите этот код в отдельный поток. Это устранит "залипания" интерфейса. А на операционку лично мне глубоко начхать - отвечает программа, или нет, если я чувствую, что программа работает - значит для меня она "отвечает".
>>> кнопку "отмена" доступной
Ну не всегда это нужно. У меня, например, при закачке файлов имеется кнопка "Отмена" - по нажатию на нее немедленно взводится флаг, кнопка меняет название на "Уничтожить". При этом создание новых потоков на закачку заблокировано, а остальные потоки ждут окончания закачки. Только по повторному нажатию кнопки я терминирую потоки безусловно - закончилась там закачка, или нет. При этом, естественно, остается файловый мусор в темпе, неосвобожденные ресурсы. Но пользователь за это в ответе - он сам дал такую команду.
>>> Не важно, что там в данный момент происходит
За дерганье стопкрана в неположенное время (нет "угрозы жизни пассажира", например если родственники опаздывают :-)) берут штраф в размере 1500 рублей. Так что и за кнопку принудительного останова тоже придется отвечать... потерей ресурсов, оставленными "мусорными" файлами, может быть, чем-то еще.
>>> но боюсь, что такой совет рассчитан на другую "весовую категорию"
Ничуть. Статья для начинающих про потоки висит на данный момент на стартовой странице.
>>> Полная чушь! Использование констант ОС...
Нет, не надо! Если пользователь сделал цвета, скажем, clWindow и clWindowText неконтрастными, то кто виноват? Об этом далее говорили Geo и Александр Алексеев. Так что просто надо немного подумать, а цвета, которые необходимо сделать контрастными - выбирать из тех, кто должен быть контрастными по умолчанию. Проблема - когда требуется выделить, скажем, "красным" цветом сообщения об ошибках, "зеленым" цветом сообщения о номинальном режиме работы и "желтым" - нечто среднее, то единственным приемлемым (на мой взгляд) решением является дать возможность пользователю редактировать цвета руками. Например, через меню настроек, или отдельной утилитой, если предусмотрено создание сложного программно-технического комплекса. И вообще... Не раскрашивайте программу как павлина. Максимальное число цветов - до 10. Цвета должны быть хорошо читабельными на любых темах Windows. Поставьте "Контрастную черную" схему и убедитесь, что все работает и читается. Если нет... извините. |
|
31-07-2008 09:19to Денис Зайцев:
Ясно дело, я имел в виду стандартные компоненты или компоненты близкие к стандартным. Естественно, никто не требует подгонять битмап, чтобы он соответствал цветовой схеме, используемой на пользовательском компьютере :D |
|
31-07-2008 08:44Конечно, бывают ситуации, когда стандартными цветами воспользоваться невозможно или нежелательно.
Например, если в том же StringGrid'е нам нужно выделить некоторое множество ячеек цветом фона (отличным от цвета фона выбранной ячейки), то для этого просто нет подходящего цвета, который бы гарантированно отличался от стандартного цвета фона (clWindow) и от цвета выбранной ячейки (clHighlight) на любой цветовой схеме.
А для некоторых приложений (не массовых) имеет смысл вообще фиксировать цветовую схему. |
|
31-07-2008 07:26to Uridian:
Живой пример.
Вы самостоятельно прорисовываете ячейки StringGrid. Вы можете, конечно, для фона выделенной ячейки использовать синий цвет, а для текста -- белый. Потому что именно такая схема используется у Вас. Но на компьютере, где для выделенной ячейки используется фиолетовый цвет, Ваше решение будет выглядеть несколько странным. Поэтому используйте clHighlight и clHighlightText. Это будет гарантировать, что ваша выделенная ячейка будет выглядеть так же, как и выделенные элементы других компонент. А если пользователь дурак и переопределил цветовыую схемы так, что эти его цвет неконтрастны, то это уже его проблемы. Однако он все равно должен будет себе глаза ломать, пользуясь плохим сочетанием цветов во всех остальных программах.
Если же Вы не ячейки грида перерисовываете, а делаете что-то нестандартное, то все равно лучше использовать те самые предопределенные цвеирвые константы ОС. Пусть на нестандартной схеме будет выглядеть коряво, но, по крайней мере, если Вы использовали цвета, которые по определению должны быть контрастными, то не нарветесь на белые буквы на белом фоне. |
|
31-07-2008 06:47>>> Использование констант ОС не убережёт вас от корявого изображения на нестандартной теме, поскольку не даёт гарантии, что два выбранных вами цвета (фона и текста) будут достаточно контрастными (сочетаемыми) в произвольной системной палитре.
Неверно. Даёт гарантию. Но только если вы сами корректно выбираете цвета и если нестандартная тема построена верно: http://blogs.msdn.com/oldnewthing/archive/2007/12/12/6648399.aspx
А вот фиксированные цвета точно будут смотреться не в тему на нестандартной схеме.
Кроме того:
>>> А лучше всего не трогать предустановленные цвета вовсе, и предоставить пользователю самому определять цветовую схему. Подумайте о людях с ослабленным зрением!
Мне кажется, что именно об этом Geo и говорил. Вы как-то странно поняли его слова. |
|
31-07-2008 05:39GEO писал
>>От себя добавлю еще, что крайне рекомендуется задавать не абсолюттные значения цветов, >>а использовать предопределенные константы OC (типа, clBtnFace, clHighlight и т.п.). >>Иначе программа будет выглядеть очень коряво на Винде с нестандартной темой.
Полная чушь!
Использование констант ОС не убережёт вас от корявого изображения на нестандартной теме, поскольку не даёт гарантии, что два выбранных вами цвета (фона и текста) будут достаточно контрастными (сочетаемыми) в произвольной системной палитре. Только указание абсолютных значений для цветов фона и текста позволит вам быть уверенным, что ваш дизайнерский изыск будет выглядеть так, как было задумано, на любой машине.
А лучше всего не трогать предустановленные цвета вовсе, и предоставить пользователю самому определять цветовую схему. Подумайте о людях с ослабленным зрением! |
|
26-07-2008 04:30сообщение от автора материала что за PriemForm в вашей FormKeyPress? Внимательней, пожалуйста
Вот за этот "тычок носом" спасибо. Действительно проглядел. Копировал из проекта, где формы имели неавтоматические имена.
Select.SelectNext
Эээ... Вы хотели сказать Self.SelectNext?
Python, ваши предложения принял к рассмотрению. |
|
25-07-2008 16:11| На счет выносите этот код в отдельный поток. это конечно правильно, но боюсь, что такой совет рассчитан на другую "весовую категорию" :) |
|
25-07-2008 14:43| Да, забыл добавить, в остльном согласен с Python. |
|
25-07-2008 14:23Если программа выполняет некие длительные действия, выводите хотя бы анимацию. Есть нервные пользователи, которые будут пытаться убить программу, если не получат от нее очень быстрого ответа. Время "нервности пользователя" колеблется по моим наблиюдениям от 10 секунд до пары минут.
Тут еще зависит от настроек системы. По умолчанию в Windows XP это время 20 секунд, потом программа помечается как "не отвечает", хотя на самом деле работает. Самый правильний вариант, ИМХО, вывести прогресс, пусть и не реальный (ложный), но чтоб пользователь видел, что "что-то происходит". И не в коем случае не допускать зависания формы, чтоб её всегда можно было свернуть, в это время видно, что программы работает, пусть все элементы управления будут недоступны, хотя я советую сделать кнопку "отмена" доступной и реагирующей по возможности как можно быстрей. Если такое сравнение подойдёт, пусть это будет как стоп-кран на поезде, дёрнул и всё! Не важно, что там в данный момент происходит, но остановить по требованию пользователя нужно. Если есть какие-то нюансы, с удовольствием послушаю! |
|
25-07-2008 07:49Есть еще ряд моментов, так же "по мотивам знакомства с чужими программами"
- Если какое-то окно не должно менять свой размер - ставьте тип рамки bsSingle, или bsDialog. НО! Если Вы ставите тип bsSingle (для bsDialog это неактуально :-)), не забывайте отключать кнопку biMaximize, иначе Ваш труд пойдет насмарку. А если программа не предназначена для того, чтобы лежать свернутой - поставьте тип bsDialog, он не имеет "лишних" кнопок.
- Если программа выполняет некую длительную непрерываемую операцию (закачка файлов из интернета, сканирование локальной сети, сложный расчет) - выносите этот код в отдельный поток. Из любого потока, кроме главного ЗАПРЕЩАЕТСЯ что-либо и где-либо рисовать. Общение потока с программой может быть реализовано огромным количеством способов - выбирайте любой, в основном я пользуюсь сообщениями. Основной поток ДОЛЖЕН заниматься только управлением дочерних потоков, но никак не выполнением основной задачи. В качестве исключения можно назвать случай, когда без завершения некоей задачи нет возможности в принципе продолжать работу. Это в первую очередь инициализация программы - посмотрите на Unreal Tournament, на момент загрузки кажется, что он "повис". Этим же страдают и другие игры.
- Если программа выполняет некие длительные действия, выводите хотя бы анимацию. Есть нервные пользователи, которые будут пытаться убить программу, если не получат от нее очень быстрого ответа. Время "нервности пользователя" колеблется по моим наблиюдениям от 10 секунд до пары минут.
- Всегда предусматривайте, что не на все действия у Вас могут быть права. Например, мои программы до сих пор не работают по Vista. Причина банальна - я храню файлы конфигурации в папке с программой, которая лежит в папке Program Files, которая не доступна для записи/изменения. В правильно написанной программе файлы конфигурации должны храниться в профиле пользователя, получаемом вызовом SHGetSpecialFolderLocation. Тем не менее, это усложняет перенос программы с одной машины на другую, поэтому я так не делаю. Начинающим пользователям так делать не следует.
- Важные сообщения должны выводиться ВСЕГДА поверх ВСЕГО. Считайте, что Ваша программа свернута. Так делает Total Commander. Его запросы требуют немного внимания, но они в целом оправданы. С другой стороны, таких вопросов должно быть минимальное количество, иначе на них перестанут обращать должное внимание.
- На некритичные сообщения Вы можете обращать внимание, например, FlashWindow, миганием иконки в трее. Смотрите, как это сделано в mIRC.
- Часто задаваемые вопросы должны иметь функцию автоответа. Например "Вы хотите удалить непустую папку?" Мало того, эта функция должна иметь возможность быть отключаемой - как в том же Total Commander.
- Не вздумайте выводить свое окно поверх всех приложений и принудительно переводить на него фокус. Пользователь будет в диком восторге, когда его CounterStrike во время ожесточенной перестрелки свернется и отобразится окно: "А какого цвета вы хотите ушки у зайчика?" Зайчик будет убит выстрелом в голову... из ножа...
- Не стесняйтесь смотреть на чужие программы... и если ими пользоваться удобно, то разберитесь, как они сделаны и сделайте также. Не знаю, как другие люди, но я очень негативно отношусь к любым скинам. Исключение - полноэкранные приложения, там можно развернуться, а в оконных приложениях лучшее оформление - стандартное.
- Избегайте статусных сообщений непонятного вида: "Нет ошибки: ДА". Попробуйте с первого раза понять, что здесь имеется в виду. Напротив: "Состояние: ОШИБКА". Слово "Ошибка" можно выделить красным цветом. Но помните про темы!!! На теме с другими цветами Ваше сообщение может не читаться.
- Есть еще очень много пунктов, которым я пытаюсь следовать в своих программах. Главное, помнить: если это удобно Вам - это еще не факт, что удобно пользователю. А вот если это Вам неудобно - пользователь тоже Вам спасибо не скажет. Лично я стараюсь все операции сделать на главных и контекстных меню и вообще минимизировать число элементов управления.
Если какие-то пункты покажутся тебе интересными - можешь включить во вторую версию. Также рекомендую включить хорошие и замечательные примеры реализации гуя (пользовательского интерфейса) на Ваш взгляд. Свое мнение я уже озвучил: Total Commander (а не Explorer), VirtualDub, Lame... |
|
24-07-2008 06:12И вместо ActiveControl лучше написать TWinControl(Sender)
procedure TForm1.FormKeyPress(Sender: TObject; var Key: Char);
begin
if Key = #13 then begin
Key := #0;
Select.SelectNext(TWinControl(Sender), GetKeyState(VK_SHIFT) and $80 = 0, True);
end;
end; |
|
24-07-2008 06:08Хочу немного расширить FormKeyPress, т.к. стандартный переход по Tab можно осуществлять как вперед, так и назад, удерживая клавишу шифт. Вот реализация FormKeyPress, когда при Shift+Enter пользователь сможет перепрыгивать в обратном порядке:
procedure TForm1.FormKeyPress(Sender: TObject; var Key: Char);
begin
if Key = #13 then begin
Key := #0;
Select.SelectNext(ActiveControl, GetKeyState(VK_SHIFT) and $80 = 0, True);
end;
end;
И совет - никогда не пишите в методах класса ссылку на некий экземпляр класса, например Form1.SelectNext, для этого есть Self! И что за PriemForm в вашей FormKeyPress? Внимательней, пожалуйста. |
|
22-07-2008 22:49Статья хорошая, и правда все труднее и труднее разбираться в последнее время с размерами окон своих программ - приходиться учитывать разрешение и DPI
Так что вот с этим всегда проблемы :-(
Ещё бы хотелось напомнить про горячие клавиши, в частности про "Alt + подчёркнутая буква" :-)
Уверен, что об этом знают не более 25-35% пользователей программ, я сам раньше особо не задумывался, что это такое изачем нужно
Сейчас, честно говоря, тоже не пользуюсь этим Alt, но изредка бывает дело... |
|
22-07-2008 00:54сообщение от автора материала Написал вторую версию, куда внес высказанные замечания и пожелания. Всем еще раз спасибо.
Многие не знают про Drag&Drop или не любят его "из принципа". Видать 1-2 раза перетащили не туда и теперь их от него клинит. Им нужен вариант Copy/Cut/Paste или другой аналог более подходящий по смыслу
Эх... Я вот тоже пару раз не туда скопировал, теперь делаю popup-меню->Copy и popup-меню->Paste :) А бывало, что тащишь - да случайно мышку отпустишь...
не было бы жуткого оформления интерфейса у новичков
К сожалению, подобные вещи случаются не только у новичков, как оказалось... Треть пунктов написана по результатам знакомства с программами, написанными профессиональными вроде как программистами, работающими уже не первый год в фирме, специализирующейся на разработке ПО. В частности пункт "Размеры окон не должны превышать размеров экрана" и "Все всегда видны". |
|
21-07-2008 03:50Недавно сам попал в ситуаци, в котрой часто оказываются "обычные" пользователи. Переставил Windows, зашел на сайт... Обычно поле "Имя пользвателя" было заполнено автоматически, но не в этот раз. Ситуация идиотская: восстановить забыть пароль ответив на контрольный вопрос можно, а вот восстановить забытый логин?
После этого я начал намного лучше понимать пользоателей, и сделал вывод, что подсказывать пользователям себе дороже (и им): когда просто нажимаешь ОК, не запоминаешь с чем соглашаешься, а когда вдруг подсказка исчезнет возникает Большая Проблема.Сообщение не подписано |
|
19-07-2008 13:002 RomeoGolf
Согласен полностью! |
|
19-07-2008 07:50Отличный список, хотя и не полный. Надеюсь, автор учтет дополнения и вторая версия увидит свет :)
Читал пару книжек на тему пользовательского интерфейса, отечественных и импортных авторов. Обе в разы толще и в разы хуже. А тут - все по полочкам, все ясно.
А тем, кто голосует "ничего нового и интересного", стоило бы сперва посмотреть, в каком разделе статья. Если бы не было ничего нового - не было бы жуткого оформления интерфейса у новичков, да и статья эта не была бы нужна. |
|
17-07-2008 07:55сообщение от автора материала Как же я согласен с Geo по поводу справок от Микрософта... |
|
16-07-2008 12:19
16-07-2008 09:53У MS изменилась идеология, или поменялся кадровый состав, "стариков" ушли, а молодежь изголяется по новому.
Раньше справка писалась для получения информации и была взаимосвязанной.
Введение, общая концепция, описание доступного инструментария, и классов /функций.
В данный момент справка пишется ради справки, нет описаний особых случаев, противоположных решений и т.п. Информацию извлечь затруднительно.
И к сожадению борланд и его приемники пошли по этому пути.
Как-то в интернете натнулся на реплику автора современного хелпа к Turbo Delphi
он явно был шокирован что люди предпочитают (ищут, устанавливают и пользуются) справку от D7.
приводил какие-то цифры о проделанной работе, и плакался что труд его команды не ценять.... :(
А чего там ценить, найти инфу стало гораздо труденее. Если я раньше помнил что выйти на вот эту функцию можно через другую функцию-инверсную к первой, то теперь этот способ не срабатывает.
|
|
16-07-2008 08:41Поиск в Microsoft ужасно сделан. И не только в справке. На сайте тоже никогда ничего не найдёшь - приходится пользоваться гуглом.
Если бы они использовали технологии гугла для поиска - вот тогда цены б справке не было бы. И дельфёвой это тоже касается, ибо в новых дельфях и справка теперь как в MSDN стала. |
|
16-07-2008 08:31| Может быть, неявня форма привлечения на свои курсы Не надо искать злого умысла в том, что объясняется простой глупостью :) Это явный результат формализма в работе. В больших и старых конторах по мере натыкания на грабли появляются различные обязательные требования к выполнению работ, постепенно их копится так много, что в процессе программирования/тестирования весь пар уходит на соблюдение этих требований (где уж там поставить себя на место пользователя). В каждом отдельном случае эти требования может и правильные, но в сумме получается "ваша мышь поменяла положение на коврике, хотите, чтобы курсор также поменял положение на экране?" |
|
16-07-2008 07:34>>> Интересно, только меня он так бесит?
Меня в нынешних хелпах от Микрософта бесит другое.
Во-превых, то, что по умолчанию ответ на поисковый запрос ищется в интернете на сервере Микрософта, хотя я специально указываю при установке, что обязательно ставить локальный хелп. Ладно, разобрался наконец, нашел переключатель и теперь ищу в локальном хелпе. Но...
Структура хелпа идиотская. Построена по принипу, какие кнопки нажимать (кнопки я и без хелпа найду). Свежий пример (рана еще кровоточит): создавал в Визио нестандратный шейп для специальных нужд. Потребовалось уточнить кое-какие ShapeSheet Fuctions (в изначальном Визио этому был посвящен целый раздел хелпа). Фигушки! Какой бы запрос я не посылал, по каждому мне выдавалось по несколько десятков результатов, в каждом из которых было описание нажатий кнопок. Плюнул и стал делать по памяти. Черт их знает, зачем они так делают. Может быть, неявня форма привлечения на свои курсы. Типа, если хочешь реально понять, то иди учиться, а не занимайся самообразованием.
Пардон, что немного не по теме. Но просто это больгая мозоль. |
|
16-07-2008 06:49Прочитал статьи по сслыке, которую привёл Сергей Любезный: http://russian.joelonsoftware.com/uibook/chapters/1.html
Мне понравилось. А особенно вот что:
"Оптимизировать базу данных под скорость или под размер? Под размер? Под скорость? ..." Ваш ли внутренний это спор, или дебаты в вашей команде, результаты в той или иной степени похожи на то, что с полным правом можно назвать самым маразматичным диалогом в истории операционной системы Windows. Диалог этот по своей тупости заслуживает награды. Целой категории наград. Имя его -- Find Setup Wizard. Появляется он, когда вы хотите найти что-либо в файле справки. Проблема первая: он отвлекает. Вы пытаетесь найти помощь в файле помощи. В этот конкретный момент вам абсолютно все равно, маленькая ли база данных, большая, оптимизирована ли она под нужды клиента или покрыта шоколадом. Вам нужна помощь, а этот отвратительный диалог сообщает вам, что он должен создать список или базу данных <...>
Вот полностью согласен! Интересно, только меня он так бесит? |
|
16-07-2008 06:35>>> Вы бы на эту тему с апологетам эпла поговорили, они вам такое пораскажут :-0
Не буду, здоровье дороже ;-)
Но на писюках Микрософт предлагает пусть простые, но достаточно качественные интерфейсные решения. |
|
16-07-2008 05:46В частности, в этой книге есть интересный ответ на такие проблемы:
>>> 8) Предупреждающие сообщения не читают! Даже если три раза злобно
>>> ругнуться, "Вы уверены, что хотите всё удалить!?" - никто не прочитает,
>>> удалит все, а потом будет искать Undo и злобно ругаться :)
Программы возлагают вину на пользователей - если программа сталкивается с проблемой, она неизменно возлагает проблему на пользователя, да ко всему еще и обвиняет его в возникновении проблемы [выдаёт предупреждающее сообщение "Вы уверены?.."]. В действительности имеет место уход от другой ответственности – ответственности программы быть готовой отменить действия, пусть даже пользователь захотел их выполнить. Люди обычно принимают решения иными способами, нежели компьютеры, так что для человека нормально и типично передумать или захотеть отменить принятое ранее решение. В реальном мире за пределами компьютеров большинство действий можно отложить, изменить, обратить. Не существует причин, по которым такое поведение не может быть реализовано и в продуктах, основанных на программном обеспечении; просто создающие их программисты об этом не задумываются.
Я, как программист, конечно, возмущён :))) |
|
16-07-2008 05:37
16-07-2008 05:07| Косяки я находил даже в программах от Микрософта Вы бы на эту тему с апологетам эпла поговорили, они вам такое пораскажут :-0 Так что это далеко не пример для подражания. |
|
16-07-2008 04:45Знаете, господа, статьи все пишут и пишут, но, тем не менее, я постоянно натыкаюсь на раздражающие ляпы в интерфейсах. Причем, не обязательно в самоделках некоего Васи Пупкина, возомнившего себя крутым программером. Косяки я находил даже в программах от Микрософта, который очень много времени уделяет разработке интерфейча. Даже в своем любимом Бате встречал косячности, которые били по глазам.
Так что не вижу ничего плохого в том, чтобы повторить еще раз. Глядь, у кого-то из начинающих и отложится что-то в голове. |
|
16-07-2008 03:46А новые статьи измельчали и пишутся ради самих себя. Не для самих себя, а для соответствующего уровня компетенции программиста.
- При голосовании учитывайте уровень, на который расчитан материал. "Интересность и полезность" имеет смысл оценивать относительно того, кому именно предназначался материал.
|
|
16-07-2008 02:36To Слава
Все верно и еше куча всяких заморочек, но про это тоже уже написано. А новые статьи измельчали и пишутся ради самих себя. |
|
15-07-2008 14:12А вот у меня много замечаний :)
Среди моих пользователей много и опытных и неопытных, но самое главное их МНОГО и я наблюдаю за ними часто.
Наблюдаю из-за спины, так чтобы меня не видели и не знали, что я смотрю! Иначе пользователь ведет себя образцово, как водитель, проезжая мимо гаишника и реальной картины программист не наблюдает.
1) Про назначение клавиши TAB не знает почти никто!
2) Про клавиши по умолчанию Enter/Esc знают 50%. Лучше делать соответствующие кнопки крупными (больше стандартных Виндусовских), чтобы по ним легче было попасть мышкой. У меня 35*140 пикселей.
3) Все диалоговые окна должны открываться по центру экрана. А на двухэкранниках по центру одного из экранов!!! Я для этого унаследовал все окна от общего предка, который правильно позиционирует диалоговые окна, так как Delphi этого не умеет.
4) Некоторые никогда не открывают Popup-меню. Не знают, не любят или не догадываются. Там не должно быть "незаменимых" команд.
5) В Popup-меню игнорируют подпункты.
6) Некоторые никогда не лазят в основное меню, если кнопками продублировано > 50% его содержания и, потому, не знают про другие возможности.
Бороться можно оставив что-то "незаменимое" только в основном меню, например "Печать" или "Открыть файл", то, что надо каждый день, но редко, 1-2 раза.
7) Многие не знают про Drag&Drop или не любят его "из принципа". Видать 1-2 раза перетащили не туда и теперь их от него клинит. Им нужен вариант Copy/Cut/Paste или другой аналог более подходящий по смыслу.
8) Предупреждающие сообщения не читают! Даже если три раза злобно ругнуться, "Вы уверены, что хотите всё удалить!?" - никто не прочитает, удалит все, а потом будет искать Undo и злобно ругаться :)
Сообщения должны быть максимально короткими (длинные никогда не дочитывают).
Их должно быть ОЧЕНЬ мало! Тогда пользователь не нажмеит кнопку на автомате, а удивится "редкому явлению" и прочитает.
Это не все, но это часто упускают из виду. |
|
15-07-2008 06:29сообщение от автора материала Всем спасибо за замечания. Учту во второй версии. :)
Все должно быть ровно. Особое внимание на всякие PageControl, когда на одном и том же месте могут появляться разные компоненты. Здесь может возникнуть эффект мультпликации, когда при быстром переключении страниц "компоненты" скачут с места на место
Совершенно верно, сколько раз сам наталкивался на подобное в своих программах и долго сидел подгонял буквально до одной точки. |
|
15-07-2008 06:12Данная статья, как бы так сказать, включает в себя лишь незначительную часть того, что может сделать программист в пользовательском интерфейсе для поднятия удобства использования своей программы. В сети на эту тему присутствует очень много материала.
Приведу ссылку на весьма интересный цикл статей по созданию UI - это тоже может пригодиться программистам и дизайнерам пользовательского интерфейса. Это ссылка на первую главу, в нижней части страницы есть ссылка на следующую страницу и.т.д.
http://russian.joelonsoftware.com/uibook/chapters/1.html |
|
15-07-2008 05:42>>> Размеры окон не должны превышать размеров экрана
Требование-то верное, но как его выполнить? :( Проектировать окна под минимально допустимый размер 640x480? А как тогда использовать возможности больших разрешений (я не говорю про 1600x1200, хотя бы 1200x800)?
Кстати, есть и противоположная ошибка - окно нельзя увеличить, а изначально оно было сделано маленьким именно с учётом этого требования. Взять хотя бы Delphi - в нём есть окна, которые ну просто нужно растянуть, чтобы удобно видеть всю информацию (длинные файловые пути, списки и т.п.). Ужасно бесит. Хоть в новых Delphi интерфейс частично переработан и то полегче стало. |
|
15-07-2008 05:39| Я бы еще сделал добавление в п.7. Не только изменение размеров окна не должно приводить к исчезновению оконных элементов, но и изменение размера стандартных шрифтов. Помню использовал какую-то программу (типа драйвера навороченной видеокарты), там появлялась форма без возможности изменения размеров, при использовании крупных шрифтов меню начинало изображаться на двух строках и кнопочка "Ок" уползала вниз за границы окна. А вроде ж не ламмеры писали... |
|
15-07-2008 05:34Хорошая и полезная статья. Вроде бы, все очевидно, но почему-то ошибки, указанные здесь, все равно встречаются.
Добавлю немного от себя.
>>> 8. Хинты везде, хинты всегда
Но желательно оставить возможность отключить показ хинтов. Если человек с программой на "ты", то его сплывающие на каждый чих хинты могут раздражать.
>>> Не стоит раскрашивать компоненты на форме во все цвета радуги.
Очень-очень важный момент. Минимум цветов (как и минимум различных шрифтов в документе). От себя добавлю еще, что крайне рекомендуется задавать не абсолюттные значения цветов, а использовать предопределенные константы OC (типа, clBtnFace, clHighlight и т.п.). Иначе программа будет выглядеть очень коряво на Винде с нестандартной темой.
Еще от себя: обратите внимание на положение элементов управления. Все должно быть ровно. Если что-то вызывает сомнения, сделайте скриншот экрана и рассмотрите в Paint под увеличением. Небольшой расхождение в один пиксел очень режет глаз, создавая ощущение лискомфорта. Особое внимание на всякие PageControl, когда на одном и том же месте могут появляться разные компоненты. Здесь может возникнуть эффект мультпликации, когда при быстром переключении страниц "компоненты" скачут с места на место. Если Вы разрабатываете форму с PageControl, то по завершении разработки не поленитесь потратить некоторое время на то, чтобы погонять быстро странички туда-сюда и посмотреть не возникает ли каких-либо эффектов (кроме скачков могут быть и другие неприятные эффекты, так как на одном и том же месте на разных старницах могут оказаться разные компоненты. |
|
15-07-2008 05:11Маленький узелок на заметку разработчикам форм.
В VCL есть глюк (не знаю, с какой версии тянется, может исправлен уже, но по крайней мере в Delphi 7 есть).
Когда мы разрабатываем форму, у которой BorderStyle = bsSizeable (это значение по умолчанию; позволяет изменять размеры формы во время выполнения программы) или bsSizeToolWin (то же, но для "инструментальных" окон, с уменьшенной областью заголовка), то мы можем столкнуться с тем, что при запуске программы на другом компьютере (с другим экранным разрешением) размеры формы исказятся и мы неожиданно увидим либо полосы прокрутки, которых при разработке не было, либо пустую область справа и снизу от формы, которой опять же при разработке не наблюдалось.
Связано это, видимо, с какими-то ошибками в реализации VCL, как-то всё руки не доходят изучить эту ситуацию досконально.
Часто пытаются бороться с этим явлением, выставляя свойство Scaled в False, либо AutoSize в True. К сожалению, эти меры могут привести к другим нежелательным эффектам.
Однако есть очень простой способ избавиться от этой напасти раз и навсегда. Для этого нужно выставить в свойствах формы BorderStyle = bsDialog (вместо bsSizeable), или bsToolWindow (вместо bsSizeToolWin), а в обработчике события OnCreate выставить нужное нам значение: function TMyForm.FormCreate(Sender: TObject);
begin
BorderStyle := bsSizeable;
end; |
|
|
|
