3.1. По мере готовности
Если вы знаете, что программа ещё очень сырая и наверняка будет меняться не один раз, пожалуйста, информируйте нас об этом. Лучше подождать и один раз сверстать приближенный к финальному вариант, чем переверстывать несколько раз с нуля.
3.2. Одна научная программа – одна задача – один дизайнер
Давайте договоримся, что работа над научной программой, куда бы она в итоге не пошла (на сайт, печататься в другом формате, на заставки в залы и прочее) должна вестись в одной задаче одним дизайнером. Все правки в программу также вносятся одним человеком в одной конкретной задаче, и только после этого исправленный вариант разносится на другие носители. Это очень важный момент, потому что ситуация, когда два дизайнера в соседних задачах работают с одним и тем же текстом научки, недопустима. Во-первых, это напрасно расходует рабочий ресурс как минимум одного человека из этой пары. Во-вторых, мы сильно путаем клиента. Не будем так делать.
3.3. Из печатки в диджитал и обратно
Печатные многостраничные издания верстаются по определенным правилам (их много, вдаваться в детали не будем). Скорректировать такой макет для диджитал среды – дело простое, так как требования для веба чуть мягче, чем для печатки. А вот при переводе макета, который сделан для диджитала, в печатный формат мы можем забуксовать. Поэтому просим вас сразу прописывать, куда макет будет направлен: печататься, на сайт или в обе стороны.
3.4. Переход из А5 в А4
В идеальном мире формат издания известен в первую очередь и не меняется по ходу работы над макетом. Если всё-таки условную брошюру формата а5 надо переверстать в а4, готовимся к тому, что это займёт какое-то время.
3.5. Как давать правки
Ещё в идеальном мире нет правок. Совсем нет. В нашем же мире правки лучше давать одним из этих способов:
как комментарии в пдф, который дизайнер ранее отправил вам на вычитку и согласование.
как комментарий в битриксе, который написан в формате «1. *текст правки* - номер страницы».
Скриншоты и правки, надиктованные по телефону, не принимаются 😊
Друзья, очень важно: даже если вы потрясающе владеете Адоб Акробат, клиент проел вам голову словом “срочно” или вы просто решили помочь, не нужно вносить правки в обход дизайнера. Это чревато тем, что вы отправите клиенту, например, исправленный файл программы, который он согласует, а после запросите у нас печатный макет, в котором всего, что вы внесли самостоятельно, просто не будет. Думаем, не нужно говорить, стрессом какого размера такая ситуация станет для всех участников процесса.
Мы не верстаем издания в Акробате, не копируем текст каждой страницы целиком, а потому не сможем довести файл-исходник до нужного вида, если все изменения, которые необходимо сделать, не будут отмечены вами одним из способов, которые мы привели выше. Даже если речь идёт про одну букву в ФИО, запятую или пробел.
3.6. Вид программы
Предоставлять программу в работу дизайнеру желательно в том виде, который предполагается увидеть в итоге: в виде таблицы или же сплошного текста. Менять вид многостраничной программы в сжатые сроки не представляется возможным!
Если вы делаете файл в виде таблицы, то не увлекайтесь излишним форматированием, так как это создает лишнюю проблему для дизайнера - убирать подложки, тени и прочие украшательства в документе.