Об авторе

Поиск по сайту:

GUI.ruПерепроектируйте это немедленно!

Проектировать взаимодействие это вам не орешки щелкать

Алексей Копылов
06.02.2006Алексей Копылов

Комментариев:

18

Вездесущие приложения-хамелеоны

Я пользуюсь (с разной степенью регулярности) настольным компьютером, ноутбуком, смартфоном на базе MS Mobile и КПК на базе Palm OS 4. На всех устройствах стоит словарь, карта метро и программа для чтения электронных книг. Всем этим хозяйством я пользуюсь каждый день. Редко, когда одна и та же программа одного производителя, выполняющая одну и ту же функцию, установлена на нескольких устройствах. Обычно же на каждом устройстве своя, уникальная.

Каждое приложение занимает место в постоянной памяти. А перед тем, как его начать использовать, его необходимо установить. Для того, чтобы укомплектовать все устройства словарем, картой метро и читалкой, мне, например, установку придется запустить 12 раз (4 по 3)! Добавьте к этому время на поиск нужной программы, ее скачивание и оплату. Кроме этого, каждая требует изучения всей совокупности функций, своего уникального характера и нуждается в индивидуальном уходе. Это, кстати, останавливает многих от приобретения смартфонов: каждое новое устройство - это новый зоопарк программ.

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

До недавней поры не было технической возможности реализовать мои «хотелки» простым и доступным способом, однако времена меняются. Bluetooth, Wi-Fi и другие способы локальной связи уже не экзотика, и решение я вижу в создании гетерогенной среды, где приложение, хранящееся в одном месте (на одном устройстве) можно было запустить на другом устройстве, невзирая на различия в операционных системах устройств и индивидуальные физические особенности каждого из них. Почему я не могу запускать словарь на смартфоне, при этом сама словарная база находилась бы в КПК или в ноутбуке? Пользовательский интерфейс может быть независимой частью программы сродни драйверам устройств в современных операционных системах.

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

Но веб-интерфейс даже в современном стероидном варианте (Ajax) имеет ограниченные возможности взаимодействия с пользователем: например, невозможно добавить поддержку управления словарем с помощью soft-keys (команд, связанных со специально выделенными кнопками) смартфонов. Или, например, сенсорный экран КПК подразумевает иную модель взаимодействия, нежели классическая (с применением мыши). Вы, наверное, поняли, к чему я клоню – необходимо полностью отделить программную логику от логики взаимодействия.

Решение я вижу в том, что ядро программы реализует ее внутреннюю логику. Это ядро крутится на устройстве-хозяине (являющееся сервером) и предоставляет внешним клиентам программный интерфейс. Клиенты реализуют пользовательский интерфейс и могут располагаться на устройстве-хозяине или на совершенно ином устройстве (с другой оперативной системой), которое связано с сервером. Логику пользовательских интерфейсов желательно максимальным образом реализовать на стороне сервера, так, чтобы клиентская часть, отвечающая за пользовательский интерфейс (ПИ), была легкой и загружалась на устройство-клиент по возможности незаметным способом. Можно реализовать такую иерархию дистрибуции: если модуль пользовательского интерфейса отсутствует на конечном устройстве, то производится поиск модуля на сервере, в некоей библиотеке готовых ПИ. Если и там его не оказалось, то гаджет ищет нужный модуль в интернете. Если модуль произвела третья компания, то пользователь может его скачать или купить. Кстати, в некоторых случаях вполне можно использовать «неродной» пользовательский интерфейс – пользователь, у которого имеется КПК с сенсорным экраном может довольствоваться ПИ с программными клавишами (то есть ПИ для смартфонов). Он сможет легко нажимать на программные клавиши, отрисованные на сенсорном экране, эмулируя тем самым работу со смартфоном. Когда для данной программы появится поддержка сенсорного экрана, то работа с приложением станет максимально комфортной.

Можно представить обратную ситуацию: под отлично реализованный пользовательский интерфейс создается несколько конкурирующих серверов реализующих необходимую функциональность. Еще одно преимущество отделения ПИ – упрощенная поддержка всеми программами пользователей-инвалидов.

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

Все это, насколько я понимаю, можно реализовать уже сейчас, например, с помощью .NET.

Но сначала придется решить массу проблем, вот их примерный список:

  1. Создание единой инфраструктуры разработки приложений с отделенным ПИ. Модули с ПИ должны поддерживать максимальное количество способов взаимодействия: сенсорные экраны, мышь, клавиатура, программные клавиши, голосовой интерфейс и так далее. Необходимо соблюсти баланс между программной логикой и логикой пользовательского интерфейса.
  2. Создание прозрачной дистрибуции всех частей программы: логической, интерфейсной, визуальной, с адаптацией под любое экранное разрешение. То есть, при каждом запуске приложения необходимо определять текущий контекст. Также прозрачной для пользователя должны быть система диагностики взаимодействия устройств и программ.
  3. Создать новые правила лицензирования и оплаты использования программных продуктов.
  4. Обеспечить безопасность выполнения таких сборных приложений на всех уровнях.
  5. Обеспечить бесперебойную автоматическую маршрутизацию информационных потоков между устройствами и интернетом.
  6. Создать гибкую систему энергопотребления устройств в случае, когда одно является сервером для другого (чтобы сервер неожиданно не заснул).

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

Комментарии (18)

RSS feed for comments on this post | TrackBack URI

romx06.02.2006 14:02
1

По поводу “вездесущих приложений”, если ты помнишь, я еще в 1999 году писал, что одной из перспективных идей для PDA должно быть дробление их на взаимодействующие блоки. Чтобы можно было Personal Digital Assistant, в полном этом смысле составлять из взаимодействующих между собой блоков. Есть процессорный блок. Есть внешняя память. Есть экран такой и экран сякой (карманный и побольше например). Есть плэйер музыки.
Накупаешь нужный набор. “Экран” отображает то, что ему предоставляет “процессор”. Понадобилось больше памяти для фотографий - связались с “блоком внешней памяти” и передали туда, или прочли оттуда. Музыку играть отправляем в плэйер, если он у нас есть.
Пришли домой - плэйер синхронизируется музыкой с хостом, а отображение перенеслось на домашний монитор, обнаружив его.
В результате “PDA” существует в виде облака устройств диаметров несколько метров. Зачем держать в руке процессор и память, если все что нам нужно это экран? Процессор в кармане, сторадж на пару (десятков) гиг в сумке, плэйер на шнуре наушников на шее, а экран - в руке.
Это не то же самое, о чем пишешь ты, но по моему на блочность устройств твоя схема тоже хорошо ложится, и дополняет.
Таким образом “устройство-кирпичик” это только функционально ограниченное устройство и набор интерфейсов для взаимодействия, которые реализованы semi-hardware. С механизмом обнаружения и распознавания сервисов соседа.
Что собственно и было сделано черт знает когда в рамках разработки BT и даже на версии 1.1 вполне работоспособно.

Однако что происходит нынче с Bluetooth в мире к сожалению моему пониманию не поддается :(

tango_rus06.02.2006 15:51
2

Очередной велосипед, ИМХО..
Есть такая штука, как X-Window. Появился лет так ..надцать назад. До сих пор живет в среде Unix/Linux. Приложения к нему имеют как раз клиент-серверную архитектуру - приложение-клиент и отображение-сервер.
Есть такая штука, как TerminalServices. Живет в среде MS Windows. Остается реализовать X-Window server и TerminalServices для нужных платформ и все дела. Единственное ограничение - разное разрешение экрана у разных устройств.

Александр06.02.2006 16:10
3

> Но сначала придется решить массу проблем, вот их примерный список:

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

Это увы, проблема стимулирования потребления, а не R&D.

Oleg06.02.2006 16:13
4

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

К идее copylove:
1. Психологический фактор. Что-либо покупать, да ещё и на ходу — в лом. Поэтому пользуются тем, что уже есть.
2. Разработчикам программ не хочется “замазывать” свои сервисы в back-end. Они хотят показать себя красиво и ярко, и в этом смысле не доверяют “дежурным” GUI.
3. Уже есть html, зачем придумывать велосипед? Надо только прикрутить к нему short-key и прочие бантики. К тому же есть и XML, с ним вообще раздолье для GUI-дизайнеров.

К идее romx:
1. Всем хочется продать своё устройство подороже, впихнув в него максимум функций и привязав таким образом клиента. “Распыляться” и становиться изготовителем гаек не захочет никто.
2. Всё это “облако” надо заряжать по отдельности каждый вечер, а это геморрой. Тем более при нынешних батарейках. Ну сколько будет работать автономно плейер на шнуре? В том и прелесть “all-in-one”-девайсов, что они делят между собой энергетические ресурсы.
3. Ну и, конечно, стандартизация коммуникаций. Тот же BlueTooth есть в основном железный протокол, и каждый вешает на него то, что сам придумает. И делиться с другими не захочет. Вон моя Моторола как-то себя через БТ синхронизирует, но сам протокол — тайна за 7П.

Так что начинать надо с косности людей, а не с производства модулей…

romx06.02.2006 16:33
5

tango_rus: чего ж не работает-то толком? ;)
Почему не работает спросите? Ну так а где оно за пределами Юникс-Линуксов, где и оно-то угнездилось только исторически?
Тем более что в данном случае тема-то вовсе не про отображение экрана на другом компьютере, вглубь смотрите.

Oleg06.02.2006 16:52
6

да и не то это, Х-Виндовз. Оне как раз GUI на сервере делают.
а зато вот есть ява-апплеты, гибкая и наработанная технология.
но вопрос, как я уже сказал, не в ней…

Alexei Puzikov06.02.2006 18:28
7

Всё хорошо в идее с PDA в виде разрозненных устройств, но вот если вернуться с небес на землю…

1. Питание. Заряжать каждое устройство - отдельно? И батарейка у каждого своя - утяжеляющая. И радиочасть у каждого своя, удорожающая.

2. Управление. Купили новый блок памяти, который в такой схеме по сути является хабом. Значит, нужно на каждом устройстве этот блок подключить, а старый отключить. А если программа залочена на старый? А если блоков несколько? К какому из них подключаться? А когда в комнате 10 человек?

3. Безопасность. Начиная с физической (свернули из сумки память) и заканчивая логической (пришли на вечеринку или в клуб, в котором ещё человек 20 с такими же комплектами, и один из них целенаправленно ищет Linksys/linksys :)

Alexei Puzikov06.02.2006 18:30
8

И по поводу универсальных ядер программ и сервисов.

В ситуации, когда почти везде есть Питон или какой-нибудь Руби, и когда мы считаем, что у нас коннективити есть везде - задача существенно упрощается. Выносим все букмарки куда-нибудь типа deli.cio.us, сихронизируемся с каждого устройства. Почту - на Gmail.

Или на .Mac account. Или на свой собственный FTP/IMAP4.

Просто нужно, чтобы кто-то начал это всё делать :)

romx07.02.2006 00:15
9

Поясню про питание. Просто первое же пришедшее в голову.
Уже несколько лет как существует устройство для “бесконтактной зарядки”. Правда для этого требуется в заряжаемом устройстве модификация.
Принцип - электромагнитная индукция низкочастотным полем.
Демонстрировалось в виде панельки размером с мауспад, на который кладется мобила. В “мауспаде” этом по контуру обмотка, в мобиле катушка. За счет правильно подобранного электромагнитного поля частотой несколько сотен герц, в катушке мобилы наводится достаточное количество электричества для зарядки. Но поле незначительно (и быстро рассеивается) для сколь-нибудь заметного паразитного воздействия.

Таким образом в квартире можно делать несколько “зон зарядки” (вешалка в прихожей, рабочий стол), находясь в которых устройство будет подзаряжаться.
Таким образом решаем проблему электропитания “облака девайсов-сервисов”

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

Teo07.02.2006 07:47
10

В свете идеи romx’a, так и представляю себе картину: выбегаешь впопыхах утром из дома, и в дороге уже понимаешь, что процессор остался в другой куртке :D . Тут же вспоминается неоригинальная фраза школьных учителей: «Ты бы еще мозг дома оставил»…

tango_rus07.02.2006 10:00
11

2 romx:
>> чего ж не работает-то толком?
Технически все работает на раз. Я пользовался и X-Window сервером. Кстати, для Windows, по работе надо было. Пользовался и TerminalServices через Интернет. Так что проблема не в технике и ПО. Проблема, как говорили выше, скорее или в инерции мышления, или в маркетинге.
Цель всех производителей, хоть ПО, хоть железок, в зарабатывании бабла, а не в развитии технологий. Технически сейчас можно сделать очень многое, только вот не делают. Потому как не придумали, как с этого деньги выкачать.

romx07.02.2006 12:05
12

Вчера пытался найти для конкретики стоимость чипов Bluetooth, от самого распространенного производителя Cambridge Silicon Radio (http://www.csr.com/products/bcrange.htm).
К сожалению в явном виде цен нет.
Но судя по тому, что в 2001 году CSR объявила, что им удалось снизить стоимость чипсета BT ниже 5$ я полагаю что стоимость в промышленной партии уже давно не превышает 1$ для самых массовых чипов. Это о стоимости радиоблока в каждом “модуле”.
Причем массовым сейчас является 2 поколение (BlueCore2), именно он идет сейчас в USB Dongle и мобильники. А производится уже пятое поколение, BlueCore 5!
А уж какие там возможности, фантастика. И когда ж мы такое увидим, и увидим ли?

romx07.02.2006 12:10
13

tango_rus:
> Цель всех производителей, хоть ПО, хоть железок, в зарабатывании бабла, а не в развитии технологий.

Но что может запретить зарабатывая бабло развивать технологии? ;) Совмещать так сказать приятное с полезным.
Вон посмотрите на Apple с его iPod, который фактически создал американский рынок mp3-гаджетов. И деньжат подзаработали, и технологии продвинули.
Вот кому бы взяться, любят они “идеологизм” в устройствах, у них бы получилось.

tango_rus07.02.2006 12:53
14

romx:
>> Но что может запретить зарабатывая бабло развивать технологии?
Отсутствие бабла не развитие технологий, не приносящих прибыли в обозримые сроки.
Для аналогии возьмем аспирин. Задача: нужен новый препарат с точки зрения получения дополнительной прибыли.
Решения:
1. Затратить кучу денег на разработку нового, более эффективного лекарства, провести исследования. Время - от 5 лет. Срок окупаемости большой.
2. Взять готовый аспирин, упаковать в красивую упаковку, сделать его шипучим, придумать новое название, широко разрекламировать. Время - 1 год. Срок окупаемости маленький.
Возникает вопрос - зачем разрабатывать новое? Для маркетологов - незачем. Они другими понятиями мыслят. Их не волнуют конечные пользователи. Абсолютно.
А в руководстве большинства компаний сидят именно маркетологи.
Вот вам и объяснение.

Илья Фомин08.02.2006 22:35
15

Уже много лет всё хотят уместить в одной “коробочке” - смысл опять разделять? Чтобы наверняка что-нибудь потерять?

может стоит подумать\поработать с этим:Wearable computers
http://www.media.mit.edu/wearables/

PS: есть здесь такие люди, которые держали в руках такие чтуки?

16

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

17

Подобная распределённая архитектура легко реализуется с помощью Java 2 Enterprise Edition, первая версия которой появилась ну очень давно и намного раньше .Net. J2EE - всего лишь спецификация. Компаниям разработчикам достаточно писать совместимые приложения и всё будет хорошо работать.

Существует масса примеров реализации подобных сервисов и программных комплексов. Ядро зачастую крутится на J2EE сервере, реализовано оно на основе Enerprise Java Beans, архитектура которых не привязана к GUI - только логика. А GUI может быть как web, так и обычный оконный интерфейс на Java. Можно сделать и набор веб-сервисов, для управления логикой. В последнем случае GUI может быть написан вообще на чём угодно.

Для разделения логики и UI существует шаблон проектирования: Model View Controller, по которому весь код делится на 3 части, каждая из которой выполняет только свою функцию: Model хранит данные, View отображает данные, а Controller осуществляет доставку и преобразование данных от Model к View и обратно.

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

Sergey11.02.2006 00:32
18

.NET 2.0 с технологией ClickOnce решает проблему “зоопарка”, технологической сложности нет.

Я полагаю проблема в культуре разработчиков софта (коим тоже являюсь), зачастую сделать правильно и удобно для пользователя попросту не заходит в их голову.

Оставить комментарий