Главная » 2010»Июль»25 » Разработка интерфейсов в неприспособленные для этого условиях!
23:19
Разработка интерфейсов в неприспособленные для этого условиях!
Разработка интерфейсов в неприспособленные для этого условиях
А мы продолжаем заниматься проектированием и разработкой интерфейсов в непредназначенные для этого условиях. Причем если с веб-интерфейсами как-то изловчились реагировать динамично, и с веб-программерами налажено, то с интерфейсами для программ все не так ровно. Может, судьба у наших дополнений такая, может, сишные возможности в самом деле далекие от перепроектировки “на лете”, может это мы все такие тяжело те, которых учат,... Да и поставщик задач для нас, не технарь, хотя и продвинутый пользователь, как-то путается, видимо, когда мы разрабатываем веб-дополнения, а когда - очередные программки для windows.
Сценарии же разработки проекта по менеджерской точке зрения в нас похожие: сначала у поставщиков идеи (это, конечно, те, кто там, за океаном) рождается идея, которые озвучивают нашим ведущей программерам с вопросом: сможете? А чего же не смочь, смогем! - получают ответ поставщики идеи и становятся постановщиками задачи разработать пилотную версию проекта, который где-то там презентуется, после чего принимается решение, будет бюджет на продакш или версию ни.
К продакшн версии мы движемся довольно хаотически, чаще всего по течению дела прибавляя-меняя интерфейс и функциональность, промежуточные версии тестирует отдел маркетинга (не украинский), что тоже выставляет свои рекомендации или требования, так же на лете что выполняются. В общему-то мы привыкли, и даже в ситуациях, когда “деньги платит” заказчик с особенно утонченным чувством прекрасного (который не видит чудеса функциональности, это для него вещи именно собой что понимают, но требует привлекательный, конфеточный дизайн, гламурно-глянцевый и ненавидимый программерами, не столько через стиль, сколько через мороку с реализацией, которая заметно повышает время разработки, а иногда чаще всего и нарушающей их стройную логическую концепцию проекта).
И чудесно, конечно, если проект “пошел”, все советы, но это, как правило, приводит к дальнейшему, еще более глобальному развитию. И чем дальше мы от пилотной версии, которая появилась прототипом, основой для сегодняшнего продукта, тем более вылазит вещей, не реализованных только из-за того, что в эту концепцию они не влазят и требуют перепроектировки из самых что ни на есть основ. И в нас все замечательно, и работа двигается, вот только... актуальная задача - выдать языковые версии проги. К дефолтной английского прибавляются французская, испанская и немецкая.
И вот такая, казалось бы, мелочь пузатая, а не задача, становится тяжело реализованной из-за того, что какая-то скромная подзакладка (типа табов) по имени “IE PLUGINS” в французской версии называется “EXTENSIONS des fichiers IE”, а вспомогательный текст на специальной панели, так к пикселя размеченный, в эту панель просто не влазит. Делать панель больше? Значит, две другие, рабочие, нужно соответственно уменьшать. А с размером шрифта поработать нельзя, так как в программеров шрифт задается в каком-то специальном объекте, одному на все текстовки. А размеры панелей в программеров где-то захардкодены так, что динамично изменять их в зависимости от локализации невозможно, а переработать - возможно, но (возвращаясь к вопросу о перепроектировке из нуля) “это займет некоторое время”, которого нет в нас, нет в плане в PM'а, нет у заказчика.
Скажите мне только, чему так испытывает удивление поставщик (сюда) задача, которая чего-то сделать нельзя или можно, но “не быстро”? Задача-то месяц назад относилось совсе-е-им другая. Даже взять всего один элемент нововведений - те же языковые локализации, уже была бы другая концепция, изначально, и проектировало бы другое, но же это только один, ближайший пример. И начинаются костыли, и разрушается логическая концепция, и у разработчиков снова залог, близкое к тому, что это они - не профессионалы, работают над трудным, очень может быть что - неудачным проектом. А трудностей-то всего в том, что основную задачу - костыля удержать так подпорки расставить. А тут еще к ихним трудностей мы, мыши дизайнеры. У нас, видите ли, немецкая кнопочка сюда не содержится, а значит, нужно не просто текстбокс уменьшать, но и прогрессбар сдвигать, и еще что-то там не состыковывается... А тут бы после добавления еще (скажем так) 10% функциональности треба бы сценарии вывода интерфейсных окон изменить...
Еще очень хорошо, просто чтобы разработчикам скучно не стало, посреди проекта освободить кого-то из команды, на ком была завязанная пусть маленькая, но не самая напрасная часть разработки. Очень весело значит, зато у дизайнерской команды появляется новый опыт в области организации своей работы и порядка в рабочих проектах. Тоже польза... Опыт во всяком случае придастся на будущее (хотя что-то мне удивительно. если в нас в компании из проекта в проект команды наступают на те самые грабли, то где же эффект от полезного опыта?), а в текучке выделяем вот что:
не расстраиваться, не брать на себя больше ответственности за неудачи в проекте, чем есть на самом деле; проблемы с дизайном интерфейса не всегда есть проблемами дизайнера интерфейсов.
не искать виноватых, а просматривать цель (или ставить новую цель) и двигаться к ней; взаимные обвинения и перекладывания ответственности - путь в никуда, в том числе и для личной кармы разработчика;
не считать начальство абстрактным начальством, считать - партнерами, но с функциями, отличными от своих, а значит, идти на контакт, терпеливо учить и взаимообучаться (об условностях и субординации, правда, тоже забывать не стоит, и матом вслух ни-ни).
Эхо: я ни разу не программист, так же, как и другие дизайнеры в команде, поэтому большую часть проблем, которые нельзя решить, озвученных программерами, мы принимаем на веру. Например: заказчик хотел. чтобы интерфейс проги мог приоткрываться на full screen. Программеры сказали: это не возможно в данных условиях реализовать на ближайшем этапе. Чему? Я не знаю. Но дизайнерам приходится работать в рамках фиксированных размерах окна. И таких примеров много.
