Есть некое контекстное меню сферического объекта. Оченно хочется сделать как-то так:



Т.е дать возможность настроить меню in-place — хоткеи, поменять пункты местами, скрыть/показать. Смущает магический момент перехода меню из обычного режима в режим редактирования и обратно — как его организовать? Ещё больше смущает тот факт, что подобной функциональности я нигде не наблюдал.
Отговорите меня

Здравствуйте, cgibin, Вы писали:
C>Т.е дать возможность настроить меню in-place — хоткеи, поменять пункты местами, скрыть/показать. Смущает магический момент перехода меню из обычного режима в режим редактирования и обратно — как его организовать?
Ну, я бы задумался об Alt-RightClick для такого.

C>Ещё больше смущает тот факт, что подобной функциональности я нигде не наблюдал.
Ну, в офисе в до-риббонные времена кнопка Alt применялась для модификации тулбаров. Можно было перетаскивать кнопки и всё такое.

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

Подозреваю, что такие вещи требуются редко, в специфических софтах. Причем таких, в которых юзер работает ежедневно и помногу, по несколько часов в день. Иначе подобные новшества в UI скорее всего не будут оправданы. Это была запрошенная попытка отговорить.

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

Если пункты меню можно скрывать, то можно сделать, как в виндах, подобно тому, ка они прячут "редко используемые" айтемы (я имею в виду чисто визальный прием). Это чтобы их было просто доставать взад, если потребуется.

C>Т.е дать возможность настроить меню in-place — хоткеи, поменять пункты местами, скрыть/показать.

Как часто ваши родственники меняют меню word под себя? Какой процент из них вообще знает об этой возможности?

C>Смущает магический момент перехода меню из обычного режима в режим редактирования и обратно — как его организовать?

Не обязательно делать настройку "онлайн". Поместите настройку в дебри остальных настроек программы.

С одной стороны наглядно всё сделано, мне нравится идея, с другой — возьмите к примеру Total Commander — как настроить его огромное меню таким способом? Удобно ли будет искать/добавлять/удалять элементы?

Здравствуйте, Моторокер, Вы писали:

C>>Т.е дать возможность настроить меню in-place — хоткеи, поменять пункты местами, скрыть/показать.

М>Как часто ваши родственники меняют меню word под себя? Какой процент из них вообще знает об этой возможности?

C>>Смущает магический момент перехода меню из обычного режима в режим редактирования и обратно — как его организовать?

М>Не обязательно делать настройку "онлайн". Поместите настройку в дебри остальных настроек программы.

М>С одной стороны наглядно всё сделано, мне нравится идея, с другой — возьмите к примеру Total Commander — как настроить его огромное меню таким способом? Удобно ли будет искать/добавлять/удалять элементы?

+1
Абсолютно согласен!
Мне тоже кажется, что это излишне. Опять же хоткей (аксели) надо будет проверять на совместимость, т.е. хорошо бы видеть и соседние клавиши из соседних подменю.
Например, если в настройках есть конфликт двух клавиш, совпадают для разных команд меню, то в редакторе клавиш можно это запросто продемонстрировать. Отсканить текущие настройки, и где-нить полем ниже показать конфликтующие команды — эдакая hot indication: пользователь набирает клавиши, программа на лету сканирует выставленные настройки, и в поле ниже сразу показываем есть или нет конфликты. В меню такого НИКАК не сделать, т.к. конфликтующая команда может быть в соседнем меню, и пока ОК не ткнут ничего и не сделаешь. А на кой "ОК-нажималова" надо!?! Если можно на лету просканить и показать проблемы в виде подсказки, отдельным полем, вообще не требуя сиюсекундной реакции пользователя!?! захочет потом переставит конфликтные команды, или сходу поменяет сочетание клавиш

Как-то делал настройку меню, правда куда как проще. Но факт остался фактом — настройкой пользуется от силы 1 (один) из тысячи, так что сильно заморачиваться не стоит. Другой разговор, что шаблон Good Defaults ("хорошие настройки по умолчанию") нужен! Надо выбрать конфигурацию по умолчанию наиболее удобную середнякам, основной массе, но это доводится итерациями, по мере фидбека от пользователей (в моем случае все было тривиальнее: какие команды в меню есть дефолтом, а какие он может включить отдельно — дык все равно мало кто перенастраивает, даже это-то... ).

Здравствуйте, Carc, Вы писали:

Я, пожалуй, отвечу в одном сообщении, чтобы не растекаться мыслёй по древу

S>Ну, я бы задумался об Alt-RightClick для такого.
Discoverability плохая, нужно ещё как-то визуально дать намёк в самом меню.

М>>Не обязательно делать настройку "онлайн". Поместите настройку в дебри остальных настроек программы.
Меня, как юзера, ничто не повергает в большее уныние, чем созерцание десятка закладок и прочих настроечных деревьев. Однажды мне понадобилось что-то настроить в TC, и я до сих пор под впечатлением, и никогда туда не вернусь добровольно Это я к тому, что у юзера может быть негативный experience настроек других программ, и одно слово "Настройка" может отвращать. А так получается, что нет отдельного действия "настроить меню", но есть естественное продолжение взаимодействия с меню. Кол-во пунктов разумное, так что дискомфорта не будет.

G>Если очень нужно, я бы сделал примерно так. Напротив пункта меню, который можно настраивать, в той же строке, что и сам item, поместил бы маленький значок, по которому надо чмыкать для настройки. Если настраивается все меню, то в углу самого меню поместил бы что-то аналогичное.
Т.е ты имеешь ввиду сделать этакую гиперссылку на настройку меню в "Настроечном Окне всея Программы"? Неплохой вариант, возможно, стоит даже сделать выборку настроек только этого элемента и показывать не все настройки, а только это подмножество.

C>Например, если в настройках есть конфликт двух клавиш, совпадают для разных команд меню, то в редакторе клавиш можно это запросто продемонстрировать. Отсканить текущие настройки, и где-нить полем ниже показать конфликтующие команды — эдакая hot indication: пользователь набирает клавиши, программа на лету сканирует выставленные настройки, и в поле ниже сразу показываем есть или нет конфликты. В меню такого НИКАК не сделать, т.к. конфликтующая команда может быть в соседнем меню, и пока ОК не ткнут ничего и не сделаешь.

Ну почему, внутрях есть хоткей менеджер, его можно спросить о любом хоткее. Затем нарисовать hint "Бла-бла конфликт с командой такой-то" и дать ссылку на закладку настроек хоткеев. Юзер может снова попытаться подобрать хоткей на месте или перейти прямо к списку всех хоткеев и там всё настроить.

C>А так получается, что нет отдельного действия "настроить меню", но есть естественное продолжение взаимодействия с меню. Кол-во пунктов разумное, так что дискомфорта не будет.

А вот это вовсе не факт, что хорошо. Потому что "настраивать меню" и "взаимодействовать с меню" вообще могут разные люди.

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

Здравствуйте, klopodav, Вы писали:

K>А вот это вовсе не факт, что хорошо. Потому что "настраивать меню" и "взаимодействовать с меню" вообще могут разные люди.

Хорошее замечание. Действительно, такой подход в некоторых сценариях может создать неудобства. С другой стороны, можно все настройки сгружать в xml на радость админам

Здравствуйте, Carc, Вы писали:

C>больше смущает тот факт, что подобной функциональности я нигде не наблюдал.

Во всех GNOME-приложениях шоркаты меню меняются таким образом: нужно выделить пункт меню и прямо на клавиатуре нажать новый шорткат. И всё.

Здравствуйте, cgibin, Вы писали:

C>Есть некое контекстное меню сферического объекта. Оченно хочется сделать как-то так:

C>[!--img]http://files.rsdn.ru/77970/menus.png[/img]

Чекбоксы слева реализованы в MS Office 2003, но только не для контекстных меню, а для тулбаров (...не в лотерею, а в преферанс, не выиграл, а проиграл...). Сделано это следующим образом: в конце каждого тулбара есть "хвостик", в нем — Add or Remove Buttons >, выпадает полное меню с чекбоксами видимости. Ни разу не пользовался: легче зажать Alt и снести кнопарик или зайти в Customize.

А вот для вашего контекстного меню это было бы прикольно: с ним Alt не сделать, а Customize неочевиден. Сделайте, например, этот "хвостик" снизу, как для сокращенных меню из MSO 2003. Толщиной в пять пикселей. Там же и порядок можно настроить.

Что касается хоткеев, не советовал бы. Хоткеи ассоциируются с командами, которые отображаются как пункты меню. Не у пунктов меню надо настраивать хоткеи, а у команд.

C>Т.е дать возможность настроить меню in-place — хоткеи, поменять пункты местами, скрыть/показать. Смущает магический момент перехода меню из обычного режима в режим редактирования и обратно — как его организовать? Ещё больше смущает тот факт, что подобной функциональности я нигде не наблюдал.
C>Отговорите меня

Здравствуйте, cgibin, Вы писали:
...
G>>Если очень нужно, я бы сделал примерно так. Напротив пункта меню, который можно настраивать, в той же строке, что и сам item, поместил бы маленький значок, по которому надо чмыкать для настройки. Если настраивается все меню, то в углу самого меню поместил бы что-то аналогичное.
C>Т.е ты имеешь ввиду сделать этакую гиперссылку на настройку меню в "Настроечном Окне всея Программы"? Неплохой вариант, возможно, стоит даже сделать выборку настроек только этого элемента и показывать не все настройки, а только это подмножество.

Я имел в виду примерно такое меню:

Чмыкаем по item'у — все как обычно. Чмыкаем точно по значку (квадратик), вылезает что-то для настройки этого айтема. Для настройки меню в целом можно поместить аналогичный значок, например, в правый нижний угол.

Подобные "квадратики" мне встречались (правда, с немного другим смыслом). Само кликанье по ним или по айтемам у юзера затруднений не вызывает, смысл юзер понимает сразу.

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

Здравствуйте, cgibin, Вы писали:

C>Ещё больше смущает тот факт, что подобной функциональности я нигде не наблюдал.
C>Отговорите меня

Когда разработчик не может принять решение — он добавляет опцию (с)

Здравствуйте, Кодёнок, Вы писали:

Кё>Здравствуйте, cgibin, Вы писали:

C>>Ещё больше смущает тот факт, что подобной функциональности я нигде не наблюдал.
C>>Отговорите меня

Кё>Когда разработчик не может принять решение — он добавляет опцию (с)

Когда решение в дизайне может развиваться двумя путями, архитектор должен сделать шаг назад. Вместо выбора альтернативы между А и В нужно задать себе другой вопрос: «Как сделать дизайн таким, чтобы выбор между А и В был менее значимым?». Самое интересное – не выбор между А и В, а само наличие такого выбора (и кстати, сам выбор далеко не всегда будет окончательным).

Оригинал тут

Здравствуйте, Carc, Вы писали:

Кё>>Когда разработчик не может принять решение — он добавляет опцию (с)
C>
C>Когда решение в дизайне может развиваться двумя путями, архитектор должен сделать шаг назад. Вместо выбора альтернативы между А и В нужно задать себе другой вопрос: «Как сделать дизайн таким, чтобы выбор между А и В был менее значимым?». Самое интересное – не выбор между А и В, а само наличие такого выбора (и кстати, сам выбор далеко не всегда будет окончательным).

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

Вот и автор топика туда же — не смог определить состав меню? не беда, дадим юзеру возможность его настройки!

Настройка программы — услуга третьего рода; юзеру надо чтобы его проблема была решена, мало того, что ему вместо этого дают программу, с помощью которой он [если повезет с программой] может сам ее решить, так программеры еще добавляют опции, с помощью которых можно настроить программу, с помощью которой он сможет решить проблему!

Не хватает только двухтомной доки, с помощью которой он сможет разобраться в опциях, с помощью которых он сможет настроить программу, с помощью которой он [если не сдохнет] сможет решить проблему. И программы-просмотрщика для этой доки, с поиском. Которая тоже имеет настройки, само собой.

Здравствуйте, Кодёнок, Вы писали:

Кё>Здравствуйте, Carc, Вы писали:

Кё>>>Когда разработчик не может принять решение — он добавляет опцию (с)
C>>
C>>Когда решение в дизайне может развиваться двумя путями, архитектор должен сделать шаг назад. Вместо выбора альтернативы между А и В нужно задать себе другой вопрос: «Как сделать дизайн таким, чтобы выбор между А и В был менее значимым?». Самое интересное – не выбор между А и В, а само наличие такого выбора (и кстати, сам выбор далеко не всегда будет окончательным).

Кё>Это у меня сарказм был. Этот принцип хорошо работает в архитектуре, но программисты имеют тенденцию переносить его и на дизайн UI, в результате чего получается ужас, а не интерфейс.

Кё>Вот и автор топика туда же — не смог определить состав меню? не беда, дадим юзеру возможность его настройки!

Кё>Настройка программы — услуга третьего рода; юзеру надо чтобы его проблема была решена, мало того, что ему вместо этого дают программу, с помощью которой он [если повезет с программой] может сам ее решить, так программеры еще добавляют опции, с помощью которых можно настроить программу, с помощью которой он сможет решить проблему!

Кё>Не хватает только двухтомной доки, с помощью которой он сможет разобраться в опциях, с помощью которых он сможет настроить программу, с помощью которой он [если не сдохнет] сможет решить проблему. И программы-просмотрщика для этой доки, с поиском. Которая тоже имеет настройки, само собой.
+1
Согласен на все 100! За исключением одной детали, программа это фигня, но если вдуматься программа просмотрщик доки это тоже фигня. А вот программа просмотрщик настроек к программе просмотра доки — вот енто по нашему.

Но с другой стороны, цитата из перевода AVL как раз очень в тему:
1) Сам факт наличия выбора куда-как любопытнее! Очень много раз напарывался на это — это действительно свидетельствует о многом: а туда ли мы идем, а в чем вопрос? По большому счету очень полезно задуматься, а зачем он вообще этот выбор? Причем с точки зрения пользователя — вот берется пользователь за программу, размахивается плечом, и вдруг ему "Подтвердите что вы хотите врезать топором по полену. Да\Нет\Отмена" — зачастую можно не только найти ответ по умолчанию, но и вовсе избавиться от вопроса! А лучший ответ — это отсутствие самого вопроса пользователю

2) Второе, что мне отдельно понравилось: потянуло на вопросы — отложи ответы. Лучше сделать один вариант использования (ну все же подумав, какой именно), а не писать ветвления кода по поведению в UI. Полагаю, заведение 33-х опций для вариантов поведения UI, это как раз не ответ — это уход от ответа, попытка переложить все на пользователя. А он все равно не будет отвечать на эти вопросы — дык стоит ли огород городить!?! Если пользователю вовсе не понравится реализованный вариант использования, вот об этом он сообщит. А если их 3 — то вряд ли он он озаботится ответственностью выбора вместо авторов...

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

Здравствуйте, Кодёнок, Вы писали:

Кё>Настройка программы — услуга третьего рода; юзеру надо чтобы его проблема была решена, мало того, что ему вместо этого дают программу, с помощью которой он [если повезет с программой] может сам ее решить, так программеры еще добавляют опции, с помощью которых можно настроить программу, с помощью которой он сможет решить проблему!

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

Здравствуйте, cgibin, Вы писали:

C>

C>Т.е дать возможность настроить меню in-place — хоткеи, поменять пункты местами, скрыть/показать. Смущает магический момент перехода меню из обычного режима в режим редактирования и обратно — как его организовать? Ещё больше смущает тот факт, что подобной функциональности я нигде не наблюдал.

Такая функциональность реализована в DevExpress. Посмотри как там сделано.

C>Отговорите меня

Если ты будешь писать все с нуля, то лучше не маяться дурью