Пещерные технологии будущего

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

    Давайте попробуем. Для этого нам необходимо понять по каким принципам идет развитие: внимательно рассмотреть те пещерные технологии, что мы использовали пару лет назад и то, как они превращались в “технологии будущего”, что мы используем сегодня.

    Один пространный пример


    Несколько лет назад, сооружая админку для фотогалереи на одном сайте, я понял, что обычный на то время подход размещения в форме нескольких инпутов не так уж хорош, особенно, учитывая, что необходимо загрузить заранее неизвестное и относительно большое количество фоток. Решением стало создание пяти полей и ссылки “добавить ещё”, которая динамически создавала ещё одно дополнительное поле. С подсказки коллеги я приделал ссылку “добавить ещё 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.

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

    Комментарии 41

      0
      А как же — отсортировать отобрать и только потом выложить? :)
        –1
        Если речь о синхронизируемой папке, то никто не мешает отобрать и обработать до того как туда складывать. В любом случае, бац и оно уже там — очень удобно. Если бы Google Docs требовал вручную подтверждать отправку или подгрузку изменений он был бы значительно менее удобен.
          –4
          Речь об обработке изображений. Фотошоп и еже с ним =)
        +5
        Google+ — это уже социальная сеть, приложение автоматически синхронизирует фото и видео, приложение работает на устройствах с фотокамерой, есть настройка, которая позволяет сразу делиться всем, что мы сфоткали.

        В итоге остается просто сфоткать и при необходимости обработать.
          +6
          Этак главное искусство фотографа, удалить 90% фотографий, исчезнет.
            0
            Там есть настройка, которая разрешает синхронизироваться только при наличии «вай-вай» или при наличии подключенной зарядки, в итоге у нас есть время для того, что бы грохнуть 99% фото до того, как мы подключимся у вай-фай или к зарядке :)

            Ну и никто не мешает удалить после.
              0
              Я бы добавил: от 95% до 100% в зависимости от автора!
            +28
            Идеальный интерфейс — это интерфейс, которого нет, но его задачи выполняются.
              0
              По ТРИЗ сказано. А можно к примеру создать «атмосферу», или «настроение» с отсутствием интерфейса? Кстати и Купер утверждал, что это одна из задач интерфейса.
                +2
                Идеальный интерфейс — это женская грудь.
                Но она есть.
                Следовательно ваш тезис не совсем корректен.
                  0
                  интерфейс, по-вашему, это то, куда прикладываются фейсом? =)
                –5
                Никогда не обращали внимание, как часто старые интерфейсы, старый код и вообще старые решения выглядят странными и уродливыми?

                До сих пор считаю самым удобным интерфейсом Макось 9. Полиграфисты надеюсь поддержат меня.
                  –1
                  Я юзаю www.uploadify.com/ когда надо позволить юзеру загрузить произвольное количество файлов.
                    +4
                    Загружать файлы — это не то, что нужно юзеру
                      –4
                      Переместить файлы с жёсткого диска пользователя на жёсткий диск сервера — вот что ему нужно. И тут uploadify (или более крутые аналоги) побеждают.
                        +4
                        Наверное, треть пользователей не знает, что такое жёсткий диск, половина не знает, что такое сервер. Это действительно не то, что нужно пользователю.
                          +8
                          “Если бы я спрашивал людей, что им нужно, они бы сказали — лошадь побыстрее.” — Г. Форд.
                            0
                            Ну да, они бы ответили — мне нужно загрузить файлы
                              0
                              Не файлы, а фотки :-)
                          0
                          Ок, это отлично, что вы уже в будуюшем. Мой коммент был просто к слову, для тех, кому здесь и сейчас надо подобный вопрос решить.
                        +2
                        Все это конечно хорошо и отчасти напоминает доклад Ильи Бирмана на 404fest «Интерфейс — зло».

                        Но вот я задаю себе вопрос: использует ли мой пользователь все эти онлайн инструменты?

                        Соц. сети — использует. А вот Flickr, Dropbox и тд? Неужели все люди, которые создают коллажи фото пользуются этими сервисами?

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

                          Ещё один пример, на некоторых сайтах Gravatar — единственный способ получить аватар и ничего, народ пользуется. Через некоторое время даже оценивает удобство.
                          +2
                          Всегда уважал прямую и беспристрастную логику.
                            0
                            Это все хорошо, но ровно до тех пор, пока мы живем в «раю для разработчиков», где каждой задаче соответствует ровно один инструмент. В реальности же, увы или к счастью, всегда есть выбор. Кто-то пользуется фейсбуком, кто-то ВК, кто-то вообще не переваривает соц. сети как явление. Я, например, принципиально не пользуюсь онлайн галереями. Плюс возможен небольшой процент людей, которые первый раз зашли в интернет именно на ваш сайт. Они вообще не знают ничего об этих сервисах.

                            В результате лишние затраты на поддержку собственных велосипедов нивелируются (нам так или иначе приходится их поддерживать), а взамен появляются затраты на поддержку всех эти публичных апи (свои функции интерфейс выполняет и без них).
                              0
                              Вы правы, однако стоит учитывать, что статья относится скорее к «будущему», тогда как ваш комментарий описывает только «настоящее». Вы же не думаете, что через 5-10 лет появится еще двадцать «фэйсбуков» и десять «вконтактов», которые по-братски поделят аудиторию интернета? Развитие такого сценария мы наблюдаем уже не один год, но всему есть предел.
                                +1
                                В том то и дело, что я так думаю. Сомнительно, что за 5-10 лет столько людей откажутся от идеи «сделать такое же, но лучше». И это хорошо — здоровая конкуренция на пользу конечным пользователям.
                                Ту же самую ситуацию мы наблюдаем на рынке операционных систем, например. Когда-то была (почти) только винда, и все стремятся ее теперь вытеснить. Рынок будет только расширяться, судя по тенденциям последних 10 лет.
                                  0
                                  Понял вашу позицию, и кажется мы говорим слегка о разных вещах. Я немного неправильно изложил свою позицию. Постараюсь переформулировать.

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

                                  Мечтать конечно не вредно, но причин сомневаться в таком «будущем» у меня нет.
                                    0
                                    Очень надеюсь, что так когда-нибудь и будет. Хотя на мой взгляд это все же несколько утопично :)
                              +6
                              А потом продвинутый пользователь, столкнувшись с подобной «технологией будущего», ждет, пока все эти проапгрейженные скрипты загрузятся на его девайсе, затем долго разбирается, какое действие привязал умник-разработчик к правой кнопке мыши и почему теперь нельзя посмотреть свойства загружаемого файла, и если все это происходит где-нибудь в дороге с неустойчивой мобильной связью, поминает такого разработчика незлым тихим словом.
                                +5
                                Прикольно. В блоге «Интерфейсы» топик с отсутствующими картинками )
                                • НЛО прилетело и опубликовало эту надпись здесь
                                    0
                                    Я не хотел подковырнуть, пусть автора не обижает это ) Статья достойная.
                                    0
                                    Вот-вот! Я вот тоже зашел сюда прежде всего поглазеть на «интерфейс будущего», а тут читать заставили. Ни тебе хлеба ни тебе зрелищ:) Благо статья интересная
                                    0
                                    Самый простой пример — «устаревшие» интерфейсы командной строки и «современный» PowerShell.
                                      –1
                                      «Интерфейс — это препятствие между человеком и тем, что он хочет.»

                                      Это смотря как интерфейс спроектирован и что это вообще такое :)
                                      Скорее, проход к желаемому… а дальше вопрос — насколько прямой и удобный :)
                                      • НЛО прилетело и опубликовало эту надпись здесь
                                          0
                                          А потом стронний сервис прекращает работу или меняет api/термсы и все.
                                          Начинай с начала.
                                            –1
                                            Ничто не вечно, и нет совершенных решений. Ваш интерфейс без стороннего сервиса устареет гарантированно
                                              0
                                              Вот только:
                                              1) поменять свой код зачастую будет проще
                                              2) сделаю это можно тогда, когда это будет необходимо и(или) когда будет возможность.
                                              3) он будет работать несмотря на его «старость», а сторонний просто прекратит.
                                              Для короткоживущих поделок это может быть и без разницы, но для долгосрочных проектов или проектов отдаваемых заказчику без поддержки, это может превратиться в бесконечные поломки и переделки.
                                              Я не против таких решений, но не стал бы их использовать в серьезных проектах (ну или как минимум делал бы альтернативный вариант).
                                                0
                                                1) Набрала новая популярность новая мобильная платформа. Выпустить свой мобильный клиент под него будет проще? Сомневаюсь. Поддерживать кучу клиентов тоже сложно. Плюс даже если вы всё это сделали, то более общий клиент скорее окажется у пользователя, чем ваш, минус лишняя установка.
                                                2) Большинство сайтов не имеет мобильных версий, мобильных клиентов, какой-то ещё функциональности из-за того, что руки не доходят. В то же время, прикрутить стороннюю систему комментариев от Disqus или даже просто из Вконтакте — плёвое дело.
                                                3) Если проект не развивать, то он умрёт. То что делается для заказчика без поддержки — не серьёзный проект, по крайне мере, не настолько насколько проект, делающийся для себя и для людей. Если, конечно, нужно сделать что-то что не требует развития и требует минимальной поддержки, то это действительно повод сокращать зависимости. Всякий подход имеет свои ограничения, подход интеграции, который я предлагаю, действительно не блещет в таком случае.
                                            +1
                                            Вспоминаются слова «Пик развития любой технологии — это отсутствие надобности в ней».
                                            Автор утерян в истории.

                                            Думаю, относительно интерфейса, в какой-то мере, также можно применить подобное утверждение, хоть оно и будет не совсем корректным, т.к. отсутствие интерфейса — это тоже интерфейс (:

                                            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                            Самое читаемое