Как построить разработку дизайна очень большого и долгого проекта

Когда проект большой, дизайнеров над ним работает много, одновременно и очень далеко друг от друга — постоянно возникают проблемы.



Представим ситуацию. Есть не очень опытный проект-менеджер. На нем висит большой проект и три дизайнера, которые готовые над этим проектом поработать. Позвольте их представить — Вася, Лена и Петя (слева направо на картинке). Немного повысим уровень сложности нашим ребятам. Пусть все они находятся в разных городах, то есть за соседними столами не сидят, на пятничные попойки обеды вместе не ходят и иначе как через мессенджеры и почту связаться не могут. Проект большой и запланирован не на один месяц. Заказчик любит часто изменять свои решения или придумывать новые фичи.

Посмотрим как они выкрутятся?

Безусловно, работа дизайнеров над любым проектом начинается с подробного изучения ТЗ, создания прототипа и его согласования. Мы этот шаг опустим, т.к. на нем проект-менеджеру (в большинстве случаев) хватило бы и одного дизайнера.

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



Менеджеру пора задуматься об очевидных вещах, ведь у каждого дизайнера свой неповторимый стиль. Даже самых подробных эскизов или прототипа порой недостаточно, чтобы у трех независимых специалистов получились страницы в одинаковой стилистике (если дизайн не под bootstrap, конечно же :-). Решение этой ситуации приходит неожиданно и поражает своей простотой: пусть Вася, как самый опытный дизайнер, нарисует главную страницу, а Лена и Петя нарисуют свои по ее образу и подобию.

Менеджер рвет на себе волосы, ведь это означает 16, а то и 32 человеко-часа простоя! Но другого выхода нет. Лена и Петя отдыхают, пока Вася трудится над главной страницей. Вот наконец макет готов, согласован с заказчиком и отдан в качестве инструкции по стилистике Лене и Пете. Сердце проект-менеджера замерло еще на пару дней, но… чуда не произошло:



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

И опять проект-менеджер рвет на себе волосы, прикидывает как наверстать упущенное время. Возможно он даже подаст объявление о поиске дизайнера с навыками фотошопа и телепатии. Однако решение опять не заставляет себя долго ждать. Пусть Вася нарисует UI kit со всеми возможными элементами сайта. Отталкиваясь от него мы будем рисовать все внутренние страницы!

Итак, потрачен еще один Васин день. Лена и Петя берут UI kit, главную, эскизы своих страниц и берутся за дело. На выходе получаются два шикарных и ровных макета:



Менеджер и Вася рукоплещут. Заказчик доволен, как кот, объевшийся сметаны. Теперь все пойдет своим чередом, наконец-то началась Работа. Страницы согласуются одна за одной. Сроки подтягиваются. Но не тут то было! Несколько страниц заказчик не заапрувил.

Пора снова включать «думалку». Ведь если любой из дизайнеров внесет изменения в какие-то элементы своей страницы — будь то кнопка или хлебные крошки — к остальным страницам она не подойдет и UI kit уже не будет актуален. Некоторые элементы конечно можно брать из исходников разных дизайнеров. Однако, количество макетов-в-которых-актуальная-кнопочка будет расти пропорционально количеству несогласованных страниц. Уследить за ними будет не так-то просто. Пропустил денек-другой, не получил сообщение в скайпе — элементов накопилось уже штук 10. Все уж и не вспомнить, вроде Вася Пете отправлял… В конце-концов дизайнеры запутаются сами и запутают заказчика. Многостраничный сайт превратится в ад для верстальщиков и программистов.

Проект-менеджеру приходит в голову отличная мысль: после внесения правок в макет и окончательного согласования Вася вносит соответствующие правки в UI kit. Потом сообщаем всем дизайнерам об актуальных изменениях и они вносят правки каждый в свои макеты. Вот и готовый подход вырисовывается:



Вася нарисовал классную промо-страницу, кнопки и изображения с которой очень понравились заказчику, и теперь он хочет видеть их на всем сайте. Применяем ту же схему. Вася готовит UI kit, отдает его Лене и Пете и они «причесывают» свои макеты. ОК

А теперь коротко о проблемах такого подхода и о том, как их можно решить



  1. Большая нагрузка на ведущего дизайнера группы на начальном этапе разработки и в процессе внесения правок, т.к. он выступает в роли «модератора» UI kit-а. В принципе каждый дизайнер может сам вносить изменения из своих макетов в UI, но тогда есть шанс потерять стилистику. Кто-то все равно должен за этим следить.
  2. Сдача страниц. Необходимо фильтровать страницы с одинаковыми элементами и согласовывать их вместе. Иначе изменения в элементах могут летать от дизайнера к дизайнеру и заметно тормозить работу.
  3. Особо сложное планирование. Запланировать большой проект по дизайну сразу на несколько человек, да еще с учетом всех возможных элементов и их комбинаций на разных страницах может быть довольно сложно. Однако говорят что хорошо спланированный проект превышает сроки в три раза, а плохо спланированный — в восемь. Поэтому не жалейте времени на начальных этапах.
  4. Самодеятельность. Многим дизайнерам кажется что при таком подходе они превращаются в «операторов фотошопа», ведь им уже ничего придумывать не надо — все элементы нарисованы, скетчи сделаны. Менеджеру будет стоить больших усилий бороться с вольнодумством.


Что ж, вернемся к нашим героям.



Немало воды утекло со времен первых многострадальных страниц. Теперь общее количество макетов исчисляется десятками. И вот тут-то Васю, Лену, Петю и доблестного проект-менеджера ожидает серьезное испытание. Заказчик передумал. То есть не так — он передумал передумывать. Помните ту промо-страницу, красивые кнопочки и иллюстрации с которой разошлись по всему сайту? Так вот, ребята, верните все обратно.

Дизайнеры и менеджер заслоняют лица руками как Патрик Стюарт, ведь ничего из старых макетов не сохранилось. Новые страницы, нарисованные после этой правки все равно пришлось бы исправлять, но если бы старые сохранились — время на исправление можно было бы смело уменьшить, скажем, вдвое.

Менеджер призадумался. А вдруг заказчик выкинет такой фокус еще раз? Конечно, теперь надо быть умнее и сохранять старые копии макетов. Но у каждого дизайнера они будут накапливаться в разных хитрых папочках. Плюс переданные от одного к другому макеты и несколько штук UI kit-ов, которые уже непонятно к каким страницам подходят. И пока ребята вносят правки, к нему приходит решение:



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

У такого «программерского» подхода тоже есть свои минусы:



  1. Конфликты SVN и PSD. По своему личному опыту могу сказать, что коммиты макетов, над которыми в данный момент ведется работа могут вызывать конфликты. Возможно это связано с тем, что у меня руки не оттуда растут, а возможно с RLE-структурой файлов PSD. Решить можно с помощью SVN lock для тех файлов, над которыми ведутся работы или для тех, которые ожидают согласования.
  2. Сложность в освоении для дизайнера. Даже многие опытные дизайнеры ни разу не пользовались SVN-клиентами, а у тех кто пользуется можно видеть все те же папочки с названиями jpg, psd и 2012-10-25. А еще пропущенные коммиты и апдейты. Выход — жесткий контроль со стороны менеджера за актуальностью версий.
  3. Отсутствие наглядности и возможности быстро просмотреть историю правок и изменений. Для того, чтобы вернуться к старой версии какого-то одного исходника придется проделать ряд манипуляций, которые для дизайнера можно приравнять к балету для тракториста. Решением был бы админ, следящий за правильностью выполнения коммитов и откатывающий макеты до старых версий в случае форс-мажоров.
  4. SVN — не самая быстрая вещь, а макеты — не самые легкие файлы. Пропущенные несколько дней и десяток новых версий файлов могут обернуться для дизайнера достаточно долгим апдейтом и потраченным на ожидание рабочим временем.


Какой выход?



Есть дизайнерский SVN-клиент Timeline от PixelNovel. Он помогает визуализировать потоки изменений в макетах. Недостатки у этого решения тоже есть. Например цена. Лично для меня 100 $ довольно значительная сумма. Ну и минус в том, что репозиторий все равно придется настраивать и от конфликтов с исходниками Timeline тоже не застрахован.

Еще одно решение — Pixelapse на который был небольшой обзор на хабре. Ребята постарались на славу, SVN тут и не пахнет. Это облачный сервис, в котором можно возвращаться к старым версиям файлов. Посредством веб-интерфейса просматривать и комментировать их. Еще можно расшарить исходники со всей историей для других пользователей или опубликовать на суд сообщества pixelapse свою работу. Недостаток — маловато места в бесплатной версии, всего 1 ГБ. А дальше 20 баксов в месяц за 50 ГБ.

Лично мне, как дизайнеру, больше всего симпатизирует обычный подход — без заморочек с SVN и облаками, но с актуализацией UI + поэтапным планированием разработки дизайна. SVN не всегда себя оправдывает. В таких случаях на него уходит больше времени, чем он экономит в конечном итоге. Но и про «щит хэппенсы» тоже забывать не стоит.

Если у вас был какой-то опыт в организации и синхронизации работы нескольких дизайнеров над одним проектом — очень прошу поделиться.

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

P.P.S. Если честно, не ожидал такого внимания к статье. Спасибо всем за комментарии, подкинули материала для изучения на пару недель так точно.

UPD: Спасибо ребятам, которые поделились системами версионирования и плагинами для работы с общим UI. Процитирую некоторые чтобы далеко не ходить:

layervault.com — дизайнерская система версионирования. Кстати, есть 30 дней триала.

www.adobe.com/ru/products/adobedrive/features.html — Adobe Drive, собственно издательская и не только система из первых рук. Заточена под Creative Suite.

www.teamwox.com — облачная система управления документооборотом с поддержкой версионности. Есть триал-период в 2 месяца.

www.canlinkit.com — плагин, позволяющий подключить стороннюю PSD с UI kit, и актуализировать ее прямо внутри макета нажатием хитрой кнопочки.

Перезалил картинки на habrostorage, извините ребят, руки не доходили
AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее
Реклама

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

    0
    Спасибо, что поделились. Тема актуальная. Надеюсь, в комментариях поделятся опытом и инструментарием
      +8
      Вам нужна vcs заточенная под хранение и работу с psd-файлами.
      Первое что нагуглилось — layervault.com/

      UPD Не надо версионировать бинарники инструментом заточенным под версионирование текстовых файлов — это действительно ад.
        0
        За ссылку спасибо, а насчет версионирования PSD файлов через SVN — так уж повелось, в конторе, в которой я раньше работал повсеместно использовался SVN, и одно из требований было чтобы и аналитики и верстальщики имели через него доступ к исходникам. Специально под исходники никто бы не стал заводить издательскую систему с поддержкой версионности, да еще обучать ей пользоваться половину отдела.
          0
          Я не знаю, честно говоря, как обстоят дела с psd, но у инженеров есть свои vcs, которые умеют делать диффы не на основе строк в текстовом файле или последовательностей байт, а на основе семантики конкретных форматов файлов.

          Вообще попытки организовать распределенную работу (да и не распределенную) над одним проектом без автоматизированного версионирования в наше время — это всегда резкое увеличение издержек на проект.
            +1
            А собственно зачем далеко ходить — www.adobe.com/products/adobedrive/features.html?
            0
            Кстати у LayerVault процесс регистрации и установки такой крутой, что можно просто так его пройти
            0
              0
              Для сохранения версий документов можно использовать TeamWox
              — разворачивается и ставится быстро,
              работают все сотрудники через веб-интерфейс,
              до 10ти юзеров бесплатна. Есть возможность делать бэкапы.
                +1
                Я вижу выход только в том, чтобы делать макеты не в PSD :-(
                  0
                  Если бы все было так просто. Дизайнеру слезть с одного редактора на другой сопоставимо по сложности с изучением нового языка программистом.
                    0
                    еще сложнее :) сам с psd не могу слезть
                      0
                      Изучать языки не такая уж большая трудность. Практически везде одни и те же ключевые слова. Немного в синтаксисе разобраться и все.
                      Куда более сложная задача, это изучение технологий, паттернов и фреймворков.

                      Поэтому, если дизайнер понимает как работает инструмент (фотошопошный) и для чего он использует фильтры, а не «потомушто так на ютубе показали», думаю, гимп освоить труда для него не составит.
                        0
                        Да, с фотошопа на гимп согласен — не проблема. А вот например с растра (фотошоп) перескочить на вектор (иллюстратор), или начать сразу верстать прототип на бутсрапе или в Dreamweaver — для многих может оказаться большой сложностью.
                          0
                          Так фотошоп и иллюстратор это как раз разные технологии. Точно так же как функциональные языки и объектно-ориентированные. Совсем другой подход.
                          0
                          о боже этот горячечный бред про «немного в синтаксисе разобраться» до сих пор плюсуют?
                            0
                            Это конечно сильно приукрашено. Но разбираясь в паскале, несложно разобраться и в Си, к примеру. Конечно, есть свои особенности. Чего-то не будет в новом языке, а что-то будет и в новинку. Практика наше всё.
                            А вот знание OpenGL в разработке на Django вам вряд ли поможет.
                              0
                              1) Похожих языков мало. 2) Знание похожего языка только даёт представление о том, что примерно может делать другой язык. Никаких «несложно разобраться» с Паскаля на СИ нет. А базовом паскале, например, и в помине нет указателей, а на Си всё на них построено. Понять эту концепцию новичку — это вам не «немного синтаксис подучить».

                              Я уж молчу про необходимость знания экосистемы языка, чтобы написать что-то выходящяя за рамки Hello World
                                0
                                Много ли новичков вы обучили, что бы утверждать это? При знакомстве с С на первом курсе из группы в 30 человек лишь единицы не сразу вникли в указатели. Для остальных же особых трудностей не составило. Секрет в том, что сначала было бы неплохо прослушать курс лекций по архитектуре компьютера. После этого вопросы типа «Что такое адрес?» отпадут сами собой. Наверняка вы делаете оценку, исходя из личного опыта. И это правильно. Но ваш опыт не единственный.
                                  0
                                  Пытаетесь выиграть спор пусть даже передергиванием? Обучение с учителем и как вы сначала написали «немного разобраться в синтаксисе» — это две разные галлактики.
                                    0
                                    Сейчас речь идёт именно об указателях. Я привёл пример из своей жизни. Не так страшен чёрт, как его малюют.
                        0
                        Надеюсь, что Adobe сделает в следующей версии фотошопа внешние смарт объекты. Это бы все решило.
                          +1
                          Помилуйте, из CS6 и так сделали комбайн. Со сторонними смарт-объектами функционала в разы прибавиться. Да и тем более — пусть будут сторонние смарт-объекты, но где-то же они должны храниться и версионироваться? + многие исходники после импорта обновленных смарт-объектов будут вести себя непредсказуемо. Придется все равно проходиться ручками. Сомневаюсь что будет особый профит по трудозатратам.
                            +3
                            Точно так же как и в indesign.
                            Именно из за подключаемых ресурсов многие переходят на indesign в веб отрасли.
                            Это конечно оправдано именно в больших проектах.
                            В Индизайне большие журналы верстат и там особых проблем с версиями нет — закинул папку с ресурсами в любой контроль версий и все.

                            Естественно придется ручками проходить если размеры будут меняться. Но вот заменить ссылку в смартобъекте футера или изменить верстку сайдблока новостей на всех 20 мкетах — было бы плевым делом, а не таккак сейчас.
                              +1
                              Рисую в Индизайне.
                              Все как вы сказали.
                              Красота.

                              + стили для параграфов, букв, объектов и таблиц, сетки, якоря и много всего для работы с текстом (из которого, как известно, на 90% и состоит дизайн).
                          +2
                          Я не вижу альтернатив.
                          +1
                          Timeline — прекрасный инструмент! Уверен, что на фоне бюджета проекта, над которым работают 3 графдизайнера, 99 доларов за лицензию — это petty cash.
                            +10
                            Dropbox умеет восстаналивать старые версии файлов на бесконечное количество шагов в прошлое (не затирая при этом актуальные, кстати).

                            А в целом всё упирается в то, что продажники продали клиенту неограниченное количество часов для достижения неопределенной цели за фиксированное количество денег. Если бы так работали рестораны, вы как заказчик могли бы заказать любое блюдо (которое готовится 2 суток, а ингредиенты стоят $1000), отщипнуть кусочек и сказать — нет, хочу такое же, но варёное, а не жареное. А когда принесут варёное (ещё 2 дня, ещё $1000 затрат для поваров), сказать — да, отлично, только соль из него уберите. И в догонку (где-то посередине очередных 2 дней на переделку) — а зажаристая корочка всё-таки была неплоха, давайте варёное, без соли, но с корочкой.

                            Но почему-то мир ИТ-разработки и вебдизайна работает примерно по описанной мной схеме и считает этот BDSM нормальным.
                              0
                              Dropbox конечно вещь хорошая, но у него отсутствует визуализация версионности дизайн-макетов, как в том же Pixelapse например.
                              почему-то мир ИТ-разработки и вебдизайна работает примерно по описанной мной схеме и считает этот BDSM нормальным.
                              Идея была показать не идеальный образец управления проектом, а именно все подводные камни. Для этого понадобился вымышленный «не очень опытный менеджер».
                                0
                                ssneg — далеко не весь мир ИТ-разработки такой, как вы его живописуете. Проблема существует, на самом деле, очень сложно продать графический дизайн по T&M — слишком дорого и субъективны критерии приемки работ. Но многие компании стараются продавать по максимуму T&M и им это удается.
                                +1
                                Многим дизайнерам кажется что при таком подходе они превращаются в «операторов фотошопа», ведь им уже ничего придумывать не надо — все элементы нарисованы, скетчи сделаны. Менеджеру будет стоить больших усилий бороться с вольнодумством.

                                Неизбежное следствие процесса углубления разделения труда
                                  –17
                                  Вася с маком молодец, а был бы у него ноут леново и ктобы знал как повернулась эта история. Ага?

                                  Тоже как-то с одним знакомым (тоже дизайнер во всей поля) обсуждали его адское пристрастие к продукции Apple (у меня самого mac mini дома, если что).
                                  — iMac — понты
                                  — Нет, iMac — это необходимость!
                                  — Окей, допустим OSX это очень важная компонента, допустим, хотя я так лично не считаю, но что тебе мешает купить mac mini + 27-дюймов монитор? Характеристики теже.
                                  — Но матрица не та.
                                  — S-IPS? Далааааадна? Ah-IPS стоит порядка 15-20к, куда круче технология, сытнее.
                                  — Но моноблок!
                                  — Ага… моноблок это очень важно и совсем не понты, точно.

                                  Не ну правда, достали уже.
                                  Компьютер это инструмент, а молоток привезенный из кореи — останется им, даже если маркировка и дизайн сделает именитая американская корпорация.
                                    +4
                                    Очевидно же, что мак у Васи не потому, что он такой молодец и мегадизайнер, а просто, чтобы придать персонажу индивидуальность.

                                    Отличные иллюстрации, всегда бы так.
                                    • НЛО прилетело и опубликовало эту надпись здесь
                                        +1
                                          0
                                          Apple mac mac? Macbook air iphone!
                                        +2
                                        Замечательные иллюстрации к статье, приятно читать и смотреть, спасибо!

                                        По поводу перелинковки смарт-объектов — есть выход, хоть и немного кривой. Существует плагин CanLinkIt с помощью которого можно инклудить другие файлы в psd. Воркфлоу следующий —
                                        1. Делаем общий UI kit;
                                        2. При помощи плагина вставляем в один из слоев страницы наш файл c элементами интерфейса, маской показываем только нужный элемент;
                                        3. При обновлении файла UI kit просто нажимаем кнопочку refresh в плагине и все;

                                        Возможно есть и более элегантное решение, я пока не нашел.
                                        Рекомендую к прочтению вот эту статью viget.com/inspire/linked-smart-objects-in-photoshop, там описано более подробно со всеми плюсами и минусами.
                                        • НЛО прилетело и опубликовало эту надпись здесь
                                            0
                                            Думаю лишним не будет. Хотя все равно считаю что подход с масками кривоват.
                                            • НЛО прилетело и опубликовало эту надпись здесь
                                            0
                                            Картинки классные.
                                            • НЛО прилетело и опубликовало эту надпись здесь
                                              0
                                              Как вариант возможно использовать системы управления документами.
                                              Например Alfresco. Пример её использования для работы с Adobe Creative Suite
                                              www.zaizi.com/blog/working-with-alfresco-from-adobe-creative-suite
                                                0
                                                Полезная хитрость: никогда не рисовать главную страницу в первую очередь.
                                                  0
                                                  А с заказчиком как быть? Показать ему UI kit и сказать, что мол, смотрите, вот такие кнопочки будут на вашем сайте? А если нарисовать UI для внутреннего пользования, то если главную страницу не согласуют, это будет мартышкин труд. Да и общая концепция не всегда рождается при рисовании сборища элементов.
                                                    0
                                                    Нужно выбрать самую сложную внутреннюю страницу и делать ее. По условному «каталогу продукции» всегда будет меньше вопросов чем по главной странице.
                                                  • НЛО прилетело и опубликовало эту надпись здесь
                                                    0
                                                    Давно убедился, что разделение работы среди дизайнеров только мешает скорости. Тут главное со знанием дела дать дизайнерам задачи и тогда ничего переделывать по 10 раз не надо.
                                                    • НЛО прилетело и опубликовало эту надпись здесь
                                                        0
                                                        Как знакомо! По опыту, сильно экономит ресурсы изначально правильная постановка задачи.

                                                        Ну и проблема с перекрашиванием всех кнопочек без насущной необходимости имхо должна решаться в первую очередь переговорами с заказчиком.
                                                          0
                                                          В описанном примере будет проще и лучше, если дизайнеры будут участвовать в прикрутке сайта и отвечать за результат, то есть за конечный сайт. Например, новые кнопки можно будет показать клиенту на одном макете, а потом, если утвердит, попросить программистов везде исправить.
                                                            0
                                                            Судя по глазам Пети, он работает не вспоминая про сон… :(
                                                            Жалко парня!
                                                              0
                                                              А зачем вообще создавать подробные дизайн-макеты каждой из 1000 страниц, если они все заточены под UI кит?
                                                              Мне кажется, самое простое решение такое:
                                                              — проектировщик рисует прототипы всех страниц. На них нарисованы стандартные хлебные крошки, стандартные меню, текст поставлен кое-как
                                                              — дизайнер отрисовывает UI кит и все уникальные элементы, главную и несколько других ключевых страниц
                                                              — верстальщики отверстывают все уникальные элементы, после чего просто собирают все страницы по скетчам проектировщика (которые функционально полностьью верные, просто не оформлены).

                                                              Теперь, если кнопочка изменится нужно будет только изаменить UI кит и отдать верстальщикам.

                                                              Тогда мы имеем дизайнера, который действительно что-то создает, а не плодит одинаковые страницы, вставляя предыдущую/следующую версию кнопочек.
                                                                0
                                                                На порталах это сработает. При условии, что нет отдельных тематических страниц. Для интранета сработает. Но схема не универсальна.

                                                                Если проект большой в том смысле. что много надо оформить много контента — не работает. А ведь именно в этом случае версии нужны как никогда. Т.е. имеем мегабайты информации, которые надо оформить/заверстать в 2-3 страницы. Понятно, что это будет утверждаться не сразу.
                                                                  0
                                                                  можно примеры, где не сработает?
                                                                    0
                                                                    Как раз на сайте продукции и не сработает. Посмотрите хотя бы apple.com — контента много, оформлен по общим гайдам, но каждая страница индивидуально. Т.е. не получиться отдать верстальщикам кнопочки и картинки продукции и все. Нужен дизайн.
                                                                0
                                                                Кто-нибудь пользовался Adobe Version Cue для совместной работы? Какие впечатления?
                                                                wiki:Version Cue
                                                                Adobe® Version Cue® – это диспетчер версий файлов, который поставляется с пакетом Adobe Creative Suite 3 (выпуски Design, Web и Master Collection) и состоит из двух частей: сервера Version Cue и средств подключения Version Cue. Сервер Version Cue поддерживает размещение проектов Version Cue и рецензирование документов PDF. Его можно установить как локально, так и на централизованном компьютере. Средства подключения Version Cue позволяют подключиться к серверам Version Cue и поставляются со всеми компонентами, поддерживающими Version Cue (Adobe Acrobat®, Adobe Flash®, Adobe Illustrator®, Adobe InDesign®, Adobe InCopy®, Adobe Photoshop® и Adobe Bridge).

                                                                Version Cue используется для отслеживания изменений в файлах, сделанных во время работы с ними, и упрощает совместное использование, управление версиями и рецензирование файлов сотрудниками рабочих групп через Интернет. Version Cue можно использовать при работе как с отдельным компонентом пакета Creative Suite, поддерживающим Version Cue (например, Photoshop), так и одновременно с несколькими компонентами (например, Photoshop, Flash и Illustrator).

                                                                Version Cue выполняет решение следующих задач.
                                                                Создание версий файлов.
                                                                Совместная работа в рабочих группах (совместное использование файлов, управление версиями, извлечение файлов с сервера и возврат их на сервер).
                                                                Объединение файлов в индивидуальные или общие проекты.
                                                                Создание миниатюр для поиска и просмотра файлов.
                                                                Систематизация данных, упрощающая поиск и просмотр информации о файлах, комментариев к версиям и состояний файлов.
                                                                Создание проектов и рецензирование документов PDF, управление доступом пользователей с помощью средств администрирования сервера Version Cue.

                                                                Последняя версия: CS4 (сентябрь 2008)
                                                                  0
                                                                  Как раз надеялся что кто-нибудь про него напишет, что это вообще такое и с чем его едят. Насколько мне известно это издательская система контроля версий, которая прикручивается к Adobe Bridge. Вроде говорят что неплохая
                                                                  0
                                                                  Первое, что надо делать — уходить от фотошопа при разработке диза сайтов. Сам перешел с пол года назад на Fireworks, время на переработку макетов сократилось в разы.
                                                                    0
                                                                    напишите статью, плз
                                                                    0
                                                                    Петя — красава.
                                                                      0
                                                                      уже были статьи про Fireworks
                                                                        0
                                                                        SVN? Нафига? Есть git, его и юзать. И у каждого свой локальный репозиторий, и общий remote, куда сливается то, что показывать коллегам.

                                                                        Откуда вообще в новых статьях и в новых проектах svn появляется-то?
                                                                          +1
                                                                          Куда пропали картинки из статьи?
                                                                          • НЛО прилетело и опубликовало эту надпись здесь
                                                                              0
                                                                              Какая мерзость это ваше вконтакте.
                                                                              Попросил автора вернуть картинки.
                                                                              • НЛО прилетело и опубликовало эту надпись здесь

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

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