Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 83
Вот! Моя любимая проблема — взаимодействие с дизайнером. Думаю только, что подобные вопросы просто нужно решать заранее. Хотя я уже дважды сталкивался с точно такой же проблемой. Еще один выход — просите psd и нарезайте сами!
Просим PSD, открываем и видим «Слой 49 копия 8». Лучше уж переименовать уже готовые файлы, но похожее письмо написать надо обязательно. И про структуру слоёв в нём упомянуть.
Понятно что и исходник может быть внутри карявым, слои обозваны странно, струкрута кривая, но вы можете все вещи эти видеть визуально + как я говорил выше — заранее нужно обговарить: кто нарезает, если нарезает дизайнер, то как именовать файлы, какого формата и прочее для вашего взаимного удобства и тогда подобной проблемы не будет. Если уж плохо подошли к вопросу, поленились, не учли эти моменты — не спроектировали, то конечно потом будут негодования, такие письма и прочее.
И да, однотипные объекты нужно называть с одинаковым префиксом.
И да, однотипные объекты нужно называть с одинаковым префиксом.
Вот именно. Достаточно перед началом работы отправить дизайнеру эту выдержку из письма:
Тоесть оговорить подготовку файла для верстальщика.
Что хотел бы видеть я:
— один объект называется везде один и тем же словом
— пара прилагательное + существительное стоят везде в одинаковом порядке
— иерархический префикс (например about_*** для всей графики принадлежащей этому экрану) — обратная иерархическая запись другими словами
— модификаторы в постфиксе (как _pressed стоит засунуть в конец например и _pp)
Тоесть оговорить подготовку файла для верстальщика.
вот нарезать самим — это не решение. я хочу расставлять элементы, зная, что где, а не путаться в названии слоев и файлов. Более того, мы уже подустали и написали скриптик, который из фотошопа все слои правильно импортирует. Но нет, иногда даже в скриптах путаются.
Согласен. Это скорее крайность или неумение договориться. Сам не люблю ковыряться в слоях во время работы над проектом. Хотя полезно + порой дизайнеры упираются рогом и кричат «Нет! Ты что? Нарезать не можешь? Это не наша работа — нарезать». Жесть, такое было.
Не соглашусь с вами, а тем более скрипт который слои импортит, зачем такое? если идет горизонтальный градиент на 1000px вы берете этот слой и клеите к верстке? Почему не вырезать из этих 1000 1 пиксель ширины, затем написать repeat-x. И вам легче и сайту и даже посетителю сайта.
Мой вам совет, нажмите CTRL+SHIFT+E, затем нажмите CTRL+ALT+SHIFT+S (можно jpg q = 90% — для веба с головой). Запускаем вот эту штуку habrahabr.ru/post/152115/ и вырезаем из JPG'a только то что нам нужно.
Мой вам совет, нажмите CTRL+SHIFT+E, затем нажмите CTRL+ALT+SHIFT+S (можно jpg q = 90% — для веба с головой). Запускаем вот эту штуку habrahabr.ru/post/152115/ и вырезаем из JPG'a только то что нам нужно.
В письме изложены очевидные вещи, но, как оказалось, для многих дизайнеров это сюрприз))
Не в обиду моему любимому дизайнеру, но я обычно вижу такое:
Иногда, по праздникам — группы со слоями называются более понятно, например «Logo», «Search» или «BG».
Хотя некоторым, в реальности, ставят такие сроки, что им уже не интересно называть каждый слой, лишь бы закончить по-скорее. Но есть и вторая сторона медали и её зовут «лень», делают как привыкли, а как будет работать верстальщик или программист с этим макетом — уже не интересно…
Иногда, по праздникам — группы со слоями называются более понятно, например «Logo», «Search» или «BG».
Хотя некоторым, в реальности, ставят такие сроки, что им уже не интересно называть каждый слой, лишь бы закончить по-скорее. Но есть и вторая сторона медали и её зовут «лень», делают как привыкли, а как будет работать верстальщик или программист с этим макетом — уже не интересно…
Что это за полуукраинский фотошоп?
Или художник ручками автоматические имена переводил с русского на украинский?
Или художник ручками автоматические имена переводил с русского на украинский?
Вы когда на девушку смотрите, думаете что вот это ее место состоит из большего количества мышечной массы. А вот в этом месте явно преобладает бурый жир. А вот здесь количество сухожилия…
Нафиг вам об этом думать?.. У вас есть образ, с ним и работайте инструментом.
Главный инструмент в фотошопе,
И не нужно так сильно парится со слоями. Да, слои меньше 50% прозрачности не цепляются этим интсрументом.
Ну вобщем я не испытаваю гречи от того что у меня бардак в слоях. Когда приходит время я что нужно удаляю и группирую. Это процесс бесконечный.
Не удержался)))
Нафиг вам об этом думать?.. У вас есть образ, с ним и работайте инструментом.
Главный инструмент в фотошопе,
И не нужно так сильно парится со слоями. Да, слои меньше 50% прозрачности не цепляются этим интсрументом.
Ну вобщем я не испытаваю гречи от того что у меня бардак в слоях. Когда приходит время я что нужно удаляю и группирую. Это процесс бесконечный.
Не удержался)))
150!!! единиц графики
Не так уж и много чтобы запутаться, честно.
У нас в одном уровне только не менее 200 единиц, а партиклы…
Помогают встроенные средства разработки на лету: визуализация в виде иконки для ускорения ассоциаций, скрипты фотошопа.
Честно говоря подустал от подобного рода постов. Во-первых я, как и ряд знакомых дизайнеров, пришел к неймингу файлов и слоев как-то самостоятельно. Просто потому что мне самому разобраться в 20 файлах со 150-300 слоями в каждом не очень удобно. А если человек дебил, то и не помогут ему нравоучения. Во-вторых — что мешает заранее оговорить подготовку макетов для работы? Одному из верстальщиков я пишу названия слоев и файлов исключительно на криллице — ну ему так удобно :)
И никогда не поверю, что дизайнер создающий такой беспредел в рабочем пространстве, выдает хороший результат. Я пока такого ни одного не видел. Все кого знаю чьими работами можно любоваться — не болеют «Layer 35 copy 43».
И никогда не поверю, что дизайнер создающий такой беспредел в рабочем пространстве, выдает хороший результат. Я пока такого ни одного не видел. Все кого знаю чьими работами можно любоваться — не болеют «Layer 35 copy 43».
В векторных программах, как правило, используется до 10 слоев. Объекты выбираются мышкой, не глядя в панели.
Какой смысл именовать все объекты в документе?
Что мешает при порезке точно так же выбирать их мышкой?
Дизайнер, использующий Индизайн, выдает плохой результат?
Какой смысл именовать все объекты в документе?
Что мешает при порезке точно так же выбирать их мышкой?
Дизайнер, использующий Индизайн, выдает плохой результат?
О боже! Меня кто то услышал!)
Жизнь файла не заканчивается даже версткой. Вам когда-то присылали на доработку pds-шники где царил хаос? Мне присылали и не раз. Редактировать такие файлы было сущим адом и времени уходило в разы больше.
Вы говорите о частном случае, что уже не корректно. Я говорю об отношении к работе в принципе.
Здесь можно очень легко провести черту. Сколько уже было постов на эту тему? Сколько раз верстальщики жаловались в комментариях на вот такой результат с которым они сталкиваются? Много. Это программная ошибка? Это неизбежность которую никак не исправить? Нет. Все просто потому что сидит члеовек, делает свою работаю и ему глубоко по **й на всех остальных, кто с ней столкнется. Потому что прогруппировать и логично назвать может занять максимум 10-15 минут и сохранить неизвестно сколько времени, нервов и сил всем кто будет сталкиватся с этим файлом дальше. Но нет! Мы гордые, мы творческие, у нас свой подход и мы на нем стоим! Это не профессионально, поэтому и говорю — не видел еще автора классных работ который страдал бы вот этим беспорядком в рабочих файлах.
Вы говорите о частном случае, что уже не корректно. Я говорю об отношении к работе в принципе.
Здесь можно очень легко провести черту. Сколько уже было постов на эту тему? Сколько раз верстальщики жаловались в комментариях на вот такой результат с которым они сталкиваются? Много. Это программная ошибка? Это неизбежность которую никак не исправить? Нет. Все просто потому что сидит члеовек, делает свою работаю и ему глубоко по **й на всех остальных, кто с ней столкнется. Потому что прогруппировать и логично назвать может занять максимум 10-15 минут и сохранить неизвестно сколько времени, нервов и сил всем кто будет сталкиватся с этим файлом дальше. Но нет! Мы гордые, мы творческие, у нас свой подход и мы на нем стоим! Это не профессионально, поэтому и говорю — не видел еще автора классных работ который страдал бы вот этим беспорядком в рабочих файлах.
Рисую макеты. Редко называю именами. Если нет в этом потребности мне, почему она возникает у тех кто режет макет?
Яж не один такой. Почему кто-то начал считать существующей проблему нейминга слоев и иерархии?
Именно проблема кучи слоев возникает почему-то не у тех кто рисует. Вопрос стоит о компетенции резальщика макета)
> то хотел бы видеть я:
> — один объект называется везде один и тем же словом
> — пара прилагательное + существительное стоят везде в одинаковом порядке
> — иерархический префикс (например about_*** для всей графики принадлежащей этому экрану) — обратная
>- иерархическая запись другими словами
> — модификаторы в постфиксе (как _pressed стоит засунуть в конец например и _pp)
ГОСподи!!! Знаете, если человек ходит домой строго по 90 градусов не срезая углы, только потому что он в школе любил ортогональное черчение, это его проблемы).
Если человек привык сохранять файлы с интернета упорядочивая их в каждую соотвествующую папочку, это его проблемы, когда он негодуя сталкивается с компьютером где все навалено в одну кучу.
Вы говорите о своих паттернах работы причем явно выраженной на основе большого опыта с ООП, иерархии, наследования, инкапЧулирования ( смешно вышло), полиморфизма, абстракционизма, полиморфизма, и прочих страшных слов, забывая, что это всего лишь проблемы вашего восприятия. У вас доминирует какое то полушаерие и вы через эту призму пытаетесь смотреть на такой несовершенный неупорядоченный мир.
Вам проще воспринимать информацию упорядоченную и структурированную. Так вы же себя сами загоняете в угл. Информация хаотична и разуму легче ее воспринимать абстрагируя и иерархируя. Но рано или поздно его буфер закончится.
У дизайнеров этот буфер меньше в разы, от того они не понимают нужны этой иерархии.
В фотошопе все слои выделяются инструментом визуально. Я на слои вообще редко смотрю.
Не существует правильного метода работы с макетом. Адоб диктует решение как будет происходить эта работа. Сейчас он решает что сайты нужно рисовать вообще в Fireworks. Но мне лично это не удобно хотя там есть отменные пирожки.
>search_bottombar_arrow_left_pressed_pp
Яро против!!! Это из серии как кастомизировать слайдер Jquery если у него имена длиннее, чем разрешает сохранять фотошоп. Это опять проблемы вашего патерна программиста. Хватит струкрутрировать все. Разве тяжело взглянуть на эскиз картинки чтобы понять что это за элемент или проще читать имена длинных файлов, от количества которых в папке в глазях рябит?
На худой конец если вам дадут спрайт, ваш метод не прокатит.
>поппиксишная нажатая левая стрелка из нижнего бара что на экране поиск
О черт! В помощнику дизайнеру нужен будет Иерархист. Иерархия вещь хорошая. Но не до таких пределов.
Лучший способ отучить дизайнера коряво рисовать, заставить его верстать.) Эффект гарантирован!!!
Мне вообще плевать на имена файлов картинок. Какая разница, у меня эскизы в проводнике, лучшие имена. Я даже читал что проблема имен файлов на компьютере возникла просто из технологической необходимости, а не из человеческой поребности.
И я не ругаюсь, совсем нет. Я про паттерны. Это всего лишь патерны которые можно менять. Понятно что смена паттернов из зоны комфорта ментальной выбивает. Но другого пути нету) Программисту просто тяжело выходить из зоны своего мышления при верстке, отсюда трабл
Яж не один такой. Почему кто-то начал считать существующей проблему нейминга слоев и иерархии?
Именно проблема кучи слоев возникает почему-то не у тех кто рисует. Вопрос стоит о компетенции резальщика макета)
> то хотел бы видеть я:
> — один объект называется везде один и тем же словом
> — пара прилагательное + существительное стоят везде в одинаковом порядке
> — иерархический префикс (например about_*** для всей графики принадлежащей этому экрану) — обратная
>- иерархическая запись другими словами
> — модификаторы в постфиксе (как _pressed стоит засунуть в конец например и _pp)
ГОСподи!!! Знаете, если человек ходит домой строго по 90 градусов не срезая углы, только потому что он в школе любил ортогональное черчение, это его проблемы).
Если человек привык сохранять файлы с интернета упорядочивая их в каждую соотвествующую папочку, это его проблемы, когда он негодуя сталкивается с компьютером где все навалено в одну кучу.
Вы говорите о своих паттернах работы причем явно выраженной на основе большого опыта с ООП, иерархии, наследования, инкапЧулирования ( смешно вышло), полиморфизма, абстракционизма, полиморфизма, и прочих страшных слов, забывая, что это всего лишь проблемы вашего восприятия. У вас доминирует какое то полушаерие и вы через эту призму пытаетесь смотреть на такой несовершенный неупорядоченный мир.
Вам проще воспринимать информацию упорядоченную и структурированную. Так вы же себя сами загоняете в угл. Информация хаотична и разуму легче ее воспринимать абстрагируя и иерархируя. Но рано или поздно его буфер закончится.
У дизайнеров этот буфер меньше в разы, от того они не понимают нужны этой иерархии.
В фотошопе все слои выделяются инструментом визуально. Я на слои вообще редко смотрю.
Не существует правильного метода работы с макетом. Адоб диктует решение как будет происходить эта работа. Сейчас он решает что сайты нужно рисовать вообще в Fireworks. Но мне лично это не удобно хотя там есть отменные пирожки.
>search_bottombar_arrow_left_pressed_pp
Яро против!!! Это из серии как кастомизировать слайдер Jquery если у него имена длиннее, чем разрешает сохранять фотошоп. Это опять проблемы вашего патерна программиста. Хватит струкрутрировать все. Разве тяжело взглянуть на эскиз картинки чтобы понять что это за элемент или проще читать имена длинных файлов, от количества которых в папке в глазях рябит?
На худой конец если вам дадут спрайт, ваш метод не прокатит.
>поппиксишная нажатая левая стрелка из нижнего бара что на экране поиск
О черт! В помощнику дизайнеру нужен будет Иерархист. Иерархия вещь хорошая. Но не до таких пределов.
Лучший способ отучить дизайнера коряво рисовать, заставить его верстать.) Эффект гарантирован!!!
Мне вообще плевать на имена файлов картинок. Какая разница, у меня эскизы в проводнике, лучшие имена. Я даже читал что проблема имен файлов на компьютере возникла просто из технологической необходимости, а не из человеческой поребности.
И я не ругаюсь, совсем нет. Я про паттерны. Это всего лишь патерны которые можно менять. Понятно что смена паттернов из зоны комфорта ментальной выбивает. Но другого пути нету) Программисту просто тяжело выходить из зоны своего мышления при верстке, отсюда трабл
Программисту просто тяжело выходить из зоны своего мышления при верстке, отсюда трабл
и дизайнеру вроде вас получается тоже тяжело выходить из зоны своего мышления при проектировании дизайна?
Конечно! Но я то еще и немного на php могу состряпать чтонибудь не особо сложное. И сверстать мне лучше самому, пусть немного дольше но так как я хочу. И всегда всегда консультации и общие мнения если есть спорные места. Куда без этого.
Странно, а почему бы не расширять зону мышления, принимая на вооружение удобные инструменты, в том числе и из других отраслей? именование файлов не от балды а хоть с какой нибудь единой иерархией (не обязательно такой как в посте) заметно облегчает работу не только верстальщику, но и самому же дизайнеру в том числе. Не всегда есть возможность смотреть файлы по превьюшкам. Что в таком случае делать? перебирать все подряд в поисках нужного? Наверняка проще взять и по имеющейся иерархии отследить какой файл как называется.
ммм… я так и делаю вобщем то. Писал немного о другом.
А вышло то о том, что вам как бы пофиг в каком виде ваша работа попадет к следующему исполнителю в цепочке. Вы делаете как вам удобней и ладно, и пусть тот кто получит от вас результат работы принимает его таким какой он есть и без возражений.
:) У нас тут тоже внутренне корпоративная дискуссия. Пишу от имени AgentSIB (если есть, дайте ему инвайт — это наш ТимЛид на Android)
Собственно, его комментарий:
Хорошо, давайте представим, что программист также начнет жить, придерживаясь хаоса и называть функции например так: function1, function2, tratataolol, а потом будет яро отстаивать свою точку зрения, мол, это продукт его «богатого внутреннего мира». — Да в шею гнать таких нужно будет (и думаю. что так и будет в итоге с такими).
Разработка не ограничивается созданием и резкой графики — это всего лишь материал, с которым позже будут работать другие люди. И если материал будет грамматно структурирован, то и разработка будет удобней и быстрей. А разбираться во внутреннем мире дизайнера как-то не очень хочется….
Собственно, его комментарий:
Хорошо, давайте представим, что программист также начнет жить, придерживаясь хаоса и называть функции например так: function1, function2, tratataolol, а потом будет яро отстаивать свою точку зрения, мол, это продукт его «богатого внутреннего мира». — Да в шею гнать таких нужно будет (и думаю. что так и будет в итоге с такими).
Разработка не ограничивается созданием и резкой графики — это всего лишь материал, с которым позже будут работать другие люди. И если материал будет грамматно структурирован, то и разработка будет удобней и быстрей. А разбираться во внутреннем мире дизайнера как-то не очень хочется….
Все правильно. Имена типа 11111.png 3333.png никуда не годятся. Под богатсвом внутренего мира прячется просто нежелание этим заниматься) Я так никогда и не называю. Яж не предендую на энцеклопидичную точность поста. Нужно быть в обществе, в комманде, чем живут чем общаются. Тогда самособой выстраиваются свои внутренние правила, когда всем легче. Потом делимся с кем нибудь этим опытом, вдрг оказывается то что то можно упростить. Я потому и верстаю сам, что не хочу обременять программиста, пока он вольется пока будет макет глядеть, я пока рисую уже знаю как верстать. Здесь же часто одна психология то и есть коллектива. Разве часто дизайнер и программист находят о чем поговорить? Друг друга же боятся как огня — никто не понимает чо он там кодит или как он там рисует)
Ваши суждения похожи на суждения упёртого новичка, не понимающего, зачем поддерживать структуру кода, «я ж и так разберусь!».
Так вот, Вы — не единственный специалист на этой планете. И возможны ситуации, когда кому то другому, придётся за Вами доделывать работу. И нужно, как ни странно, беспокоится о удобстве этого человека.
Так вот, Вы — не единственный специалист на этой планете. И возможны ситуации, когда кому то другому, придётся за Вами доделывать работу. И нужно, как ни странно, беспокоится о удобстве этого человека.
Структуру кода поддерживать необходимо.Я codex от wordpress три раза перед едой читаю. Я не говорил обратного.
Работа со слоями в шопе не есть верное сравнение. Мне, лично мне, вобще спокойно что там со слоями на самом деле даже у другого человека если я беру его макет. Другое дело, что он использует некоторые вещи потипу корректирующих слоев и масок с режимом смешивания, когда один слой выше, влияет на разные слои ниже, стоящие в разных логических при верстке блоках. И их необходимо разрезать.
Я не вижу, реально не вижу, проблем со слоями среди дизайнеров. Ну да, в папку не положил ну и что Ну честное слово, это вот не самая большая проблема, я говорил об уровне компетенции. Разобраться дизайнеру в чужих слоях не сложнее, как программисту разобрать код бекапа, который админ написал.
Работа со слоями в шопе не есть верное сравнение. Мне, лично мне, вобще спокойно что там со слоями на самом деле даже у другого человека если я беру его макет. Другое дело, что он использует некоторые вещи потипу корректирующих слоев и масок с режимом смешивания, когда один слой выше, влияет на разные слои ниже, стоящие в разных логических при верстке блоках. И их необходимо разрезать.
Я не вижу, реально не вижу, проблем со слоями среди дизайнеров. Ну да, в папку не положил ну и что Ну честное слово, это вот не самая большая проблема, я говорил об уровне компетенции. Разобраться дизайнеру в чужих слоях не сложнее, как программисту разобрать код бекапа, который админ написал.
Знаете, это не программисту трудно «выйти из зоны своего мышления», а вам почему то трудно осознать тот факт, что конечный результат вашей работы обязан быть структурированным иначе это будет некачественный продукт. Либо верстальщику нужно будет разобраться в вашей работе, что там к чему у вас и проименовать объекты соответственно. Это у вас эскизы в проводнике, а у него HTML и CSS. И речь в посте не о том, чья точка зрения верна, а о том, что при небольших усилиях можно тупо ускорить процесс (общий процесс, замечу). Судя по вашей логике вам вообще плевать что там дальше, тупо сделал своё и до свиданья.
Справедливости ради в данном случае есть и другой перегиб — search_bottombar_arrow_left_pressed_pp — это конечно кромешный ад, это навязывание некой уже конечной структуры дизайнеру, разжеванной до мелочей, так тоже нехорошо. Но система взаимодействия и каких то простых правил должна быть. По крайней мере первые два пункта из списка очень верны и их стоит соблюдать.
В одном вы правы точно — я считаю, что КАЖДЫЙ дизайнер должен сверстать 2-3 макета в своей жизни, просто для общего развития и понимания, что с его работой происходит дальше. Я знаю таких дизайнеров, с ними изумительно удобно работать и это их большой плюс при выборе.
Справедливости ради в данном случае есть и другой перегиб — search_bottombar_arrow_left_pressed_pp — это конечно кромешный ад, это навязывание некой уже конечной структуры дизайнеру, разжеванной до мелочей, так тоже нехорошо. Но система взаимодействия и каких то простых правил должна быть. По крайней мере первые два пункта из списка очень верны и их стоит соблюдать.
В одном вы правы точно — я считаю, что КАЖДЫЙ дизайнер должен сверстать 2-3 макета в своей жизни, просто для общего развития и понимания, что с его работой происходит дальше. Я знаю таких дизайнеров, с ними изумительно удобно работать и это их большой плюс при выборе.
Так как в веб как и любые технологии в основном основаны на иерархии, от нее уйти нельзя. Отсюда и правило, что глубже 3 ссылок на сайтах ничего не прятать. А то буфер памяти у человека просто переполняется. Дизайнеру трудно осознать чо ему нужно сделать, потому что он не понимает как оно дальше будет работать. Так как я немного знаком с программированием и версткой, проблем на меня особо нет. Я знаю людей, кто даже для меня рисует так шо АД.
Рисуют картины, а не макеты. Кучи корректирующих слоев из за страха убить оригинал кнопочки.
Но в техпроцессе виноватых много. Кто то не умеет сказать а кто то не захотел слушать.
search_bottombar_arrow_left_pressed_pp
Я про этоже и говорил, достаточно максимум 3, ладно, 4-х составных имен. Выше уже башня задымится.
Важно убить страх у дизайнера, что он не поймет как работает верстка. Как когда то я победил свой страх)) И к чертям мечтаю всю спецификацию переделать. Наплодили адовых тегов, свойств, префиксов CSS. Урезать все можно без ущерба для здоровья раза в два я думаю точно.
Рисуют картины, а не макеты. Кучи корректирующих слоев из за страха убить оригинал кнопочки.
Но в техпроцессе виноватых много. Кто то не умеет сказать а кто то не захотел слушать.
search_bottombar_arrow_left_pressed_pp
Я про этоже и говорил, достаточно максимум 3, ладно, 4-х составных имен. Выше уже башня задымится.
Важно убить страх у дизайнера, что он не поймет как работает верстка. Как когда то я победил свой страх)) И к чертям мечтаю всю спецификацию переделать. Наплодили адовых тегов, свойств, префиксов CSS. Урезать все можно без ущерба для здоровья раза в два я думаю точно.
не задымится, если придерживатся последовательности.
Вы же каждый день одеваетесь (не 3-4 одёжки), быть может готовите кушать, что-то более сложное, чем пельмени, пишите свой физический адрес (тоже иерархический). Ничего ведь — привыкли. И совсем не страшно.
Именно это название — search_bottombar_arrow_left_pressed_pp — позволяет мне даже не видя картинки понять — что это такое.
Относитесь к вопросы с другой стороны. Верстальщик не занимается пониманием того, что Вы нарисовали — это занятие художественных критиков (или других дизайнеров). Его задача — просто сделать из картинки HTML-код. Поэтому, чем точнее Вы опишите отдельные элементы — тем точнее верстальщик перенесёт их
Вы же каждый день одеваетесь (не 3-4 одёжки), быть может готовите кушать, что-то более сложное, чем пельмени, пишите свой физический адрес (тоже иерархический). Ничего ведь — привыкли. И совсем не страшно.
Именно это название — search_bottombar_arrow_left_pressed_pp — позволяет мне даже не видя картинки понять — что это такое.
Относитесь к вопросы с другой стороны. Верстальщик не занимается пониманием того, что Вы нарисовали — это занятие художественных критиков (или других дизайнеров). Его задача — просто сделать из картинки HTML-код. Поэтому, чем точнее Вы опишите отдельные элементы — тем точнее верстальщик перенесёт их
Черт, да отличное это решение я не спорю. Но я могу ваш search_bottombar_arrow_left_pressed_pp
Но я могу назвать так piosk_niz_left_released. Нельзя назвать файл так, чтобы вы точно не ошиблись при выборе какого то элемента. И откуда вы знаете какой элемент нарезан, если вы не резали макет и не видете элемент. Вы же все равно визуально проверяете рано или поздно. Чем больше писанины в имени, тем сложнее поиск.
Со временем конечно можно притереться с людьми в этом плане и это будет очень удобно. Однако это будет только ваш компанийский сленг. И требовать его вы будете еще сильнее потому что вы так привыкли. обозначение _pp в имени мне не знакомо. Ровным счетом сленг у меня с моим программистом свой. И не важно как мы называем файлы — если нам удобно. Завтра вы увидете другой сленг, другие синонимы в названии картинок. Как было у меня с JQUERY. У них свой сленг в зависимоти от проекта, в зависимости от людей.
Верстальщик даже есть увидит название файлов, все равно часто, на моей скромной практике, не делает то что в макете))) Все равно что то он упускает. А до pixel perfect не все верстальщики обучены.
Я не пиксельперфектчик и стчитаю пару пятерку пикселей можно кое кто упускать верстальщику.
Желание 100% совпадения по пикселям считаю тихой сексуальной неудовлетворенностью.)
И я не ругаюсь, вы не подумайте лишнего.
Но я могу назвать так piosk_niz_left_released. Нельзя назвать файл так, чтобы вы точно не ошиблись при выборе какого то элемента. И откуда вы знаете какой элемент нарезан, если вы не резали макет и не видете элемент. Вы же все равно визуально проверяете рано или поздно. Чем больше писанины в имени, тем сложнее поиск.
Со временем конечно можно притереться с людьми в этом плане и это будет очень удобно. Однако это будет только ваш компанийский сленг. И требовать его вы будете еще сильнее потому что вы так привыкли. обозначение _pp в имени мне не знакомо. Ровным счетом сленг у меня с моим программистом свой. И не важно как мы называем файлы — если нам удобно. Завтра вы увидете другой сленг, другие синонимы в названии картинок. Как было у меня с JQUERY. У них свой сленг в зависимоти от проекта, в зависимости от людей.
Верстальщик даже есть увидит название файлов, все равно часто, на моей скромной практике, не делает то что в макете))) Все равно что то он упускает. А до pixel perfect не все верстальщики обучены.
Я не пиксельперфектчик и стчитаю пару пятерку пикселей можно кое кто упускать верстальщику.
Желание 100% совпадения по пикселям считаю тихой сексуальной неудовлетворенностью.)
И я не ругаюсь, вы не подумайте лишнего.
piosk_niz_left_released — Вы съели мой мозг. Пожалуйста, никогда так ничего не называйте. И удачи в обьяснении англоговорящему коллеге, что это такое.
Насчёт устаявшегося сленга/наименования — да, в разных командах он разный. Главное чтоб он был.
pixel perfect — хорошая вешь. Бывают ситуации, когда он невозможен по обьективным причинам — тогда это проблема дизайнера (исправить макет, чтоб он был воплощаем в жизнь). Но если отсутствие пиксель-перфекта обьясняется исключительно ленью верстальщика — то этому нет оправдания.
Насчёт устаявшегося сленга/наименования — да, в разных командах он разный. Главное чтоб он был.
pixel perfect — хорошая вешь. Бывают ситуации, когда он невозможен по обьективным причинам — тогда это проблема дизайнера (исправить макет, чтоб он был воплощаем в жизнь). Но если отсутствие пиксель-перфекта обьясняется исключительно ленью верстальщика — то этому нет оправдания.
Как много можно налить воды, чтобы оправдать собственное раздолбайство.
Когда вы что-то делаете, вам в своей собственно работе разобраться несложно, потому что подсознательно вы помните где и что именно вы делали.
Как только над проектом начинает работать несколько человек — без стандарта начинается бардак. Просто потому что люди не телепаты и не могут понять каким восприятием мира вы пользовались и какое творческое настроение у вас было, когда вы выполняли свою работу.
Уважайте коллег, пожалуйста. Сандарты на такие вещи пишутся кровью умерших проектов и нервами специалистов загибающихся во время дедмаршей перед дедлайнами.
Когда вы что-то делаете, вам в своей собственно работе разобраться несложно, потому что подсознательно вы помните где и что именно вы делали.
Как только над проектом начинает работать несколько человек — без стандарта начинается бардак. Просто потому что люди не телепаты и не могут понять каким восприятием мира вы пользовались и какое творческое настроение у вас было, когда вы выполняли свою работу.
Уважайте коллег, пожалуйста. Сандарты на такие вещи пишутся кровью умерших проектов и нервами специалистов загибающихся во время дедмаршей перед дедлайнами.
МММ… так и не смог донести свою мысль. Я как раз и писал о стандартах. Я предерживаюсь стандартов в оформлении CSS.
Учитываю при верстке имена файлов, в но не таких длинных search_bottombar_arrow_left_pressed_pp, советы от гугла при html верстке.
Кода я пишу про паттерны у программистов, я пишу про то что иерархия search_bottombar_arrow_left_pressed_pp заберет все силы трудового дня. У программиста все восприятие на ООП построено и иерархии, и когда он говорит ах какой ужасный макет, я ему показываю элементарные азы работы со слоями. Потому что часто под призывами именования слоев в фотошопе, я вижу только умение программиста включать и выключать слои мышкой + обрезать и сохранять файл.
Учитываю при верстке имена файлов, в но не таких длинных search_bottombar_arrow_left_pressed_pp, советы от гугла при html верстке.
Кода я пишу про паттерны у программистов, я пишу про то что иерархия search_bottombar_arrow_left_pressed_pp заберет все силы трудового дня. У программиста все восприятие на ООП построено и иерархии, и когда он говорит ах какой ужасный макет, я ему показываю элементарные азы работы со слоями. Потому что часто под призывами именования слоев в фотошопе, я вижу только умение программиста включать и выключать слои мышкой + обрезать и сохранять файл.
Верстальщику трудно выходить за пределы стандартов, это да, а за пределы мышления как раз-таки несложно.
Меня просто иерархия выбесила при кастомизации Jquery контрола. Потому она меня пугает. Сейчас похоже сделали попроще вот смотрю в ресурсах.
ui-bg_diagonals-thick_18_b81900_40x40.png
Но раньше было невозможно сохранить файл поверх существующего из за тоо что шоп урезал имена файлов до 32 сиволов или около того. Потому меня корежит от советов делать так ui-bg_diagonals-thick_18_b81900_40x40.png когда файлов 100 штук. Я пречитываю то что написал, да… читается конечно не очень. Но писал я немного о другом.
ui-bg_diagonals-thick_18_b81900_40x40.png
Но раньше было невозможно сохранить файл поверх существующего из за тоо что шоп урезал имена файлов до 32 сиволов или около того. Потому меня корежит от советов делать так ui-bg_diagonals-thick_18_b81900_40x40.png когда файлов 100 штук. Я пречитываю то что написал, да… читается конечно не очень. Но писал я немного о другом.
Ломка паттернов = трата времени (на понимание Вашей системы/безсистемности именования). Трата времени = трата денег.
С другой стороны — поддержание правильного именования — трата времени дизайнера. Однако же, по идее, улучшает приемственность работ между дизайнерами (готов к аргументированной дискуссии). Ибо Ваш творческий хаос, дизайнер с чуть другим устройством внутреннего мира будет разбирать довольно долго.
Так что — взвешиваем, в каком случае тратим больше — и принимаем решение.
С другой стороны — поддержание правильного именования — трата времени дизайнера. Однако же, по идее, улучшает приемственность работ между дизайнерами (готов к аргументированной дискуссии). Ибо Ваш творческий хаос, дизайнер с чуть другим устройством внутреннего мира будет разбирать довольно долго.
Так что — взвешиваем, в каком случае тратим больше — и принимаем решение.
Такое ощущение что вы всегда работаете в одиночестве.
Проблема многих дизайнеров в нарезке графики и в том, что они часто не называют слои.
В определенный момент, при достижении определенного профессионального уровня (в культурном наверно плане), дизайнер начинает группировать слои в папки, называть нормально папки, называть нормально слои, и даже кодировать их цветом.
Выигрывает тут и дизайнер, который может не запутаться в проекте, если он его откроет через месяц, и верстальщик/программист, который будет после дизайнера, возможно, ковыряться в проекте.
Хорошо когда наименования осмысленные совсем.
Это панель кнопок на iPhone? «Bottom Bar» называй, и никаких проблем.
Это подвал сайта? «footer», и т.д
Еще одна плюшка — называние слоев так, как они будут при экспорте.
«button_mail_pressed.png» — отличное название для слоя.
Используйте пожалуйста Layer comps.
Это позволит проще показать состояния объектов и другое минимальное изменение.
Например: можно взять кнопку, и сделать из неё smart-object, а внутри объекта, сделать 3 layer comps: normal, hover, pressed.
Можно забиндить на клавиши перемещение между layer comps и наглядно смотреть на кнопку в разных состояниях, без особого труда.
Ах, ну и еще. Есть такой инструмент — Layer Cake.
Если вы будете называть слои *.png, а потом просто перетащите PSD файл в окно с программой — она сама порежет на кусочки все картиночки. Хоть у вас там 150 кнопок. Все порежет без труда.
Правда смарт объекты не умеет резать по layer comps, но это другая история.
Главное — основную графику режет просто и быстро.
В определенный момент, при достижении определенного профессионального уровня (в культурном наверно плане), дизайнер начинает группировать слои в папки, называть нормально папки, называть нормально слои, и даже кодировать их цветом.
Выигрывает тут и дизайнер, который может не запутаться в проекте, если он его откроет через месяц, и верстальщик/программист, который будет после дизайнера, возможно, ковыряться в проекте.
Хорошо когда наименования осмысленные совсем.
Это панель кнопок на iPhone? «Bottom Bar» называй, и никаких проблем.
Это подвал сайта? «footer», и т.д
Еще одна плюшка — называние слоев так, как они будут при экспорте.
«button_mail_pressed.png» — отличное название для слоя.
Используйте пожалуйста Layer comps.
Это позволит проще показать состояния объектов и другое минимальное изменение.
Например: можно взять кнопку, и сделать из неё smart-object, а внутри объекта, сделать 3 layer comps: normal, hover, pressed.
Можно забиндить на клавиши перемещение между layer comps и наглядно смотреть на кнопку в разных состояниях, без особого труда.
Ах, ну и еще. Есть такой инструмент — Layer Cake.
Если вы будете называть слои *.png, а потом просто перетащите PSD файл в окно с программой — она сама порежет на кусочки все картиночки. Хоть у вас там 150 кнопок. Все порежет без труда.
Правда смарт объекты не умеет резать по layer comps, но это другая история.
Главное — основную графику режет просто и быстро.
Писал недавно статью как раз от верстальщика дизайнерам, хотел посоветовать Layer Comps для отрисовки нескольких состояний элемента. Протестировал и разочаровался, фича очень ограничена, у векторных элементов не подхватывает самые важные части как fill и stroke.
Вот поддерживаю, о том же говорил и я только с другой стороны.
Layer comps — вата. Все плохо тем, что раз поменяв макет, все Layer comps придется переделывать. Да в фотошопе все так, как начинаешь сруктурировать, так что то меняется потом в дизайне и все летит к чертям.
В фотошопе нет нормальных средств для удобного отображения разных элементов состояний, hover и прочее. Только опять эти папки хренапки, smartlayer…
Layer comps — вата. Все плохо тем, что раз поменяв макет, все Layer comps придется переделывать. Да в фотошопе все так, как начинаешь сруктурировать, так что то меняется потом в дизайне и все летит к чертям.
В фотошопе нет нормальных средств для удобного отображения разных элементов состояний, hover и прочее. Только опять эти папки хренапки, smartlayer…
Иерархическое именование. А вообще, жесть конечно что в Google не сделали нормальную генерацию идентификаторов по ветке дерева.
У меня если объектов на выходе больше 3-4 штук, то всегда начинаю делать «специализацию» в названиях для удобной работы.
Почему бы не использовать Slice Tool в фотошопе?
Дизайнерам это тоже становится удобно — есть один файл, в котором вносятся изменения в графику на продакшн, потом один раз сохраняется через Save For Web and Devices и вся графика нарезана по заранее заданным правилам именования (о которых стоит договориться с программистом).
Один клик и готово. И дизайнер доволен, что графика такая, какая должна быть, и программист, что не нужно запариваться с этой грудой файлов.
Например, у меня и такие бывает получаются файлы:
Дизайнерам это тоже становится удобно — есть один файл, в котором вносятся изменения в графику на продакшн, потом один раз сохраняется через Save For Web and Devices и вся графика нарезана по заранее заданным правилам именования (о которых стоит договориться с программистом).
Один клик и готово. И дизайнер доволен, что графика такая, какая должна быть, и программист, что не нужно запариваться с этой грудой файлов.
Например, у меня и такие бывает получаются файлы:
Здесь чревато большой ошибкой обрезать лишнее у полупрозраных элементов. Потому я советую команду TRIM в фотошопе.
Если не хотите чтобы потом было примерно так
Если не хотите чтобы потом было примерно так
Спасибо за трим — хорошее решение. Сам обычно брал с запасом.
А есть ли в Фотошопе функция, чтобы он все слой тримировал :-) и потом сохранял их в ПНГ с названием идентичным имени слоя, если будут сохранены папки, будет вообще здорово.
Понятно, что все равно придется делать коррекцию, но львиная доля рутинной работы будет выполнена.
А есть ли в Фотошопе функция, чтобы он все слой тримировал :-) и потом сохранял их в ПНГ с названием идентичным имени слоя, если будут сохранены папки, будет вообще здорово.
Понятно, что все равно придется делать коррекцию, но львиная доля рутинной работы будет выполнена.
В фотошопе плохо организован процесс нарезки, взять тот же нож. Устарел он уже сильно.
Я не делаю спрайты в фотошопе — это труд не облегчает. Я делаю по отдельности каждый элемент, быстро отключаю лишние нижние слои, делаю трим. Потом сохраняю для веба png24. Если нужно экспортировать сразу все объекты в файлы то можно воспользоваться этим
Есть функция сохранить слои как файлы.
ТО есть объединяем в слои нужные элементы, и просто прогоняем их как на картинке. В Итоге у нас есть в папке все файлы из слоев, а теперь фокус.
Малозамеченный веб интсрумент описанный мною в статье:
habrahabr.ru/post/139914/
Вы выделяете все файлы из своей папки и кидаете на эту страницу. В итоге вы получаете спрайт с координатами нужных объектов. Имена классов — имена файлов. Не нужно больше писать css самому. Да, есть и заменители десктопные, что вобщем то тоже не плохо. В итоге это очень удобно.
Я беру макет, отключаю лишнее быстро, трим, сохраняю. Так все объекты png и jpg. Я не любитель плодить к сайту кучу PSD. Я заметил что разбираться где последняя версия иконки дольше, чем заново ее экспортнуть с одного меcта где она рисовалась.
Я не делаю спрайты в фотошопе — это труд не облегчает. Я делаю по отдельности каждый элемент, быстро отключаю лишние нижние слои, делаю трим. Потом сохраняю для веба png24. Если нужно экспортировать сразу все объекты в файлы то можно воспользоваться этим
Есть функция сохранить слои как файлы.
ТО есть объединяем в слои нужные элементы, и просто прогоняем их как на картинке. В Итоге у нас есть в папке все файлы из слоев, а теперь фокус.
Малозамеченный веб интсрумент описанный мною в статье:
habrahabr.ru/post/139914/
Вы выделяете все файлы из своей папки и кидаете на эту страницу. В итоге вы получаете спрайт с координатами нужных объектов. Имена классов — имена файлов. Не нужно больше писать css самому. Да, есть и заменители десктопные, что вобщем то тоже не плохо. В итоге это очень удобно.
Я беру макет, отключаю лишнее быстро, трим, сохраняю. Так все объекты png и jpg. Я не любитель плодить к сайту кучу PSD. Я заметил что разбираться где последняя версия иконки дольше, чем заново ее экспортнуть с одного меcта где она рисовалась.
Трим подходит, если в одном документе один объект, но если их несколько, они разноформатные, и могут быть позже правки, то лучше ножа пока ничего не нашлось. Для интерфейсов самое то.
Чтобы не обрезать лишнего, можно продублировать слои и сделать мерж, тогда останутся только видимые пиксели, к которым уже можно и гайды подвести и нож примагнитить.
Чтобы не обрезать лишнего, можно продублировать слои и сделать мерж, тогда останутся только видимые пиксели, к которым уже можно и гайды подвести и нож примагнитить.
Недавно наткнулась на плагин для Photoshop-а: Cut&Slice me. Умеет нарезать весь PSD или выбранную группу. В деле показал себя очень неплохо.
Все правильно в письме и очень многие именно так и делают (я например :) отправляя псд заказчику все слои переименовываю, группирую и выделяю цветом). Более того, чем больше опыта у дизайнера, тем чаще он так делает даже для себя, потому как заглянув через пару месяцев можно долго искать блок с нужным контентом.
А вообще меня давно подмывает написать статью «письмо дизайнера программистам», уж сколько раз сталкивался с весьма странной интерпретацией дизайна, рисуешь текст с отступом- делают без отступа и т.д…
А вообще меня давно подмывает написать статью «письмо дизайнера программистам», уж сколько раз сталкивался с весьма странной интерпретацией дизайна, рисуешь текст с отступом- делают без отступа и т.д…
> потому как заглянув через пару месяцев можно долго искать блок с нужным контентом.
Признатся честно.Лично мне по барабану. Не испытываю сложностей ни с каким макетом.
> сколько раз сталкивался с весьма странной интерпретацией дизайна.
Именно по этому я сам и верстаю как писал выше. А то вот это дизайнеры виноваты что слои не называют, нам не удобно, все путанно. А то что кроме выкл выкл слоя не умеют это вот извините, это я не хочу понять программистов не думаю о комманде и стандартах.
Те кто верстал мои макеты — не ругались, ибо я им кое что подсказывал и показывал как надо работать. Само собой безумия я не вторил — в идел как они работают.Я знаю как верстают сайты. Кое что в папках — кое что названо.
Я не трачу время на ненужную излишнюю иерархию, и они не путаются.
Признатся честно.Лично мне по барабану. Не испытываю сложностей ни с каким макетом.
> сколько раз сталкивался с весьма странной интерпретацией дизайна.
Именно по этому я сам и верстаю как писал выше. А то вот это дизайнеры виноваты что слои не называют, нам не удобно, все путанно. А то что кроме выкл выкл слоя не умеют это вот извините, это я не хочу понять программистов не думаю о комманде и стандартах.
Те кто верстал мои макеты — не ругались, ибо я им кое что подсказывал и показывал как надо работать. Само собой безумия я не вторил — в идел как они работают.Я знаю как верстают сайты. Кое что в папках — кое что названо.
Я не трачу время на ненужную излишнюю иерархию, и они не путаются.
А слабо было опубликовать это в корп аккаунте?)
Мечта программиста?
Обычно так делают веб-дизайнеры, которые умеют верстать. В прочем — это отлично.
Оффтоп:
Сейчас еще должны прийти ребята, и кричать: «Fireworks! Fireworks!»
Сейчас еще должны прийти ребята, и кричать: «Fireworks! Fireworks!»
Мне кажется те кто умеют верстать этим не будут заниматься, они верстают. Этот момент хорош, когда в макет точно не будут вноситься изменения, и верстать собирается человек второй раз загрузивший фотошоп. Удобно не спорю — но не всегда того стоит. Разве что в резюме.
Под такую иерархию в слоях можно уже плагин написать, уже сверстаный макет сохранит)
Под такую иерархию в слоях можно уже плагин написать, уже сверстаный макет сохранит)
Не знаю как моих коллег дизайнеров, но я даже немного нервничать начинаю, когда нахожу у себя какие-то нераспределенные по папкам или необозначенные слои. Зачастую открывая новый проект, первым делом создаю несколько основных папочек от которых отталкиваюсь в процессе. Я понимаю, если бы это структурирование занимало много времени, но это же дело нескольки секунд взять и выделить пару слоев той же кнопки какой-то, перетянуть их в папку и переименовать ее под имя нужного элемента.
Тем более это очень экономит время самому дизайнеру, когда, у него к примеру, 7-8 ПСД-файлов одного сайта и нужно перекинуть какой-то элемент или продублировать его из одного файла в другой. Делов то, зажать папочку и перетащил в другое окно.
Тем более это очень экономит время самому дизайнеру, когда, у него к примеру, 7-8 ПСД-файлов одного сайта и нужно перекинуть какой-то элемент или продублировать его из одного файла в другой. Делов то, зажать папочку и перетащил в другое окно.
Сталкивался с ещё одной темой особенностей работы дизайнера.
Настроят фотошоп по своему, под свои личные единицы измерения. Настроит и монитор по своему.
Получаю макет я. Своим дефолтовым фотошопом (только для нарезки). Начинаю пилить. Сдаю. Прибегает дизайнер:
— А, всё пропало! Цвета не те, масштабы не те!!!111адинадин
При этом цвета я беру пипеткой и тупо копирую код. А масштабы, тут так же, тупо выделил область, сохранил её картинкой.
И вот кто тут не прав? :)
Настроят фотошоп по своему, под свои личные единицы измерения. Настроит и монитор по своему.
Получаю макет я. Своим дефолтовым фотошопом (только для нарезки). Начинаю пилить. Сдаю. Прибегает дизайнер:
— А, всё пропало! Цвета не те, масштабы не те!!!111адинадин
При этом цвета я беру пипеткой и тупо копирую код. А масштабы, тут так же, тупо выделил область, сохранил её картинкой.
И вот кто тут не прав? :)
Тот, кто техзадание составлял :)
Виноват дизайнер. Если он доверяет макет человеку на верстку, он дожен учитывать особенности настроек цветовых профилей на дефолтном компьютере. Кто если не он должен разбираться в области подготоки изображений?
Вобще по дефолту дожно быть гладко. Админ в этом не сечет. Это узкая область. С этим очень большие путаницы до сих пор. Второе, единицы измерения не так важны, они взимокомпенируются, в фотошопе что pt что px одно и тоже к примеру. Все равно в браузере иногда не совпадают размеры шрифтов.
.А цветовой профиль поставить на тот, где первым словом «Monitor» — потом проверить что во view отключена главка Proof colors и в Proof Setup стоит Monitor RGB. Это привет от полиграфии.
А так же есть понитие цветовых профилей icc которые либо интегрируются в jpg, cмещая его цвета по этому профилю, или же цвета «зашиты» точно такие же как с этим профилем icc. (второе нужное) Поэтому бразуер в верстке не читает ICC. А открыв файл в бразуере без верстки(я про мозиллу, открыть изображение) он будет читать ICC. C этим гемор есть
небольшой. Точно так же icc не читает или читает стандартная виндовая утилита.
Важно знать что никаких профилей не прилагается в изображения при экспорте и по насыщенностри ( обычно это насыщенность страдает) файл остается таким же в двух окошках при операции save for web.
Вобще по дефолту дожно быть гладко. Админ в этом не сечет. Это узкая область. С этим очень большие путаницы до сих пор. Второе, единицы измерения не так важны, они взимокомпенируются, в фотошопе что pt что px одно и тоже к примеру. Все равно в браузере иногда не совпадают размеры шрифтов.
.А цветовой профиль поставить на тот, где первым словом «Monitor» — потом проверить что во view отключена главка Proof colors и в Proof Setup стоит Monitor RGB. Это привет от полиграфии.
А так же есть понитие цветовых профилей icc которые либо интегрируются в jpg, cмещая его цвета по этому профилю, или же цвета «зашиты» точно такие же как с этим профилем icc. (второе нужное) Поэтому бразуер в верстке не читает ICC. А открыв файл в бразуере без верстки(я про мозиллу, открыть изображение) он будет читать ICC. C этим гемор есть
небольшой. Точно так же icc не читает или читает стандартная виндовая утилита.
Важно знать что никаких профилей не прилагается в изображения при экспорте и по насыщенностри ( обычно это насыщенность страдает) файл остается таким же в двух окошках при операции save for web.
Не люблю когда мне дают макет с кучей вложенных друг в друга подпапок — в этом разбираться час только нужно. Так для порядка пару папок — больше зачем, не понимаю. Касательно конкретно случая, описанного в статье — на лицо обоюдная проблема «недоговоренности» (во сказал :). Просто нужно постоянно коммуницировать дизайнеру с технарем и технарю с дизайнером и будет вам счастье.
Я не одинок. Я уже привык все картинки переименовывать по своему, т.к. не то, что дело в именах, так еще и в разных папках все картинки, а какие-то из них еще подразумивается переиспользоват в другой папке (оптимизация работы блин, мол раз выдал картинку, другой раз разработчик сам найдет какая нужна).
Было бы интересно прочитать еще и ответ дизайнера :)
Мы у себя в процессе работы делаем такую штуку как «дизайн-документ», простая таблица из полей «описание картинки», «размер», «название», «статус готовности». Составляется он после утверждения эскизов, в результате:
— все сразу видят весь требуемый объем работ
— дизайнер, в случае если указаны приоритеты дополнительно, знает в каком порядке работать
— программист заранее знает какие они получит картинки — их названия и размеры
— руководитель видеть прогресс по процессу обработки задачи
Постепенно он уже становится меньше нужен этот документ, так как привычка к правильному именованию файлов всем прививается.
— все сразу видят весь требуемый объем работ
— дизайнер, в случае если указаны приоритеты дополнительно, знает в каком порядке работать
— программист заранее знает какие они получит картинки — их названия и размеры
— руководитель видеть прогресс по процессу обработки задачи
Постепенно он уже становится меньше нужен этот документ, так как привычка к правильному именованию файлов всем прививается.
Такие вещи надо в уставе прописывать, либо в техническом регламенте. Попробую пояснить «почему», на примере сайтов, но часто подходит и под gamedev и пр.
Обычно, за более-менее быструю и качественную работу премируют дизайнеров. Качество дизайна определяется не по именованиям файлов и слоев, а по визуальной составляющей. И ходатайствует о выписывании премии дизайнеру обычно выписывает либо непосредственный начальник, либо повыше руководство.
А теперь представляем ситуацию дизайнера. Есть у него две задачи на ближайшие 10 дней (два дизайна). На каждый допустим выделяется по 5 рабочих дней. И за каждый ему допустим светит 15 т.р и премию можно получить за каждый допустим 5 т.р., если сделает раньше.
У него будет 2 варианта:
1) Сделать быстро и классно, и делать удобный макет для дальнейшей работы с ним другими специалистами — 5 дней на дизайн.
2) Сделать быстро и классно, и забить на чужие проблемы, когда грезит премия и почести — 4 дня на дизайн + по факту начать второй проект с форой в 1 день.
Почему-то большинство выбирают 2-ой вариант(и получает 15+5+15+5+«похвала от начальства»=40т.р.+«похвала начальства»). И плевать часто хотят, на то, что у других, из-за их пофигистического отношения к технической стороне вопроса, наоборот время больше уйдет, и просрочки сдачи этапов проекта. Это уже проблема других.
Обычная человеческая жадность. И это дико раздражает.
К счастью попадаются и шикарные дизайнеры, причем даже среди новичков. Иногда таким хочется просто подойти, лично вручить бутылку коньяка и поблагодарить, за то, что уделил внимание и другим.
Обычно, за более-менее быструю и качественную работу премируют дизайнеров. Качество дизайна определяется не по именованиям файлов и слоев, а по визуальной составляющей. И ходатайствует о выписывании премии дизайнеру обычно выписывает либо непосредственный начальник, либо повыше руководство.
А теперь представляем ситуацию дизайнера. Есть у него две задачи на ближайшие 10 дней (два дизайна). На каждый допустим выделяется по 5 рабочих дней. И за каждый ему допустим светит 15 т.р и премию можно получить за каждый допустим 5 т.р., если сделает раньше.
У него будет 2 варианта:
1) Сделать быстро и классно, и делать удобный макет для дальнейшей работы с ним другими специалистами — 5 дней на дизайн.
2) Сделать быстро и классно, и забить на чужие проблемы, когда грезит премия и почести — 4 дня на дизайн + по факту начать второй проект с форой в 1 день.
Почему-то большинство выбирают 2-ой вариант(и получает 15+5+15+5+«похвала от начальства»=40т.р.+«похвала начальства»). И плевать часто хотят, на то, что у других, из-за их пофигистического отношения к технической стороне вопроса, наоборот время больше уйдет, и просрочки сдачи этапов проекта. Это уже проблема других.
Обычная человеческая жадность. И это дико раздражает.
К счастью попадаются и шикарные дизайнеры, причем даже среди новичков. Иногда таким хочется просто подойти, лично вручить бутылку коньяка и поблагодарить, за то, что уделил внимание и другим.
Да, не только мы сталкиваемся с подобным родом проблемами. На почту начали приходить письма от «незахабренных» пользователей. которые просят оставить комментарий от их имени. Одно письмо я опубликую:
Здравствуйте!
Хотел ответить вам комментарием к посту, да «незахабренный» я пока, не позволено.
Поэтому пишу тут: вот хороший сайт сделали на эту тему photoshopetiquette.com — оставьте комментом к посту, если в тему.
И спасибо за пост, в комментариях много полезного )
Andrew Yugay
Я не дизайнер, но по ссылке что то про фотошоп и слои… Да и сайт приятно оформлен.
Здравствуйте!
Хотел ответить вам комментарием к посту, да «незахабренный» я пока, не позволено.
Поэтому пишу тут: вот хороший сайт сделали на эту тему photoshopetiquette.com — оставьте комментом к посту, если в тему.
И спасибо за пост, в комментариях много полезного )
Andrew Yugay
Я не дизайнер, но по ссылке что то про фотошоп и слои… Да и сайт приятно оформлен.
таких сайтов много ilovepsd.ru
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Письмо программиста — дизайнерам (в процессе подготовки нового проекта Winx...)