Итак, очередной выпуск подкаста. На этот раз посвящен разбору ошибок дизайнеров при работе с флэшерами.
Краткое содержание.
- Как происходит создание флэш сайта.
- Дизайнер — он ленивое животное изначально, для этого его нужно дрессировать.
- Итак, кто такой дизайнер? 90% народу считающего себя дизайнерами, таковыми не являются. 90% этих людей считает, что они лучше дизайнеры, чем 90% остальных.
- 1. Дать послушать штатному дизайнеру 2. ??? 3. Profit
- Дизайнер должен знать для какой платформы он рисует.
- Дизайнер должен знать особенности предметной области, для которой делается дизайн.
- Из предоставленного дизайна должно быть понятны размеры, расстояния и расположение.
- Из дизайна или приложения к нему должно быть понятно как все это работает.
- Хороший дизайнер рисует мне все экраны, которые могут понадобиться на сайте.
- Недостающие элементы.
- Недостающие невидимые элементы.
- Удобные исходники.
- Срывание сроков и лажовые сайты.
- Давайте жить дружно.
Мнение субьективное, летящие в мою сторону тапки будут доджиться.
Audio clip: Adobe Flash Player (version 9 or above) is required to play this audio clip. Download the latest version here. You also need to have JavaScript enabled in your browser.
я как раз скоро собирался пообщаться с моей напарницей на тему best practices и общего workflow.. ситуацию, правда, несколько усугубляет 1) женский пол 2) недружба с математикой.
в дополнение я бы выделил стоящие вопросы:
1. как отучить от нецелых размеров и координат. конечно, если это какой-то персонаж или ручной рисунок – тут этот вопрос не стоит. но всякие прямоугольные блоки (кнопки/контейнеры/фоны и т.д.)… рисуется всё “на глаз” и выставляется “от руки”.. в итоге имеет прямоугольники с размерами 412.3 х 207.76, расположенный в точке (302.1, -13.5)
2. расположение графики внутри объекта относительно его нулевой точки (т. регистрации). обычно всё располагается обсолютно случайно! когда я понаблюдал за работой – понял, конечно, почему. сперва рисуется, скажем, TextField, потом преобразуется в символ, потом даблкликом входим внутрь его и уже двигаем это текстовое поле куда нам нужно..ну и ресайзим его при необходимости. в итоге если клип добавляется на сцену программно, то его визуальное месторасположение, конечно же, абсолютно непредсказуемо..
и здесь пол-дела приучить выставлять внутренности клипа в ноль.. иногда удобнее сделсть точку регистрации посередине или в каком-то углу, если этот объект потом надо привязывать к середине сцены или к какому-нибудь из углов. в таком случае расположение внутренностей начиная от нулевой точки может оказаться неполезным, потому что правильно определить размеры обекта 1) может быть сложно из-за масок в нём 2) просто ненужные вычисления
3. вопрос именования клипов и вообще организация библиотеки.. здесь у меня самого не сложилось никаких однозначных правил.. часть клипов не используется кодом, другая часть является классами и имеет смысл именовать как ИменаКлассов. третья часть используется как чисто как скины и их вроде Адобе советует именовать вроде SomeButton_overSkin… хз вобщем
пообщаться всегда полезно
kakaya eto vse huynya ne zdorovaya, lechis druzghok
designer
приятно познакомиться
очень смешной подкаст :)
прям акая-то классовая ненависть в ваших словах присутсвует :)
вы не пробовали давать дизайнерам нормальное ТЗ, в котором все просто описывать что надо сделать?
снимает 99 процентов описанных вами проблем!
послушайте еще раз внимательно
Вот если бы Валентин знал, что кроме фрилансрушной схемы “заказчик->менеджер->флэшер<-дизайнер”, существуют и другие, и что бывает такая вещь, как ТЗ на дизайн, он бы такую ерунду не говорил.
ТЗ не имеет отношение к перечисленным косякам. Про косяки с участием ТЗ я могу еще 2 часа говорить.
Мне иногда проще самому создать несложный дизайн или исправить некоторые косяки, чем пытаться заставить сделать это дизайнера.