Никогда не обращали внимание, как часто старые интерфейсы, старый код и вообще старые решения выглядят странными и уродливыми? Причём всё это может стать старым за считанные годы. Когда приходится очень быстро бежать только, чтобы оставаться на месте, возникает желание как-нибудь срезать, заглянуть немного в будущее, перепрыгнуть через пару пунктов.
Давайте попробуем. Для этого нам необходимо понять по каким принципам идет развитие: внимательно рассмотреть те пещерные технологии, что мы использовали пару лет назад и то, как они превращались в “технологии будущего”, что мы используем сегодня.
Несколько лет назад, сооружая админку для фотогалереи на одном сайте, я понял, что обычный на то время подход размещения в форме нескольких инпутов не так уж хорош, особенно, учитывая, что необходимо загрузить заранее неизвестное и относительно большое количество фоток. Решением стало создание пяти полей и ссылки “добавить ещё”, которая динамически создавала ещё одно дополнительное поле. С подсказки коллеги я приделал ссылку “добавить ещё 5”, и “технология будущего” была готова.
И она действительно была хороша, какое-то время, по прошествии которого в другом проекте, я использовал загрузку картинок в архиве. Новый способ имел своё преимущество — не нужно выбирать множество файлов, и свои недостатки — человеку нужно предварительно запаковать свои изображения (нормально для админки, неприемлемо для фронтенда) и нет возможности управлять порядком изображений.
Шло время, и чуть более года назад та же задача встала вновь, как водится, на очередном новом проекте. Были и отличия, во-первых, на этот раз форма была “для людей”, а, во-вторых, максимальное число фоток на форму было небольшим (фотки правда подросли, набрали вес за прошедшее время). Реализованное решение в итоге было таким — одно поле, при заполнение сразу отправляющееся через iframe, результаты обработки (URL и статистика) подсовываются в скрытое поле в исходной форме и показываются в виде миниатюрки. Преимуществ тут много, но главными для нас стали возможность отдельной загрузки изображений и формы (можно дозаполять форму пока изображения грузятся, сокращая, таким образом, время ожидания) и возможность загрузки изображений на отдельный сервер, минуя сервер приложений. Завернув всё это дело в виджет мы избавили себя от всякой необходимости обрабатывать загрузки изображений в этом проекте. Именно благодаря этому, такой способ стал для нас очередной “технологией будущего” на год.
Как вы догадываетесь, через год старое решение перестало нас удовлетворять и мы решили его проапгредить. Во-первых, во всех браузерах которые умеют (все кроме IE), поле загрузки файла сделали множественным. Во-вторых, опять же где возможно (везде кроме IE и Оперы) вместо iframe-а стали использовать AJAX 2 с его кросс-доменными загрузками файлов, при этом с помощью File API множественный набор файлов разбивался на отдельные, что ускоряло загрузку и упрощало серверную часть (не нужно распараллеливать пережимку, не нужно аггрегировать ошибки в один результат). Что ж это звучит достаточно круто, пока.
В моей небольшой повести о загрузке картинок я упоминал различные причины и преимущества отдельных шагов как интерфейсные, так и технические. Теперь давайте отбросим всё, что не касается интерфейса, и попытаемся разобраться, куда оно всё идёт.
Чтобы отделить интерфейс от всего остального, нужно чётко понять что это. Что же такое интерфейс? Ладно, это слишком сложный вопрос для разминки, зададим другой, попроще. Когда мы сталкиваемся с интерфейсом? Общий ответ мог бы быть таким: когда мы имеем дело с какой-то системой (программой, сервисом) и хотим, чтобы она для нас что-то сделала. Звучит разумно, будем плясать от этого, с небольшой поправкой: система, как правило, посредник между нами и другими людьми (или между нами и физической реальностью), поэтому её следует выбросить из формулировки, т.е. мы сталкиваемся с интерфейсом когда чего-то хотим. Таким образом:
Интерфейс — это препятствие между человеком и тем, что он хочет.
Чтобы этот вывод и последние несколько фраз не казались мутным и чрезмерным обобщением, вернёмся к примеру с загрузкой фоток. Чего человек хочет когда он обращается к этому интерфейсу? Загрузить картинки на сайт? Не совсем так, точнее это верно лишь отчасти, на самом деле, он хочет показать другим что-то что видит/видел сам. Вторая формулировка более общая и она даёт свои преимущества — становится очевидно, что и “сайт”, и “фотки” дополнительные сущности не содержащиеся в исходной задаче, если бы можно было выполнить желание “показать то, что вижу другим” без того и другого это бы стало выигрышем в плане интерфейса.
Из определения сразу следует, что идеальный интерфейс — это тот, где желание пользователя исполняется сразу без дополнительных шагов. А эти самые дополнительные шаги и сущности не содержащиеся в самой задаче, но использующиеся в интерфейсе, и составляют сложность интерфейса.
Что ж, обретя всю эту мудрость, попробуем применить её к истории с картинками. Для ясности распишем все элементы сложности интерфейса для каждого случая.
0. То, что было до. Шаги — выбор файла каждой картинки в отдельное поле, при нехватке полей нужно всё повторить. Дополнительная сущность — максимальное количество фоток за раз.
1. Добавляем поля динамически. Шаги — выбор каждой картинки в отдельное поле, при нехватке полей добавить их с помощью одной и специальных ссылок. Дополнительные сущности — ссылки добавления полей.
2. Загрузка архивом. Шаги — создание архива с нужными изображениями, выбор файла архива в поле. Дополнительная сущность — архив.
3. Iframe. Шаги — выбрать файлы фоток по одному в единственное поле.
4. multiple + Files API + AJAX 2. Шаги — выбрать все нужные файлы фоток в поле загрузки.
Видно, что с каждой итерацией шагов и дополнительных понятий становится всё меньше, последний вариант кажется вообще отличным — всего один шаг и ни одной лишней сущности!
Как бы не так. Вспомним наиболее общую формулировку того, что хочет пользователь: “показать другим то, что видит сам” и сразу заметим дополнительные шаги и сущности общие для всех вышеприведённых вариантов. Шаги — съёмка фоток, переброска их на компьютер, запуск браузера, заход на сайт, авторизация, заполнение формы, отправка формы. Сущности — загрузка файлов, файлы, фотки, фотоаппарат, компьютер, браузер, сайт, форма, интернет.
Чёрт возьми, есть куда расти! И похоже наша технология будущего станет таким же артефактом как все предыдущие, слишком много возможных улучшений. Посмотрим как можно устранить эти дополнительные шаги и понятия.
Один эффективный способ устранить шаг — это сделать его автоматическим, если пользователю не нужно о чём-то думать, то это перестаёт быть элементом интерфейса.
Загрузку файлов можно заменить на автоматическую синхронизацию, именно это уже делает Dropbox и отчасти Google Docs. Пример Dropbox показателен как раз тем, что он решает одну зато очень распространенную проблему и на этом строит весь свой бизнес.
Переброску файлов на компьютер, запуск браузера заменяют мобильные приложения. Клиент Dropbox на телефоне эффективно устраняет эти шаги, как впрочем и любое другое мобильное приложение для работы с сайтом. Есть даже целая операционная система ChromeOS, которая устраняет необходимость запуска браузера (кроме того, конечно, она сильно упрощает установку приложений и синхронизацию рабочего окружения).
Можно устранять даже такие фундаментальные понятия как файлы или интернет. Понятие файлов довольно успешно скрывается в iOS там пользователь имеет дело с изображениями, видео, музыкой, книгами или контактами, с чем угодно, но не с файлами. Интернет же исчезает (из списка забот пользователя, а следовательно и из интерфеса) если он просто есть всегда и везде, бесплатное повсеместное подключение для Amazon Kindle 3G, в этом смысле, это не просто халявный трафик, это качественное улучшение интерфейса.
Мы видим, что кто-то как-то преодолевает многочисленные оставшиеся фрагменты интерфейса. Вопрос был в том, что бы такое придумать, чтобы улучшить наш интерфейс. Вернёмся к примеру с картинками ещё раз.
Можно пойти по пути синхронизации. Все фотки на компьютере, сложенные в определенную папку, могут появляться на сайте (можно добавить специальный шаг их публикации, хотя лучше, например, публиковать всё в «несортированном», предоставляя пользователю возможность привести всё в порядок когда ему будет удобно). Синхронизация будет ещё удобнее в случае мобильного приложения — все снятые фотки могут просто появляться на сайте.
Всё это здорово для больших ресурсов (если бы я был Flickr-ом, я бы всерьёз задумался как впихнуть свой клиент в фотоаппараты), но что делать автору небольшого сайта? Ответ — интегрироваться с внешними сервисами. Если нам нужно получить фото от пользователя, это не значит, что нам нужно организовывать загрузку файлов, в действительности это даже не значит, что пользователю нужно что-то загружать (например, потому что он это уже сделал). Нужно подумать откуда мы можем взять эти фото. И таких мест не так мало: аватар можно стянуть с Gravatar, различные фотографии с социальных сетей и сервисов вроде Flickr, любые файлы с Dropbox.
Использование сторонних сервисов даёт большие преимущества:
— в какой-то момент можно просто отказаться от реализации и поддержки этой функциональности сайта своими силами,
— вы автоматически получаете (предоставляете вашим пользователям) все удобства появляющиеся в сервисах, с которыми вы интегрируетесь. Dropbox выпускает клиент для PS 3 — вы можете загружать оттуда скриншоты, Flickr делает пресловутый клиент для фотоаппаратов — вы опять в выигрыше.
Такой аутсорсинг не только позволяет получить лучший интерфейс, он позволяет сосредоточиться на том, что делает именно ваш сервис. Например, если вы задумали создать онлайн-редактор для создания коллажей, то традиционными методами вам нужно реализовать регистрацию/авторизацию пользователей, загрузку изображений, систему комментариев (куда без них?) и собственно ваше приложение — специально заточенный редактор фотографий. Вместо того, чтобы делать всё это самому, вы можете использовать социальные сети для авторизации, их же, Flick и Dropbox в качестве источника фото и Disqus как систему комментирования. Кроме того, сторонние сервисы (социальные сети, в основном) также послужат отличной средой публикации, а следовательно сарафанной рекламы для вашего приложения. Всё что вам останется сделать это то, что вы собственно и собирались — онлайн-редактор коллажей (плюс собрать это всё вместе, конечно).
Шансы велики, что если вы не будете тратить время на разработку и поддержку всей непрофильной функциональности, то суть, ваше творение — редактор коллажей, в данном случае — будет лучше. Ваше приложение будет делать одну простую вещь хорошо. А чтобы завершить аналогию с Unix-way научите ваше приложение работать с другими — предоставьте API.
Вы решаете, что вы делаете — ещё один (возможно, неплохой) сервис или ещё один камень в фундамент будущего сети.
Давайте попробуем. Для этого нам необходимо понять по каким принципам идет развитие: внимательно рассмотреть те пещерные технологии, что мы использовали пару лет назад и то, как они превращались в “технологии будущего”, что мы используем сегодня.
Один пространный пример
Несколько лет назад, сооружая админку для фотогалереи на одном сайте, я понял, что обычный на то время подход размещения в форме нескольких инпутов не так уж хорош, особенно, учитывая, что необходимо загрузить заранее неизвестное и относительно большое количество фоток. Решением стало создание пяти полей и ссылки “добавить ещё”, которая динамически создавала ещё одно дополнительное поле. С подсказки коллеги я приделал ссылку “добавить ещё 5”, и “технология будущего” была готова.
И она действительно была хороша, какое-то время, по прошествии которого в другом проекте, я использовал загрузку картинок в архиве. Новый способ имел своё преимущество — не нужно выбирать множество файлов, и свои недостатки — человеку нужно предварительно запаковать свои изображения (нормально для админки, неприемлемо для фронтенда) и нет возможности управлять порядком изображений.
Шло время, и чуть более года назад та же задача встала вновь, как водится, на очередном новом проекте. Были и отличия, во-первых, на этот раз форма была “для людей”, а, во-вторых, максимальное число фоток на форму было небольшим (фотки правда подросли, набрали вес за прошедшее время). Реализованное решение в итоге было таким — одно поле, при заполнение сразу отправляющееся через iframe, результаты обработки (URL и статистика) подсовываются в скрытое поле в исходной форме и показываются в виде миниатюрки. Преимуществ тут много, но главными для нас стали возможность отдельной загрузки изображений и формы (можно дозаполять форму пока изображения грузятся, сокращая, таким образом, время ожидания) и возможность загрузки изображений на отдельный сервер, минуя сервер приложений. Завернув всё это дело в виджет мы избавили себя от всякой необходимости обрабатывать загрузки изображений в этом проекте. Именно благодаря этому, такой способ стал для нас очередной “технологией будущего” на год.
Как вы догадываетесь, через год старое решение перестало нас удовлетворять и мы решили его проапгредить. Во-первых, во всех браузерах которые умеют (все кроме IE), поле загрузки файла сделали множественным. Во-вторых, опять же где возможно (везде кроме IE и Оперы) вместо iframe-а стали использовать AJAX 2 с его кросс-доменными загрузками файлов, при этом с помощью File API множественный набор файлов разбивался на отдельные, что ускоряло загрузку и упрощало серверную часть (не нужно распараллеливать пережимку, не нужно аггрегировать ошибки в один результат). Что ж это звучит достаточно круто, пока.
Интерфейс
В моей небольшой повести о загрузке картинок я упоминал различные причины и преимущества отдельных шагов как интерфейсные, так и технические. Теперь давайте отбросим всё, что не касается интерфейса, и попытаемся разобраться, куда оно всё идёт.
Чтобы отделить интерфейс от всего остального, нужно чётко понять что это. Что же такое интерфейс? Ладно, это слишком сложный вопрос для разминки, зададим другой, попроще. Когда мы сталкиваемся с интерфейсом? Общий ответ мог бы быть таким: когда мы имеем дело с какой-то системой (программой, сервисом) и хотим, чтобы она для нас что-то сделала. Звучит разумно, будем плясать от этого, с небольшой поправкой: система, как правило, посредник между нами и другими людьми (или между нами и физической реальностью), поэтому её следует выбросить из формулировки, т.е. мы сталкиваемся с интерфейсом когда чего-то хотим. Таким образом:
Интерфейс — это препятствие между человеком и тем, что он хочет.
Чтобы этот вывод и последние несколько фраз не казались мутным и чрезмерным обобщением, вернёмся к примеру с загрузкой фоток. Чего человек хочет когда он обращается к этому интерфейсу? Загрузить картинки на сайт? Не совсем так, точнее это верно лишь отчасти, на самом деле, он хочет показать другим что-то что видит/видел сам. Вторая формулировка более общая и она даёт свои преимущества — становится очевидно, что и “сайт”, и “фотки” дополнительные сущности не содержащиеся в исходной задаче, если бы можно было выполнить желание “показать то, что вижу другим” без того и другого это бы стало выигрышем в плане интерфейса.
Из определения сразу следует, что идеальный интерфейс — это тот, где желание пользователя исполняется сразу без дополнительных шагов. А эти самые дополнительные шаги и сущности не содержащиеся в самой задаче, но использующиеся в интерфейсе, и составляют сложность интерфейса.
Извлекаем уроки
Что ж, обретя всю эту мудрость, попробуем применить её к истории с картинками. Для ясности распишем все элементы сложности интерфейса для каждого случая.
0. То, что было до. Шаги — выбор файла каждой картинки в отдельное поле, при нехватке полей нужно всё повторить. Дополнительная сущность — максимальное количество фоток за раз.
1. Добавляем поля динамически. Шаги — выбор каждой картинки в отдельное поле, при нехватке полей добавить их с помощью одной и специальных ссылок. Дополнительные сущности — ссылки добавления полей.
2. Загрузка архивом. Шаги — создание архива с нужными изображениями, выбор файла архива в поле. Дополнительная сущность — архив.
3. Iframe. Шаги — выбрать файлы фоток по одному в единственное поле.
4. multiple + Files API + AJAX 2. Шаги — выбрать все нужные файлы фоток в поле загрузки.
Видно, что с каждой итерацией шагов и дополнительных понятий становится всё меньше, последний вариант кажется вообще отличным — всего один шаг и ни одной лишней сущности!
Как бы не так. Вспомним наиболее общую формулировку того, что хочет пользователь: “показать другим то, что видит сам” и сразу заметим дополнительные шаги и сущности общие для всех вышеприведённых вариантов. Шаги — съёмка фоток, переброска их на компьютер, запуск браузера, заход на сайт, авторизация, заполнение формы, отправка формы. Сущности — загрузка файлов, файлы, фотки, фотоаппарат, компьютер, браузер, сайт, форма, интернет.
Чёрт возьми, есть куда расти! И похоже наша технология будущего станет таким же артефактом как все предыдущие, слишком много возможных улучшений. Посмотрим как можно устранить эти дополнительные шаги и понятия.
Один эффективный способ устранить шаг — это сделать его автоматическим, если пользователю не нужно о чём-то думать, то это перестаёт быть элементом интерфейса.
Загрузку файлов можно заменить на автоматическую синхронизацию, именно это уже делает Dropbox и отчасти Google Docs. Пример Dropbox показателен как раз тем, что он решает одну зато очень распространенную проблему и на этом строит весь свой бизнес.
Переброску файлов на компьютер, запуск браузера заменяют мобильные приложения. Клиент Dropbox на телефоне эффективно устраняет эти шаги, как впрочем и любое другое мобильное приложение для работы с сайтом. Есть даже целая операционная система ChromeOS, которая устраняет необходимость запуска браузера (кроме того, конечно, она сильно упрощает установку приложений и синхронизацию рабочего окружения).
Можно устранять даже такие фундаментальные понятия как файлы или интернет. Понятие файлов довольно успешно скрывается в iOS там пользователь имеет дело с изображениями, видео, музыкой, книгами или контактами, с чем угодно, но не с файлами. Интернет же исчезает (из списка забот пользователя, а следовательно и из интерфеса) если он просто есть всегда и везде, бесплатное повсеместное подключение для Amazon Kindle 3G, в этом смысле, это не просто халявный трафик, это качественное улучшение интерфейса.
Ближе к жизни
Мы видим, что кто-то как-то преодолевает многочисленные оставшиеся фрагменты интерфейса. Вопрос был в том, что бы такое придумать, чтобы улучшить наш интерфейс. Вернёмся к примеру с картинками ещё раз.
Можно пойти по пути синхронизации. Все фотки на компьютере, сложенные в определенную папку, могут появляться на сайте (можно добавить специальный шаг их публикации, хотя лучше, например, публиковать всё в «несортированном», предоставляя пользователю возможность привести всё в порядок когда ему будет удобно). Синхронизация будет ещё удобнее в случае мобильного приложения — все снятые фотки могут просто появляться на сайте.
Всё это здорово для больших ресурсов (если бы я был Flickr-ом, я бы всерьёз задумался как впихнуть свой клиент в фотоаппараты), но что делать автору небольшого сайта? Ответ — интегрироваться с внешними сервисами. Если нам нужно получить фото от пользователя, это не значит, что нам нужно организовывать загрузку файлов, в действительности это даже не значит, что пользователю нужно что-то загружать (например, потому что он это уже сделал). Нужно подумать откуда мы можем взять эти фото. И таких мест не так мало: аватар можно стянуть с Gravatar, различные фотографии с социальных сетей и сервисов вроде Flickr, любые файлы с Dropbox.
Использование сторонних сервисов даёт большие преимущества:
— в какой-то момент можно просто отказаться от реализации и поддержки этой функциональности сайта своими силами,
— вы автоматически получаете (предоставляете вашим пользователям) все удобства появляющиеся в сервисах, с которыми вы интегрируетесь. Dropbox выпускает клиент для PS 3 — вы можете загружать оттуда скриншоты, Flickr делает пресловутый клиент для фотоаппаратов — вы опять в выигрыше.
Такой аутсорсинг не только позволяет получить лучший интерфейс, он позволяет сосредоточиться на том, что делает именно ваш сервис. Например, если вы задумали создать онлайн-редактор для создания коллажей, то традиционными методами вам нужно реализовать регистрацию/авторизацию пользователей, загрузку изображений, систему комментариев (куда без них?) и собственно ваше приложение — специально заточенный редактор фотографий. Вместо того, чтобы делать всё это самому, вы можете использовать социальные сети для авторизации, их же, Flick и Dropbox в качестве источника фото и Disqus как систему комментирования. Кроме того, сторонние сервисы (социальные сети, в основном) также послужат отличной средой публикации, а следовательно сарафанной рекламы для вашего приложения. Всё что вам останется сделать это то, что вы собственно и собирались — онлайн-редактор коллажей (плюс собрать это всё вместе, конечно).
Шансы велики, что если вы не будете тратить время на разработку и поддержку всей непрофильной функциональности, то суть, ваше творение — редактор коллажей, в данном случае — будет лучше. Ваше приложение будет делать одну простую вещь хорошо. А чтобы завершить аналогию с Unix-way научите ваше приложение работать с другими — предоставьте API.
Вы решаете, что вы делаете — ещё один (возможно, неплохой) сервис или ещё один камень в фундамент будущего сети.