Речь пойдёт о тех окнах GUI в которых можно просматривать и открывать некую иерархию “контейнеров” (папок, директориев, …). В “контейнерах” могут содержаться «файлы” (документы, …). Всем известным примером такого экрана является диалог Open Files — здесь

Вопрос вот в чём – меня интересуют случаи, когда в таких экранах заведены раздельные списки для контейнеров и для файлов. Вот пример из приложения MS Source Safe -здесь

По моим наблюдениям, первый подход (один общий список и для контейнеров и для файлов) встречается чаще. Хотя когда-то (во времена Windows 3) было не так — здесь.

Интересно – ПОЧЕМУ подход “общий список и для контейнеров и для файлов” стал преобладающим? Это произошло «само собой”; или были какие-то исследования? И кто приведёт ещё примеры использования второго подхода (раздельные списки для контейнеров и для файлов) в современных приложениях?

Здравствуйте, Glenn, Вы писали:

G>Интересно – ПОЧЕМУ подход “общий список и для контейнеров и для файлов” стал преобладающим? Это произошло «само собой”; или были какие-то исследования? И кто приведёт ещё примеры использования второго подхода (раздельные списки для контейнеров и для файлов) в современных приложениях?
Если вы не найдёте блоги разработчиков, то вряд ли узнаете ответ.
А в целом, можно отметить, что в Windows Explorer нет чёткого разделения на контейнеры и файлы. Вот, скажем, .zip — в него можно "провалиться", как в контейнер, но при этом это вполне себе файл — со всеми его атрибутами типа размера и прочего.
Отразить этот дуализм в UI с раздельным показом того и другого было бы крайне затруднительно.
Кроме того, панель навигации в Explorer необязательна. Её можно спрятать и вполне успешно навигироваться в едином списке. Опять же, разделив контейнеры и файлы, мы потеряем эту возможность.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Glenn, Вы писали:

G>>Интересно – ПОЧЕМУ подход “общий список и для контейнеров и для файлов” стал преобладающим? Это произошло «само собой”; или были какие-то исследования? И кто приведёт ещё примеры использования второго подхода (раздельные списки для контейнеров и для файлов) в современных приложениях?
S>Если вы не найдёте блоги разработчиков, то вряд ли узнаете ответ.
S>А в целом, можно отметить, что в Windows Explorer нет чёткого разделения на контейнеры и файлы. Вот, скажем, .zip — в него можно "провалиться", как в контейнер, но при этом это вполне себе файл — со всеми его атрибутами типа размера и прочего.
S>Отразить этот дуализм в UI с раздельным показом того и другого было бы крайне затруднительно.
S>Кроме того, панель навигации в Explorer необязательна. Её можно спрятать и вполне успешно навигироваться в едином списке. Опять же, разделив контейнеры и файлы, мы потеряем эту возможность.

А то я в своём приложении должен буду сделать диалог, который как раз используется для просмотра некоей "иерархии" с Контейнерами и Документами в них; и открытия выбранного Документа. И вот думаю — сделать в этом диалоге один общий список; или два раздельных?

Здравствуйте, Glenn, Вы писали:
G>А то я в своём приложении должен буду сделать диалог, который как раз используется для просмотра некоей "иерархии" с Контейнерами и Документами в них; и открытия выбранного Документа. И вот думаю — сделать в этом диалоге один общий список; или два раздельных?
Ну, вообще-то это совсем-совсем другой вопрос. Вы начали с общефилософского рассуждения про единство противоположностей, а надо было с самого начала фокусироваться на вашем конкретном сценарии.

Вот как, например, выглядит UX открытия файла в Office 2013:

Найдите 10 различий за 13 лет:


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

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

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


Как только вы идентифицируете те сценарии, которые заслуживают оптимизации, вы поймёте, каким должен быть UI. Останется только одна инженерная задача: сделать переключение между разными сценариями очевидным.

Здравствуйте, Glenn, Вы писали:

G>Речь пойдёт о тех окнах GUI в которых можно просматривать и открывать некую иерархию “контейнеров” (папок, директориев, …). В “контейнерах” могут содержаться «файлы” (документы, …). Всем известным примером такого экрана является диалог Open Files — здесь

G>Вопрос вот в чём – меня интересуют случаи, когда в таких экранах заведены раздельные списки для контейнеров и для файлов. Вот пример из приложения MS Source Safe -здесь

G>По моим наблюдениям, первый подход (один общий список и для контейнеров и для файлов) встречается чаще. Хотя когда-то (во времена Windows 3) было не так — здесь.

G>Интересно – ПОЧЕМУ подход “общий список и для контейнеров и для файлов” стал преобладающим? Это произошло «само собой”; или были какие-то исследования? И кто приведёт ещё примеры использования второго подхода (раздельные списки для контейнеров и для файлов) в современных приложениях?

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

Здравствуйте, pu4koff, Вы писали:

P>Здравствуйте, Glenn, Вы писали:

G>>Речь пойдёт о тех окнах GUI в которых можно просматривать и открывать некую иерархию “контейнеров” (папок, директориев, …). В “контейнерах” могут содержаться «файлы” (документы, …). Всем известным примером такого экрана является диалог Open Files — здесь

G>>Вопрос вот в чём – меня интересуют случаи, когда в таких экранах заведены раздельные списки для контейнеров и для файлов. Вот пример из приложения MS Source Safe -здесь

G>>По моим наблюдениям, первый подход (один общий список и для контейнеров и для файлов) встречается чаще. Хотя когда-то (во времена Windows 3) было не так — здесь.

G>>Интересно – ПОЧЕМУ подход “общий список и для контейнеров и для файлов” стал преобладающим? Это произошло «само собой”; или были какие-то исследования? И кто приведёт ещё примеры использования второго подхода (раздельные списки для контейнеров и для файлов) в современных приложениях?

P>Только из-за возможной навигации с клавиатуры стоило везде ввести один список и ничего никак не разбивать по разным контролам.

Чуть выше я писал:

"я в своём приложении должен буду сделать диалог, который как раз используется для просмотра некоей "иерархии" с Контейнерами и Документами в них; и открытия выбранного Документа. И вот думаю — сделать в этом диалоге один общий список; или два раздельных?"

Вот сейчас — в связи с Вашими словами — думаю: если я всё же сделаю два раздельных списка, то непременно добавлю над ними текстовое "Look in" ("Quick search"; "Filter out", ...).
Оно будет выполнять роль фильтра (работающего сразу же как только cодержимое поля поменялось; кнопки SEARCH там не будет) и станет действовать на ОБА списка (Контейнеров и Файлов) сразу!

Здравствуйте, Glenn, Вы писали:

G>Вот сейчас — в связи с Вашими словами — думаю: если я всё же сделаю два раздельных списка, то непременно добавлю над ними текстовое "Look in" ("Quick search"; "Filter out", ...).
G>Оно будет выполнять роль фильтра (работающего сразу же как только cодержимое поля поменялось; кнопки SEARCH там не будет) и станет действовать на ОБА списка (Контейнеров и Файлов) сразу!
Непонятна мотивация такого неочевидного решения. Может, конечно, у вас там есть особая специфика именования контейнеров и файлов, но в стандартной модели вы бы сильно усложнили пользователям жизнь.
Вымышленный пример — ищем фотографии. Предполагаем, что контейнеры названы по датам съемки и событиям, а файлы — по сюжету и именам участников. Ну, типа 2013\Jan\01 — New York Party\JamesWithJessica.jpg.
Хочу найти фото Джеймса. Если я ввожу в ваш Filter out "James", у меня моментально исчезает всё из списка контейнеров. То, что фильтр мог чего-то там найти в файлах, уже неважно — ведь фокуса нет ни на одном из контейнеров.
Ок, пробую набрать "Party". Дерево контейнеров показывает мне все вечеринки, я встаю на 2013\Jan\01 — New York Party, но ничего не вижу в файлах — они все отфильтрованы. То есть мне теперь надо пойти обратно в Filter out и стереть его.
Имхо, это как-то очень неудобно.

На всякий случай напомню, что фильтр в объединённой модели работает по "или" — т.е. объединяет результаты поиска в контейнерах и файлах.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Glenn, Вы писали:

G>>Вот сейчас — в связи с Вашими словами — думаю: если я всё же сделаю два раздельных списка, то непременно добавлю над ними текстовое "Look in" ("Quick search"; "Filter out", ...).
G>>Оно будет выполнять роль фильтра (работающего сразу же как только cодержимое поля поменялось; кнопки SEARCH там не будет) и станет действовать на ОБА списка (Контейнеров и Файлов) сразу!
S>Непонятна мотивация такого неочевидного решения. Может, конечно, у вас там есть особая специфика именования контейнеров и файлов, но в стандартной модели вы бы сильно усложнили пользователям жизнь.
S>Вымышленный пример — ищем фотографии. Предполагаем, что контейнеры названы по датам съемки и событиям, а файлы — по сюжету и именам участников. Ну, типа 2013\Jan\01 — New York Party\JamesWithJessica.jpg.
S>Хочу найти фото Джеймса. Если я ввожу в ваш Filter out "James", у меня моментально исчезает всё из списка контейнеров. То, что фильтр мог чего-то там найти в файлах, уже неважно — ведь фокуса нет ни на одном из контейнеров.
S>Ок, пробую набрать "Party". Дерево контейнеров показывает мне все вечеринки, я встаю на 2013\Jan\01 — New York Party, но ничего не вижу в файлах — они все отфильтрованы. То есть мне теперь надо пойти обратно в Filter out и стереть его.
S>Имхо, это как-то очень неудобно.

S>На всякий случай напомню, что фильтр в объединённой модели работает по "или" — т.е. объединяет результаты поиска в контейнерах и файлах.

" Дерево контейнеров показывает мне все вечеринки" — Ваши соображения в принципе правильно, НО — я и НЕ собирался успользовать дерево контейнеров! Когда я писал "список контейнеров", я и имел в виду просто список (а не дерево). То есть: в каждый момент времени Окно отображает Контейнеры и Файлы, лежащие на данном текущем уровне (этот Текущий Уровень иерархии можно показать простым статическим текстом в окне.). Контейнеры отобразятся в одном списке; Файлы — в другом. В списке Контейнеров будет элемент ".." . Клик по нему означает "перейти на один уровень вверх по Иерархии". Ну а клик на "просто" Контейнер в этом списке означает, естественно — "войти в этот Контейнер и сделать его Текущим Уровенем иерархии в Окне".

Итак, "дерева контенеров" у меня и не будет.

Здравствуйте, Glenn, Вы писали:

G>Интересно – ПОЧЕМУ подход “общий список и для контейнеров и для файлов” стал преобладающим?

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

G> Это произошло «само собой”; или были какие-то исследования?

Само собой. Индустрия толкает писать быстрее и больше => прогер всё меньше уделяет время обдумыванию.

G> И кто приведёт ещё примеры использования второго подхода

Total Commander. Нажми в панели Ctrl+F8 — получишь только дерево папок. Даблклик — в другой панели увидишь файлы.
Мне, перебирающему море информации, важна быстрая навигация по папкам для классификации данных. А когда уже папка найдена, тогда можно и файлы в ней посмотреть.