Веб-страницы, которые просто делают слишком много всего

Question

Относительно страниц, которые создают веб-приложение:

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

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

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

Мои вопросы:

• Я обдумываю эти вещи?
• Кто-нибудь еще обнаружил, что делает это?
• Где счастливая среда?

Answer 1

Нет эксперта, который мог бы дать вам правило, которое работает везде и всегда. В течение многих лет я был известен в своей отрасли благодаря «легким» интерфейсам, и мы получили за это значительные объемы бизнеса (а также 5 наград «Лучший в своем классе»). У меня также были люди в моей компании, и за ее пределами - в течение многих лет - они говорили мне, что им нравится моя работа, но хотелось бы, чтобы я "подбодрил ее" большим количеством графики и тому подобного. Что меня всегда удивляет, так это то, как мало людей видят связь между ними.

Итак ... несколько правил:

1. Страница должна выполнять одну главную вещь.
2. На странице вполне может быть несколько ссылок, связанных с главным
3. Меню и расположение ссылок должны быть одинаковыми на всех страницах
4. Чем проще, тем сложнее
5. Страницы должны быть визуально привлекательными и привлекательными
6. Правило 4 более важно, чем правило 5.

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

Итак,

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

---

Несколько последних замечаний о пользовательском интерфейсе и графическом дизайне.

Во-первых, разработайте свое собственное видение и будьте единообразны для всех страниц и приложений.

Во-вторых, не бойтесь простоты .

Далее, когда вы запрашиваете советы у других, имейте в виду, что вы не хотите их совета - вы хотите их впечатлений: вы хотите понять, как они воспринимают интерфейс. Иногда советы полезны, но чаще всего вредны. По моему опыту, все думают, что они эксперт по пользовательскому интерфейсу.

Когда вы проводите тестирование на удобство использования в коридоре (или формально), вы должны игнорировать почти все рекомендации о том, что «вы должны сделать , что выделится больше». Как вы увидите, оно быстро станет «и , что », «и , что », «» и другим ». Если вы последуете этому совету, вы получите беспорядок из-за первого правила дизайна Бриттингема: Если все важно, чем ничего. (Вот так: объясняя, почему нельзя кого-то заставить выделите больше, просто скажите им, что «это нарушает первое правило дизайна Бриттингема!»)

Надеюсь, это поможет!

Answer 2

Ты ударишь ногтем по голове. Используйте принцип KISS. (Держать его просто глупо) Я делал это и раньше, и это не только создает отвратительный пользовательский интерфейс, но и сбивает с толку то, какие операции вы можете выполнять на странице из-за слишком большой функциональности. В тестировании я часто обнаруживал, что у меня недостаточно проверок, чтобы определить, может ли пользователь выполнить определенную операцию в зависимости от состояния данных.

В ASP.Net достаточно легко написать несколько страниц, которые выполняют простые задачи, а затем связать их вместе с Response.Redirect или Server.Transfer. Теперь все, что я пытаюсь достичь на любой странице - это то, что говорят спецификации дизайна. Так что, если моя страница просто страница поиска, это все, что я даю. Если пользователь хочет просмотреть сведения об элементе, который был возвращен в результате поиска, я отправляю их на страницу itemDetails.aspx.

Answer 3

Определенно согласен: большинство попыток написания страниц / форм, которые слишком много, привели к

• ошибки и переписывает. Проблемы возникают с сохранением / синхронизацией всех частей,
• избыточное управление ожиданиями пользователей (" Я ввел здесь номер счета и нажал" найти человека "там, но он выдает сообщение об ошибке. Почему? "), когда они логически разделены. Эти вопросы не могут возникнуть, если видны только допустимые параметры,
• Проблемы форматирования / компоновки: Попытка компоновки независимых пользовательских элементов управления на страницах ASP.NET оказывается кошмаром (" Но мы действительно хотим, чтобы все кнопки были выровнены по вертикали! " в отдельных пользовательских элементах управления. Удачи с этим.)

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

Даже тогда, в большинстве случаев, возможно разделить страницы на отдельные блоки.

Answer 4

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

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

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

Answer 5

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

Answer 6

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

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

Я бы предложил прочитать Не заставляй меня думать, Стив Круг . Эта книга не займет у вас много времени для чтения, и в ней представлены некоторые фантастические идеи, которые могут помочь вам в разработке приложений, которые намного проще в использовании и понимании.

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

Answer 7

Количество функций на странице обычно определяется не вами, а вашим клиентом. Если клиент требует, чтобы одна страница обновила VeryComplexObject, вы, скорее всего, получите страницу aspx со значительным количеством строк. Основная причина в том, что у вас просто много обработчиков событий для всех действий на странице.

Является ли эта страница сложной, зависит только от вас. Вы всегда должны стараться сделать ваш файл с выделенным кодом максимально простым и чистым. Некоторые предложения в этом направлении:

• Переместить весь бизнес-код на другой прикладной уровень.
• Используйте ObjectDataSource для предоставления данных элементам управления с привязкой к данным, таким как ListView, GridView, Repeater, ... Передача загрузки данных в выделенный объект предотвращает большие издержки в вашем aspx.cs файл.

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

Answer 8

1. Нет
2. Да - я
3. Я обнаружил, что счастливой средой было использование Masterpages и использование его таким образом, который был знаком IFrames. То, что я мог бы объединить множество функциональных возможностей. Есть более интересный способ сделать это с WPF / Silverlight под названием Prism