> а можно примеры адекватной иерархии Примером адекватной иерархии является практически любое меню известной программы. Я не хочу брать конкретные примеры просто потому, что каждый пример сам по себе ничего не показывает. Возьмите установленные на своём компьютере программы, у 9 из 10 меню будет достаточно адекватным, чтобы не путаться при минимальном опыте использования компьютера.
(Разумеется, есть сомнительные пункты (например, чтобы посмотреть настройки в firefox, надо идти в Edit->Preferences), но они решаются по месту - если бы это было заметной проблемой, добавили бы View->Preferences с закрытием изменений.)
> было бы интересно, как вы выстроите аргументацию в защиту интерфейса доступа к
> лбому элементу иерархии
Простите, а это надо защищать? По-моему, и меню, и командная строка, и предложение Шаттлворта - это всё "интерфейс доступа к любому элементу" (иерархии или нет - несущественно, потому что иерархия внутри есть всегда)
> насчет конкретики - вам уже предложили отображение в плоском виде, выбор нужного
> элемента упрощен на мой взгляд до предела
Плоский вид - это как раз не упрощение, а усложнение. Плоский вид хорош при полном наборе элементов не более чем в 10. Уже при 15 он сомнителен. Чем дальше, тем нуднее становится искать что-то в этом списке и тем самым усложняется работа с ним.
Оптимум элементов на каждом уровне иерархии - это пресловутые 7+/-2. Ладно, для программистов - до 12, и то - в конце рабочего дня начинаешь путаться.
> есть ли более эффективное решение, которые вы заочно так яростно защищаете?
Конечно, есть. Для общения в режиме опережающего вопроса лучше чем меню так и не придумали. Возможно, с массовым дублированием пунктов, переформулировками на разный стиль - это уже вопрос качества восприятия пользователями - но сама по себе возможность получить варианты выбора, не будучи в состоянии (временно или постоянно) чётко сформулировать и определить нужный, критична для работы. Поэтому, пока Шаттлворт играется с альтернативами - пусть себе играется, я даже "за", но как только он заявляет, что "HUD, which will ultimately replace menus in Unity applications", я "хватаюсь за пистолет" (tm).
>> Ага. То есть для начала в интерфейсе надо придумать, кроме того, как что-то назвать, ещё и отловить все "псевдонимы" (странно, я думал, что проблема больше в синонимах - Вы их не путаете часом?)
> Это вам только кажется, что все сложно. На самом деле для простых
> операций удаления/модификации in place количество вариантов, полагаю, будет сводиться
> к одному-двум.
При чём тут "удаление/модификация in place", и, кстати, что Вы вообще имеете в виду под этим? Я не понимаю, что это значит в контексте организации меню, HUD или любого другого стиля интерфейса (а не конкретных пунктов, которые тут неважны). Уточните, plz.
> Полагаю, можно даже математически просчитать для всех пунктов меню и даже наверное
> для всех действий конкретной программы, сколько действий займет доступ к нужному
> пункту.
Можно. Более того, нужно. И это регулярно делается соответствующими структурами в заинтересованных организациях. Проблема не в этом. Организация эффективного интерфейса для типичных, шаблонизированных и закреплённых в навыках действий, и организация интерфейса, пригодного для всех видов работы, включая те, которые ни разу не делались - это совершенно разные и во многом несовместимые задачи. И их надо решать раздельно.
> Есть только один неточно измеряемый фактор - субъективизм ассоциативной системы пользователя,
> но даже это я думаю просчитывается. Можно взять вполне конкретный пример
> непростой программы, тот же Blender.
У меня такого нет и облом ставить. Поэтому не скажу, что там "так" или "не так". Но могу поспорить, что предложение М.Ш. с *заменой* меню "не взлетит". Реально останется вариант вызова полной иерархии, пусть даже через "шестерёнку" в углу, как в Chrome.
