Блог NunDesign

А мы продолжаем заниматься проектированием и разработкой интерфейсов в непредназначенных для этого условиях. Причём если с веб-интерфейсами как-то приловчились реагировать динамично, и с веб-программерами отлажено, то с интерфейсами для программ всё не так ровно. Может, судьба у наших приложений такая, может, сишные возможности в самом деле далеки от перепроектирования “на лету”, может это мы все такие трудно обучаемые… Да и поставщик задач для нас, не технарь, хоть и продвинутый пользователь, как-то путается, видимо, когда мы разрабатываем веб-приложения, а когда — очередные програмки для windows.

Сценарии же разработки проекта с менеджерской точки зрения у нас похожи: сначала у поставщиков идеи (это, обычно, те, кто там, за океаном) рождается идея, которую озвучивают нашим ведущим программерам с вопросом: сможете? А чего ж не смочь, смогём! – получают ответ поставщики идеи и становятся постановщиками задачи разработать пилотную версию проекта, которая где-то там презентуется, после чего принимается решение, будет бюджет на продакш версию или нет.

К продакшн версии мы движемся достаточно хаотично, чаще всего по ходу дела добавляя-меняя интерфейс и функциональность, промежуточные версии тестирует отдел маркетинга (не украинский), который тоже выставляет свои рекомендации или требования, так же на лету исполняемые. В общем-то мы привыкли, и даже в ситуациях, когда “деньги платит” заказчик с особо изощрённым чувством прекрасного (который не видит чудеса функциональности, это для него вещи само собой разумеющиеся, но требует привлекательный, конфеточный дизайн, гламурно-глянцевый и ненавидимый программерами, не столько из-за стиля, сколько из-за мороки с реализацией, заметно повышающей время разработки, а иногда зачастую и нарушающей их стройную логичную концепцию проекта).

И замечательно, конечно, если проект “пошёл”, все рады, но это, как правило, приводит к дальнейшему, ещё более глобальному развитию. И чем дальше мы от пилотной версии, которая явилась прототипом, основой для сегодняшнего продукта, тем больше вылазит вещей, не реализуемых только из-за того, что в эту концепцию они не влазят и требуют перепроектирования с самых что ни на есть основ. И у нас всё замечательно, и работа движется, вот только… актуальная задача — выдать языковые версии проги. К дефолтной английской добавляются французская, испанская и немецкая.

И вот такая, казалось бы, мелочь пузатая, а не задача, становится трудно реализуемой из-за того, что какая-то скромная подзакладка (типа табов) по имени “IE PLUGINS” во французской версии называется “EXTENSIONS des fichiers IE”, а вспомогательный текст на специальной панели, так до пикселя размеченный, в эту панель просто не влазит. Делать панель больше? Значит, две другие, рабочие, нужно соответственно уменьшать. А с размером шрифта поработать нельзя, потому что у программеров шрифт задаётся в каком-то специальном объекте, одном на все текстовки. А размеры панелей у программеров где-то захардкодены так, что динамично изменять их в зависимости от локализации невозможно, а переделать – возможно, но (возвращаясь к вопросу о перепроектировании с нуля) “это займёт некоторое время”, которого нет у нас, нет в плане у PM`а, нет у заказчика.

Скажите мне только, почему так удивляется поставщик (сюда) задания, что чего-то сделать нельзя или можно, но “не быстро”? Задача-то месяц назад ставилась совсе-е-ем другая. Даже взять всего один элемент новшеств — те же языковые локализации, уже была бы другая концепция, изначально, и проектировалось бы другое, а ведь это только один, ближайший пример. И начинаются костыли, и разрушается логичная концепция, и у разработчиков опять состояние, близкое к тому, что это они — не профессионалы, работают над трудным, очень может быть что — неудачным проектом. А трудностей-то всего в том, что основная задача – костыли удержать да подпорки расставить. А тут ещё к ихним трудностям мы, мыши дизайнеры. У нас, видите ли, немецкая кнопочка сюда не помещается, а значит, нужно не просто текстбокс уменьшать, но и прогрессбар сдвигать, и ещё что-то там не состыковывается… А тут бы после добавления ещё (скажем так) 10% функциональности надо бы сценарии вывода интерфейсных окон изменить…

Ещё очень хорошо, просто чтобы разработчикам скучно не стало, посреди проекта уволить кого-то из команды, на ком была завязана пусть маленькая, но не самая бесполезная часть разработки. Очень весело выходит, зато у дизайнерской команды появляется новый опыт по части организации своей работы и порядка в рабочих проектах. Тоже польза… Опыт в любом случае пригодится на будущее (хотя что-то мне странно. если у нас в компании из проекта в проект команды наступают на одни и те же грабли, то где же эффект от полезного опыта?), а в текучке выделяем вот что:

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

UPD: я ни разу не программист, так же, как и прочие дизайнеры в команде, поэтому большую часть проблем, которые нельзя решить, озвученных программерами, мы принимаем на веру. К примеру: заказчик хотел. чтобы интерфейс проги мог открываться на full screen. Программеры сказали: это не возможно в данных условиях реализовать на ближайшем этапе. Почему? Я не знаю. Но дизайнерам приходится работать в рамках фиксированных размерах окна. И таких примеров много.

Из прошлого поста о верстальщиках и программерах могло сложиться (и у некоторых, судя по переписке, сложилось) неправильное впечатление: да, я писала о кривом коде, порождаемом визуальными редакторами, да, я недоумевала – как же так, не ВасиПупкины, не начинающие веб-дизайнеры — вполне себе сложившиеся программисты, и вдруг – режим Design в VisualStudio для быстрого создания типовых форм. Но ведь и фраза “а что, у нас программеры уже напрочь ручками код перестали писать?” не имеет ничего общего с рекомендациями “писать” в блокноте, ни разу. И более того, когда касается не программирования, а вёрстки – своим ребятам я категорически запрещаю верстать в notpad`e, а программерам я вообще не указ. Просто – чем больше проект, тем меньше работы для дизайнера и верстальщика в проекте (когда уже написана общая таблица стилей, уделить пять минут тюнингу новой части сервиса — когда продумана и разработана концепция иконочек, маркеров и прочих фишечек, нарисовать новую козявочку — никакой сложности), но тем больше работы, связанной с тем, что ломается и “едет” дизайн после того, как программер поработал с проектом.

И здесь работа не для тестировщика, ему-то что, он таск отправил – что видит, о том и написал. А техническому дизайнеру – разгадывать шарады, почему что-то куда-то уехало. На днях звонит канадский программер, говорит — “я там ничего такого особого не делал… а блок с прелоадером (очередная крутящаяся козявочка с надписью “Loading…”), которая показывалась всегда в центре экрана, уехала в левый верхний угол“. Что делает дизайнер? Правильно, ломится проверять таблицу стилей – вдруг где-то правила сбились, вдруг где-то и в самом деле неграмотно написано… вроде всё честно. Ломится в код – бывало такое, когда программер добавлял контейнер (div) в код “не правильно”, а где ему показалось удобнее, но в коде тоже всё корректно. В чём глюк, разумеется, нашла – раньше прелоадер показывался на довольно простых условиях, когда генерилась таблица статистики, или подгружались ещё какие-то объёмы данных; но сейчас сценарии усложнились, и блок с картинкой (с тем же, как бы, идентификатором) программеру пришлось сделать серверным контролом. Т.е. с динамически создаваемым именем идентификатора. Т.е. правила, в соответствии с которыми прелоадер показывался в центре экрана, правила, которые назначались блоку по имени идентификатора, больше не применяются – имя-то меняется. (more…)

Сержусь. На дотнет, микрософт, билагейтса и ленивых программеров. Можно сколько угодно говорить о валидной вёрстке, с умным видом вещать о том, что таблицы в гипертексте используются для табличных данных, а макет, все контейнеры документа, весь этот дизайн – для этого есть другие теги, что избыточность в вёрстке – это дурной тон, код должен быть оптимальным и совершенным, как алмазная призма. А потом с таким старанием размеченный шаблон верстальщик отдаёт программеру, и на стерильность можно забить уже через пять минут (и, кстати, не первый раз на эту тему пишу).

Из простейшей (на первый взгляд) странице с редактированием профайла юзверя только что убила четыре (!) избыточные одноячеечные таблицы. Одна обрамляющая контент, одна – для блока с общими данными юзера, одна – для Change Password если юзер кликнул сменить пароль и одна – на Confirmation, если всё прошло успешно. На четвёртой не сдержалась, подзываю программера, мол, шо за дела? Мы же договаривались – ты вообще никакую вёрстку на странице не делаешь, кидаешь свои контролы в линейном порядке, я сама разрулю, как они должны ОТОБРАЖАТЬСЯ! А он мне отвечает… я, говорит, и не добавлял никакую разметку… оно, говорит, само. Он в студии, в режиме дизайн за один клик просто добавляет целый блок (размеченную форму) для, к примеру, смены пароля – со всеми необходимыми тегами, айдишниками и прочими атрибутами. Охренительная экономия времени! И вот при таких вот автоматизированных для ускорения работы программера действиях и добавляется, автоматически же, “контейнер” в виде одноячеечной таблицы, обрамляющей этот блок.

Спрашиваю – а что, у нас программеры уже напрочь ручками код перестали писать? Или вся работа верстальщика должна заключаться в том, чтобы каждую страницу при доработке сначала долго вычищать от избыточного кода, самодобавляющегося при пользовании программистами режимом “дизайн”, от самопрописавшихся атрибутов width и height, которые появляются, когда программер в том же блин режиме “дизайн” случайно где-то что-то дёрнет? Или – ещё хуже, когда программист, утомившись программировать, вместо того, чтобы пойти чайку попить садится, и начинает “оформлять” созданные им только что формы.

И вот я вышкаливаю пару талантливых юных верстальщиков. Ругаю за ошибки при анализе сетки. Если позволяет проект – заставляю перевёрстывать, объясняю, что вёрстка веб-страниц – это как раз та отрасль, где уместно применять свои способности к анализу. Потому что на самом деле это так, прежде чем вырезать из эскиза первую картинку, прежде чем написать первую строчку кода, первый контейнер, имеет смысл потратить время на то, чтобы понять макет, продумать для него его модульную структуру; и если на недовёрстанной ещё первой странице макета появляется необходимость какому-то классу переназначить правила с помощью ! important – значит, недопроанализировал, значит – всё заново (ага, и как раз пару дней назад такое было) перевёрстывать, благо есть возможность. В отличие, к примеру, от тех ситуаций, когда приходит сюда давно свёрстанный проект на доработку программерам, и спустя месяц вспоминают про дизайн (ой-ё, Таня, тут бы поправить бы), и ты прекрасно понимаешь, что поправить “честно” не выйдет. Или вместо 30 минут надо затребовать 3-4 дня на перемакетирование и перевёрстку всего этого разросшегося уже проекта, или – переназначение доменных правил, увы. Но если есть возможность – давайте продумывать макет изначально так, чтобы не было необходимости во всех этих important`ах.

И вот они, такие продвинутые верстальщики, откроют свой проект через какое-то время, когда уже динамика, посмотрят на код страниц… На все эти самодобавившиеся и саморасплодившиеся таблицы. На разъехавшиеся контейнеры из-за самопрописавшихся в их содержимом ширин и высот. И спросят меня – Таня, а к чему был весь этот предварительный цирк с логичной и валидной вёрсткой? И я не буду знать, что им ответить. Или – как мне сегодня программер посоветовал – посоветую им так же написать гневное письмо Биллу Гейтсу, или разработчикам Visual Studio, чтобы они укротили свой сервис с такими полезными автоматическими решениями. И режим “design” в Visual Studio прибили нафиг, навсегда. О. И Visual Studio тоже прибить, и тоже навсегда. Пусть на Java переучиваются, ибо нефиг.