Места в конкурсе я никакого не занял и не заслужил упоминания в статье. Я даже так и не дождался обещанного инвайта на Dribbble… Ну ладно. Видимо моя работа была сочтена «откровенно провальной в плане визуала»…
Шут с ним, с визуалом, но я все же считаю что идеи заложенные мной в проект стоят того чтобы их увидело больше 4 человек (столько просмотров моей работы на behance). Дело в том что сами идеи я развиваю достаточно давно, а конкурсная задача позволяет продемонстрировать их в реальной задаче.
Сразу скажу, что по уровню прорисовки и внимания к деталям — другие работы превосходят мою на порядок. Например, я вообще не отрисовывал список писем, а взял аналог из другого приложения. Вместо этого я рисовал концепт — принципиальную схему работы приложения и описывал принципы по которым оно работает.
Позволю себе цитату из упомянутого поста, я с ней полностью согласен, и в какой-то мере именно такими мыслями я руководствовался во время работы:
Итак. Если вы еще не передумали читать дальше — добро пожаловать под кат)Артем Тройной: Очень жаль, что некоторые дизайнеры не старались придумать что-то совершенно новое, а лишь добавляли категории для сортировки. Это же не тестовое задание при приёме на работу. В таких конкурсах есть возможность придумать, что-то совершенно уникальное, а не то что будет внедрено после конкурса.
На изображении выше показан основной экран моего решения. Визуально — это просто кнопка поиска. Но возможности гораздо выше.
Кнопка становится «ассоциативным элементом» (как я это называю:) — ее теперь можно «применить» к любому элементу на экране и получить логичный ответ.
Перетаскиваем кнопку поиска на имя адресата — получаем все письма от него (и все вложения).
Перетаскиваем на дату — получаем письма за этот день. И так далее.
Смысл идеи в том, что часто нет нужды пользоваться каталогом файлов, поиском, фильтрами, вспоминать язык запросов или полагаться на рекомендательные системы. Достаточно просто уметь находить письма похожие на нужное по каким-либо критериям. И сделать это можно просто перетащив значок поиска на нужный элемент.
Многие типичные задачи сведутся к всего одному действию, например пожелав найти все фотографии во вложениях — достаточно перетащить значок поиска на любую фотографию. Классический подход потребует как минимум перейти к разделу вложений, выбрать поиск по типу файла, указать тип файла «изображения»…
Но что делать если нужно найти фотографии присланные определенным пользователем? Нужен какой-то механизм комбинации запросов.
А если нужно найти скажем pdf-документ, а «образца» под рукой нет? Опять придумывать разделы, списки, группировки, язык запросов и т.п.?..
Все проще. Для начала нужно позволить объединять запросы вместе. Перетащив кнопку поиска на нужного адресата, а потом на любую картинку в выдаче — мы сформируем нужный запрос.
Как быть если «образца» нет? Нужно добавить понимание «связей» между критериями поиска.
Например, если мы ищем по имени адресата, а он в основном присылает счета — логично не заставлять пользователя искать подходящий счет, а сразу предложить такой запрос в виде возможного уточнения.
Или посложнее. Пользователь ищет все письма присланные одним адресатом. Но результатов конечно очень много. Мы можем кластеризировать результат и выделить значимые группы. Например, оказалось, что было много уведомления о заказе билетов и документов в различных форматах. А вот фотографий и уведомлений — не было.
Мы предлагаем «документы» и «билеты» в качестве уточнения. И если пользователь выберет «документы» — возможно новыми дополнениями станут «счета» или «сметы»…
Суть в том что мы не пытаемся решить за пользователя, «что ему нужно» — как делают многочисленные «интеллектуальные помощники». Но и не заставляем его бродить по меню и спискам в поисках нужного пункта.
Наша задача предложить в каждый момент именно те варианты, которые больше всего соответствуют запросу.
Процитирую свою работу:
Представьте, что у вас есть список фильтров по которым вы можете искать. Например: «фото», «документы», «счета», «покупки», «архивы», «задачи», «даты»,… и т.п.
Фильтров может быть очень много, все адресаты могут быть фильтрами, диапазоны дат могут быть фильтрами («последняя неделя», «зима 2014-го») и т.п. С обновлениями программа может научиться определять новые фильтры, например «авиабилеты» или «3D-модели».
Имея перед глазами такой список, можно было бы выбирая фильтры и комбинируя их — легко конструировать сложные запросы. Например «счета от ebay за 2014 год» — это три фильтра «ebay» + «счета» + «2014 год».
Но вот пользоваться списком из сотен фильтров было бы крайне неудобно.
Решение в том чтобы связать фильтры друг с другом ассоциативными связями. Тогда «счета» будут связаны с «документы» и «покупки». «2014» — будет связан с «календарь», а «весна» — с «2014», «2015», «2016» и так далее…
Показывая пользователю только несколько главных фильтров, а также те которые связаны с уже выбранными — получим быстрый и удобный конструктор для построения запроса, буквально в несколько тапов. Это проще чем набирать запрос на экранной клавиатуре, хотя конечно набрать запрос тоже можно (белая строка вверху).
На картинках видно, что связи между фильтрами вычисляются на основе содержимого почты.
Если от admin@ebay.com — в основном приходят новости и счета, то этот контакт будет связан с фильтрами «новости» и «счета».
Фильтр «фотографии» связан с контактом «Андрей» правда чтобы увидеть больше контактов придется немного вытянуть список фильтров.
В заключение скажу, что идеи 1 и 2 — дополняют друг друга. Вместе они образуют интерфейс управления данными, построенный на ассоциациях.
Вместо изучения нескольких экранов, меню, фильтров, настроек и т.п., Пользователь получает всего два интуитивных действия: перетянуть значок поиска на похожий элемент, и воспользоваться «умными» фильтрами для уточнения запроса.
При этом большинство задач решиться уже на первом действии. А второе будет помимо удобства выполнять и незаметное обучающее действие. Ведь привыкнув к набору фильтров, пользователь сможет использовать их даже без подсказок, например, при голосовом управлении.
Сам ассоциативный подход я разрабатываю давно, и здесь просто старался показать некоторые наработки на «живом примере».
Если этот подход вас заинтересует — пишите мне на daniil.bakalin@gmail.com, сейчас идет разработка похожего решения для управления файлами на обычных компьютерах.
Спасибо за то что дочитали)
Даниил Бакалин. 09.2015.
upd.
В комментариях многие написали, что по внешнему виду кнопки не ясно, что ее можно перетаскивать.
Согласен, взять стандартную кнопку, в этом случае, было моим упущением. Просто я старался донести саму концепцию, о превращении кнопки во что-то совсем другое. По сути это вообще не кнопка, а самостоятельный объект. с которым можно взаимодействовать сложнее чем просто «нажать».
В концепции «ассоциативного дизайна», которую я разрабатываю — такие элементы есть нескольких типов. Но суть их всех в том что они принципиально другие. Это не просто плоские картинки которые можно двигать или нажимать. Они могут существовать в виртуальной реальности или скажем в мысленном интерфейсе, или еще какой-то другом.
Я хочу сказать, что сейчас управляя компьютером мы в голове «переводим» свою задачу на понятный компьютеру «язык», в виде последовательности каких-то нажатий, выборов или тапов. Мы привыкли к этому как люди когда-то привыкли к командной строке, и нам кажется это правильным и логичным. Но это нелогично и неправильно. Человек думает образами и ассоциациями, а не кнопками и списками. И эти образы и ассоциации — должны так или иначе присутствовать в интерфейсе будущего.
Я не говорю что мой концепт правильный, или даже, что я двигаюсь в нужном направлении. Просто пытаюсь нащупать что-то за пределами привычных интерфейсов. И хочется услышать комментарии к самой идее.
Представьте что вы пытаетесь объяснить, что такое меню человеку всю жизнь пользовавшемуся только командной строкой. А он придирается что цвет курсора ему напоминает о командной строке, и вообще двигать куском мыла по столу пытаясь попасть в двигающиеся строчки на экране — странно и неудобно…
Ни сколько ни принижаю роли командной строки сегодня. Также как уверен, что сегодняшние интерфейсы останутся в сложных системах и конфигураторах завтра. Но типичные, распространенные интерфейсы должны измениться. Не верится, что то, что есть — вершина развития.
Конечно есть еще голосовые помощники, и хотя сегодня они применимы далеко не всегда, но с развитием ИИ их доля конечно возрастет. Но даже если ИИ станет близок к человеческому, будет ли голоса достаточно?
Скажем вам нужно разработать сайт. Сколько времени займет объяснить как он должен выглядеть другому человеку (по сути написать ТЗ)? А сколько мелочей останется «за кадром»? И на сколько проще создать сайт в режиме диалога, и имея возможность воздействовать на любой элемент при создании? Что проще, сказать «увеличь логотип на 8% и сдвинь влево до пересечения с направляющей объединяющей отступы текста основного контентного блока» — или просто подвинуть логотип?
Что проще, найти нужного адресата путаясь надиктовать правильный запрос (типичный голосовой помощник), или просто увеличить рукой объект «контакты», который при этом разобьётся на кластеры по типу переписки, и просмотрев нужный — выбрать адрес (объекты + ассоциации + голосовой помощник)?.. В общем это тема отдельной статьи. Хочу просто сказать что просто голосом управлять чем-то не так просто. Но и типичные интерфейсы неудобны. Нужно что-то между ними, работающее по принципам человека, но предоставляющего ему новые возможности.
This entry passed through the Full-Text RSS service - if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.
Комментариев нет:
Отправить комментарий