Часто приходится слышать – «Delphi – среда для разработки «кривых» интерфейсов». Либо Delphi-разработчики какие-то генетически ущербные в плане создания интерфейсов. Либо сама среда провоцирует на плохой дизайн GUI. Есть повод сконцентрировать на данной проблематике своё внимание.
В начале «эпохи прикладного бума» за счёт использования средств визуальной разработки доминировала Delphi. Конечно, были и другие средства разработки приложений с оконным интерфейсом (Visual Basic, Visual Studio и т.д.), но, вспоминая ситуацию в России периода Delphi 1…3, можно достаточно обоснованно говорить широчайшем распространении этой среды. Продукт «выстрелил», прежде всего, из-за гигантского дефицита программного обеспечения. Но и языковая простота Delphi сыграла ключевую роль – очень много было инженеров, но мало программистов. Зато в Delphi люди после институтского курса за месяц могли если не стать программистами, то хотя бы разработчиками. В смысле, могли самостоятельно создавать программные продукты.
Delphi вкупе с нехитрыми навыками создания оконного интерфейса стала для многих путёвкой в IT-жизнь. Люди учились создавать ПО, руководствуясь собственными представлениями о том, каким должен быть GUI. Ситуацию усложняло то, не было правил проектирования интерфейсов. В до-дельфийском Borland C++4.x заготовка шаблона диалогового окна подразумевала вертикальное расположение кнопок [Ok] [Cancel] справа. В Delphi можно было кнопки размещать как угодно. Можно ли это считать провокацией? Ровно настолько, насколько таковой считается «свобода» в общем представлении и «гибкость» в сфере инструментов для разработки ПО.
Итак, на входе мы имеем значительное количество разработчиков, квалификация которых определялась временем на самоподготовку. Обучение проходило «по ходу дела» и за счёт «собственных ресурсов». Вполне естественно, что первые приложения поражали разнообразием своих интерфейсных форм. Если бы вместо Delphi выступала другая технология, то именно она бы была использована для массового само-обучения с вполне предсказуемыми последствиями. Если учительница русского языка в школе жалуется, что «ученики совсем не знают русский язык и пишут с чудовищными ошибками», то здесь дело не в русском языке. Английские (китайские, японские, чешские) школьники выдают не менее забавные «перлы», учась формулировать свои мысли в свободных рамках грамматики и стилистики естественного языка.
Вывод (эволюционный): в Delphi из-за её «первичности» как технологии разработки ПО сделано очень много не самых выдающихся интерфейсов. Но проблема не в Delphi, а в естественном ходе истории.
Далее, в «ранне-дельфийский период» практически любое создаваемое прикладное ПО было уникальным (в плане отсутствия аналогов). Чем эффективнее был проект, тем больше шансов было его пере-стабилизировать, заморозив изначальные, пусть и не оптимальные, компоновки GUI. Поэтому существование успешного ПО с «кривым» интерфейсом есть признак успешности!
Вывод (парадоксальный): чем успешнее bad-gui проект, тем меньше шансов сделать его лучше. А успешность достигается за счёт множества факторов, не обязательно связанных с качеством графического интерфейса.
Конечно… Если бы в Delphi все использовали MVC или какую-либо другую технику отделения интерфейса от алгоритма и логики… Но эти надежды неоправданны. Нам как бы обещают «лёгкую замену» интерфейса. Только вот интерфейс растёт с функционалом, иногда обгоняя его, иногда догоняя. Смена интерфейса – это не машину перекрасить, это кузов поменять.
Сколько раз мы слышали от пользователей: «Куда ты дел мою кнопку? Она была «кривой», но я привык. А где теперь мне её искать?» Как минимум это фиксирует не самые красивые решения, а в самых тяжелых случаях приходится «продолжать валить кнопки на форму», т.к. того требует конечный потребитель.
Вывод (неутешительный): Качество интерфейса пользователя может снижаться (не повышаться) из-за требований пользователей! Привычки пользователя — тормозной башмак на пути бронепоезда революционных улучшений интерфейса.
Программисты – народ креативный. Главный драйвер развития всех технологий – желание сделать лучше. Функционал – в функции, поцедурный код – в классы, классы – обобщить шаблонами («дженериками» в Delphi). Никто не хочет выполнять однообразно-рутинные операции и делать скучные интерфейсы. «Заказчик хочет, чтобы я написал второй Ехель!» — вот одна из главных проблем того начального периода, когда пользователь ориентировался в своих предпочтениях на продукты из состава MS Office. Но разработчику удавалось, порой, продавить свои «инсталляции».
Вывод (творческий): слишком оригинальные интерфейсы есть не признак отсутствия вкуса/знаний. Это — побочный эффект стремления к самовыражению, свойственному программистам.
Мальчики не умеют танцевать/рисовать. Отбросив весь сексизм, те�� не менее, мы должны признать, что разработка ПО во многом зона ответственности сильной половины человечества. Многие делают интерфейсы «безобразно, зато однообразно» (армейская шутка). Являются ли «дельфисты» более «мужланистыми», чем пользователи других средств разработки – не известно. Был случай в моей практике (разработка по теме для силовой гос. структуры), когда было предъявлено требование – интерфейс должен быть зелёным (в прямом смысле)! Броневик – зеленый, бортовой ноутбук – зеленый, интерфейс – тоже должен быть зелёным! А можно просто цветовую схему Windows поменять на зелёную? Нет! И чтобы все кнопки были «квадратно-гнездовые», как на пульте управления.
Вывод (бесхарактерный): «кривость» интерфейса часто определяется вкусами пользователей. Какие пользователи, такие и вкусы. А причём тут Delphi? При том, что «дельфист» покладист и несклочен вследствие визуальности среды разработки. Хотите 3 пикселя влево? Пожалуйста!
Windows как операционная система отличается консервативностью в плане интерфейса прикладных программ. С Windows 95 до Windows 7 кроме «Ribbon» (и то, как ещё смотреть на данное явление) никаких особых инноваций не предлагала (зато Windows 8 с лихвой компенсировала годами накопленную потребность в нововведениях). В дизайне на основе «классических компонентов» не было поля для поиска конкурентных преимуществ. Ведущие игроки начали «зашкуривать» интерфейсы, им хватало на это вкуса, таланта и ресурсов для приглашение профессионалов со стороны. Прикладники на��али уподобляться им, только богатая львиная шкура заменялась лоскутным одеялом из шкурок разномастных кроликов.
Общий вывод: когда мы глядим в очередной продукт с интерфейсом пользователя, поражающим своей дикостью, нужно понимать степень влияния Delphi как инструмента на конечный дизайн. Выезжая на дороги нашей страны и нервничая из-за «плохой культуры вождения», «опасной езды» и «непреднамеренного создания аварийных ситуаций» силами участников движения, мы же не обвиняем производителей автомобилей!
Скоро закончится конкурс мобильных приложений для Android, сделанных в Delphi. Будет отличный материал для обобщения техники использования «Платформы FM» для создания «мобильных интерфейсов». Подано более 300 заявок.
Всех с пятницей!
До окончания конкурса ещё 12 дней, есть разработчики, уже подавшие свои законченные проекты на рассмотрение. Пока как новые, так и старые «дельфисты» демонстрируют тонкое чувство специфики мобильных интерфейсов для Android. С нетерпение ждём подведения итогов.
В начале «эпохи прикладного бума» за счёт использования средств визуальной разработки доминировала Delphi. Конечно, были и другие средства разработки приложений с оконным интерфейсом (Visual Basic, Visual Studio и т.д.), но, вспоминая ситуацию в России периода Delphi 1…3, можно достаточно обоснованно говорить широчайшем распространении этой среды. Продукт «выстрелил», прежде всего, из-за гигантского дефицита программного обеспечения. Но и языковая простота Delphi сыграла ключевую роль – очень много было инженеров, но мало программистов. Зато в Delphi люди после институтского курса за месяц могли если не стать программистами, то хотя бы разработчиками. В смысле, могли самостоятельно создавать программные продукты.
Delphi вкупе с нехитрыми навыками создания оконного интерфейса стала для многих путёвкой в IT-жизнь. Люди учились создавать ПО, руководствуясь собственными представлениями о том, каким должен быть GUI. Ситуацию усложняло то, не было правил проектирования интерфейсов. В до-дельфийском Borland C++4.x заготовка шаблона диалогового окна подразумевала вертикальное расположение кнопок [Ok] [Cancel] справа. В Delphi можно было кнопки размещать как угодно. Можно ли это считать провокацией? Ровно настолько, насколько таковой считается «свобода» в общем представлении и «гибкость» в сфере инструментов для разработки ПО.
Итак, на входе мы имеем значительное количество разработчиков, квалификация которых определялась временем на самоподготовку. Обучение проходило «по ходу дела» и за счёт «собственных ресурсов». Вполне естественно, что первые приложения поражали разнообразием своих интерфейсных форм. Если бы вместо Delphi выступала другая технология, то именно она бы была использована для массового само-обучения с вполне предсказуемыми последствиями. Если учительница русского языка в школе жалуется, что «ученики совсем не знают русский язык и пишут с чудовищными ошибками», то здесь дело не в русском языке. Английские (китайские, японские, чешские) школьники выдают не менее забавные «перлы», учась формулировать свои мысли в свободных рамках грамматики и стилистики естественного языка.
Вывод (эволюционный): в Delphi из-за её «первичности» как технологии разработки ПО сделано очень много не самых выдающихся интерфейсов. Но проблема не в Delphi, а в естественном ходе истории.
Далее, в «ранне-дельфийский период» практически любое создаваемое прикладное ПО было уникальным (в плане отсутствия аналогов). Чем эффективнее был проект, тем больше шансов было его пере-стабилизировать, заморозив изначальные, пусть и не оптимальные, компоновки GUI. Поэтому существование успешного ПО с «кривым» интерфейсом есть признак успешности!
Вывод (парадоксальный): чем успешнее bad-gui проект, тем меньше шансов сделать его лучше. А успешность достигается за счёт множества факторов, не обязательно связанных с качеством графического интерфейса.
Конечно… Если бы в Delphi все использовали MVC или какую-либо другую технику отделения интерфейса от алгоритма и логики… Но эти надежды неоправданны. Нам как бы обещают «лёгкую замену» интерфейса. Только вот интерфейс растёт с функционалом, иногда обгоняя его, иногда догоняя. Смена интерфейса – это не машину перекрасить, это кузов поменять.
Сколько раз мы слышали от пользователей: «Куда ты дел мою кнопку? Она была «кривой», но я привык. А где теперь мне её искать?» Как минимум это фиксирует не самые красивые решения, а в самых тяжелых случаях приходится «продолжать валить кнопки на форму», т.к. того требует конечный потребитель.
Вывод (неутешительный): Качество интерфейса пользователя может снижаться (не повышаться) из-за требований пользователей! Привычки пользователя — тормозной башмак на пути бронепоезда революционных улучшений интерфейса.
Программисты – народ креативный. Главный драйвер развития всех технологий – желание сделать лучше. Функционал – в функции, поцедурный код – в классы, классы – обобщить шаблонами («дженериками» в Delphi). Никто не хочет выполнять однообразно-рутинные операции и делать скучные интерфейсы. «Заказчик хочет, чтобы я написал второй Ехель!» — вот одна из главных проблем того начального периода, когда пользователь ориентировался в своих предпочтениях на продукты из состава MS Office. Но разработчику удавалось, порой, продавить свои «инсталляции».
Вывод (творческий): слишком оригинальные интерфейсы есть не признак отсутствия вкуса/знаний. Это — побочный эффект стремления к самовыражению, свойственному программистам.
Мальчики не умеют танцевать/рисовать. Отбросив весь сексизм, те�� не менее, мы должны признать, что разработка ПО во многом зона ответственности сильной половины человечества. Многие делают интерфейсы «безобразно, зато однообразно» (армейская шутка). Являются ли «дельфисты» более «мужланистыми», чем пользователи других средств разработки – не известно. Был случай в моей практике (разработка по теме для силовой гос. структуры), когда было предъявлено требование – интерфейс должен быть зелёным (в прямом смысле)! Броневик – зеленый, бортовой ноутбук – зеленый, интерфейс – тоже должен быть зелёным! А можно просто цветовую схему Windows поменять на зелёную? Нет! И чтобы все кнопки были «квадратно-гнездовые», как на пульте управления.
Вывод (бесхарактерный): «кривость» интерфейса часто определяется вкусами пользователей. Какие пользователи, такие и вкусы. А причём тут Delphi? При том, что «дельфист» покладист и несклочен вследствие визуальности среды разработки. Хотите 3 пикселя влево? Пожалуйста!
Windows как операционная система отличается консервативностью в плане интерфейса прикладных программ. С Windows 95 до Windows 7 кроме «Ribbon» (и то, как ещё смотреть на данное явление) никаких особых инноваций не предлагала (зато Windows 8 с лихвой компенсировала годами накопленную потребность в нововведениях). В дизайне на основе «классических компонентов» не было поля для поиска конкурентных преимуществ. Ведущие игроки начали «зашкуривать» интерфейсы, им хватало на это вкуса, таланта и ресурсов для приглашение профессионалов со стороны. Прикладники на��али уподобляться им, только богатая львиная шкура заменялась лоскутным одеялом из шкурок разномастных кроликов.
Общий вывод: когда мы глядим в очередной продукт с интерфейсом пользователя, поражающим своей дикостью, нужно понимать степень влияния Delphi как инструмента на конечный дизайн. Выезжая на дороги нашей страны и нервничая из-за «плохой культуры вождения», «опасной езды» и «непреднамеренного создания аварийных ситуаций» силами участников движения, мы же не обвиняем производителей автомобилей!
Скоро закончится конкурс мобильных приложений для Android, сделанных в Delphi. Будет отличный материал для обобщения техники использования «Платформы FM» для создания «мобильных интерфейсов». Подано более 300 заявок.
Всех с пятницей!
До окончания конкурса ещё 12 дней, есть разработчики, уже подавшие свои законченные проекты на рассмотрение. Пока как новые, так и старые «дельфисты» демонстрируют тонкое чувство специфики мобильных интерфейсов для Android. С нетерпение ждём подведения итогов.
