Нужно ли редактировать страницы и просматривать страницы одинаково? - PullRequest
1 голос
/ 11 марта 2009

С точки зрения дизайна и удобства использования, лучше ли, чтобы страница редактирования имитировала макет страницы просмотра?

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

Ответы [ 5 ]

2 голосов
/ 11 марта 2009

Это определенно ухудшает удобство использования. Две опасности переустройства полей:

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

Эти проблемы усугубляются на страницах с высокой плотностью.

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

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

2 голосов
/ 11 марта 2009

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

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

1 голос
/ 11 июля 2009

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

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

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

1 голос
/ 11 марта 2009

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

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

1 голос
/ 11 марта 2009

Это зависит от вашего рабочего процесса.

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

Если ваша страница просмотра очень плотная, вы можете попробовать разбить ее на разделы, каждый со своей функцией редактирования. Вы можете сделать так, чтобы он стрелял на свою собственную страницу редактирования или был полностью «web 2.0» и включил лайтбокс с формой редактирования раздела на странице просмотра.

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