Переводы Ижайти. Горизонтальная или многоуровневая иерархия сайта?

avatar Павел
Овчинников
14.01.2014, 19:35
комментировать

От редакции: Часто в сторону Ижайти мы слышим упреки, мол, мало стало про разработку сайтов, а было много про разработку сайтов. Поскольку никто из читателей про это писать не соглашается, то мы решили найти специально обученного человека для того, чтобы он переводил нам интересные статьи про сайты и веб-разработку хотя бы раз в месяц. Первый такой перевод вы уже читаете. Сегодня будет статья «Flat vs. Deep Website Hierarchies» с сайта www.nngroup.com.

Надеемся, новая инициатива Ижайти будет полезна разработчикам и веб-дизайнерам. Будем рады обсудить и саму статью и перевод.

Резюме: при организации информации может быть использована как горизонтальная, так и многоуровневая иерархия; оба способа имеют свои достоинства и слабые места.

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

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

Рассмотрим два варианта структуры: каждый позволяет организовать одинаковое количество информации и предлагает вполне логичный способ представления контента на сайте. Однако опыт взаимодействия конечных пользователей с этими иерархиями – даже если они содержат одну и ту же информацию – будет очень разным.

eirarhy

В независимости от структуры, сайт начинается с домашней страницы, но информация на последующих страницах будет представлена совершенно по-разному: на изображении слева сайт имеет 8 основных категорий, в то время как структура сайта, представленного на правом изображении, имеет только 4 категории. Это одновременное сравнение показывает, что мы имеем в виду, когда мы говорим о горизонтальной и многоуровневой иерархии. Горизонтальная (или, как ее еще называют, широкая) структура сайта, изображенная на картинке слева, выглядит широкой и короткой, потому что у нее всего 3 уровня. Структура справа, с уменьшающимся количеством категорий и подкатегорий на каждом уровне, в конце концов, становится выше и тоньше.

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

  1. Контент воспринимается значительно проще, когда он не погребен под несколькими промежуточными слоями. При всех прочих равных условиях многоуровневая иерархия сложнее в использовании.
  2. Категории, которые являются специфическими и не перекрывают друг друга, всегда легче понять. Это палка о двух концах: в многоуровневой иерархии, когда на каждом уровне есть только несколько категорий, разделы, как правило, более универсальны, но с другой стороны, это может запутать пользователей. Более плоская структура с большим количеством категорий на каждом уровне, как правило, имеет более определенные названия разделов, которые легче понять; но в горизонтальной иерархии с очень большим числом элементов часто встречаются некоторые концептуальные перекрытия между, как минимум, несколькими категориями. Такое беспорядочное меню сайта также может «ошеломить» пользователя.

Три сайта разных больниц во Флориде демонстрируют преимущества и недостатки различных структур сайта. На сайте Tampa General Hospital категория «Медицинские услуги» представлена списком из 32 отдельных заболеваний и лечебных центров. Эта горизонтальная иерархия позволяет легко обнаружить, какие лечебные услуги предлагает данная больница. Посетители могут кликнуть на страницу с конкретным заболеванием прямо в раскрывающемся меню в глобальной навигации. Поскольку большинство пациентов в заданный момент времени лечатся от одной болезни, возможность прямого перехода к информации более привлекательна.

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

1

На веб-сайте Baptist Health из Джексонвилля только половина подразделов спрятана в выпадающем меню «Услуги». Этот короткий список гораздо проще просматривать, но через него будет сложно выйти на специфический контент. В большинстве случаев пользователям придется кликнуть на одну категорию, а затем перейти на категорию более низкого уровня, чтобы найти конкретную информацию, например, о процедуре искусственного оплодотворения или интенсивной терапии новорожденных. Иногда совсем не очевидно, какая категория станет отправной точкой при поиске нужной информации. Например, вы можете нажать на ссылку «Лечение рака», чтобы получить информацию о раке простаты, но нет категории «Урология», поэтому неясно, где найти сведения о других заболеваниях простаты.

2

Сайт для University of Florida Health, напротив, показывает информацию о конкретных заболеваниях только на нижних уровнях иерархии сайта. Чтобы попасть на конкретные страницы с информацией о лечении, нужно предварительно спуститься на 3 уровня вниз: Patient Care -> Medical Care -> Specialty Care.

3

Требовать от пользователей проходить такое количество уровней, чтобы добраться до конкретного материала, как правило, очень сложно. Они могут легко заблудиться, отвлечься, или просто решить, что это слишком трудоемко, и в итоге покинуть ваш ресурс. Таким образом, для многоуровневой иерархии важно предоставить альтернативные варианты навигации: ссылки, которые напрямую ведут на нижние уровни. UF Health делает это в раскрывающемся меню из основной панели навигации, где пользователи также могут поискать информацию о конкретных болезнях в алфавитном порядке или выбрать темы в блоке «Наиболее просматриваемые болезни/сервисы».

4

Представление иерархии в интерфейсе

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

Плоская или многоуровневая?

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

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

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

***

Не скупитесь на ретвиты ↓
  • http://extremefrost.wordpress.com/ Алексей Евдокимов

    Ну вот, выросло очередное поколение «специалистов», которое опять путает тёплое с мягким. Иерархия != навигация. Я ещё лет 10 назад об этом писал... Но сколько раз уже натыкался на такое узкое понимание. Особенно на западе, у них в вебе всё ещё каменный век.

    Окромя иерархии, есть ещё 100500 способов организации навигации. Календарный, тематический, многомерный... Каждый подходит для своего типа контента. Видимо, для чувихи с ннгруп.ком они будут великим открытием, ежели она так многословно рассуждает про глубину иерархии. Если у ней ума хватит до них додуматься ваще.

    • Alex

      >>Особенно на западе, у них в вебе всё ещё каменный век.

      Точно, один Лешка Евдокимов впереди планеты всей. Ведь он один задает направление всей ИТ индустрии своими впечатляющими проектами и весь запад со своими проектами «каменного века» даже близко не находятся рядом с ним.

      • http://extremefrost.wordpress.com/ Алексей Евдокимов

        Уж не знаю, Сашка ты или Лешка, но аргументы в духе lurkmore.so/images/thumb/...0px-Dobeisa.jpeg определённо делают тебе честь, чувак. Продолжай.

        • Alex

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

    • sdf

      >Особенно на западе, у них в вебе всё ещё каменный век.

      Смело.

  • Ivan Steblenko

    Алексея, наверное, смутило невысокое качество перевода, так как в оригинале не проводится соответствие иерархии и навигации. По сути, там все крутится вокруг 2-х общеизвестных паттернов для навигации:

    а) так называемый иерархический — контент имеет несколько отдельных секций (например, деление по теме, как это делают в nytimes);

    б) плоский — контент на одном уровне иерархии (например, игры).

    А воды в статье — да, много.

    PS. Уважаемая редакция, публикация переводных статей не прибавит интереса к этому ресурсу, так как тот же хабр вы не догоните, а качеством, несомненно, уступите. Не мне вас учить, но то что читатели не шлют материалов — это только оправдание. Паша, походи по отделам того же НПО, уверен, что ты легко наберешь материал на техническую статью, например, про то, как работает сайт Directum (это я наобум выбрал). Уверен, что во многих компаниях города есть либо энтуазисты, которые прямо сейчас пробуют что-нибудь аля React/om в деле, либо есть проекты не закрытые NDA и про которые могут рассказать.

    PSS. Кстати, 20-летие компании EPAM Systems, в которой работают многие из читателей, так и не было ни разу упомянуто :(.

    • Oleg Vylegzhanin

      Я лично уведомлял Павла об этом значимом событии. Павел довольно странно тогда отреагировал... )

      • izhit

        Чего же странного в моей реакции? Вроде как сбор материала идет. Мы с Ириной этот вопрос уже обсуждали сразу после завершения НГ-каникул.

        • Oleg Vylegzhanin

          Ну, ждем тогда.

    • http://twitter.com/apodkin Andrew Podkin

      >> Уверен, что во многих компаниях города есть либо энтуазисты, которые прямо сейчас пробуют что-нибудь аля React/om в деле, либо есть проекты не закрытые NDA и про которые могут рассказать.

      Иван, ну зачем ты лукавишь? Постоянно обращаемся к сотрудникам ЕПАМа, но даже когда есть интересные материалы, вы предпочитаете писать их в личных блогах, а не здесь. А потом приходите и жалуетесь.

      Так что вы уж «или крестик снимите, или трусы наденьте» © анекдот.

      • Ivan Steblenko

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

        1) я подразумевал не только компанию EPAM Systems, в этом городе есть и другие, не менее уважаемые компании;

        2) вот сразу, из головы: если те, с кем вы общались предпочитали поголовно писать в личных блогах, а не сюда, может стоит пересмотреть подход к потенциальным авторам (тенденция как-бы намекает)? Может что-то их не устраивало в вашем предложении? Проводился ли такой анализ — почему отказываются? И какие работы планируются чтобы переломить тенденцию?

        Очень возможно, что вы честно пытаетесь что-то сделать, но делать это посредством публикации переводных статей — безнадежно по причинам, которые я привел выше. А винить во всем специалистов из EPAM Systems — ей богу, смешно.

        • http://twitter.com/apodkin Andrew Podkin

          Иван, никто кроме вас не делает никаких категоричных заявлений. Обращаемся всегда очень просто. После очередного наезда (типа такого, как у тебя сейчас) спрашиваем наехавшего: «Товарищ дорогой, а вот недавно у тебя в блоге у тебя был такой интересный пост. Ты не хотел бы его и аналогичные опубликовать на ИжАйТи?»

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

          У меня вообще складывается впечатление, что многие относятся к ИжАйТи не как к сообществу, где каждый вносит посильный вклад, а как к какому-то коммерческому проекту, где есть большая редакция, каждый редактор получает $100500 (и нигде при этом больше не работает) и вместо того, чтобы отрабатывать эти деньги (ходить по конторам и выбивать поводы или даже готовые тексты), ничего не делает.

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

          А я не говорю, что это хорошо.

          >> А винить во всем специалистов из EPAM Systems — ей богу, смешно.

          Иван, еще раз: вас никто не винит. Это вы вините ИжАйТи. Я не знаю, как Паша, но я читая ваши обвинения (твои, Мишины, Алексея, Никиты) просто сижу и тихонько фигею.

  • Владислав Стерлин

    Отличное начинание. Есть шероховатости, но смысл понятен.

    Я при проектировании навигации руководствуюсь двумя правилами:

    1) Не больше трех кликов до цели (а вообще, чем меньше тем лучше).

    2) «5±2», меньше 3 пунктов для человека мало и не интересно, больше 7 —

    много и сложно.

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

    Переводите ещё. Если нужна рецензия на перевод перед публикацией готов помочь.

    • izhit

      Спасибо за отзыв)

Get Cloud PHP Hosting on CatN