Станет ли WPF спасением от нашего небрежного пользовательского интерфейса?

Мы начали использовать WPF, но у нас нет дизайнеров пользовательского интерфейса - и это видно. Некоторые из наших пользовательских интерфейсов (99% в Windows Forms, приблизительная оценка) могут быть отнесены к категории «преступления против человечности». Я сделал кое-что относительно приятное для глаз с моим первым приложением WPF, но оно все еще может использовать некоторые TLC < / а>. Я должен сказать, что хотя WPF сначала сводил меня с ума, теперь я надеюсь, что мне не придется возвращаться к Windows Forms для будущих проектов.

Вам нужен не графический дизайнер, а дизайнер UI / UX.

Вообще говоря, разработчики, как известно, плохо справляются с двумя вещами: поиск узких мест в приложениях (для этого следует использовать профилировщики) и создание интерфейсов:

_{(источник: mac.com)}

Суть WPF заключается в том, что он отделяет макет пользовательского интерфейса от реального кода пользовательского интерфейса, что позволяет разработчикам и дизайнерам работать над этими двумя частями отдельно, каждая из которых использует соответствующие инструменты: Visual Studio для разработчиков и Expression для дизайнеров.

И да, если вы хотите иметь красивый интерфейс, вам следует нанять дизайнера.

Хотя дизайн интерфейса в WPF может быть независимым от программирования, это не чисто графический дизайн. Человек может работать с интерфейсом самостоятельно, но он должен иметь достаточные знания в области разработки программного обеспечения, .NET и WPF изнутри.

Вероятно, наиболее распространенный подход заключается в том, что дизайнер создает шаблоны и рекомендации для разработчиков, а затем просматривает полученные интерфейсы.

Сам WPF не улучшит внешний вид ваших приложений автоматически. На самом деле, я думаю, что большинство попыток создать первое приложение WPF обычно выглядят хуже, чем если бы разработчик просто придерживался Windows Forms. Что делает WPF, так это предоставляет творческим / дизайнерским типам большую свободу в разработке приложения за пределами обычного рабочего процесса разработки, ориентированного на код. Если ваши текущие пользовательские интерфейсы кричат: «Меня создал разработчик», то я бы сказал, что вам нужен дизайнер, независимо от того, используете ли вы WPF или нет.

WPF вас не спасет. Даже в простом html / css можно создавать гораздо лучшие пользовательские интерфейсы, чем это обычно наблюдается сейчас. Проблема в невнимании к UI дизайну (лень), а не в отсутствии инструментов. Если рядом есть кто-то, кто говорит всем, что они могут выполнять свою работу намного лучше (и показывает, как), это может обеспечить лучшие результаты.

Я читаю точную главу Pro WPF 4.5 через пять лет после публикации этого вопроса.

И мои мысли таковы: 1) Для всех внутренних бизнес-приложений, с которыми я работал за последние 10 лет, не было абсолютно никакой необходимости в специализированном UI-дизайнере. Пока разработчик умен, дизайн пользовательского интерфейса разработчика намного лучше, чем кричащий мусор, созданный дизайнерами, который никому не интересен (их волнует только функциональность, а не излишества).

2) Отделение пользовательского интерфейса от кода, предлагаемого XAML, в лучшем случае является смешанным преимуществом. Я до сих пор помню дни, когда разрабатывались приложения X-Window в Unix, и все определялось в коде. Прелесть этого заключалась в том, что все находилось под точным контролем, и если что-то пошло не так, отладить и исправить очень просто. WinForms следовали в значительной степени тому же шаблону, что и X-Windows, но с надежной IDE дизайнера графического интерфейса, которая упростила работу. Чего не хватало WinForms, так это гибкого способа создания сложной компоновки пользовательского интерфейса, который предлагали контейнеры WPF.

3) Выполнение WPF с кодом XAML + довольно подвержено ошибкам и трудно поддается отладке, особенно со сложными привязками данных. Короче говоря, это довольно неестественный способ написания кода (он работает вопреки мнению большинства разработчиков). Чарльз Петцольд довольно хорошо понимал эту психологию и объяснил, как писать приложения WPF на чистом коде, в своей книге App = Code + Markup. Однако, учитывая, что большинство разработчиков предпочитают использовать IDE для создания пользовательского интерфейса, а не кодировать с нуля, почти все приложения WPF, которые я видел до сих пор, по-прежнему используют XAML + Code Behind. MVVM вызывает много религиозного рвения, но ни одно из бизнес-приложений, которые я видел, не использует этот шаблон.