Интерфейсы будущего. III Первые итоги дискуссии

[vitus_wagner]

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

Но вот rainbow_beast просветил меня по поводу разницы между mind maps и concept maps.

Хотя я не уверен, что термин mind mapping не подходит, но все же в названии "Концептуальный интерфейс" что-то есть. Постмодерном попахивает.

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

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

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

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

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

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

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

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

Вокруг области tiled окон имеется рамка экрана. Где показываются какие-то объекты, связанные с сессией в целом или компьютером в целом.

У окна четыре стороны и можно их закрепить за разными типами связей.

Возможно, стоит позаимствовать из Ashton Tate Framework концепцию "изнанки фрейма". Там на изнанке фрейма можно было писать скрипт, генерирующий содержимое фрейма. Здесь более логичным является наличие на изнанке пояснительного (гипер)текста про то что можно с этим фреймом делать. Скрипт там тоже может быть, на то еcть literate programming.

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

Идеями Раскина насчет полностью modeless интерфейса злоупотреблять не стоит. Смена взгляда на один и тот же информационный объект иногда вполне оправдана. Но только надо оформить смену режима как переход по ссылке в concepts map. Вот до сих пор это у нас был текст, который мы набирали, и ассоциировался он с набором инструментов для работы с содержимым, а сейчас это стал верстаемый документ, и набор инструментов стал совсем другой.

Comments

[rainbow_beast.livejournal.com]

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

[ramendik]

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

Моя работа предполагает, если прикинуть, примерно следующие объекты:

- 1 основной текст. Это не строгий текст в Unix-смысле, я вижу там визуальное форматирование и втягиваемые иллюстрации, но основная информация именно текстовая. Объект редактирования или чтения. Забирает от 50 до 95 процентов внимания в зависимости от ситуации в данный момент.

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

- От 2 до 5 фоновых приложений, которым требуется интерфейс, но он должен обращать на себя внимание только когда он нужен (и притом только если ему сейчас это позволено). Чат-клиенты, медиаплеер, VPN-клиент, монитор мобильного инета...

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

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

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

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

[d1f]

xterm в зубы и достаточно.

[rainbow_beast.livejournal.com]

Скажите, как сеййчас вы всё это располагаете и какой размер экрана - пропробую придумать вам раскладку. Сам я на тайлах сижу уже больше пяти лет - и пока не попалось задачи, которую в них неудобно реализовать. Пока что я вижу основную зону ("основной текст"), которая должна быть всегда и должна быть большой, вторую зону - для "источников информации". Причем одновременно видны в ней могут быть не все - а, допустим, два-три, тех, к которым обращались последними. Чтобы увидеть остальные - жмём кнопки (можно циклически переключать, можно вывести список, можно временно мозаикой их вывалить на весь экран для выбора - вариантов много). Выбранный источник может по желанию (грубо говоря, с шифтом кнопку ткнули или нет) заменить один из техЮчто показывались ранее или добавиться к ним.

Фоновые приложения, понятно,сидят в notification area, по команде активации (мышь или хоткей - по выбору) - разворачиваются в заранее выбранное место - либо поверх основного текста, либо поверх "панели источников", либо вообще скрывают всё. Либо, что мне оказалось удобнее всего - такие вещи вообще висят на отдельном workspace, куда и происходит переключение по их активации.

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

Файлменеджеры и командные строки - на своём рабочем столе. Тамони все видны, но какой-то находится в большом фрейме, остальные - в меньших. По нажатию одной кнопки любой из них может попасть в большой фрейм, поменявшись с тем, что там в данный момент.

Ну а с играми или просмотром видео вообще просто - это живёт на отдельном workspace и открывается обычно на весь экран, скрывая даже notification area. Основное приложение плюс пара источников - тоже не проблема.

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

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

[rainbow_beast.livejournal.com]

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

С другой - такой вариант не дружит со sloppy focus, который хотелось бы оставить - для тайла он абсолютно естественен и экономит клики.

[ramendik]

Основные экраны у меня такие - 15 дюймов 16:9 мобильный и 17 дюймов 4:3 стационарный. Будут деньги - прикуплю побольше, надеюсь что смогу купить дюйма так 22 4:3. (Кино я смотрю редко, и мне 4:3 удобнее по расположению текста).

Используемая сейчас раскладка - текст на весь экран (кроме таскбара), источники на весь экран переключаемо, остальное popup по необходимости, по занимаемому месту хаотично.

С места, конечно, вижу вариант превратить недостаток 16:9 в достоинство, но на это нужны деньги - взять дюйма 24-26 16:9, создать область для текста размерами 4:3. Но в оставшийся кусочек мне не удастся комфортно поместить источники информации или привычные файл-менеджеры! И если файл-менеджер можно и поменять (ну расположатся там панели вертикально), то источники - нет.

Чтобы тайл стал мне удобен для варианта "зона текста плюс зона источников", мне надо откуда-то взять вертикальный экран, и то в режиме чтения или вычитки удобнее будет расширять текст на всё пространство. Или уж тогда - такой огромный 16:9, чтобы разделить пополам и в обоих частях достаточная ширина. Вот это уже да, всегда быо бы удобнее, но это как бы не 32 дюйма требуется. Не меньше 26 точно. А я между прочим иногда и на ноутбуке работаю, том самом на котором 15 дюймов 16:9.

[sash-kan.blogspot.com]

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

[rainbow_beast.livejournal.com]

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

[rainbow_beast.livejournal.com]

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

[rainbow_beast.livejournal.com]

Может человек видел только тайловые WM a-la dwm, где табов нет... В notion (живой форк ion3) или i3 никаких проблем с егопривычным workflow нет принципе, из коробки оно именно так и работает.

[sash-kan.blogspot.com]

про скрытие я написал в последней фразе.

[rainbow_beast.livejournal.com]

Я хотел просто акцент на этом сделать

[shadowfoto]

наверное разочарую, но по крайней мере мне упоминание об экранах 4:3 или 5:4 больше 20" не попадалось.

вертикальный экран - берем широкий моник на IPS и поворачиваем. IPS - обязателен, тк имеет нормальный угол обзора вне зависимости от направления.
собственно натыкаюсь периодически на такие виды рабочих мест - 26-30" монитор основной, а по бокам 1-2 вертикально повернутых.


PS: могу предложить поискать б/у IBM T220/T221, кстати. с их разрешением все проблемы отпадают, хоть и 22" - 3840х2400.

[vitus_wagner]

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

Кстати, между прочим по-моему файловый менеджер и терминал это два вида одного объекта - каталога файловой системы. Либо у нас список файлов с возможностью выполнять файловые операции, либо у нас терминал с cwd в этом каталоге.

[vitus_wagner]

В Xterm-е очень неудобно работать с картами и чертежами. Да и с фотографиями как-то не очень. Вот, графики гнуплотом рисовать в xterm-е - это я умею. А одно время у меня даже dvi-вьюер был для тектроникса (который xterm-ом эмулируется).

[d1f]

Из xterm всё остальное запускается.
В GUI должна быть единственная кнопка - запустить ещё один xterm.
Кто не может пользоваться таким интерфейсом,
объявляется не владеющим компьютером.

[max630.net]

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

У тайлов вообще есть принципиальная проблема - нельзя отвести столько места, сколько для того надо, надо отдавать полосу длиной во всю сторону окна.

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

[vitus_wagner]

Тайловый интерфейс я рассматриваю как компромисс между полноэкранным и перекрывающимися окнами в стиле Palo Alto, которые сейчас используюся в большинстве традиционных GUI-систем - X11, Windows, MacOS Cocoa.

Практика показывает, что гибкость, обеспечиваемая произвольно перекрывающимися окнами - избыточна. Многие люди как вот ramendik предпочитают развертывать приложения на полный экран. Более того, в таких относительно свежих системах как Android или Maemo другого способа в общем-то и не предусмотрено.
Тайловая система, под которой я понимаю более-менее произвольное разделение экрана на неперекрывающиеся окна, как в Oberon, vim или emacs, является на мой взгляд, достаточно хорошим компромиссом между многооконностью и полноэкранностью.

[vitus_wagner]

Запуск меня волнует в наименьшей степени. Меня волнует управление этим когда оно уже запущено.

[d1f]

Нуууу... я предпочитаю N виртуальных десктопов
с одним приложением во весь экран на каждый,
кроме меню/таск/чего-там бара.
И редактор поверх развёрнутого xterm-а.
Для счастья ничего больше не надо.
Ах да - focus follow mouse, это ещё главнее.

[vitus_wagner]

Ну это собственно тот же tiled window management только на виртуальном экране размером в N физических.

[max630.net]

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

Тем более что наиболее продвинутые из них таки позволяют использовать плавающие окна. Так что всё это сводится к контролам и прочей вкусовщине.

Причина по которой maemo и android не использовали перекрывающиеся окна, очень проста - ограничение аппаратных возможностей.

[d1f]

Ну так будет оно признано?

[vitus_wagner]

Про "ограничение аппаратных возможностей" - это чушь собачья. Когда я купил себе N800 c Maemo она обладала большей тактовой частотой процессора и большим объемом памяти, чем мой тогдашний ноутбук IBM Thinkpad 600. Сейчас я купил себе ASUS Transformer с Андроидом. Он превосходит имеющийся у меня асусовский же EeePC 900 по всем параметрам, включая разрешение и физичекий размер экрана и объем постоянной памяти. Про RAM и CPU я вообще не говорю. Тем не менее на EeePC у меня интерфейс с перекрывающимися окнами,: а на трансформере - с полноэкранными.

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

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

[max630.net]

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

Мне кажется вполне удовлетворительным показываемое по кнопке меню.