Comments on: onEnterFrame #9 — Дрессируем Дизайнера

By: Яски

Яски — Sat, 11 Apr 2009 04:40:27 +0000

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

By: Valentin Vladimirovich

Valentin Vladimirovich — Tue, 07 Apr 2009 16:05:30 +0000

ТЗ не имеет отношение к перечисленным косякам. Про косяки с участием ТЗ я могу еще 2 часа говорить.

By: Артём

Артём — Tue, 07 Apr 2009 15:55:49 +0000

Вот если бы Валентин знал, что кроме фрилансрушной схемы “заказчик->менеджер->флэшер<-дизайнер”, существуют и другие, и что бывает такая вещь, как ТЗ на дизайн, он бы такую ерунду не говорил.

By: Valentin Vladimirovich

Valentin Vladimirovich — Mon, 06 Apr 2009 17:03:20 +0000

послушайте еще раз внимательно

By: Valentin Vladimirovich

Valentin Vladimirovich — Mon, 06 Apr 2009 17:01:35 +0000

приятно познакомиться

By: mariarti

mariarti — Mon, 06 Apr 2009 16:37:42 +0000

очень смешной подкаст :)
прям акая-то классовая ненависть в ваших словах присутсвует :)

вы не пробовали давать дизайнерам нормальное ТЗ, в котором все просто описывать что надо сделать?

снимает 99 процентов описанных вами проблем!

By: misha

misha — Mon, 06 Apr 2009 16:29:27 +0000

kakaya eto vse huynya ne zdorovaya, lechis druzghok
designer

By: Valentin Vladimirovich

Valentin Vladimirovich — Wed, 01 Apr 2009 17:55:27 +0000

пообщаться всегда полезно

By: fljot

fljot — Wed, 01 Apr 2009 17:34:00 +0000

я как раз скоро собирался пообщаться с моей напарницей на тему best practices и общего workflow.. ситуацию, правда, несколько усугубляет 1) женский пол 2) недружба с математикой.
в дополнение я бы выделил стоящие вопросы:

1. как отучить от нецелых размеров и координат. конечно, если это какой-то персонаж или ручной рисунок – тут этот вопрос не стоит. но всякие прямоугольные блоки (кнопки/контейнеры/фоны и т.д.)… рисуется всё “на глаз” и выставляется “от руки”.. в итоге имеет прямоугольники с размерами 412.3 х 207.76, расположенный в точке (302.1, -13.5)

2. расположение графики внутри объекта относительно его нулевой точки (т. регистрации). обычно всё располагается обсолютно случайно! когда я понаблюдал за работой – понял, конечно, почему. сперва рисуется, скажем, TextField, потом преобразуется в символ, потом даблкликом входим внутрь его и уже двигаем это текстовое поле куда нам нужно..ну и ресайзим его при необходимости. в итоге если клип добавляется на сцену программно, то его визуальное месторасположение, конечно же, абсолютно непредсказуемо..
и здесь пол-дела приучить выставлять внутренности клипа в ноль.. иногда удобнее сделсть точку регистрации посередине или в каком-то углу, если этот объект потом надо привязывать к середине сцены или к какому-нибудь из углов. в таком случае расположение внутренностей начиная от нулевой точки может оказаться неполезным, потому что правильно определить размеры обекта 1) может быть сложно из-за масок в нём 2) просто ненужные вычисления

3. вопрос именования клипов и вообще организация библиотеки.. здесь у меня самого не сложилось никаких однозначных правил.. часть клипов не используется кодом, другая часть является классами и имеет смысл именовать как ИменаКлассов. третья часть используется как чисто как скины и их вроде Адобе советует именовать вроде SomeButton_overSkin… хз вобщем