Вы когда-нибудь замечали, как часто старые интерфейсы, старый код и старые решения в целом выглядят странно и некрасиво? Более того, все это может устареть за считанные годы.
Когда приходится очень быстро бежать, чтобы просто остаться на месте, возникает желание как-то срезать путь, заглянуть немного в будущее, перепрыгнуть пару точек.
Давай попробуем.
Для этого нам необходимо понять принципы, по которым происходит развитие: внимательно рассмотреть пещерные технологии, которые мы использовали пару лет назад, и то, как они превратились в «технологии будущего», которые мы используем сегодня.
Один длинный пример
Несколько лет назад, строя админку фотогалереи на одном сайте, я понял, что привычный тогда подход размещения в виде нескольких входов не так уж и хорош, особенно если учесть, что нужно было загрузить неизвестный и относительно заранее большое количество фотографий.Решением стало создание пяти полей и ссылки «Добавить еще», которая динамически создавала еще одно дополнительное поле.
По предложению коллеги я добавил ссылку «добавь еще 5», и «технология будущего» была готова.
И это было действительно хорошо, какое-то время, после чего в другом проекте я использовал загрузку изображений в архиве.
У нового метода было свое преимущество - нет необходимости выбирать много файлов, и свои недостатки - человеку нужно заранее упаковывать свои изображения (обычно для админки, неприемлемо для фронтенда) и нет возможности контролировать порядок изображений.
Прошло время, и чуть больше года назад та же задача, как обычно, возникла вновь на очередном новом проекте.
Были и отличия: во-первых, на этот раз форма была «для людей», а, во-вторых, максимальное количество фотографий на форму было небольшим (фотографии со временем действительно выросли и набрали вес).
Реализованное решение в итоге было такое — одно поле при заполнении сразу отправляется через iframe, результаты обработки (URL и статистика) подсовываются в скрытое поле в исходном виде и отображаются в виде миниатюры.
Плюсов здесь много, но главными для нас были возможность загружать изображения и формы отдельно (форму можно заполнять во время загрузки изображений, тем самым сокращая время ожидания) и возможность загружать изображения на отдельный сервер.
, минуя сервер приложений.
Обернув все это в виджет, мы избавили себя от необходимости обрабатывать загрузку изображений в этом проекте.
Именно благодаря этому этот метод стал для нас еще одной «технологией будущего» на этот год. Как нетрудно догадаться, через год старое решение нас уже не устраивало и мы решили его обновить.
Во-первых, во всех браузерах, которые это умеют (все кроме IE), поле загрузки файла сделано множественным.
Во-вторых, опять же, где это возможно (везде, кроме IE и Opera), вместо iframe стали использовать AJAX 2 с его междоменной загрузкой файлов, при этом с помощью File API множественный набор файлов делился на отдельные, что ускорило загрузку и упростило серверную часть (не нужно распараллеливать сжатие, не нужно агрегировать ошибки в один результат).
Что ж, на данный момент это звучит довольно круто.
Интерфейс
В своем небольшом рассказе о загрузке изображений я упомянул различные причины и преимущества отдельных шагов, как интерфейсных, так и технических.Теперь отбросим все, что не касается интерфейса, и попробуем разобраться, куда все это девается.
Чтобы отделить интерфейс от всего остального, нужно четко понимать, что это такое.
Что такое интерфейс? Ладно, это слишком сложный вопрос для разминки, давайте зададим другой, более простой.
Когда мы встречаемся с интерфейсом? Общий ответ может быть таким: когда мы имеем дело с какой-то системой (программой, сервисом) и хотим, чтобы она что-то для нас сделала.
Звучит разумно, потанцуем от этого, с небольшой поправкой: система, как правило, является посредником между нами и другими людьми (или между нами и физической реальностью), поэтому ее следует исключить из формулировки, т.е.
мы сталкиваемся интерфейс, когда мы чего-то хотим.
Таким образом: Интерфейс — это преграда между человеком и тем, что он хочет. Чтобы этот вывод и несколько последних фраз не показались мутными и чрезмерными обобщениями, вернемся к примеру с загрузкой фотографий.
Чего хочет человек, когда обращается к этому интерфейсу? Загрузить фотографии на сайт? Не совсем так, точнее это правда лишь отчасти, на самом деле он хочет показать другим то, что видит/увидел сам.
Вторая формулировка более общая и дает свои преимущества - становится очевидным, что и «сайт», и «фотографии» являются дополнительными сущностями, не содержащимися в исходной задаче, если бы можно было реализовать желание «показать другим то, что я вижу».
Без того и другого это было бы победой с точки зрения интерфейса.
Из определения сразу следует, что идеальный интерфейс — это тот, в котором желание пользователя исполняется сразу, без дополнительных действий.
И эти дополнительные шаги и сущности, которые не содержатся в самой задаче, но используются в интерфейсе, и составляют сложность интерфейса.
Уроки выучены
Что ж, усвоив всю эту мудрость, попробуем применить ее к рассказу с картинками.Для наглядности опишем все элементы сложности интерфейса для каждого случая.
0. Что было раньше.
Шаги: выберите файл для каждого изображения в отдельном поле; если полей недостаточно, нужно все повторить.
Дополнительная сущность — максимальное количество фотографий одновременно.
1. Добавляйте поля динамически.
Шаги - выберите каждую картинку в отдельном поле, если полей недостаточно, добавьте их по одной и специальным ссылкам.
Дополнительные сущности — ссылки для добавления полей.
2. Загрузка архива.
Шаги – создайте архив с необходимыми изображениями, выберите в поле файл архива.
Дополнительным объектом является архив.
3. Айфрейм.
Шаги — выберите файлы фотографий по одному в одном поле.
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, научите свое приложение работать с другими — предоставьте API. Вы сами решаете, что вы делаете — очередной (возможно, хороший) сервис или еще один камень в фундамент будущего сети.
Теги: #будущее #интерфейсы #сеть #unix-way
-
Кэдворт, Ральф
19 Oct, 24 -
35 Примеров Дизайна Лонгридов Со Всего Мира
19 Oct, 24 -
Пользователи И Клиенты. В Чем Разница?
19 Oct, 24 -
Использование Раскадровки
19 Oct, 24 -
Давай Включим Музыку С Дивана
19 Oct, 24
