Рабочий процесс Mobile First и RWD и взаимодействие с клиентом

Рабочий процесс нашего агентства по созданию веб-сайта обычно состоит из:

  1. обсудить контент-дизайн с клиентом
  2. создаем каркасы (с опциональным, в зависимости от клиента, согласованием)
  3. мы создаем один или несколько пиксельных "макетов" в иллюстраторе/фотошопе
  4. клиент утверждает с исправлениями
  5. вернуться к шагу 3
  6. начать кодирование.

Теперь, когда мы медленно приближаемся к 2010 году и размышляем о RWD («Отзывчивый веб-дизайн») и «сначала мобильные устройства», становится ясно, что наш рабочий процесс не будет работать без дополнительных затрат для клиента ( учитывая, что технические накладные расходы на CSS не НАСТОЛЬКО велики).

Каков наилучший рабочий процесс, который работает с RWD и mobile first? Кроме того, есть ли какие-либо специальные инструменты, которые могут помочь?

@Lauren Ipsum, откат. Это был самоуничижительный юмор. RWD на самом деле не новинка, и мы немного поздно реагируем на это...
RWD = адаптивный дизайн ширины? Возможно, стоит прояснить это.
@e100 Отзывчивый веб-дизайн. Я сделаю это более ясным
@ Роман, я исправлен. Юмор был слишком тонким для меня, и я пропустил его. Извините, что наступил на вашу шутку. :) Я также нахожусь в середине проекта для клиента, обсуждая, что компании действительно только начинают заниматься мобильным дизайном в следующем году (2013), поэтому, с моей точки зрения, это не «поздняя реакция на что-то новое».

Ответы (3)

Отбой - шаги 3-4. Их необходимо удалить, а процесс утверждения/проверки выполнить ПОСЛЕ начала кодирования.

Посмотрите на Agile Development и Lean UX:

http://uxdesign.smashingmagazine.com/2011/03/07/lean-ux-getting-out-of-the-deliverables-business/

+1. Это то, что интересует меня больше всего. Но на самом деле я не могу полностью убрать графические результаты... Менеджерам проекта это совсем не понравится (им придется НАМНОГО больше выступать посредниками между командой и клиентом). После некоторых исследований я узнал о прототипах стилей и плитках стилей . Думаю, я пойду в этом направлении.
Конечно, хорошо делать визуальные графические результаты, но убедитесь, что они а) не считаются идеальными по пикселям и б) дайте клиенту возможность оставить отзыв, но не делайте это контрольной вехой.
Сброс шагов 3 и 4 звучит великолепно в теории, но я видел, как много времени разработчиков тратится впустую, следуя этому формату. В конце концов, быстрее всего смоделировать статичный визуальный элемент, чем кодировать интерактивную страницу. Вы можете построить свою композицию, больше похожую на плотный каркас, чем на образец с идеальной точностью до пикселя. Вы бы не убрали 3 и 4, вы подошли бы к ним с другим мышлением.

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

1.обсудить контент-дизайн с клиентом

2. создаем каркасы (с опциональным, в зависимости от клиента, согласованием)

2a.для настольных компьютеров (классический)

2b.для планшетов

2c.для телефонов

3. мы создаем трехпиксельные идеальные «макеты» в Photoshop

4.клиент одобряет/с исправлениями

5а. вернуться к шагу 3

5c.begin кодирование для всех трех значений ширины

Итак, вы, по сути, говорите, что нам не нужно менять наш рабочий процесс?
Во всяком случае, ненамного. Но вы должны различать сайты, которые должны хорошо выглядеть на мобильных устройствах, и мобильные приложения, у которых другой рабочий процесс.
Это только усложняет ту же проблему... что утверждение статических документов является очень несовершенным/непрактичным процессом для веб-дизайна.
Тогда ваши вайрфреймы должны быть кодом, а не статичными. Создавайте черно-белые каркасы с заполнителями для текста и изображений.

Рабочий процесс

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

Что меняется, так это то, как вы анализируете карту данных. Вы должны начать с каждой части данных/контента, а затем перейти к уровням приоритета. Есть четыре широкие категории:

  1. Все устройства
  2. Какое-то сочетание трех
  3. Только для рабочего стола
  4. Нигде

Сначала мобильный?
Мобильный телефон на самом деле не является «первым» в этом подходе: вы рассматриваете все сразу. Имея это в виду, я думаю, что самое большое изменение рабочего процесса произойдет на этапе 1: вам нужно разработать карту контента/данных (что вы уже делаете), а также решить, что когда отпадает.

Отзывчивый дизайн

Принятие решения о разработке RWD действительно зависит от проекта. Адаптивность идеально подходит для контентных сайтов. С другой стороны, в мире ecomm сайты и приложения для конкретных устройств по-прежнему играют главную роль. Я не думаю, что мы выяснили, насколько отзывчивость действительно соответствует проблеме ecomm. (Честно говоря, я не думаю, что мы разобрались с ecomm на мобильных устройствах в целом, за исключением самых простых сценариев, но это тема для другого дня.)

Вне кода решение быть отзывчивым или нет в любом случае не сильно меняет ситуацию. Вам еще предстоит вайрфреймить и скомпилировать все три (или четыре... спасибо мини-планшетам!).

Рабочий процесс Mobile First и RWD и взаимодействие с клиентом
СпросиСетьПолитика конфиденциальности1y, 0v