Разработка интерфейсов в неприспособленных для этого условиях
А мы продолжаем заниматься проектированием и разработкой интерфейсов в непредназначенных для этого условиях. Причём если с веб-интерфейсами как-то приловчились реагировать динамично, и с веб-программерами отлажено, то с интерфейсами для программ всё не так ровно. Может, судьба у наших приложений такая, может, сишные возможности в самом деле далеки от перепроектирования “на лету”, может это мы все такие трудно обучаемые… Да и поставщик задач для нас, не технарь, хоть и продвинутый пользователь, как-то путается, видимо, когда мы разрабатываем веб-приложения, а когда — очередные програмки для windows.
Сценарии же разработки проекта с менеджерской точки зрения у нас похожи: сначала у поставщиков идеи (это, обычно, те, кто там, за океаном) рождается идея, которую озвучивают нашим ведущим программерам с вопросом: сможете? А чего ж не смочь, смогём! - получают ответ поставщики идеи и становятся постановщиками задачи разработать пилотную версию проекта, которая где-то там презентуется, после чего принимается решение, будет бюджет на продакш версию или нет.
К продакшн версии мы движемся достаточно хаотично, чаще всего по ходу дела добавляя-меняя интерфейс и функциональность, промежуточные версии тестирует отдел маркетинга (не украинский), который тоже выставляет свои рекомендации или требования, так же на лету исполняемые. В общем-то мы привыкли, и даже в ситуациях, когда “деньги платит” заказчик с особо изощрённым чувством прекрасного (который не видит чудеса функциональности, это для него вещи само собой разумеющиеся, но требует привлекательный, конфеточный дизайн, гламурно-глянцевый и ненавидимый программерами, не столько из-за стиля, сколько из-за мороки с реализацией, заметно повышающей время разработки, а иногда зачастую и нарушающей их стройную логичную концепцию проекта).
И замечательно, конечно, если проект “пошёл”, все рады, но это, как правило, приводит к дальнейшему, ещё более глобальному развитию. И чем дальше мы от пилотной версии, которая явилась прототипом, основой для сегодняшнего продукта, тем больше вылазит вещей, не реализуемых только из-за того, что в эту концепцию они не влазят и требуют перепроектирования с самых что ни на есть основ. И у нас всё замечательно, и работа движется, вот только… актуальная задача — выдать языковые версии проги. К дефолтной английской добавляются французская, испанская и немецкая.
И вот такая, казалось бы, мелочь пузатая, а не задача, становится трудно реализуемой из-за того, что какая-то скромная подзакладка (типа табов) по имени “IE PLUGINS” во французской версии называется “EXTENSIONS des fichiers IE”, а вспомогательный текст на специальной панели, так до пикселя размеченный, в эту панель просто не влазит. Делать панель больше? Значит, две другие, рабочие, нужно соответственно уменьшать. А с размером шрифта поработать нельзя, потому что у программеров шрифт задаётся в каком-то специальном объекте, одном на все текстовки. А размеры панелей у программеров где-то захардкодены так, что динамично изменять их в зависимости от локализации невозможно, а переделать - возможно, но (возвращаясь к вопросу о перепроектировании с нуля) “это займёт некоторое время”, которого нет у нас, нет в плане у PM`а, нет у заказчика.
Скажите мне только, почему так удивляется поставщик (сюда) задания, что чего-то сделать нельзя или можно, но “не быстро”? Задача-то месяц назад ставилась совсе-е-ем другая. Даже взять всего один элемент новшеств — те же языковые локализации, уже была бы другая концепция, изначально, и проектировалось бы другое, а ведь это только один, ближайший пример. И начинаются костыли, и разрушается логичная концепция, и у разработчиков опять состояние, близкое к тому, что это они — не профессионалы, работают над трудным, очень может быть что — неудачным проектом. А трудностей-то всего в том, что основная задача - костыли удержать да подпорки расставить. А тут ещё к ихним трудностям мы, мыши дизайнеры. У нас, видите ли, немецкая кнопочка сюда не помещается, а значит, нужно не просто текстбокс уменьшать, но и прогрессбар сдвигать, и ещё что-то там не состыковывается… А тут бы после добавления ещё (скажем так) 10% функциональности надо бы сценарии вывода интерфейсных окон изменить…
Ещё очень хорошо, просто чтобы разработчикам скучно не стало, посреди проекта уволить кого-то из команды, на ком была завязана пусть маленькая, но не самая бесполезная часть разработки. Очень весело выходит, зато у дизайнерской команды появляется новый опыт по части организации своей работы и порядка в рабочих проектах. Тоже польза… Опыт в любом случае пригодится на будущее (хотя что-то мне странно. если у нас в компании из проекта в проект команды наступают на одни и те же грабли, то где же эффект от полезного опыта?), а в текучке выделяем вот что:
- не расстраиваться, не брать на себя больше ответственности за неудачи в проекте, чем есть на самом деле; проблемы с дизайном интерфейса не всегда есть проблемами дизайнера интерфейсов.
- не искать виноватых, а пересматривать цель (или ставить новую цель) и двигаться к ней; взаимные обвинения и перекладывания ответственности — путь в никуда, в том числе и для личной кармы разработчика;
- не считать начальство абстрактным начальством, считать — партнёрами, но с функциями, отличными от своих, а значит, идти на контакт, терпеливо обучать и взаимообучаться (про условности и субординацию, правда, тоже забывать не стоит, и матом вслух ни-ни).
UPD: я ни разу не программист, так же, как и прочие дизайнеры в команде, поэтому большую часть проблем, которые нельзя решить, озвученных программерами, мы принимаем на веру. К примеру: заказчик хотел. чтобы интерфейс проги мог открываться на full screen. Программеры сказали: это не возможно в данных условиях реализовать на ближайшем этапе. Почему? Я не знаю. Но дизайнерам приходится работать в рамках фиксированных размерах окна. И таких примеров много.
зато я программист. и проблема на самом деле только одна —
в ДНКв подходах. и вот почему:1) ваша проблема локализации аж ни разу не уникальна, я скажу больше — это классическая проблема десктопных приложений. самые проблемные языки немецкий, испанский, иврит и фарси. то, что приложение будет нужно локализовывать не было выявлено на этапе разработки архитектуры проетка? минус человеку, занимавшему анализом идеи. кстати, если твои коллеги не знают, Канада официально двуязычная страна, уже поэтому можно изначально планировать локализацию, а где французский, там и испанский — Штаты-то рядом, а если языков уже три, так проще универсальное решение в планы заложить.
2) что-то где-то у кого-то захардкоджено? пусть пойдет и помоет руки с мылом. а когда вернется, пусть почитает про XML, INI и прочие форматы хранения настроек. и никогда, никогда больше так не делает.
3) у вас классический Agile или эволюционное прототипирование. и если люди, которые разрабатывают архитектуру решения, не научились делать ее гибкой…. наверное нужно поставить делать архитектуру других людей
4) если бы я был поставщиком задания и мне бы рассказали, что для того чтобы локализовать интерфейс мне нужно потратить время (а следовательно и деньги) на перепроектировать и переписать все с нуля, я бы не то что удивился. я бы решил, что моя команда либо абсолютно не компетентна (что врядли), либо просто пытается меня “обуть”.
Не-не, локализация интерфейса проходит без переписывания “с нуля”. Это я вчера невнятно изъяснялась, видимо.
Вообще я действительно довольно часто слышу “это нельзя реализовать” (на данном этапе) или “чтобы разобраться, как такое сделать, нужно N времени”, но не могу озвучить или объяснить, почему. Может, проблема в технологии, может, в том, что программеры наши опыта набираются на текущих проектах, а не на предыдущих местах работы.
С этими глобальными переменными вообще какая-то муть, я вроде и понимаю, что мне недоговаривают или вешают лапшу, но поспорить-то не могу? К примеру в одном интерфейсном окне на одной подпанельке выведены одни тексты (скажем, дерево элементов), на второй подпанельке - другие тексты (скажем, информационные пояснялки). Я вижу, что там используется РАЗНЫЙ шрифт. Он почти одинаковый. Но не один, точно. А мне программер расказывает, что и туда, и туда свойства шрифта задаются из одной глобальной переменной, поэтому он не может быть разный. Я ему в фотошопе показываю (вырезаю буковки и ставлю их рядом), что буквы не совпадают. А он мне опять про особености задания свойств для всего…
Да, а локализацию, хоть она почти и доделана, пусть и не оптимально, действительно изначально не планировали, потому что не было известно, пойдёт ли вообще эта программа в серьёзную разработку или нет.
А про перепроектирование с нуля - это не в контексте локализации, а в контексте того, что на сегодняшний день глобальная задача-то отличается уже от той, что озвучивалась поставщиком идеи и постановщиком задачи полтора-два месяца назад. От трёх простых действий к многофункциональному приложению с кучей настроек, отчётов, свойств и шедулеров. По традиционному сценарию “всё чудесно, а давайте добавим ещё такую-то фичу”.
погоджуся з Anton Naumov
Відділ планування повинен передбачати можливі шляхи розвитку проекту методами універсальності.
А з хардкода ржу. Технології є, які це обходять без проблем.
Podarok: який ще вiддiд планування? Немає у нас нiякого вiддiда планування. Тiльки программiсти та дизайнери.
ті, хто пишуть і затверджують ТЗ - ті і повинні закладати ці моменти
Це дуже цiкава думка, я обов’язково напишу канадським керівникам про ваші ради. Дякую.
гм