Стоит ли изучать разработку графического интерфейса для настольных компьютеров? [закрыто]

18

За последние пару лет все серьезные проекты, над которыми я работал, были либо веб-основаны, либо имели не графический интерфейс пользователя (службы, сценарии командной строки и т. Д.). Я могу собрать приложение WinForms или сделать несколько простых WPF, когда это необходимо, но я никогда не углублялся в некоторые API более низкого уровня, такие как MFC или QT.

Я понимаю, что это зависит от ситуации, но в целом все же стоит потратить время на то, чтобы хорошо изучить разработку настольных систем, или приложения перемещаются в Интернет и на мобильные устройства такими темпами, которые делают эти знания менее значимыми? Кроме того, ожидаете ли вы, что разработчики, с которыми вы работаете, будут иметь опыт работы с графическим интерфейсом?

learning education gui aubreyrhodes
источник
5
Разработка настольных приложений - это здорово, но ради любви к Кнуту не беспокойтесь о MFC. Все, что вам нужно для 95% рабочих мест приложений Windows, - это WinForms или WPF / XAML. Остальные 5% рабочих мест вы не хотите иметь.
Адам Кроссленд
1
@ Adam: +1 за «Остальные 5% рабочих мест, которые вы не хотите иметь». - Это точно. :)
Бобби Столы

Ответы:

38

Я бы сказал, да, это так. В разработке программ есть своего рода маятниковый эффект. Сначала все работало прямо на компьютере. Затем, когда компьютер стал достаточно мощным для запуска нескольких программ, они получили мейнфреймы с немыми терминалами. Но тупые терминалы действительно бесполезны с точки зрения удобства использования, поэтому, как только компьютеры стали достаточно мощными, чтобы разместить разумное количество оборудования в системе размером с терминал, у нас появились персональные компьютеры, и все работало прямо на компьютере.

Затем они изобрели Всемирную паутину, и мы вернулись к мэйнфрейму (серверу) и тупому терминалу (браузеру). Но немые терминалы все еще действительно отстают в плане удобства использования, и люди начинают переучивать уроки 30 лет назад и мы снова отклоняемся от этого. В наши дни очень популярна разработка настольных (или мобильных) приложений, которые работают локально, но в определенных целях могут подключаться к Интернету для повышения их функциональности.

Мейсон Уилер
источник
5
+1 за указание на то, что эти тренды цикличны. Однако я видел случай, когда терминальное приложение было переписано как настольное приложение, и пользователи смогли более эффективно работать с терминальным приложением.
Ларри Коулман
2
Разница с браузерами заключается в том, что они могут выполнять код в локальной системе, и эта возможность растет с каждым поколением браузеров. Следствием этого является то, что разница в удобстве использования между настольными и веб-приложениями не так уж велика. Для многих людей (включая меня) gmail более полезен, чем внешний вид. Маятник с каждым разом все меньше отклоняется и останавливается на полпути, а приложения представляют собой смесь локальных и облачных компонентов, независимо от базовой технологии.
Джори Себрехтс
13
+1, я ненавижу, когда люди начинают утверждать, что рабочий стол мертв, это смешно.
доктор Ганнибал Лектер
1
@Joeri: большинство терминалов всегда могут делать хотя бы несколько кусочков на месте. Удручающее количество JavaScript, которое я видел, делает то, что IBM 3270 (для одного примера) мог бы делать и локально.
Джерри Гроб
1
@Joeri Sebrichts - когда Gmail позволяет мне перетаскивать электронное письмо в задачу или элемент календаря, я могу с вами согласиться, но до этого времени функций будет слишком мало.
JeffO
11

Даже если вы никогда не собираетесь заниматься разработкой для настольных компьютеров, я бы посоветовал вам получить достаточно опыта, чтобы иметь обоснованное мнение о том, когда лучше использовать настольное решение поверх веб-клиента.

Билл
источник
+1: Предполагая, что «рабочий стол мертв», а приложения-хранилища являются противоположностью чистых разработчиков настольных систем, говоря: «это никогда не может быть хорошим, как веб-приложение». Выберите то, с чем вы хотите работать, но достаточно знать другого, чтобы понять его истинные преимущества / недостатки.
Стивен Эверс
8

Да, но не так, как вы думаете.

Программирование с помощью графического интерфейса не является более сложным, и при этом оно не требует специальных навыков, кроме знакомства с интерфейсом программирования с графическим интерфейсом. Подключить кнопки, окна и элементы управления не очень сложно, и это довольно просто в современных средах программирования по сравнению с первыми днями в таких вещах, как MFC. Программирование GUI - это материал, который довольно легко освоить, когда это необходимо.

Однако, хотя подключать кнопки и текстовые поля довольно просто, очень сложно знать, когда и где размещать кнопки, и разработать графический интерфейс для людей. Это очень ценный и важный навык. Тем не менее, принципы проектирования, которые применяются к нативным интерфейсам против веб очень похожи.

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

как зовут
источник
2
Особенно в эти дни пользовательский опыт отвечает за разработку программного обеспечения. Архитектура больше не отвечает.
rwong
5

Это действительно будет зависеть от вашей ситуации. Недавно я работал в компании Fortune 500, у которой было несколько проектов по преобразованию веб-приложений обратно в настольные приложения (SmartClient / Click-Once). В их конкретных обстоятельствах это имело большой смысл и устранило некоторые проблемы с юзабилити, от которых пострадали их существующие приложения.

Если вы работаете полный рабочий день, и ваша компания обычно не разрабатывает настольные приложения, то, вероятно, не имеет никакого смысла полностью использовать Winforms или WPF. Однако, если вы являетесь консультантом и хотите предложить своим клиентам другую услугу, это не может повредить.

Вальтер
источник
4

Хм, кроме GMail, Stack-Exchange и домашнего банкинга моего банка, я использую весь день не веб-программное обеспечение. Теперь, с появлением смартфонов и планшетов, веб-приложение стало для меня еще менее привлекательным (я использую свой смартфон на Facebook для клиента). Это на стороне пользователя.

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

Так что да, это все еще необходимо для изучения настольных графических сред.

Wizard79
источник
2
Вау, вы не пользуетесь поисковой системой в Интернете?
JBRWilkinson
1
@JBRWilkinson: нет, я полагаюсь на суслика. Серьезно, конечно, я пользуюсь Google весь день, но на самом деле это не замена любого настольного инструмента или приложения.
Wizard79
2

Конечно "это зависит" - но я думаю, что ваш опыт типичен. Мне редко приходилось создавать толстый клиент для любого приложения, которое я написал. Если нет конкретной причины, по которой клиент должен работать на рабочем столе (проблемы с подключением, 3D-игры и т. Д.), Я считаю, что разработчику и администраторам проще поддерживать один «экземпляр» приложения. Если у них есть навыки, необходимые для разработки веб-приложения, они должны нормально переходить в область настольных приложений.

На самом деле, я думаю, что более важно, чтобы толстый клиент-разработчик изучил программирование веб-приложений - унаследованное отсутствие состояния HTTP делает парадигму разработки приложений более сложной, чтобы обернуть голову (или, по крайней мере, вам нужно немного подумать, чем просто шлепать элементы управления на панели).

Не забывайте - у вас есть такие технологии, как Silverlight и Adobe Flex / AIR, которые могут занимать границу между настольным компьютером и веб-приложением.

Уотсон
источник
+1 для веб-разработки сложнее. Я начинал как разработчик настольных систем и должен был заняться веб-разработкой. Это определенно сложнее (очевидно, это предполагает сопоставимые задачи, что не так просто).
Бобби Столы
@Guzica - да, я столкнулся с похожим отношением хороших разработчиков, с которыми я работал, которые были привязаны к разработке приложений для настольных компьютеров. Как только они пытаются сделать это, им становится не так легко, как они думали. Я не знаю, является ли это какой-то внутренней сложностью в программировании веб-приложений, это просто другой способ программирования, и многие ваши базовые предположения о том, что может сделать система, должны измениться (в дополнение к изучению новых фреймворков).
Уотсон
Всегда труднее делать что-то с инструментами, которые более ограничены, что не делает его «более сложным». Это делает его более хлопотным.
Сэм
0

По словам команды IE9:

Не должно быть разрыва между нативными и веб-приложениями. HW ускорение, быстрый JS и закрепление сайта запускают его

Я думаю, можно с уверенностью сказать, что эти технологии станут ближе друг к другу. Если вы являетесь Java-разработчиком, разница между разработкой приложений для настольных компьютеров и веб-приложений очень мала (с помощью GWT). Не исключено, что все больше и больше «настольных» платформ разработки смогут ориентироваться на движок браузера. Также не исключено, что все больше и больше настольных приложений будут иметь сетевую модель распространения (автообновление в фоновом режиме, выполнение в «песочнице», например chrome).

Джори Себрехтс
источник
3
Это всего BS. Я работаю над приложением измерения задержки, которое должно быть расположено локально, чтобы измерять и отображать в режиме реального времени задержки доставки рыночной информации. Такие вещи НИКОГДА не будут перемещены в облако.
Тим
Это полная BS, потому что вы обнаружили смехотворно неясную потребность в локальном приложении?
Майк М.
@Tim: вы правы, что некоторые приложения всегда будут локальными. Также верно, что другие приложения никогда не могут быть локальными (например, Google Translate). Но локальный запуск не означает, что он не приходит из облака. Chrome работает локально, но является облачным приложением (у вас мало контроля над тем, что это за «версия»). Есть попытки связать выполнение нативного кода с платформами браузера (Google NaCl) и попытки связать веб-языки с нативными приложениями (Adobe Air).
Джори Себрехтс
1
@ Майк М - это не до смешного неизвестно. На своей предыдущей работе я работал над корабельным программным обеспечением ВМФ. Таких, скорее всего, тоже не будет в облаке. Домены, в которых я работаю, скорее всего, не будут мигрировать - они должны быть локальными по причинам задержки и аппаратного интерфейса. Сеть хороша, но некоторые из нас все еще работают в родной области приложений по причине.
Тим
@ Тим, я хочу сказать, что вы нашли сценарий, который не выдерживает критики. Автор осознает это, когда говорит МОСТ. Вы придумали контрапункт, и это здорово. Вы никоим образом не доказали, что все это не имеет под собой никаких оснований. Конечно, будут времена, когда он должен быть локальным по множеству причин. Но для подавляющего большинства добавьте какой-нибудь оптоволоконный кабель, и ваши 1200 миль могут быть преодолены за 10 миллисекунд? Как пользователь, я бы согласился, чтобы каждое из моих приложений для настольных компьютеров занимало 10 миллисекунд дольше для загрузки формы.
Майк М.