Какой из них лучше в нашем случае, если MDI считается плохим?

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

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

Люди предлагают использовать несколько окон с одним документооборотом (SDI), например, как выглядит MS Word. Но я думаю, что это имеет некоторые недостатки в нашем приложении:

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

2) наш пользователь часто открывает более 10, а иногда и 20 отчетов одновременно в нашем старом программном обеспечении. Мне лично не нравится, когда будет отображаться длинный список из 20 элементов, когда я нажимаю мышь на значок Word на панели задач. Кроме того, они свободно, но все же связаны друг с другом. Пользователь может захотеть перейти от одного отчета к другому.

Другой часто упоминаемый макет - это компоновка вкладок, например Visual Studio. Мне нравится идея наличия некоторых элементов /элементов управления в некоторых конкретных, возможно, статических местах, таких как окна вывода и точки останова в нижней части визуальной студии, а также окна свойств на стороне. Я думаю, что мы можем переместить некоторые наши отчеты в такие области. Но основная область, область вкладок в визуальной студии, по-моему, не подходит для наших основных отчетов:

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

2) На мой взгляд, навигация в Visual Studio по-прежнему слаба. Мне лично нравится пользовательское программное обеспечение таким образом, что я открываю несколько отчетов и помещаю их в разные области внутри контейнера. Поэтому я могу легко переключаться между ними.

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

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

12 голосов | спросил tete 23 rdEurope/Moscowp30Europe/Moscow09bEurope/MoscowMon, 23 Sep 2013 13:22:08 +0400 2013, 13:22:08

6 ответов


9

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

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


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

Вопросы юзабилити с традиционным MDI

Размещение окон обременяет пользователя:

[править] Пользователь может иметь несколько целей для размера, соотношения сторон или относительного положения отдельных дочерних окон MDI, но, в конечном счете, правильное позиционирование по пикселям не является чем-то, чего хочет пользователь . Пользователи вынуждены мириться со слишком многими степенями свободы. Чтобы добиться разумного отображения, мы в основном просим пользователя несколько раз приближать проблему упаковки . [/Править]

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

Перекрытие окон приводит к постоянному "где мое окно?" взаимодействие: драпирование и щелчок, чтобы найти его.

Оформление окна мешает.

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

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

Полностью отстой на нескольких мониторах.
Вы можете растянуть окно кадра MDI на нескольких рабочих столах, но это усугубляет проблемы с расположением окон, поскольку окна, перекрывающие края экрана, представляют собой массивный не-go.

Растяжение рамки ограничивает доступ к другому приложению или документам. Ограничение кадра одним окном запихивает много информации на одном мониторе, а другой - один.

Решения и обходные пути

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

У меня нет убедительной идеи о том, как работать с несколькими мониторами (пока).

Альтернативы проектирования

В моем понимании метафора Dashboard довольно эффективно фиксирует этот вариант использования: разрешить пользователю упорядочивать подмножество из пула информации или гаджетов.

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

ответил peterchen 23 rdEurope/Moscowp30Europe/Moscow09bEurope/MoscowMon, 23 Sep 2013 15:03:10 +0400 2013, 15:03:10
4

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

Более новая форма MDI основана на вкладе (например, Visual Studio) с окнами с инструментами стыковки по сторонам. Это упрощает работу с несколькими документами, чем отдельное окно для каждого из них (Word /Excel).

Считывая свое описание, похоже, что вы можете имитировать интерфейс Visual Studio 2012 и иметь смысл.

Интерфейс типа Visual Studio 2012 будет иметь следующие функции:

  • Область с вкладками для быстрого доступа ко многим отчетам
  • Пользователь может перетаскивать отчеты и создавать несколько областей с вкладками в основном фрейме (удобно для просмотра отчетов рядом)
  • Окна инструментов, которые могут быть скрыты или показаны для дополнительной функциональности
  • Возможность перетаскивания отчетов и /или окон инструментов за пределы основного кадра для просмотра на нескольких мониторах
  • Все, что вы вытаскиваете из основного фрейма, можно состыковать вместе
ответил 17 of 26 23 rdEurope/Moscowp30Europe/Moscow09bEurope/MoscowMon, 23 Sep 2013 18:42:30 +0400 2013, 18:42:30
1

DIY UI, такие как MDI, налагают бремя дизайна макета на пользователя, как указано в @tete.
С другой стороны, пользователи ожидают от нас, ИТ-специалистов, предоставить им хорошо отточенные решения для своих нужд.
ИМО в этом конкретном случае может быть множество вариантов использования и повторное поведение, отличное от «любой может делать что угодно с любым количеством отчетов».
ИТ следует принять к сведению, как пользователи используют отчеты и действуют соответственно. Например, несколько небольших отчетов могут использоваться почти всеми, кто их использовал, чтобы они могли отображаться бок о бок в одном окне (или что-то еще).
Кроме того, за 10 лет с момента разработки приложения до сегодняшнего дня экраны сильно изменились. Тем более, теперь они намного шире и способны отображать больше данных одновременно. Изменение форм-фактора является значительным. Это делает интерфейс с вкладками более правдоподобным, поскольку столбец вкладок (а не строка!) Может содержать описания отчетов, заменяя заголовки заголовков подзаголовков.
Кроме того, динамически изменяющиеся отчеты могут отображать флаг измененный на своих вкладках, чтобы избежать нагрузки пользователя на необходимость периодически их проверять.
Если вкладки имели ярлыки для их быстрого и непосредственного выбора, это было бы еще лучше, особенно если ярлыки показаны на вкладках.
Исследование пользователей, о котором я упоминал выше, может быть выполнено путем записи в файл шаблонов использования на некоторое время, а затем анализа данных для шаблонов, а именно, какие отчеты просматриваются максимально, а какие множества небольших отчетов просматриваются бок о бок и т. Д.
Вы не должны быть дизайнером пользовательского интерфейса для создания отличного пользовательского интерфейса, вам действительно нужно знать пользователей. Я разработчик, который сделал VB6 UI, которые мои пользователи любили просто, наблюдая за их работой.

ответил Juan Lanus 25 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowWed, 25 Sep 2013 00:02:10 +0400 2013, 00:02:10
0

Если бы я был вами, я просто сделаю приложение достаточно гибким, чтобы иметь возможность поддерживать как MDI, так и TDI. И просто позвольте своим потребностям решить, какой стиль им нравится. Если вы используете LinsUIWPF Suite, это позволит вашему приложению автоматически поддерживать оба. Вы можете ссылаться на следующую ссылку Введение в LinsUIWPF Suite .

ответил user3221975 26 Jam1000000amSun, 26 Jan 2014 09:06:20 +040014 2014, 09:06:20
0

Хорошим примером приложения MDI с использованием веб-технологий является jsoncv.com (который я совместно разработал) - он дает настоящий опыт MDI, как вы обычно видите в приложениях Windows. Если ваша аудитория используется в MDI изнутри корпоративной среды, то идите на нее, это определенно стоит, если вы хотите получить такую ​​богатую функциональность, а не потерять ее только из-за технологии - в наши дни нет причин. Даже для веб-сайта, такого как jsoncv.com, мы обнаружили, что хотим повысить эффективность MDI для большего сообщества, поскольку он обеспечивает гораздо более приятный опыт. Кстати, он также возвращается к SDI на некоторых устройствах (в случае, если вы решите проверить его на планшете или мониторе с низким разрешением). В будущем улучшена поддержка телефона.

ответил Julian Cassin 19 FebruaryEurope/MoscowbThu, 19 Feb 2015 10:38:52 +0300000000amThu, 19 Feb 2015 10:38:52 +030015 2015, 10:38:52
0

Почему ваши пользователи предложили использовать модель SDI? Это признак необъяснимой необходимости.
MDI получает очень высокую способность открывать документы /окна с низким уровнем удобства использования , на мой взгляд! Он предназначен для охвата необработанного использования сложных приложений.
Я предлагаю вам собирать больше информации о текущем использовании приложений пользователями, а также проверять потребности пользователей и избегать ненужной способности пользователя уменьшать сложность и улучшать удобство использования.

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

ответил S.M.Mousavi 2 32016vEurope/Moscow11bEurope/MoscowWed, 02 Nov 2016 20:49:22 +0300 2016, 20:49:22

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

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

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