Лучший способ показать экраны пользователю в приложении
Я разрабатываю приложение Winforms, которое работает в течение многих лет с видом обозревателя (TreeView слева, экран справа). Я имею в виду, что:
- Все экраны имеют иерархическую организацию
- Все узлы в TreeView имеют один и только один связанный экран.
- Экран активируется, когда выбирается узел в виде дерева.
Одним из преимуществ является то, что у пользователя есть упорядоченная структура, и одно из неудобств состоит в том, что с сотнями экранов пользователь запутывается.
Я вижу другие варианты: используйте классические меню, используйте вкладки или все что угодно.
Какой-нибудь совет для хорошего способа показать много экранов пользователю удобным для пользователя способом?
Обновление: я изменил "сотни экранов" на "много экранов". Самое главное не показать все вовремя, а то, что пользователь может легко найти то, что ему нужно.
Обновление 2: в этом предложении пользователь видит только один экран за раз.
Update3: я говорю об обработке нескольких экранов, не показывая несколько экранов. Нет MDI, только один вовремя.
5 ответов
Я использовал другие приложения, похожие на это в прошлом, и основная проблема заключается в попытке найти именно тот экран, который вы хотите. Существует два распространенных решения этой проблемы: горячие коды и меню избранного.
С помощью кодов быстрого доступа назначьте короткий код (5 или 6 символов) для каждого экрана. Затем пользователь вводит этот код быстрого доступа в текстовое поле, которое затем переходит на правильный экран. Пользователи будут создавать свой собственный список часто используемых кодов.
Для меню избранного предоставьте пользователям возможность создавать свой собственный список меню в структуре, которую они хотят. Им будет легче, если они сами это организуют.
Зачем вам нужно показывать так много отдельных экранов одновременно? Почему бы просто не показать экран для выбранного узла, зачем все сразу?
Если это все табличные данные, это, вероятно, слишком много, чтобы потреблять их все сразу, если это графические данные, не могут ли они быть объединены?
Может быть веская причина, чтобы показать все данные сразу, или нет, трудно сказать из того, что указано в вашем вопросе. С учетом вышесказанного, лучше сделать это проще, чем перегружать пользователя. Приложения MDI никогда не просты в использовании.
Вкладки могут работать для небольшого набора элементов, но все еще не являются хорошим интерфейсом для сотен элементов.
Если вы одновременно показываете только один элемент из сотен возможных на узлах дерева, тогда это нормально. Один экран, показываемый одновременно, будет контекстным для элемента, выбранного при перемещении пользователя по узлам. Подумайте о подходе Outlook, в котором то, что выбрано на левой панели, отображается на правой панели в любой форме, подходящей для отображаемых данных.
Рассматривали ли вы офисную ленту?
Лента дает вам большую гибкость в том, как показывать и организовывать функции, и она очень наглядна.
Вот хорошая ссылка о Ленте, а также здесь
Чтобы использовать ленту, вы должны получить лицензию от Microsoft. Вы можете сделать это онлайн.
Предоставление пользователю выстрелов кетборда, как правило, тоже хорошо.
Я также хотел бы предоставить пользователю поле "автозаполнение" в меню, чтобы они могли найти функцию по имени (или ее части) и иметь возможность непосредственно перейти туда, куда они хотят пойти.
На самом деле, сложно разбить иерархию для организации большого количества предметов. Я не предпочел бы классическое выпадающее меню для огромного количества окон, потому что было бы еще сложнее отслеживать, где вы находитесь, чем в дереве (например, дерево позволяет вам просматривать несколько ветвей одновременно). Но вот несколько альтернатив:
Мне непонятно, как у вас получилось так много окон, но, возможно, это происходит из-за сочетания классов, представлений, контента и деталей, или, может быть, из-за использования ориентированной на задачи структуры пользовательского интерфейса для чего-то слишком сложного (я Подробнее об этом на http://www.zuschlogin.com/?p=3). Для сложных приложений требуется отдельное главное окно для каждого значимого класса объекта данных (например, счета, сотрудники). Они перечислены в одном меню, и обычно их достаточно (15 или меньше), чтобы это могло быть одно не каскадное выпадающее меню. Содержимое каждого окна задается отдельным меню, возможно, с помощью пункта меню, который открывает диалоговое окно, которое может включать в себя список со списком (например, диалог открытия) или другие элементы управления для запроса / поиска. "Вид" каждого окна (как отображаются объекты данных, например, таблица в сравнении с формой) задается пунктами меню в меню "Вид". Детали для любого данного объекта в окне могут быть показаны на отдельной панели внутри окна в отношении "мастер-детализация", по существу превращая ваши объекты данных в меню для деталей. Одно окно может иметь несколько панелей подробностей, чтобы пользователь мог открывать и закрывать для выбора конкретной детали для отображения. Вкладки могут также использоваться в пределах одной панели, чтобы соответствовать подразделам контента.
Вы говорите, что не важно показывать все параметры окна одновременно, но часто показывая все параметры одновременно, пользователям проще всего найти то, что им нужно. Может быть, вам нужно "домашнее" окно, в котором перечислены все другие окна в организованных, помеченных и разделенных категориях. Это будет проще в использовании, чем дерево, если ваши пользователи выбирают окно, а затем придерживаются его в течение большей части сеанса. Ваше дерево будет лучше, если в течение сеанса будет часто выбираться окно из-за накладных расходов, связанных с переходом к главному окну. Если все окна / опции не умещаются в одном главном окне, тогда показывать только выбранные общие окна для каждой категории в главном окне и предоставить кнопку или ссылку для отображения исчерпывающего списка.
Если вы говорите о сотнях окон, возможно, вам нужен поиск, возможно, в дополнение к основанному на меню подходу к просмотру окна.
В любом случае, обеспечить легкий доступ к нескольким наиболее часто используемым окнам - хорошая идея. Такие окна могут быть явно выбраны разработчиком на основе исследования пользователя или выбраны пользователем (избранное), но они также обычно работают хорошо, чтобы сделать их автоматически с помощью алгоритма, который использует некоторую комбинацию частоты и времени использования.
В целом, я считаю деревья плохой идеей, особенно если ваша "иерархия" имеет небольшую фиксированную глубину.
Если у вас небольшая фиксированная глубина, рассмотрите возможность замены дерева списком. В верхней части списка могут быть раскрывающиеся списки для фильтрации на основе свойств уровня узла. Он будет занимать меньше места на экране, потому что он только вертикальный, без горизонтальной составляющей.
Щелкнув по элементу, можно отобразить его в виде (как в настоящее время), но это может быть хорошей идеей, чтобы позволить пользователю дважды щелкнуть более чем один элемент, который может запустить больше окон, или создать мозаику с существующими отображаемыми элементами. (Я предполагаю, что в настоящее время пользователь видит только один подробный вид сразу в любом данном окне.)