Вообще обсуждение уже принесло немало интересного, хотя постоянно норовит свалиься куда-то на низкий ...
Вообще обсуждение уже принесло немало интересного, хотя постоянно норовит свалиься куда-то на низкий уровень - в обсуждение шин сообщений и прочих 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. Вот до сих пор это у нас был текст, который мы набирали, и ассоциировался он с набором инструментов для работы с содержимым, а сейчас это стал верстаемый документ, и набор инструментов стал совсем другой.
This entry was originally posted at http://vitus-wagner.dreamwidth.org/765301.html. Please comment there using OpenID. Now there are 
comments
Тут с удивлением выяснил что пакет libpam-ssh не пользуется популярноностью в Debian, что и ...
Тут с удивлением выяснил что пакет libpam-ssh не пользуется популярноностью в Debian, что и послужило одной из причин его удаления.
Меня это как-то сильно удивляет - удобная же штука.
Этот pam-модуль позволяет, логинясь в систему интерактивно сразу получить ssh-агент с загруженным ключом, введя пароль/пассфразу один раз. (для этого, правда, требуется совпадение пароля в /etc/shadow и пассфразы на ключ).
Я, правда, пока не добился того, чтобы при запуске скринсейвера ключи удалялись из памяти, а при вводе пароля в xscreensaver - грузились обратно, но вроде теоретически ничего невозможного нет.
This entry was originally posted at http://vitus-wagner.dreamwidth.org/764848.html. Please comment there using OpenID. Now there are 
comments
+ развернуть текст сохранённая копия
