а если кто в курсе - что говорят по поводу ХИГи разных национальностей?

> что говорят по поводу ХИГи разных национальностей?

Они говорят «keep user informed», поэтому п. 1.

Первое, конечно. Второе бесит и не нужно.

2. интерфейс - лишь морда.

Второй вариант выглядит лучше если на первой стадии операции выдает ....

А вобще наверное 1.

Первое.
Второе когда встречаю - хочется разработчика банально покарать черенком.

3. Показывать все элементы, но если элемент по какой-то причине недоступен — не прятать его, а давать ему свойство «disabled».

Не знаю что мне было бы удобнее, но для «простых пользователей» я бы сделал первый вариант. Причем лучше, наверное, «лишние» элементы интерфейса, иначе простые пользователи занодаедят тупыми вопросами почему это им не нажать этоу красивую кнопочку.

В лучших традициях open source программа должна просто тихо сломаться. Шучу. :-)

>2. интерфейс - лишь морда.

Для «простого пользователя» - это вся программа, простой пользователь не знает как оно устроено унутрях.

Нравится как сделано в VLC.

>Они говорят «keep user informed», поэтому п. 1.

но при этом юзер врядли поймет - почему ему нельзя делать ту или иную операцию...

простой пример - контекстное меню файлового менеджера - «Создать директорию» - можно просто disable() ему сделать, и пусть юзер разбирается, а можно пояснить при нажатии, что «Файловая система смонтирована в режиме read-only» или " У вас нет прав доступа для записи в этой директории".

можно просто disable() ему сделать, и пусть юзер разбирается, а можно пояснить при нажатии, что «Файловая система смонтирована в режиме read-only» или " У вас нет прав доступа для записи в этой директории".

И как это поможет пользователю? У него как не работало, так и не работает. Зачем давать пользователю возможность делать заведомо невыполнимы операции? И вообще их показывать?

То, что нельзя сделать неактивным.
Можно при наведении маленькую подсказку «см. справку, раздел такойто»

>простой пример - контекстное меню файлового менеджера - «Создать директорию» - можно просто disable() ему сделать, и пусть юзер разбирается, а можно пояснить при нажатии, что «Файловая система смонтирована в режиме read-only» или " У вас нет прав доступа для записи в этой директории".

В таком варианте трудно определить границу, где нужно юзеру пояснять, а где не нужно. «Файловая система смонтирована в режиме read-only» - для многих (если не большинства) «прострых пользователей это не будет достаточным пояснением, он и слова файловая система не очень то поймет, не говоря уже о read-only.
ИМХО при написании интерфейса нужно попытаться определиться для какого уровня грамотности пользователя (пусть это даже будет сферический в вакууме пользователь) мы пишем интерфейс и уже от этого и плясать. Пользователям находящимся с обоих сторон этих рамок может быть не очень удобно пользоваться данным софтом, но для них я думаю найдется свой софт - т.е. кому то удобнее пользоваться скажем mc, кому-то - наутилусом, а кому то вообще консолью с башем. Угодить всем пользователям в рамках одного интерфейса - нереально.

> как это поможет пользователю? У него как не работало, так и не работает. Зачем давать пользователю возможность делать заведомо невыполнимы операции? И вообще их показывать?

принимается, весомо!

Не позволяй, но объясняй.

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

Если интерфейс - это что-то вроде диалогового окна с переключателями, то лучше первое. А то пользователь галочек наставит, нажмет «ОК», а ему - «Нельзя».

Первое и кстати, это даже хигоугодно ))

ИМХО при написании интерфейса нужно попытаться определиться для какого уровня грамотности пользователя (пусть это даже будет сферический в вакууме пользователь) мы пишем интерфейс и уже от этого и плясать.

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

Делать их нечувствительными-самое интуитивно понятное на мой взгляд

В идеале - дизэйблить.

Я недавно разработчиков пинал: есть кнопка для выполнения операции, после нажатия требуют подтверждения, ввода пароля, а потом: not allowed. Как я разозлился, когда увидел эту надпись! Оказалось, что у пользователя по определению нет прав на эту операцию, они есть только у оператора. Запинал, теперь кнопка отображается только у администратора.

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

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

>Ну и до кучи, бесит ещё, когда заполняешь 20 обязательных полей, интерфейс проверяет, находит ошибку в одном из них и сбрасывает значения всех - так тоже делать не надо.

ну это даже не обсуждается.
всем спасибо, общее мнение понятно, принято делать disable() с подсказками.

> простой пример - контекстное меню файлового менеджера - «Создать директорию» - можно просто disable() ему сделать, и пусть юзер разбирается, а можно пояснить при нажатии, что «Файловая система смонтирована в режиме read-only» или " У вас нет прав доступа для записи в этой директории".

Элементарно: пункт в меню отключить, но при наведении мыши на него писать пояснение в статусной строке.

1

>3. Показывать все элементы, но если элемент по какой-то причине недоступен — не прятать его, а давать ему свойство «disabled».+1

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

+ указать причину недоступности/что сделать, чтоб можно было воспользоваться отключённым элементом.

двое спецов по юзабилити проголосовали за 1й вариант.

хотя лично я склоняюсь к валидации всего подряд и выдаче ошибки сразу как неправильное действие сделано

Смесь 1го и предложенного варианта с дизэйблом.

Состав видимых элементов должен зависеть от роли пользователя в системе (например если представить интерфейс программы в виде набора табов с разными задачами, таб «администрирование» для обычного пользователя вообще не должен быть виден, а не только задизэйблен, т.к. ни при каких обстоятельствах у пользователя не будет причины им воспользоваться).

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

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

> Допустим есть пользовательский интерфейс, который позволяет проделать некоторые действия в логике программы

fail. Пользовательский интерфейс должен позволять проделывать некоторые действия в логике пользователя. Логика программы никого, кроме программиста не интересует.

пользовательский интерфейс не позволяет проводить запрещенные операции посредством выключения/прятанья элементов которые приводят к этим операциям

Да. И не забудьте undo/redo.

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

За каждый alert, вида «вы уверены? (да/нет)» с программиста надо брать штраф, равный 1/20 того, что он получит за работу. Если программа СПО, от отнимать 20 скора на ЛОРе.

> В толксах потому, что хочется знать мнение простых обывателей, а не только гиков )

Вы надеетесь в толксах найти не гиков? На ЛОРе? Ню-ню...

Первое. А то, что спрятано, должно быть можно настроить ручками в конфигах.

Интерфейс, спроектирвоанный специально для того, чтобы в нём разбирались без документации, никогда не будет удобным.

>Интерфейс, спроектирвоанный специально для того, чтобы в нём разбирались без документации, никогда не будет удобным.

собственно этого я и хочу избежать. Когда элемент просто disabled, не всегда понятно почему. И далеко не всегда даже документация дает на это ответ.

Случай из жизни - настраиваем NM по телефону, на другом конце провода - девушка, диктую ей IP DNS, говорю «жми Закрыть», а в ответ - не нажимается!! некорректный IP (ну не все девушки знают что IPv4 может иметь значения только 0...255 в каждом поле) не дает завершить операцию, а ведь мог бы и сказать по-человечески, что «там-то там-то прописано с ошибкой» и начинаем в телефон «читать все что видишь на экране»...

http://tema.livejournal.com/286569.html

>В контексте заглавного поста пользователь есть оператор некоторых функциональных возможностей. Набор этих возможностей у разных пользователей разный, как и обязанности. Всё. Грамотность пользователя не имеет никакого значения. Пояснять тоже ничего не нужно. Нужен набор функций, который характерен для данного уровня доступа. Для всего остального есть более привелигерованные пользователи.

Ну тогда вариант 1, что тут думать то.

>Интерфейс, спроектирвоанный специально для того, чтобы в нём разбирались без документации, никогда не будет удобным.

плюстыщапицот.

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

>Случай из жизни - настраиваем NM по телефону, на другом конце провода - девушка, диктую ей IP DNS, говорю «жми Закрыть», а в ответ - не нажимается!! некорректный IP (ну не все девушки знают что IPv4 может иметь значения только 0...255 в каждом поле) не дает завершить операцию, а ведь мог бы и сказать по-человечески, что «там-то там-то прописано с ошибкой» и начинаем в телефон «читать все что видишь на экране»...

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

k0l0b0k> Когда элемент просто disabled, не всегда понятно почему. И далеко не всегда даже документация дает на это ответ.

Если такие вопросы возникают, то пользователь не умеет работать с системой, либо интерфейс криво спроектирован.

>И как это поможет пользователю? У него как не работало, так и не работает. Зачем давать пользователю возможность делать заведомо невыполнимы операции? И вообще их показывать?

Быть может это натолкнет его на то, что надо смонтировать в режим чтения/записи? Меня постоянно наталкивает в соответствующих ситуациях

Женится вам барин надо, женится

как же напрягает вот это желание школоты, вызубрившей назубок жаргон ЛОРа, применить его в самом невероятном месте...

Второе когда встречаю - хочется разработчика банально покарать черенком.

Мне хочется покарать разработчика как в первом, так и во втором случае. Правильно и удобно сделано, ВНЕЗАПНО, в виндус семерке: операции, которым требуются права администратора помечены специальным значком и при их использовании спрашивается пароль. В том же наутилусе такой функциональности очень не хватает.

>Мне хочется покарать разработчика как в первом, так и во втором случае. Правильно и удобно сделано, ВНЕЗАПНО, в виндус семерке: операции, которым требуются права администратора помечены специальным значком и при их использовании спрашивается пароль. В том же наутилусе такой функциональности очень не хватает.

Подозреваю, топискстартер подразумевал несколько другое ПО.