Рубрика «проектирование взаимодействия» - 2

План статьи:

  1. Этапы проектирования интерфейса;
  2. Пользователи;
  3. Взаимодействие и требования;
  4. Инфраструктура;
  5. Детализация;
  6. Инструменты для создания прототипов.

Любое сложное действие можно декомпозировать на более простые. Когда не представляешь, как решить задачу нужно пытаться ее разбивать на простые до тех пока не поймешь, что нужно делать. Проектирование интерфейсов — трудная задача, поэтому декомпозируем ее на этапы:
Исследование -> Моделирование пользователей -> Выработка требований -> Определение общей инфраструктуры -> Детализация -> Обсуждение.
Читать полностью »

В последние несколько лет крупные веб-сервисы (Google, Яндекс, Amazon и т.д.), целенаправленно идут в сторону предоставления пользователям персонализированного контента на основе анализа истории запросов и некоторых других метрик, например, геопозиционирования. Вместе с недавними событиями, связанными с проектом PRISM, Сноуденом и безопасностью персональных данных, в определенных кругах такой подход даже начал провоцировать истерию, главные тезисы которой можно свести к следующим:

  • интернет перестал быть для всех одинаковым;
  • пользователям теперь можно показать только то, что нужно, без права выбора;
  • за всеми нами следят.

Компании и жертвы истерии все чаще говорят о персонализированном контенте, когда каждому из пользователей предлагается информация наиболее релевантная к его потребностям, которые были проанализированы системой. Следующим шагом в этом направлении с точки зрения customer experience должна стать модель предиктивных интерфейсов, в которой персонализируется не только контент, но и сам способ его подачи. В итоге, для двух разных пользователей одно и то же ПО может выглядеть по-разному.

Об этом и поговорим.

Читать полностью »

Что не так с нашим EsheDeshe?

Этим летом мы в компании Aidem совместно с партнерами запустили проект интернет-магазина совместных покупок EsheDeshe.ru. Задача стояла сделать совместную покупку удобной (сейчас это в 99% форумы, на которых нормальный человек без «поллитры» не разберется).

Проектирование UX и UI — наша специфика, поэтому начали с изучения и аналитики рынка и схожих проектов. Разработали персонажей, концепцию, запрототипировали, описали логику, поведение, определили требования к дизайну, материалам и пр. — получили спецификацию формы и поведения (60+ страниц). Заказали разработку айдентики и макетов сайта у хорошего дизайнера, ушли в разработку, параллельно начав заключать договора с поставщиками и партнерами.

В магазине мы используем несколько вспомогательных сервисов (определение геопозиции покупателя, сервис расчета стоимости доставки разными транспортными компаниями, сервис отправки смс и другие).Читать полностью »

Начиная с версии 5.4.0, в PHP появится новая конструкция языка — трейты (traits), реализующая возможность использования примеси (mix in). Механизм примесей является еще одним механизмом повторного использования кода и присутствует в том или ином виде в других языках, например, Ruby, Python, Common Lisp, etc.

Примеси позволяют использовать существующий код при реализации поведения классов, избегая при этом многих проблем множественного наследования. Взаимодействующие друг с другом примеси, объединенные в отдельные программные библиотеки, представляют собой очень мощный инструмент при реализации сложной логики.

Следует отметить, что реализации примесей в PHP существуют как минимум с версии 4.0.1, и в настоящее время присутствуют, чаще всего под именем behavior, в ряде популярных фреймворков, например, в Yii, Symfony, Doctrine, CakePhp, Propel.

Цель статьи — продемонстрировать и сравнить несколько основных подходов к реализации примесей в PHP до версии 5.4.0, базирующихся только лишь на функциях самого языка и не использующих сторонние расширения, как-то, например, функцию runkit_method_copy из PECL runkit.
Читать полностью »

Некоторое время назад я выступал на конференции ISDEF и рассказывал о том, что бывает, когда программисты вынуждены заниматься проектированием интерфейсов.

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

Суть проблемы

Управление продуктами: Увидеть продукт глазами пользователяПримеры того, как замечательно программисты могут проектировать UX, попадаются сплошь и рядом.
Например, это замечательная форма заполнения истории из трудовой книжки на портале гос. услуг (про неё я уже писал), которая убивает сессию через 15 минут после открытия и заставляет пользователя перегружать страницу с потерей всех данных.

Это чудесные формы по заполнению совершенно непонятной информации, как на рисунке слева.

Это закрывающиеся окошки текстового редактора, которые даже не пытаются предложить сохранить текст, на который несчастный пользователь потратил два часа своей жизни.

Мне очень грустно работать с таким ПО. Я понимаю, что его писали первоклассные специалисты, я допускаю, что код этих систем тоже в полном порядке. Однако я не стану ими пользоваться. В крайнем случае, если у меня не будет выбора, я всё-таки буду «плакать, колоться и жрать кактус», но при этом окончательно испорчу карму разработчикам своими мало литературными комментариями.
Читать полностью »

From Idea to App

В первой и второй частях статьи мы рассмотрели четыре первых шага на пути проектирования приложения:

  1. Определение целевой аудитории
  2. Формулировка цели приложения
  3. Отбор ключевых сценариев
  4. Планирование навигации

В третьей части мы поговорим о том, как предполагаемая функциональность приложения должна пробрасываться через интерфейс приложения: где ее следует завязывать на системные решения, где использовать специальные элементы управления, а где ее нужно интегрировать в контент.
Читать полностью »

После появления статей типа "Я не знаю ООП" — возникает желание внести ясность, «сорвать покровы» и «докопаться до истины».

Принципы объектно-ориентированности

Обычно выделяют (читай: на собеседовании требуют назвать) четыре «принципа объектно-ориентированного программирования»: абстракцию, инкапсуляцию, наследование и полиморфизм.

На мой взгляд (не говоря о том, что абстракция и полиморфизм могут быть запросто отнесены к подразделам наследования), принцип тут один, в общем, тот же самый, что при проектировании баз данных: представление всего в виде объекта — некоторой штуковины со свойствами. Набор обычно бывает фиксированным, и тогда говорят о классе объектов, а даже если понятия класса и нет, то наличие свойств с определёнными названиями подразумевается логикой программы, т.е. нечто типа класса в виде некоего минимального набора свойств всё равно присутствует. В общем, воззрения восходят к давнему С-шному/паскалевскому типу данных struct/record. Потом к этому добавили немного «функциональности» (в смысле функционального программирования): значением свойства может быть функция, причём такая, которая имеет доступ к самой структуре/записи, значением одного из свойств которой она является. Сей феномен, в лучших традициях немецкого латиноязычного нейминга (когда опция называется «вариантом», а степень числа — «потенцией»), назвали «методом». Желание повторно использовать код, в сочетании с представлением каждого предмета как некоего подобия паскалевской «записи», привело к появлению концепции «наследования».Читать полностью »

В конце апреля я делал доклад на РИФ 2012 про этапы проектирования пользовательского интерфейса. Так как видео нет, попробую представить доклад в виде слайдов с моими комментариями.

UX

Я расскажу как процесс разработки сайта или приложения выглядит с точки зрения дизайнера. Как вы сможете только за счет интерфейса улучшить впечатление пользователя от вашего стартапа.

Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js