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

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

Структура системы

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

Конфликт между структурой меню и структурой сайта

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

Проблемы с панировочными сухарями

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

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

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

Возможные решения

Ни один из них не кажется идеальным.

  1. Показать дорожку пути, по которой элемент находится в главном меню . Если элемент не находится в главном меню, просто не показывайте сухарики.
  2. Показывать дорожку пути, которую пользователь взял, чтобы получить этот элемент , эффективно отражая собственную «заднюю» функциональность браузера.
  3. Показать список всех прямых родительских элементов , позволяя пользователям находить свой путь ко всем элементам для брака.

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

7 голосов | спросил Neil Dawson 5 FebruaryEurope/MoscowbWed, 05 Feb 2014 15:40:54 +0400000000pmWed, 05 Feb 2014 15:40:54 +040014 2014, 15:40:54

6 ответов


1

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

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

Панели могут отображаться на основе уровней страниц внутри сайта, а не просто просматривать историю просмотров.

Если пользователь пошел: ДРУГОЙ СТРАНИЦЫ> HOMEPAGE> PAGE 2> HOMEPAGE> PAGE 4> СТРАНИЦА 5

Он установил бы страницы в виде разветвленной пачки.

Если на СТРАНИЦЕ 2, это будет: HOMEPAGE> СТРАНИЦА 2

Если на стр. 5, это будет: HOMEPAGE> [PAGE4 v]> СТРАНИЦА 5

В данном случае это выпадающий список с параллельными страницами.

Наличие якоря, такого как Домашняя страница, поможет ориентировать пользователя.

ответил Pdxd 3 MarpmMon, 03 Mar 2014 20:08:08 +04002014-03-03T20:08:08+04:0008 2014, 20:08:08
1

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

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

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

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

Но, как сказано, есть некоторые трюки, чтобы увеличить объем информации, которую вы можете положить в свою панировку.

Составные панировочные сухари из меню + категории

Обычно я об этом говорю:

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

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

Грановитые сухари, представляющие несколько таксономий

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

  1. Вы просто сосредотачиваетесь на одной из таксономий и игнорируете других. Например. один из

    • Велосипеды »По категориям» Внедорожник »Acme Model XYZ
    • Велосипеды »По производителям» Acme »Модель XYZ
    • Велосипеды »По материалам» Алюминий »Acme Model XYZ
  2. Ваша сухарь представляет собой накопленные фильтры, например.

    • Велосипеды »Внедорожник» Внедорожные велосипеды от Acme »Алюминиевые внедорожные велосипеды от Acme» Acme Model XYZ

    На этикетках можно было просто сказать «Велосипеды» Offroad »Acme» Алюминий »Модель XYZ», но если вы нажмете «Алюминий», вы не получите все алюминиевые байки, а только те, что от Acme, которые также находятся в Offroad категория.

  3. Разделите ссылки категорий запятой, а не «» ». Например.

    • Велосипеды »Offroad, Acme, Aluminium» Acme Model XYZ

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

    Если вы нажмете на «Алюминий» здесь, вы действительно получите велосипеды all , которые сделаны из алюминия, независимо от того, принадлежат ли они к категории Acme или в категории Offroad.

«История» панировочных сухарей?

Я лично не думаю, что панировочные сухари должны зависеть от того, где пользователь был раньше. Это работа браузера.
http://www.nngroup.com/articles /крошка-навигационно-полезный /
См. «Иерархия или история?» Я полностью согласен с Нильсеном здесь, даже если это с 2007 года.

Сайты, которые не нуждаются в панировке

Есть определенные места, где хлебная крошка не имеет такого смысла. Подумайте о stackexchange, facebook, gmail. Возможно, в некоторых подразделах может быть смысл (настройки пользователя, справочные страницы ..), но не для навигации по озеру неструктурированной информации.

В этом случае вы хотите

  • боковые панели с различными типами «связанных»вещи ". Stackexchange хорошо справляется с этим.
  • хороший поиск.
ответил donquixote 22 AMpTue, 22 Apr 2014 06:09:59 +040009Tuesday 2014, 06:09:59
1

Категории + метатеги

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

Я уверен, что это не является репрезентативным для вашей системы, но вы получаете идею:

 Структура категории с применением фильтра метатеги

ответил plainclothes 24 22015vEurope/Moscow11bEurope/MoscowTue, 24 Nov 2015 03:49:49 +0300 2015, 03:49:49
0

Я не думаю, что это огромная проблема not иметь панировку, особенно если она вводит в заблуждение.

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

Вы можете предоставить «недавно просмотренный» список (похожий на Amazon или другой сайт на основе продукта), чтобы пользователи могли легко отступать.

Кроме того, вы, вероятно, на правильном пути с идеей «список родителей» связанных с ними тем.

ответил user42539 5 FebruaryEurope/MoscowbWed, 05 Feb 2014 20:23:30 +0400000000pmWed, 05 Feb 2014 20:23:30 +040014 2014, 20:23:30
0

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

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

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

ответил Squig 3 MarpmMon, 03 Mar 2014 19:50:34 +04002014-03-03T19:50:34+04:0007 2014, 19:50:34
0

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

Итак, это швы, которые вы хотите показать навигацию по мини-карте (например, в играх).

 введите описание изображения здесь>> </a> </p>

<p> <strong> Но вы говорите, что речь идет о бизнес-процессах. Здесь вид (и навигация) зависит от роли пользователя и вопроса процессов. </Strong> </p>

<p> Менеджер процессов (и, возможно, директор) может захотеть увидеть всю карту. Владелец процесса (определенных процессов) может захотеть следовать только подмножеству процессов или одному конкретному процессу. Им может потребоваться минимизированная версия карты перекрестного функционального процесса. </p>

<p> <a href= введите описание изображения здесь>> </a> </p>

<p> Пользователь-пользователь обычно не заботится о процессах - он /она заботится о людях, стоящих за шагами процесса, до и после его /ее процесса. </p>

<p> <a href= введите описание изображения здесь>> </a> </p>

<p> Пользователь, отправляющий какое-либо приложение, проходит несколько этапов процесса. Он /она должен знать, где они находятся, и в основном, что нужно делать. (Например, подумайте об эскере.)
<a href=введите описание изображения здесь

В целом

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

ответил Radek 24 22015vEurope/Moscow11bEurope/MoscowTue, 24 Nov 2015 01:07:20 +0300 2015, 01:07:20

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132