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

Question

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

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

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

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

Мои вопросы:

• Am I overthinking эти вещи?
• Неужели кто-то еще нашел это?
• Где находится счастливая среда?

Answer 1

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

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

1. страница должны сделать одну главной вещи.
2. страница также может иметь несколько ссылок, относящихся к главному
3. Menuing и раскладка ссылка должна соответствовать по страницам
4. Simpler лучше, чем более сложный
5. Страницы должны быть визуально привлекательным и привлекательным
6. Rule 4 является более важным, чем правило 5.

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

Так,

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

---

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

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

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

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

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

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

Answer 2

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

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

Answer 3

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

Answer 4

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

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

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

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

Answer 5

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

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

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

Answer 6

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

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

Я предлагаю прочитать Don't Make Me Think by Steve Krug. Эта книга не займет у вас времени для чтения, и в ней есть некоторые фантастические идеи, которые помогут вам разработать приложения, которые намного проще в использовании и понимании.

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

Answer 7

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

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

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

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

Answer 8

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