xaml+VS+Blend — решение всех бед?
Много дизайнерами сломано копий на тему того, что программисты как правило оперируют всего тремя цветами (красный, синий и зеленый), а добиться от программиста нормального дизайна приложения — так проще убить себя об стену.
Отчасти это правда, потому что наука юзабилити, существование которой многими причисляется к мифическим фактам, а еще большим количеством людей к сомну заокеанских диковинок, до которых у нас пока что руки не доходят ну и ладно, требует такого же к себе отношения, как и любая наука. Для того, чтобы пользователь с пеной у рта защищал ваше приложение перед другими на разных форумах, нужно сделать его простым и приятным в использовании. Вне зависимости от того, что вы пишите — программу управления атомной станцией или калькулятор. А это требует настолько обширных знаний и погружения в техники, что на изучение этого знания может уйти не один год. А когда же программисту заниматься этими вопросами? Майкрософт с кроличьим энтузиазмом плодит технологии, одна другой краше. Чтобы быть «в потоке», нужно совершенствовать не только скорость десятипальцевого слепого набора, но и технологии, которые вы используете. Мне иногда начинает казаться, что специалиста, который в совершенстве ориентируется во всех технологиях Майкрософта, попросту не существует.
Вот и получается, что для разработки интерфейса нам нужен отдельный специалист, который должен кроме непосредственно разработки внешнего вида программ постоянно совершенствоваться в СВОЕЙ професси, для того чтобы выпускаемые нами программы продолжали оставаться вкусными и приятными. И как бы программисты не выли белугой от этого факта, но такому специалисту некогда разбираться с запустанными перипетиями кода, эвентов, процедур, методов и еще бог знает чего.
Все это приводило к тому, что гуй создаваемой программы рисовался в той программе, в которой удобно работать дизайнеру. А потом программист, если дизайнер не взял на себя труд составить подробный диздок, должен был носиться и выяснять, что же конкретно должна делать программа в ответ на те или иные действия пользователя и злобно шипеть сквозь зубы, насылая на дизайнера пожелания самому как нибудь попробовать сваять что то подобное.
И тут — ВУАЛЯ! Мы получаем связку MS Visual Studio + Expression Blend. По замыслу великой и ужасной компании, программист должен был в студии в экстазе сливаться с замудреными методами, а дизайнер. легко и непринужденно воплощать свои мечты, работая с визуальной частью Бленда. Все это было обильно посыпано соусомКальве xaml как той самой недостающей части, которая должна была свести воедино все усилия. Профессионалы своего дела соединялись под его флагом для достижения максимально быстрого и клевого результата.
Проработав с данными программами некоторое время, я хочу указать Вам на то, как вольготно эти программы обращаются с таким интересным, в сущности, инструментом, как xaml. Надеюсь, что мой опыт поможет перешагнуть через некоторые грабли тем, кто только начинает свой путь среди этих технологий.
Итак, начнем.
Косяк #1
Отметим его за продуктом с именем Visual Studio, потому что за ним их водится меньше (или привык к нему я больше :) ). Все мы помним, как формировался гуй WinForms. Как правило. это было перетаскивание контролов из запасника на грядку, где они любовно окучивались, удобрялись, и потом благополучно там функционировали. Философия xaml потребовала совершенно другого подхода к созданию интерфейса. Прежде всего — его можно писать (как показывает практика, даже нужно!). Во вторых — грядка Form1 — больше не грядка. Это целый огород! Теперь грядка — это любой контрол, в который можно насажать, окучить и удобрить еще сколько душе будет угодно маленьких контролчиков. Полная вакханалиия, с гуями можно теперь творить что угодно! То, что раньше требовало плясок с бубном, теперь стало простым и изящным. Но! перестроиться на то, что код стоит творить ручками на клаве, было не просто, и поначалу мы высаживали грядки привычным для нас способом — из тулбокса.
Вот тут то и появлялась первая опасность: студия совершенно запросто могла пихнуть контрол в контрол. При этом визуально это можно было заметить, только погасив какой то элемент, или. к примеру, создав для него анимацию. Очень было интересно наблюдать, как бордер, который по замыслу автора чинно удалялся с экрана, уносил на теле совсем ничего не подозревавшую кнопку, которая как бы немым укором взирала на тебя. скрываясь за обрезом окна: «За ЧТО?!?!?!?!....» Так что работая с перетаскиванием контролов на грид, внимательно следим за тем. куда студия их запихнула, а еще лучше — забываем об этой привычке и пишем код визуальной разметки ручками.
Косяк #2
Эх, бленд, бленд… вот всем хорош, собака (лично для меня, дезигнер вопит о ностальгии по 1С и куче и маленькой кучке кнопочек и свойств), если бы не но. Первое но звучит так — почему в установившемся бленде, задача которого — работа с xaml и все — нет типа проекта Silverlight Navigation App? Куда подевалась такая замечательная особенность? Да, конечно, ее можно в последствии добавить, но почему не дать возможность создать такой проект сразу? Непонятно.
Косяк #3
Зачем отображать папку, в которой, как мы привыкли в студии, лежат подключаемые к проекту библиотеки, если в привычном способе добавления референсов — ПКМ — Add… этого пункта нет вообще? Это, наверное, чтобы дизайнер ощущал свое отличие от программиста, с превосходством демонстрируя ему, где в ЕГО программе можно добавлять сборки. Извините, конечно, но я все таки за единообразие…
Косяк #4
пространства имен в бленде… У меня складывается ощущение, что создавали данную программу люди, для которых ООП — пустой звук. Ну как можно давать возможность складировать все по папочкам, при этом сохраняя адрес папки при указании релятивного Uri, например, к картинке, но все создаваемые контролы (страницы, дочерние окна, юзер контролы) оставлять в корне проекта? Разрыв шаблона программисту обеспечен — вроде как контрол лежит в Project.Wins.Default.SomeControl, но обращаться к нему надо Project.SomeControl. Понимаю. что можно дописать ручками, но не дизайнера это дело, и уж тем более не программиста, подчищающего хвосты за дизайнером, согласитесь…
Может быть мои претензии к двум средам не обоснованы. Может быть — где то надуманны. Но тем не менее это те грабли, на которые мне приходилось наступать, и которые сильно осложняли жизнь в определенные этапы. Надеюсь, что это кому то поможет избежать моих ошибок. И господа — будьте бдительны. Хорошего дня :)
Отчасти это правда, потому что наука юзабилити, существование которой многими причисляется к мифическим фактам, а еще большим количеством людей к сомну заокеанских диковинок, до которых у нас пока что руки не доходят ну и ладно, требует такого же к себе отношения, как и любая наука. Для того, чтобы пользователь с пеной у рта защищал ваше приложение перед другими на разных форумах, нужно сделать его простым и приятным в использовании. Вне зависимости от того, что вы пишите — программу управления атомной станцией или калькулятор. А это требует настолько обширных знаний и погружения в техники, что на изучение этого знания может уйти не один год. А когда же программисту заниматься этими вопросами? Майкрософт с кроличьим энтузиазмом плодит технологии, одна другой краше. Чтобы быть «в потоке», нужно совершенствовать не только скорость десятипальцевого слепого набора, но и технологии, которые вы используете. Мне иногда начинает казаться, что специалиста, который в совершенстве ориентируется во всех технологиях Майкрософта, попросту не существует.
Вот и получается, что для разработки интерфейса нам нужен отдельный специалист, который должен кроме непосредственно разработки внешнего вида программ постоянно совершенствоваться в СВОЕЙ професси, для того чтобы выпускаемые нами программы продолжали оставаться вкусными и приятными. И как бы программисты не выли белугой от этого факта, но такому специалисту некогда разбираться с запустанными перипетиями кода, эвентов, процедур, методов и еще бог знает чего.
Все это приводило к тому, что гуй создаваемой программы рисовался в той программе, в которой удобно работать дизайнеру. А потом программист, если дизайнер не взял на себя труд составить подробный диздок, должен был носиться и выяснять, что же конкретно должна делать программа в ответ на те или иные действия пользователя и злобно шипеть сквозь зубы, насылая на дизайнера пожелания самому как нибудь попробовать сваять что то подобное.
И тут — ВУАЛЯ! Мы получаем связку MS Visual Studio + Expression Blend. По замыслу великой и ужасной компании, программист должен был в студии в экстазе сливаться с замудреными методами, а дизайнер. легко и непринужденно воплощать свои мечты, работая с визуальной частью Бленда. Все это было обильно посыпано соусом
Проработав с данными программами некоторое время, я хочу указать Вам на то, как вольготно эти программы обращаются с таким интересным, в сущности, инструментом, как xaml. Надеюсь, что мой опыт поможет перешагнуть через некоторые грабли тем, кто только начинает свой путь среди этих технологий.
Итак, начнем.
Косяк #1
Отметим его за продуктом с именем Visual Studio, потому что за ним их водится меньше (или привык к нему я больше :) ). Все мы помним, как формировался гуй WinForms. Как правило. это было перетаскивание контролов из запасника на грядку, где они любовно окучивались, удобрялись, и потом благополучно там функционировали. Философия xaml потребовала совершенно другого подхода к созданию интерфейса. Прежде всего — его можно писать (как показывает практика, даже нужно!). Во вторых — грядка Form1 — больше не грядка. Это целый огород! Теперь грядка — это любой контрол, в который можно насажать, окучить и удобрить еще сколько душе будет угодно маленьких контролчиков. Полная вакханалиия, с гуями можно теперь творить что угодно! То, что раньше требовало плясок с бубном, теперь стало простым и изящным. Но! перестроиться на то, что код стоит творить ручками на клаве, было не просто, и поначалу мы высаживали грядки привычным для нас способом — из тулбокса.
Вот тут то и появлялась первая опасность: студия совершенно запросто могла пихнуть контрол в контрол. При этом визуально это можно было заметить, только погасив какой то элемент, или. к примеру, создав для него анимацию. Очень было интересно наблюдать, как бордер, который по замыслу автора чинно удалялся с экрана, уносил на теле совсем ничего не подозревавшую кнопку, которая как бы немым укором взирала на тебя. скрываясь за обрезом окна: «За ЧТО?!?!?!?!....» Так что работая с перетаскиванием контролов на грид, внимательно следим за тем. куда студия их запихнула, а еще лучше — забываем об этой привычке и пишем код визуальной разметки ручками.
Косяк #2
Эх, бленд, бленд… вот всем хорош, собака (лично для меня, дезигнер вопит о ностальгии по 1С и куче и маленькой кучке кнопочек и свойств), если бы не но. Первое но звучит так — почему в установившемся бленде, задача которого — работа с xaml и все — нет типа проекта Silverlight Navigation App? Куда подевалась такая замечательная особенность? Да, конечно, ее можно в последствии добавить, но почему не дать возможность создать такой проект сразу? Непонятно.
Косяк #3
Зачем отображать папку, в которой, как мы привыкли в студии, лежат подключаемые к проекту библиотеки, если в привычном способе добавления референсов — ПКМ — Add… этого пункта нет вообще? Это, наверное, чтобы дизайнер ощущал свое отличие от программиста, с превосходством демонстрируя ему, где в ЕГО программе можно добавлять сборки. Извините, конечно, но я все таки за единообразие…
Косяк #4
пространства имен в бленде… У меня складывается ощущение, что создавали данную программу люди, для которых ООП — пустой звук. Ну как можно давать возможность складировать все по папочкам, при этом сохраняя адрес папки при указании релятивного Uri, например, к картинке, но все создаваемые контролы (страницы, дочерние окна, юзер контролы) оставлять в корне проекта? Разрыв шаблона программисту обеспечен — вроде как контрол лежит в Project.Wins.Default.SomeControl, но обращаться к нему надо Project.SomeControl. Понимаю. что можно дописать ручками, но не дизайнера это дело, и уж тем более не программиста, подчищающего хвосты за дизайнером, согласитесь…
Может быть мои претензии к двум средам не обоснованы. Может быть — где то надуманны. Но тем не менее это те грабли, на которые мне приходилось наступать, и которые сильно осложняли жизнь в определенные этапы. Надеюсь, что это кому то поможет избежать моих ошибок. И господа — будьте бдительны. Хорошего дня :)
0 комментариев