Роман Химов

Конечно, барьеры могут быть не только физическими.

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

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

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

Поэтому особенно интересно видеть, когда люди чувствуют барьеры и ломают их. Взять, например, недавний выход спецификации ВебЮЭсБи, с инженерной точки зрения проблема вполне понятная — прокидывание одного протокола поверх другого. Не сказать, что тривиальная, но понятная. А вот с точки зрения снимаемых барьеров штука весьма серьёзная, например, сейчас для некоторых возможностей портала Госуслуг необходима установка плагина, что невыполнимо для большинства пользователей, а с новым протоколом ничего уже не нужно, всё просто будет работать (вопросы безопасности я намеренно опускаю).

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

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

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

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

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

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

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

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

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

Не так давно мне приходилось смотреть бизнес-центры. Лишь в одном из десятка не было турникетов. Странным образом, выбран был именно он.

Рассказ Алексея Березина трёхлетней давности как-то прошёл мимо меня, а он прекрасен, явно писан с натуры. С удовольствием наверстал упущенное. Как оказалось, нынче есть ещё и две экранизации: наша и импортная.

Собственно, чего я хотел от Umbrello. 🙂 UML я тут маленько рисую. Ну и, попутно, надо схему БД нарисовать не менее красивую. В своё время рисовал подобные штуки в OpenOffice, муторное довольно дело, но получалось. А тут захотелось, понимаешь, чтобы «по-правильному».

Докладываю, грустно с этим. ER диаграммы — запросто, но от них до реальной схемы, как ни крути. Umbrello не умеет (только ER), ArgoUML с модулем DB-UML рисует не так (хотя от ER ушёл серьёзно, факт) и ужасен в интерфейсе, BoUML недееспособен, Kexi (а-ля Access) нарисовать диаграмму не может. В общем, ничего что бы мне понравилось, я так и не нашёл. Кстати, именно по UML части всё как раз наоборот, тот же Argo наворочен аж жуть, Umbrello проигрывает и местами староват, но для многих применений будет достаточен.

Остаются всякие OpenOffice Draw, Kivio, Dia и прочие, прямоугольнички с палочками без малейшего учёта семантики. Эх.

P.S. Может я всё-таки что-то упустил где-то и есть волшебные средства?
P.P.S. Я таки помучал ещё раз новый Umbrello из KDE4 и имею сказать, что он почти на уровне Argo в отношении ER/DB (только несравненно удобнее). Единственное, блин, ну почему при явном указании «FOREIGN KEY» не нарисовать связь от поля к полю, а не от таблицы к таблице. Вот он, вот он этот баг…
P.P.P.S. Гм, вот первый случай, когда реально что-то из KDE4 вроде как надобно уже. Скорей бы 4.1, глядишь, можно будет переползать помаленьку.
P.P.P.P.S. А ещё Umbrello стал гораздо лучше автоматически стрелки рисовать.

Читаю и думаю, а, собственно, не слишком ли стало много маразма в стиле «безопасность надо обдумывать с самого начала проекта», «юзабилити надо иметь в виду еще до первой строчки кода» и т.п.? Что мы получим, если будем пытаться все учитывать с самого начала?

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

Ну а теперь другой вопрос — какого, извините, хрена это становится понятным только в виде «о $вот_этой_фигне тоже надо думать, прикинь?» Причем, желательно, до первой строчки кода.