Рекомендуемый подход для разработки основных / подробных форм на одной странице? - PullRequest
0 голосов
/ 22 сентября 2010

У меня есть одна веб-страница с основной формой детализации / макетом ввода.В настоящее время форма работает следующим образом:

  1. Пользователь открывает страницу, содержащую оба элемента управления вводом основных / подробных данных, и вводит основную информацию (кнопка сохранения сведений отключена)
  2. Когда онсохраняет основную информацию, кнопка «Сохранить мастер» отключается и включается сохранение сведений
  3. Пользователь продолжает вводить несколько сведений, которые заполняются в виде таблицы внизу страницы
  4. Все работает хорошо
  5. Проблема в том, что основная часть содержит множество элементов управления вводом данных (выпадающие списки видов сетки и т. Д.)

Как я могу облегчить пользователю намного больше, чем текущий макет?Должен ли он быть перенаправлен на новую страницу после того, как он войдет в основную запись?Как я могу улучшить это?

Ответы [ 2 ]

1 голос
/ 22 сентября 2010

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

Предполагая, что желательно сохранить все на одной странице, я думаю, что вижу несколько вещей, которые вы можете сделать:

  • Используйте редактирование на месте как для мастера, так и для детализации, поэтому вам не понадобится место для редактирования / создания записи и пространство для ее отображения. Каждое поле должно появляться только один раз.

  • Соберите ваши элементы управления более плотно вместе. Вы можете сделать это, не выглядя слишком загроможденным, если вы применяете более тихий визуальный стиль (например, теряете реверс-видео и правила). Выделите около 20 пикселей по вертикали для одного элемента управления

  • Примите синтаксис действия выбора объекта, чтобы вам не нужно было занимать место, повторяя одни и те же командные кнопки / ссылки для каждой записи. Это оставляет больше пространства для полей.

  • Поместите ваши столы в свои собственные панели с вертикальной прокруткой. Таблицы, которые у вас сейчас есть, уже довольно короткие (5 или менее строк), но ограничение их до 5 или менее видимых строк не позволит окну быть слишком длинным для случаев, когда строк много.

  • Предполагая, что у вас есть редактирование на месте, используйте более широкие таблицы, каждая из которых установлена ​​на отдельной панели с горизонтальной прокруткой, чтобы уменьшить высоту, перемещая поля из пространств «переполнения» в таблицы. Убедитесь, что у вас есть заголовки строк, которые не прокручиваются.

  • Разделите поля на вкладки, особенно на мастере. Это уменьшает пространство, необходимое мастеру, до доли. Вы можете иметь вкладки в пределах части мастера, если ваши пользователи должны постоянно видеть ключевые поля.

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

  • Подумайте об использовании интерфейса «подкачки» для стека многострочных текстовых полей в нижней части мастера, чтобы они «складывались» в z-измерении, а не в y-измерении, и таким образом занимали пробел в одном текстовом поле.

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

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

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

1 голос
/ 22 сентября 2010

Возможны различные варианты:

  1. На странице может отображаться основная и сводная информация (сетка) деталей. Кнопка Сохранить будет работать только для основных данных. Добавление / редактирование деталей происходит в модальном всплывающем окне.

  2. Иметь представление с вкладками - одна вкладка будет отображать мастер, а другая вкладка будет отображать детали. Там будет одна кнопка сохранения на вкладке. Переключение вкладок произойдет на стороне клиента.

  3. И мастер, и детали всегда открыты для редактирования. Любые изменения в деталях будут временно удерживаться в состоянии просмотра / состоянии сеанса. Кнопка сохранения для мастера сохранит изменения как для мастера, так и для деталей. Нет необходимости отключать любой пользовательский интерфейс.

Обычно мы предпочитаем # 1 - IMO, его простой пользовательский интерфейс с точки зрения пользователя.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...