![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
vitus_wagnerВообще обсуждение уже принесло немало интересного, хотя постоянно норовит свалиься куда-то на низкий уровень - в обсуждение шин сообщений и прочих API. А мы вообще-то еще требования к UI не сформулирвали.
Но вот![[livejournal.com profile]](https://www.dreamwidth.org/img/external/lj-userinfo.gif)
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. Вот до сих пор это у нас был текст, который мы набирали, и ассоциировался он с набором инструментов для работы с содержимым, а сейчас это стал верстаемый документ, и набор инструментов стал совсем другой.
Но вот
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. Вот до сих пор это у нас был текст, который мы набирали, и ассоциировался он с набором инструментов для работы с содержимым, а сейчас это стал верстаемый документ, и набор инструментов стал совсем другой.
no subject
Date: 2012-08-15 08:19 am (UTC)no subject
Date: 2012-08-15 08:44 am (UTC)Это, я бы сказал, сущность несколько избыточная. У того кто работает с хоткеями постоянно - они уходят в мышечную память а накрайняк можно посмотреть конфиг hotkey manager'a или icevm, где оно все и прописано. У пользователя стандартного ленивого - что ни покажи, что ни напиши - читать и делать сколь угодно "естественные жесты" он не будет.
В этом и заключастся главная трудность создания универсального интерфейса - люди разные, и потому универсально удобный интерфейс это такая же фантазия как подходящие на любую ногу ботинки.
no subject
Date: 2012-08-15 08:58 am (UTC)Ну, если для того чтобы посмотреть какой хоткей назначен на данное действие, нужно залезть на шкаф, взять бинокль и по пояс высунуться из окна, 90% пользователей, конечно же, останутся ленивыми скотинами, не желающими этого делать.
Тут как раз вопрос в том, чтобы с одной стороны не отвлекать зря внимание тех, кто хоткей уже выучил, а с другой - достаточно навязчиво рассказывать об его существовании тем, кто его ещё не выучил.
no subject
Date: 2012-08-15 09:14 am (UTC)no subject
Date: 2012-08-15 10:52 am (UTC)лютую помойкуразветвленую структуру каталогов и файлов и будет на ура ориентироваться где что у него лежит, а вот на предложение изучить что-то, что даже поможет ему в работе - "ай нет, это так слоожно я ничего не понимаю." Так что судьба таких "напоминалок" - быть выключенными нафиг у опытных, и быть незамеченными у остальных.Идеальный же интерфейс - это конструктор, позволяющий настроить его под себя. Но по причине, которую см. выше востребован был есть и будет именно тем меньшинством которое и так сейчас настраивает его под свои нужды. 90% будут жрать кактус из коробки.
no subject
Date: 2012-08-15 01:44 pm (UTC)Для действий в программах эта функция классически выполняется главным меню, где команды разложены в подменю и подписаны клавиатурные шорткаты. Gtk+, к тому же, позволяет прямо оттуда же шорткаты и назначать (правда, существование этой возможности не очень discoverable).
Логично распространить эту парадигму также и на запуск программ.
no subject
Date: 2012-08-15 01:53 pm (UTC)Что-то очень похожее давно сделано и в Gnome, и в виндах. А в Debian вообще wm-independent система application menu есть.
Другое дело, что я бы постарался как-то извесли вообще понятие "запуск программы".
Когда мы работаем в командной строке, мы не "запускаем программы", а "выполняем команды". Понятие "запустить программу" возникает вместе с полноэкранными программами, которые меняют контекст.
Мне хочется интерфейс, который бы работал не в терминах программ (которые - сущность глубоко служебная), а в терминах, более близких к предметной области.
Собстенно, термин "открыть документ" гораздо лучше термина "запустить программу". Вопрос в том что программы много разнообразнее, чем "открывалки документов".
Поэтому надо придумать термины для тех видов деятельности за компьютером, которые не являются документ-ориентированными и оперировать в них. А как работа с этими сущностями будет там организована внутри- одна программа или куча взаимосвязанных компонент, это уже глубоко технический вопрос, на который пользователь обращать внимания не должен, как не обращает внимания пользователь shell-а на то, является команда echo встроенной командой шелла или отдельным исполняемым файлом /bin/echo
no subject
Date: 2012-08-15 03:49 pm (UTC)Гномо2вское, kde3’шное, xfce’шное и виндовое (до XP включительно) меню программ я знаю и люблю. Однако, из них всех более-менее нормальное назначение горячей клавиши есть, боюсь, только у винды. Отображения (за которым не нужно было бы лазить в диалоговое окошко Properties) нет ни у кого.
Более новые версии сделали вместо обозреваемого меню слабоструктурированную кучу с поиском, и это плохо.
Система с командами «открыть документ foo.html» вместо «запустить программу firefox с параметром командной строки foo.html» хороша ровно до тех пор, пока у пользователя есть понимание, что за этим всё равно стоят программы, и концептуальная модель того, как MIME-типы (или расширения файлов) отображаются на конкретные программы и как это настраивать. Иначе какая-нибудь свежеустановленная программа захватывает себе расширение (или MIME-тип), и всё-капец-ступор-вирус-переустановка.
OK, ориентируемся на пользователя умного. Но я всё равно запускаю LibreOffice Writer (возможно, горячей клавишей) и из File|Open Recent выбираю последний документ, а не иду в файловый менеджер/Documents/…/foo.odt.