Часто приходится слышать – «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. С нетерпение ждём подведения итогов.
