в поисках юзабилити

В феврале �?того года по�?вила�?ь возможно�?ть проверить в�?е догадки и домы�?лы отно�?ительно Sparkle, как ин�?трумента дл�? проектировани�? интерфей�?ов. В каче�?тве проверки �? обычно пытаю�?ь �?оздать типичные интерфей�?ные решени�? или же конкретный �?кран одного из по�?ледних проектов. Дл�? Sparkle потребовало�?ь не�?колько больше времени, по�?кольку множе�?тво и�?пользуемых в нём решений и идиом до�?таточно новы и непривычны, из-за чего в начале кажет�?�?, что интерфей�? неудобен.

Сразу �?кажу, что Sparkle не оправдал многих моих ожиданий. Однако �?то не значит, что программа плоха, нет, про�?то видимо в при�?тупе �?йфории �? решил, что Microsoft наконец от�?тупила от �?воего прагматичного подхода к �?озданию программ – ма�?�?ового рынка, «до�?таточно хорошего» интерфей�?а и внедрению пары-тройки таких возможно�?тей, которые �?разу за�?тавл�?ют задумать�?�? о переходе на неё (например как �?то было �? подчёркиванием неверных �?лов в Word 95).

Вы�?�?н�?ет�?�? что нет, не от�?тупила: в�?е �?ти факторы при�?ут�?твуют и в Sparkle. �?е�?мотр�? на по�?то�?нный ро�?т и попул�?рно�?ть нашей профе�?�?ии, проектирование интерфей�?ов в�?ё таки до�?таточно �?пециализированный рынок и большой прибыли зде�?ь не получить.

Интерфей�? Sparkle «до�?таточно хорош»: возможно�?ти путём пр�?мой манипул�?ции прив�?зывать, выравнивать, ма�?штабировать и вращать фигуры дей�?твительно удобны в работе по �?равнению �? традиционными интерфей�?ными решени�?ми, но они �?корее и�?ключение, чем правило.

Самый главный плю�? Sparkle, из-за которого многим буквальным образом придёт�?�? его и�?пользовать �?то та �?ама�? пр�?ма�? �?в�?зь �? программным кодом, то е�?ть генераци�? XAML на о�?нове прототипа интерфей�?а и компил�?ци�? его в и�?полн�?емый файл. По �?ути Sparkle �?вл�?ет�?�? в�?его лишь заменой визуального редактора в Visual Studio, но в тоже врем�? не�?омненно �?вл�?ет�?�? большим шагом вперёд, по�?кольку впервые в и�?тории позвол�?ет чётко разделить роли проектировщика интерфей�?а и разработчика �?амой программы.

Теоретиче�?ки, при и�?пользовании Sparkle отпадает нужда имплементировать интерфей�? на о�?нове прототипов, �?озданных проектировщиком интерфей�?ов, а значит почти пропадает проблема не�?овпадени�? (в худшую �?торону) готовой программы программы и прототипа.

Практиче�?ки же, Sparkle �?вл�?ет�?�? ин�?трументом реализации интерфей�?а, а не его проектировани�?. Пред�?тавьте, что вы точно знаете как �?делать нужный вам интерфей�?, и вам нужно лишь опи�?ать его – вот �?то �? и называю реализацией.

В реально�?ти же так не бывает. Проектирование – проце�?�? творче�?кий, по�?то�?нное �?к�?периментирование и пои�?к лучшего варианта. Дл�? �?того Sparkle к �?ожалению почти ничего не предо�?тавл�?ет, а в р�?де �?лучаев ещё и мешает проце�?�?у проектировани�?:

Выбор готовых �?лементов управлени�? на о�?нове «программной» терминологии �?разу за�?тавл�?ет проектировщика интерфей�?а думать в терминах реализации, тогда как ему �?корее необходим ин�?трумент дл�? �?оздани�? набро�?ка решени�?, �?уще�?твующего в его голове. Каким образом реализует�?�? объединение �?лементов в один объект – �? помощью GroupBox, CollectionContainer или Canvas – на �?том �?тапе �?овершенно не важно.

Пред�?тавьте �?ебе кон�?труктора, обладающего только набором готовых трафаретов дл�? черчени�?, �?кажем, болтов разного диаметра и длины, и не имеющего возможно�?ть нари�?овать болт от руки. Е�?ли ему потребует�?�? начертить болт дл�? �?креплени�? чего-либо, ему придёт�?�? по�?то�?нно выбирать подход�?щий из имеющих�?�? трафаретов, вме�?то того чтобы про�?то обозначить на чертеже «зде�?ь будет болт».

�?ет в Sparkle и не раз упом�?нутой мною возможно�?ти, котора�? �?могла бы �?�?кономить многие ча�?ы и дни механиче�?кого труда проектировщика интерфей�?ов: возможно�?ти обозначить группу �?лементов управлени�? дл�? и�?пользовани�? её как мини-шаблона на других �?кранах. Типичный пример – «шапка» веб-�?айта. Е�?ли у ва�? в прототипе пара де�?�?тков �?кранов �?траниц �?айта и вы хотите помен�?ть что-то в «шапке», вам придёт�?�? мен�?ть в�?е �?траницы: тупа�? и неблагодарна�? работа.

Далее, е�?ли даже на�? избав�?т от необходимо�?ти �?оздани�? прототипов как �?пецификации интерфей�?а, �?то не означает, что интерфей�? не нужно документировать – нужно, и ещё как, причём на разных �?тади�?х: от демон�?трации первых грубых прототипов началь�?тву или клиенту до комментариев, почему именно так, а не иначе был реализован данный интерфей�? и приведени�? �?�?ылок на конкретные проектные требовани�?.

Сейча�? мне например приходит�?�? либо в�?тавл�?ть прототипы в Word и комментировать тек�?том, либо делать отдельные �?лои в Visio. В �?том вопро�?е от Sparkle также нет никакой пользы.

Чтобы не заканчивать обзор на минорной ноте, упом�?ну ещё об одной привлекательной возможно�?ти Sparkle, котора�? фактиче�?ки уже �?ейча�? �?вл�?ет�?�? „must have“ дл�? проектировани�? интерфей�?ов: анимации. Ра�?�?казывают, что интерфей�?ное решение аналогично и�?пользуемому во Flash. Сам �? Flash до �?их пор не видел, по�?тому прокомментировать не могу, но про�?тые анимации в Sparkle получают�?�? довольно бы�?тро.

Вот например что у мен�? вышло (каче�?тво немного потер�?ло�?ь при конвертации в gif):

Краткий итог: официальный выход Sparkle не�?омненно вызовет переход на него ча�?ти проектировщиков интерфей�?ов. Дл�? о�?тальных пока о�?таёт�?�? Visio и аналогичные программы. Специализированные программы дл�? проектировани�? интерфей�?ов пока в�?ё ещё �?ыры, но когда-нибудь одна из них вполне может «�?озреть». Будем �?нова ждать.