Нет фрамеворк для чего нужен: Для чего нужен Microsoft .NET Framework?

Содержание

ASP.NET — что это, как работает и зачем нужно, основы

ASP.NET — свободно распространяемая платформа для разработки динамических сайтов и веб-приложений, созданная компанией Microsoft и являющаяся частью NET.Framework. Она является дальнейшим развитием более старой технологии Microsoft ASP и сохранила многие ее некоторые внешние признаки и функции, что упрощает переход разработчиков на использование нового инструмента.

Разработка АСП.НЕТ началась в 1997 году, когда Microsoft начала поиск новой модели веб-приложения. Первая версия была выпущена одновременно с платформой .NET Framework и позволяет писать веб-приложения и сайты на любом языке, поддерживаемом .NET. С помощью этой технологии были реализованы многие крупные веб-проекты, в том числе основной сайт разработчика, компании Microsoft.

Альтернативной модификацией этой платформы является ASP.NET Core — кроссплатформенный фреймворк с открытым исходным кодом для разработки веб-приложений. Хотя в его структуре применены иные архитектурные решения, обеспечивающие большую модульность и производительность по сравнению с предшественником, в целом оба этих продукта реализует одни и те же концепции программирования.

Что такое ASP.NET

Платформа разрабатывалась как альтернатива другому популярному инструменту веб-разработки под названием Java. Изначально опытные версии Microsoft ASP.NET (тогда они еще назывались XSP) были написаны именно на языке Java, однако у компании лицензия на использование этого языка в своих продуктах истекала в 2003 году. С учетом этой перспективы разработчики компании решили создать платформу с собственной общеязыковой средой исполнения Common Language Runtime. Она позволила разрабатывать веб-приложения на любом языке, поддерживаемом технологией .NET, — а это большинство современных языков программирования.

Использование общеязыковой среды исполнения означает, что код, написанный веб-программистом на любом языке программирования, работает в два этапа:

сначала компилируется в промежуточный язык Microsoft Intermediate Language — то есть независимо от того, на каком языке изначально была написана веб-страница, она превращалась в унифицированный документ;
затем полученная сборка на IL компилируется в низкоуровневый машинный код, который и исполняется в режиме just-in-time, то есть непосредственно перед запуском приложения.

Перед компиляцией в низкоуровневый машинный код компилятор определяет тип операционной системы и ее разрядность. Благодаря этому программисты могут создавать единый код на высокоуровневом языке для всех распространенных платформ.

Созданные в платформе ASP.NET приложения компилируются в IL только один раз, повторная компиляция осуществляется только в том случае, если в исходный код были внесены изменения. А машинный код кэшируется в системном каталоге. При этом, если приложение создается в Visual Studio, его код переписывается в IL в рамках общей компиляции проекта. Однако код веб-сайта, созданный вне какого-либо проекта, компилируется постранично при первом запросе конкретной страницы. В любом случае преобразование IL-кода приложения в машинный происходит при первом же выполнении.

В ASP.NET реализована модель объектно-ориентированного программирования. Благодаря этому она дает разработчику доступ ко всем объектам в .NET Framework. Также данная модель обеспечивает:

создание повторно применяемых классов, которые упрощают и ускоряют написание кода;
стандартизацию кода с использованием интерфейсов;
расширение существующих классов путем наследования;
объединение полезных функций в скомпилированный компонент, который можно распространять отдельно.

Другая возможность, обусловленная объектно-ориентированной моделью программирования, заключается в серверных элементах управления. Они представляют собой инкапсулированные объекты, которыми разработчики могут манипулировать с помощью кода для настройки их облика, предоставления данных и реакции на события. HTML-разметка низкого уровня, визуализируемая этими компонентами управления, скрыта. Благодаря этому разработчики могут не писать ее самостоятельно — вместо этого инкапсулированные объекты самостоятельно переписываются в соответствующие HTML-элементы после того, как веб-страница будет визуализирована.

Модели разработки в ASP.NET

Во фреймворке ASP.NET реализованы три инструмента для разработки различных веб-приложений. Каждый из них предлагает свой стиль программирования, выбор между которыми определяется типом создаваемого веб-приложения, знаниями и навыками программиста.

ASP.NET Web Forms. Эта платформа предназначена для разработки сайтов путем перетаскивания объектов и управления событиями. Фактически это визуальный конструктор веб-страниц. Благодаря наличию области конструирования и широкому набору компонентов и элементов управления можно быстро разрабатывать комплексные сайты с полноценным интерфейсом пользователя и доступом к данным. Подходит программистам, владеющим средним и расширенным уровнем быстрой разработки приложений.

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

ASP.NET WEB API. Этот фреймворк упрощает разработку служб HTTP для множества клиентов, таких как веб-браузеры и мобильные устройства. ASP.NET Web API позволяет создавать разметку HTML и основной код одновременно в одном и том же файле — это классическая модель разработки, оставшаяся еще с эпохи появления интернета. Тем не менее она идеально подходит для сборки легко масштабируемых приложений на основе платформы .NET Framework. Чаще всего эта платформа используется новичками или программистами среднего уровня.

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

Помимо этих основных платформ в состав ASP.NET WEB API входят:

Web Pages (сейчас Razor) — механизм просмотра с упрощенным синтаксисом, позволяющий добавить динамический код и доступ к данным в HTML-разметку страницы;
WebHooks — версия шаблона Webhook, позволяющая подписываться на события и публиковать их через HTTP-протокол;
СигналR — открытая программная библиотека, которая позволяет серверному коду отправлять асинхронные уведомления клиентским веб-приложениям;
HTTP-handler — обработчик запросов, поступающих веб-приложению, который представляет собой файл с программным кодом, написанным на любом из . NET-совместимых языков, без HTML-разметки, обработки событий и прочих вспомогательных технологий;
ASP.NET AJAX — расширение с клиентскими и серверными компонентами для разработки страниц с фоновым обменом информацией между веб-браузером и сервером;
Dynamic Data — компонент для создания веб-приложений, взаимодействующих с базами данных.

Преимущества ASP.NET

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

Минимизация ошибок. Большинство ошибок в исходном коде «отлавливается» платформой еще на стадии разработки. Однако, даже если какие-то баги будут пропущены системой в готовый код, они обрабатываются непосредственно при выполнении запущенной программы. Это, с одной стороны, упрощает процесс разработки, так как программисту не приходится искать ошибки вручную. С другой — повышает стабильность работы приложения за счет устранения критических багов.

Мультиязычность. Приложения в ASP.NET можно писать на большинстве современных распространенных языков программирования, так как все они поддерживаются «материнской» платформой .NET Framework. Исходный код программы преобразуется в промежуточный, который уже затем компилируется в машинный код. Благодаря поддержке множества языков программирования ASP.NET становится действительно универсальной платформой, доступной для использования программистами, изучающими разные языки программирования.

Привязка к Windows. Хотя ASP.NET разрабатывается и поддерживается Microsoft, является собственностью этой корпорации, она доступна для использования на ПК с операционными системами MacOS и Linux. Это существенно расширяет число программистов, которые могут использовать эту платформу для создания веб-приложений.

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

Простота разработки. ASP.NET создана в рамках основного подхода Microsoft к программированию как к максимально простому процессу, многие функции и стадии которого можно автоматизировать. Широкий набор элементов управления, инкапсулируемые объекты, преобразующиеся в HTML-разметку, шаблоны и другие возможности значительно упрощают создание веб-приложений, в том числе комплексных. Наличие в ASP.NET нескольких платформ позволяет программисту выбрать инструменты, соответствующие его уровню знаний и навыков.

Многофункциональность. ASP.NET обладает широким набором различных функций, компонентов, элементов управления, шаблонов страниц и т. д. Благодаря этому с помощью фреймворка можно разрабатывать сайты и веб-приложения различного размера и структуры, придавать им уникальный облик, тестировать готовые продукты и выполнять подавляющее большинство операций, связанных с разработкой. Кроме того, функционал платформы можно расширить путем установки дополнительных расширений и интеграции с .NET.Framework.

Недостатки ASP.NET

Зависимость от поставщика. ASP.NET полностью разрабатывается и поддерживается корпорацией Microsoft. Из-за этого задержка с выпуском важных обновлений (например, в безопасности) может повлиять на продолжительность разработки или качество конечного веб-приложения.

Недостаточная производительность при разработке небольших сайтов. Если сайт разрабатывается без использования Visual Studio, каждая его страница компилируется отдельно при отправлении к ней запроса. Это несколько снижает производительность небольших сайтов. В то же время этого недостатка нет при разработке больших комплексных проектов, так как в них страницы компилируются сразу.

В момент своего появления в 2002 году ASP.NET стала настоящим прорывом по сравнению не только со своей предшественницей ASP, но и с многими другими аналогами от сторонних разработчиков. Многие широко используемые сегодня идеи и модели веб-программирования впервые были реализованы именно в этой платформе. До сих пор она остается одним из самых популярных фреймворков для создания веб-приложений различного типа — от небольших одностраничных сайтов до комплексных и сложных проектов. В то же время развитие других сред разработки сделало преимущества ASP.NET не такими актуальными, что привело к созданию ее альтернативной модификации ASP Core, отличающейся модульностью и повышенной производительностью.

NET Framework — что это?

Каждый пользователь Windows сталкивался с ситуацией, когда операционная система просила его установить определенную версию .NET Framework. Эти же загадочные пакеты можно заметить в списке установленных программ. Если вы задались вопросом о том, что такое . NET Framework или зачем устанавливать .NET Framework, тогда скорее всего вы не являетесь разработчиком и поэтому вам не надо знать много об этом загадочном продукте компании Microsoft. Эта статья предоставит вам общую информацию о том, для чего нужен этот фреймворк и что он делает.

.NET Framework — что это такое?

Framework – это коллекция так называемых API (application programming interfaces) и библиотека общего кода, который разработчики могут использовать при создании своих приложений. Такие фреймворки или библиотеки экономят время и усилия, поскольку избавляют разработчика от необходимости писать уже существующий код с нуля. В NET Framework базовая библиотека кода называется Framework Class Library (FCL). С ее помощью приложение может выполнять самые разнообразные функции.

Логотип.

В .NET Framework заложены десятки тысяч строк кода, который существенно облегчает жизнь разработчикам. Считайте это такой страховкой от необходимости заново изобретать колесо. Вместо того, чтобы тратить время на написание традиционных и общих элементов приложения, разработчик может взять готовый код и затем сосредоточить свои усилия на действительно уникальных аспектах своего проекта. Кроме того, благодаря .NET Framework между приложениями установлена условная стандартизация. Таким образом часть общих функций будет работать одинаково в различных приложениях, и пользователь будет понимать, что «Открыть» или «Сохранить как» будет работать как положено, что в одном, что в другом приложении.

NET Framework также выполняет роль среды исполнения. Среда исполнения — это словно некая виртуальная машина или песочница, в котором приложение работает. В .NET эта среда называется Common Language Runtime. Когда пользователь запускает приложение, его код компилируется в машинный код внутри среды исполнения, после чего собственно и исполняется. CLR также предоставляет разработчикам другие сервисы, вроде управления памятью, потоками процессора, программными исключениями и безопасностью. Среда исполнения – это «прослойка» между приложением и железом, на котором оно работает.

Портативность – один из самых больших плюсов использования среды исполнения. Разработчик может написать код с использованием любого из поддерживаемых языков, вроде C#, C++, Visual Basic и так далее. Этот код будет работать на любом железе, которое поддерживает .NET. Хотя платформа была создана с целью работать на разном железе (не только на Windows-компьютерах), проприетарная натура .NET Framework привела к тому, что его используют только в Windows-приложениях.

Чтобы исправить это, Microsoft создала другие версии .NET. Mono – бесплатный open-source проект, созданный обеспечить совместимость между .NET-приложениями и другими платформами, в особенности Linux. .NET Core – такой же бесплатный фреймворк с открытым исходным кодом, благодаря которому разработчики могу перенести легкие модульные приложения на другие ОС. Core поддерживает macOS, Linux и Windows, включая универсальные приложения Windows.

Читайте также: Почему Microsoft Visual C++ установлено много раз.

Использование .NET Framework выгодно для всех. Разработчик пишет софт на предпочитаемом ему языке, а также уверен в том, что он будет работать всюду, где поддерживается фреймворк. Пользователь в свою очередь получает относительную стандартизацию, да и собственно сами приложения, поскольку многие из них не моглы бы существовать, не имей разработчик доступа к нужным фреймворкам.

Как установить .NET Framework

За время своего существования вышло несколько версий .NET Framework. Зачастую самые новые версии .NET уже включены в состав актуальной Windows. В этом вы можете убедиться сами, попробовав установить .NET Framework 4.7 на компьютер с Windows 10. Система сообщит, что фреймфорк уже является частью самой операционной системы.

.NET создан таким образом, чтобы обеспечить программам обратную совместимость. Иными словами, приложение, которому нужна версия .NET Framework 2, будет работать с . NET Framework 3. Часто же бывает так, что приложение не может корректно работать с более новыми версиями фреймворка, поэтому вы можете увидеть несколько версий .NET на своем компьютере, либо же система попросит вас установить старый компонент при первом запуске игры / приложения.

С выходом Windows 8 появился .NET Framework 4. Этот набор уже не был обратно совместим, но нормально уживается на одном ПК с параллельно установленным .NET 3.5 (пришел с Windows Vista), обеспечивающим обратную совместимость. Windows сама управляет всеми процессами установки .NET, поэтому пользователю фактически не надо ничего скачивать или устанавливать.

Windows 10 включает в себя .NET Framework 3.5 и .NET Framework 4.7 (Windows 10 Fall Creators Update). Они активируются в тот момент, как только первое приложение сообщит системе о необходимости во фреймворке. Вы можете включить их и вручную из интерфейса «Компоненты Windows» (см. «Что такое компоненты Windows и какие из них можно отключить»). Хотя надо сказать, что нет никакого смысла делать это, поскольку система сама сделает все за вас. Здесь надо отметить, что иногда система не может установить .NET Framework 3.5 из-за проблем в работе центра обновлений или других багов. В таком случае надо установить .NET Framework 3.5 в Windows 10 вручную.

Проблемы с .NET Framework

На современных версиях Windows существует очень малая вероятность того, что вы встретитесь с определенными проблемами в работе .NET. На старых Windows, вроде Windows XP / Vista, пользователям иногда приходилось удалять и заново устанавливать фреймворк, чтобы заставить приложение работать и внимательно следить за тем, чтобы установилась именно та версия, которая нужна приложений. Все это уже ушло в прошлое.

Если же что-то работает не так как надо и вы подозреваете .NET (что очень маловероятно), есть несколько шагов, которые можно предпринять, чтобы попытаться исправить неполадки.

Прежде всего, убедитесь в том, что у вас установлены все обновления Windows. Вполне возможно, что новое приложение требует новую версию .NET, которая еще не установлена на вашем компьютере. Microsoft рассылает обновления фреймворка через центр обновлений Windows, поэтому загляните туда и загрузите все доступные апдейты.

Второй вариант – «удалить» и вернуть обратно поддерживаемые фреймворки. Нажмите Win + R и введите optionalfeatures. В появившемся окошке снимите отметки возле .NET всех версий, перезагрузите компьютер и затем активируйте их обратно.

Третий вариант – проверить файлы Windows на целостность. Об этом описано в статье «Как исправить ошибки Windows».

Если ни один из вышеперечисленных вариантов не помог, попробуйте воспользоваться утилитой .NET Framework Repair Tool. Она поддерживает все актуальные версии фрейморка и позволяет проверить и исправить ошибки в .NET.

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

Нужна ли вашему веб-приложению интерфейсная структура?

Вероятно, вы слышали о интерфейсных фреймворках. Такие имена, как React, Vue и Angular, изобилуют учебными пособиями и дебатами Hacker News. Если вам интересно, почему и когда используются эти фреймворки и не пора ли вам внедрить их в свой проект, вы не одиноки. Несколько лет назад, когда я работал над побочным проектом Hackterms, мой собственный интерфейс стал громоздким. У меня было слабое ощущение, что внедрение фреймворка было бы правильным следующим шагом, но я имел слабое представление о том, что они сделали. (Мы вернемся к тому, как это получилось, в конце статьи.) Это то объяснение, которое я хотел получить тогда. В этом посте мы взглянем с высоты птичьего полета на проблемы, которые интерфейсные фреймворки пытаются решить, и когда вы, возможно, захотите их использовать.

В частности, мы рассмотрим:

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

Небольшое замечание: «front-end framework» ставится через дефис, так как это составное прилагательное. Однако у вашего приложения есть «внешняя часть» — существительное, без дефиса. Похулиганить со мной.

Некоторые термины для ознакомления

Мы собираемся много говорить о интерфейсных фреймворках (вы, возможно, поняли намек из названия), так что давайте обратимся к терминологии на одной странице:

Программный фреймворк — это предварительно написанное приложение. структура для вас, чтобы построить на вершине. Практически это набор файлов и каталогов, в которые вы добавляете свой собственный код и файлы. Платформа предназначена для того, чтобы помочь вам быстрее создавать приложения, решая распространенные проблемы разработки, и часто начинается с:

Стандартный код, охватывающий функции, повторно используемые большинством приложений.
Структура каталогов, часто следующая философии дизайна.
Набор принципов проектирования, с которыми часто приходится сталкиваться вашему типу приложений. Фреймворки, реализующие эти принципы, такие как Ruby on Rails, обычно называют самоуверенными .

Внешний интерфейс — это уровень представления вашего приложения. Его часто называют всем, что видит пользователь, но в более общем смысле это любой код, отвечающий за эффективное отображение данных для пользователя. Таким образом, передняя часть включает в себя создание интуитивно понятных и приятных интерфейсов, а также эффективное хранение, представление и обновление данных, полученных от задней части или API.

Интерфейсный каркас — это каркас для создания внешнего интерфейса. Обычно он включает в себя некоторый способ структурирования ваших файлов (например, с помощью компонентов или препроцессора CSS), выполнение запросов AJAX, стиль ваших компонентов и связывание данных с элементами DOM.

Развивающееся приложение

Вы можете создать простой внешний интерфейс, используя всего три файла: HTML, CSS и JavaScript. Однако по мере масштабирования вашего приложения ваши файлы будут расти вместе с ним, заполняясь непостижимыми и неподдерживаемыми файлами 9.0019 код спагетти .

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

Вы создаете первую версию этой страницы профиля с помощью трех основных технологий: HTML, CSS и JavaScript. Это работает примерно так:

При начальной загрузке страницы серверная часть изначально отправляет пустую страницу профиля с минимальным стилем. Затем и для всех будущих загрузок внешний интерфейс запрашивает пользовательские данные через AJAX.
Серверная часть отправляет некоторые общедоступные пользовательские данные в виде JSON, и вы используете JavaScript для динамического добавления элементов DOM для игровых значков и записей на страницу.
Когда вы решаете создать страницы для конкретных игр, на которых перечислены все пользователи и их записи, вы создаете новые файлы JavaScript, которые копируют большую часть кода, поскольку они используют одни и те же игровые данные.
В каждом игровом значке (и значке матча) используется один и тот же HTML-код, поэтому вы сохраняете разметку в строке JavaScript и придумываете способ вставки туда данных, специфичных для игры, ex : «{{Game Имя}}
” . Затем вы добавляете HTML-код значка на страницу для каждой игры.
Когда пользователь обновляет какое-либо значение на странице, вы можете либо считывать данные из DOM, запрашивая атрибуты, либо присоединяя прослушиватели событий к каждому элементу — получая данные, читая их из DOM.

По мере того, как MySquare становится популярным, а ваш набор данных растет, этот подход быстро становится громоздким:

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

Решить эти проблемы можно с помощью ванильного JavaScript и достаточного терпения. Благодаря планированию и предусмотрительности вы сможете структурировать свое приложение таким образом, чтобы предвидеть некоторые из этих проблем. Однако по мере роста вашего внешнего интерфейса эти проблемы будут только усугубляться — вы никогда не можете быть уверены, как будет развиваться ваше приложение.

Вы понимаете, что хранение ваших данных в DOM и бесконечное добавление HTML, хранящегося в строках JavaScript, не может быть лучшим способом справиться с этим проектом. К счастью, нет необходимости изобретать велосипед. Когда вы обнаружите, что вам нужно создать надежный, удобный в сопровождении пользовательский интерфейс, пришло время… как вы уже догадались! Фронтенд-фреймворк.

Enter, framework

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

Ваш код должен быть удобен в сопровождении: вам и другим должно быть легко читать, тестировать и изменять его.
Сложные интерфейсы обычно состоят из одних и тех же компонентов. Вы должны иметь возможность создавать и повторно использовать эти компоненты, чтобы легко создавать новые страницы.
Поскольку манипуляции с DOM выполняются медленно, необходимо выполнять как можно меньше обновлений элементов.
Вы должны легко управлять своим пользовательским интерфейсом на основе данных.
Пользовательский интерфейс должен быть последовательным и интуитивно понятным. это означает стандартизацию типографики, цвета, кнопок, элементов ввода и других элементов.
Вам не нужно заново изобретать велосипед и писать тонны шаблонов, когда дело доходит до решения этих распространенных интерфейсных задач.
У вас должен быть общий язык для общения ваших идей и шаблонов с другими разработчиками.

Различные фреймворки решают некоторые, но обычно не все из этих вопросов. Некоторые, такие как Bootstrap и SemanticUI, сосредоточены на создании удобочитаемых, удобных в сопровождении HTML и CSS, уделяя особое внимание последовательному визуальному дизайну. Другие, такие как Vue, React и Angular, успешно структурируют поток данных в вашем приложении, позволяя вам сосредоточиться на управлении данными, а не на DOM.

(У Сары Драснер есть фантастическое вступление, демонстрирующее разницу между чтением данных из DOM и сохранением их в JS. Хотя в ее примере обсуждается переход от jQuery к Vue, вы можете прочитать его как более широкий сдвиг мышления от манипуляций с DOM к сосредотачиваясь на структурах данных.)

Как бы выглядел MySquare, если бы вы внедрили популярную интерфейсную среду, такую как React? Вот несколько изменений, с которыми вы можете столкнуться:

Вы должны будете создать повторно используемые компоненты HTML/CSS/JavaScript с заполнителями данных для игровых значков, записей матчей и других общих элементов. Затем платформа будет отображать эти элементы на основе входящих данных (JSON, которые мы получаем с сервера или API). Например, если в JSON есть девять игровых записей, мы визуализируем девять 9. 0073 компонентов с автоматически вставленными данными соответствия.
Вы должны следовать шаблонной структуре каталогов для создания компонентов, сценариев и таблиц стилей таким образом, чтобы их было легко отслеживать и поддерживать. Нужно внести изменения в структуру и стиль игровых записей? Найдите небольшой автономный компонент и внесите необходимые изменения.
Вы сможете воспользоваться новейшими функциями JavaScript, а также препроцессором CSS, таким как SASS, для написания лаконичного, выразительного, современного кода. Фреймворк преобразует это в HTML/CSS/JavaScript, понятный браузерам.
Имея такую инфраструктуру, вы можете сосредоточиться на манипулировании данными, а не на DOM. Функции привязки данных нашего фреймворка будут автоматически перерисовывать соответствующие компоненты при изменении данных. Например, если вы получаете данные о новом результате совпадения с сервера, фреймворк автоматически добавит на экран еще один компонент .
Если вы столкнулись с проблемой, вы можете обратиться за помощью к сообществу фреймворка. Объяснить вашу проблему должно быть даже проще, поскольку вы следуете соглашениям фреймворка, которые помогают создавать популярные интерфейсные функции.
Поскольку популярные фреймворки часто следуют схожим принципам проектирования, было бы проще сотрудничать с другими разработчиками, даже с теми, которые не работают в вашем конкретном фреймворке — вам не нужно было бы знакомить новых разработчиков с вашей собственной пользовательской структурой кода.

Разделение ответственности

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

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

В качестве выделенного уровня просмотра вашего приложения ваш внешний интерфейс должен нести исключительную ответственность за логику вокруг:

какие элементы следует отображать или скрывать
когда запрашивать данные или отправлять обновления на сервер
когда отображать простая проверка и сообщения об ошибках
выбор стилей на основе данных

Вот два сценария MySquare: в одном архитектура следует разделению ответственности, а в другом — нарушает его. Посмотрим, сможешь ли ты понять, что есть что!

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

Вы заметили нарушение? Задняя часть не должна быть связана со стилем. Эта логика должна жить во внешнем интерфейсе, который определяет способ отображения данных . Если ваши дизайнеры хотят украсить дизайн MySquare, им не нужно беспокоиться о структурах данных.

Преимущества использования фреймворка

Давайте вспомним основные способы, которыми внедрение интерфейсного фреймворка поможет нашему быстро растущему приложению:

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

Недостатки и альтернативы

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

Недостатки

Абстрактно, служебный код: Пока вы не ознакомитесь с ним полностью, код фреймворка — это черный ящик. Может быть трудно определить, какая часть кода полезна для вашего приложения и разочаровывает при исправлении ошибок, возникающих из-за кода, с которым вы не знакомы.
Кривая обучения: Обучение эффективному использованию фреймворка требует времени. Чтобы быть продуктивным, вам необходимо понимать синтаксис, инструменты, философию и , лежащую в основе функционирования фреймворка. Для проектов, где важна скорость, изучение совершенно новой технологии может быть не лучшим использованием вашего времени.
Избыточность для небольших проектов: Если вы хотите развернуть статический сайт или сайт, каждый компонент которого уникален, вам может не понадобиться мощность и накладные расходы полноценной инфраструктуры. Все еще может быть полезно реализовать минимальную структуру или даже библиотеку — мы обсудим это в следующем разделе.
Настройка: Настройка и настройка платформы для вашего конкретного варианта использования требует времени. Если важна скорость, используйте то, что вы знаете, или то, что удобно вашей команде разработчиков.
Сильные мнения: Самоуверенная структура может показаться ограничивающей, а ее принципы проектирования могут противоречить вашим. Убедитесь, что вы изучаете конкретный фреймворк, который внедряете. Если вы предпочитаете создавать с нуля, воспользуйтесь собственным решением.
Эволюция экосистемы: Экосистема фреймворка JavaScript известна своей нестабильностью. Самый популярный фреймворк на сегодняшний день может не стать популярным в следующем году, и с этим сдвигом может быть трудно найти разработчиков и поддержку.

Альтернативы

Существует несколько альтернатив крупным средам JavaScript, таким как Vue, React и Angular. Как мы упоминали ранее, разные интерфейсные фреймворки пытаются решить разные проблемы. В зависимости от ваших потребностей вам могут подойти небольшие фреймворки и библиотеки. Кроме того, вы можете отказаться от разделения задач и использовать монолитное приложение полного стека с представлениями, отображаемыми на стороне сервера. Вот несколько альтернатив для рассмотрения:

Механизмы шаблонов : Если все, что вам нужно, — это повторно используемые компоненты, рассмотрите возможность использования механизма шаблонов, такого как Handlebars.js, EJS, Underscore.js или mustache. Эти движки позволяют хранить компоненты HTML/CSS/JavaScript и вставлять в них переменные JavaScript. В начале этой статьи я упомянул о проблемах с масштабированием моего проекта Hackterms. Оглядываясь назад, я абсолютно должен был использовать полноценный фреймворк. Однако в то время у меня было мало времени и терпения, поэтому я успешно использовал Handlebars для создания многоразовых шаблонов.

Фреймворки и библиотеки CSS : Если вы хотите создать согласованный пользовательский интерфейс, хорошим вариантом может стать такой инструмент, как Bootstrap, SemanticUI, Bulma или Tailwind. Кто-то однажды описал использование фреймворка CSS как «дизайнер, который заглядывает вам через плечо и подталкивает вас к передовым методам». Вам не нужно наследовать визуальный дизайн этих фреймворков, но для разработчика без сильного опыта проектирования может быть очень полезно знать, сколько шрифтов использовать, какие разные состояния кнопок и как выглядят интуитивно понятные формы. нравиться.

Монолитные приложения с полным стеком: Многие фреймворки с полным стеком, такие как Ruby on Rails, Meteor.js и Django, поставляются со своими собственными механизмами шаблонов, которые отображают HTML на сервере. Рендеринг на стороне сервера и монолитная архитектура — концепции, заслуживающие отдельного сообщения в блоге, но вы можете думать об этом варианте как о выборе одной фреймворка с полным стеком для всего приложения и написании уровня представления и серверной логики в единой кодовой базе. Большинство фреймворков с полным стеком позволяют вам подключать интерфейсные фреймворки по вашему выбору, но по умолчанию вы используете их собственные механизмы шаблонов. Это хорошее решение, если вы хотите использовать единую структуру для всего приложения; это также может быть быстрый способ создать прототип полнофункционального приложения.

В заключение

Интерфейсные платформы — это мощный инструмент для разработки сложных пользовательских интерфейсов. Они призывают вас создать удобную в сопровождении модульную автономную архитектуру, которая упрощает создание вашего приложения и сотрудничество с другими разработчиками. Популярные фреймворки поддерживаются поддерживающими сообществами, множеством документации и учебных пособий и предлагают проверенный в боевых условиях код, решающий распространенные проблемы, возникающие перед интерфейсами по мере их масштабирования. Фреймворки позволяют использовать самые современные функции JavaScript и предлагают инструменты, упрощающие создание прототипов приложений. Наконец, они предоставляют вам общий язык для обсуждения вашей архитектуры и проблем.

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

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

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

Большое спасибо Джеймсу Майру и Лорен Рисберг за рецензирование этой статьи, обнаружение множества ошибок и внесение замечательных предложений.

Теги: внешний интерфейс, javascript, веб-разработка

Вам не нужна структура пользовательского интерфейса — Smashing Magazine

13 мин чтения
CSS,
интерфейс,
Инструменты,
Frameworks
Поделиться в Twitter, LinkedIn

Об авторе

Джош Комо — разработчик программного обеспечения, педагог, пианист-любитель и любитель кошек. Последние несколько лет он работал инженером-программистом в таких организациях, как Хан…
Больше о
Джош ↬

Разработчики часто используют фреймворки пользовательского интерфейса, такие как Bootstrap или Material UI, надеясь, что они сэкономят кучу времени и быстро создадут профессионально выглядящее приложение. К сожалению, так дело обстоит редко. Давай поговорим об этом.

Время от времени кто-нибудь будет спрашивать у меня рекомендации по фреймворкам пользовательского интерфейса. Под «фреймворком пользовательского интерфейса» я подразумеваю любой сторонний пакет, ориентированный на предоставление стилизованных компонентов пользовательского интерфейса. Он включает в себя CSS-фреймворки, такие как Bootstrap, а также библиотеки компонентов JS, такие как Material UI или Ant Design.

Мой ответ на этот вопрос, как правило, застает людей врасплох: я не использую их и не думаю, что их следует использовать для большинства потребительских товаров. 😅

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

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

Привлекательность фреймворков пользовательского интерфейса

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

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

Это вполне разумные вещи, которые нужно хотеть, и я абсолютно понимаю привлекательность поиска решения этих проблем. Но в некоторых случаях я думаю, что есть несоответствие между ожиданием и реальностью. В других, я думаю, есть лучшие инструменты для работы.

Давайте приступим.

Профессиональный дизайн

Первая причина может быть наиболее распространенной. Есть множество разработчиков, которые хотят что-то создавать, но у которых нет опыта в дизайне. Вместо того, чтобы тратить годы на обучение дизайну, почему бы не использовать сторонний пакет, который предоставляет красиво оформленные компоненты прямо из коробки?

Вот в чем проблема, на мой взгляд: дизайн — это примерно гораздо больше, чем красивые вещи.

Недавно я получил в подарок LEGO Nintendo Entertainment System:

(Большое превью)

Это был действительно забавный набор для сборки. Если вы поклонник LEGO, я настоятельно рекомендую проверить это!

Но вот в чем дело: я смог собрать эту модель, потому что в наборе шла книга на 200 страниц, в которой мне было указано, куда класть каждый кирпичик.

Если бы мне дали все части, но не инструкции, моя NES выглядела бы намного хуже, чем она есть на самом деле. Мало иметь качественные кирпичи, нужно еще уметь их использовать.

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

Блоки в такой системе проектирования, как Material Design, были созданы талантливой командой дизайнеров. Эта команда понимает фреймворк и умеет собирать из кусочков красивые интерфейсы. У нас есть доступ к одним и тем же произведениям, но это не значит, что мы автоматически достигаем тех же результатов.

Я помню, как один дизайнер сказал, что только Google может делать приложения в стиле Material Design, которые хорошо выглядят. В Android App Store полно сторонних приложений, которые используют те же профессионально разработанные компоненты, но совсем не выглядят профессиональными.

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

Кроме того, какой бы обширной ни была библиотека, в ней никогда не будет всего необходимого. Каждое приложение и веб-сайт уникальны, и всегда будут особые требования. Создание совершенно нового компонента, который «вписывается» в существующую стороннюю дизайн-систему, — это 9.0035 чертовски тяжело .

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

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

Экономия времени

Следующая причина, по которой я слышал, заключается в том, что фреймворки пользовательского интерфейса помогают экономить время. Создание целой библиотеки компонентов с нуля — серьезное мероприятие, которое можно пропустить, полагаясь на инфраструктуру пользовательского интерфейса.

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

Несколько лет я преподавал основы веб-разработки студентам буткемпа в Университете Конкордия. Программа завершается 2-недельным персональным проектом. Учащиеся решают, что строить, и они должны это сделать. Как инструктор, я отвечал на вопросы и помогал их распутать.

Мы заметили тенденцию: учащиеся, выбравшие инфраструктуру пользовательского интерфейса, такую как Bootstrap или Material UI, быстро приступают к работе и добиваются быстрого прогресса в первые несколько дней. Но со временем они затухают. Растет разница между тем, что им нужно, и тем, что предоставляет библиотека компонентов. И они тратят столько времени на то, чтобы согнуть компоненты в правильную форму.

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

Написание собственных стилей для меня немного похоже на написание тестов: поначалу это немного медленнее, но первые усилия окупаются. В долгосрочной перспективе вы сэкономите много времени, энергии и нервов.

Удобство использования и доступность

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

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

К счастью, есть еще одна категория инструментов, которая ориентирована исключительно на удобство использования и доступность, без , предписывающего кучу стилей.

Вот некоторые из моих любимых инструментов в этой категории:

Reach UI
Набор ориентированных на специальные возможности примитивов для React. Создан Райаном Флоренсом, соавтором React Router и Remix.
Headless UI
Набор полностью доступных компонентов пользовательского интерфейса без стиля для React и Vue. Создан и поддерживается командой Tailwind.
Radix Primitives
Набор нестилизованных, ориентированных на специальные возможности компонентов для React. Эта библиотека имеет очень широкий набор включенных компонентов, много действительно полезных вещей!
React ARIA
Библиотека хуков React, которые можно использовать для создания доступных компонентов с нуля.

Примечание: Я понимаю, что этот список очень насыщен React; могут быть аналогичные инструменты для Angular, Svelte и других фреймворков, но я не так активен в этих сообществах, поэтому не уверен. Не стесняйтесь, дайте мне знать в Твиттере, если вы что-то знаете!

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

Еще после прыжка! Продолжить чтение ниже ↓

Опровержения

Я разговаривал с разработчиками на эту тему уже пару лет и слышал несколько довольно убедительных опровержений.

Знакомство

Во-первых, Дэниел Шуцсмит отметил, что «стандартные» инструменты, такие как Bootstrap, имеют одно большое преимущество: знакомство.

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

С точки зрения агентства, которое берет на себя множество краткосрочных/среднесрочных проектов, это может иметь большой смысл. Им не нужно начинать каждый новый проект с нуля. И по мере того, как команда все больше и больше осваивает этот инструмент, они учатся использовать его действительно эффективно.

Я мало работал в агентствах, поэтому мне сложно что-то сказать. Большую часть своей карьеры я работал в продуктовых компаниях. Ни одно из мест, где я работал, никогда не использовало сторонний UI-фреймворк. Мы всегда создавали что-то своими силами (например, Wonder Blocks в Khan Academy или Walrus в DigitalOcean).

Внутренние инструменты

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

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

Что насчет интерфейса Tailwind и Chakra?

Итак, я не считаю, что Tailwind или Chakra UI относятся к той же категории «фреймворков пользовательского интерфейса».

Tailwind не предоставляет готовые компоненты, но предоставляет маркеры дизайна. Как говорит Макс Штойбер, Tailwind дает разработчикам набор ограждений. Вам по-прежнему нужна дизайнерская интуиция, чтобы эффективно использовать ее, но это не так сложно, как проектирование чего-то с нуля.

Пользовательский интерфейс Chakra предоставляет стилизованные компоненты из коробки, но они очень минимальны и низкоуровневы. В основном они просто выглядят как более приятные версии стандартных значений платформы.

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

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

Моя рекомендуемая альтернатива

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

У меня есть несколько предложений.

Развитие интуиции в дизайне

Итак, вот плохие новости: я думаю, вам следует потратить немного времени на изучение некоторых основ дизайна.

Это одна из тех вещей, где нужно немногое. Вам не нужно ходить в художественную школу или посвящать годы изучению нового ремесла. Дизайн — это сложно, но мы не пытаемся стать дизайнерами мирового уровня. Наши цели намного скромнее, и вы можете быть удивлены тем, как быстро их можно достичь или как далеко вы уже продвинулись!

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

Например:

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

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

Как развить дизайнерскую интуицию?

Если вы работаете с командой разработчиков/продуктов, у вас есть огромный ресурс! Подумайте критически о дизайне, который они производят. Задавайте много вопросов — большинство дизайнеров будут рады помочь вам понять, как все устроено и почему они приняли те или иные решения. Отнеситесь к этому как к инженерной задаче. Вы можете изучить системы и процессы, которые приводят к хорошему дизайну.

Некоторое время назад я написал в блоге сообщение под названием «Эффективное сотрудничество с продуктом и дизайном». Он идет немного глубже в некоторые из этих идей.

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

Украсть

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

Вместо этого давайте попробуем найти несколько профессиональных проектов, похожих на то, что мы пытаемся построить. Вы можете искать на сайтах дизайнерских сообществ, таких как dribbble или behance, или использовать архивы, такие как awwwards.

Допустим, мы создаем стартап Uber-for-dog и пытаемся спроектировать панель управления водителем. Поиск на Dribbble по запросу «приборная панель» выдает массу интересных дизайнов:

(Большой предварительный просмотр)

Dribbble имеет тенденцию искажать «дизайн», поэтому вы можете использовать продукты из реального мира для вдохновения. Это тоже работает!

Хитрость заключается в использовании нескольких источников. Если вы украли 100% дизайна, это плагиат и дурной тон. Люди заметят, и это вызовет проблемы.

Вместо этого мы можем смешать 3 или 4 дизайна вместе, чтобы создать что-то уникальное. Например, я возьму цветовую схему с одного сайта, общий макет и интервалы с другого, а стили типографики с третьего!

Когда я рассказал об этой стратегии настоящим дизайнерам, они засмеялись и сказали, что все так делают. Я думаю, это их версия «шутки» о том, что программисты тратят половину своего времени на гугление.

Эта стратегия похожа на лайфхак. это не легко , и это требует некоторых дизайнерских отбивных. Дизайн, который вы используете для вдохновения, не будет на 100% соответствовать тому, что вы строите, и вам нужно будет использовать свою интуицию, чтобы заполнить пробелы. Но это , безусловно, , самый быстрый способ, который я нашел, чтобы придумать профессионально выглядящий дизайн без опыта дизайна.

Собираем все вместе

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

Хорошая новость: вы определенно можете создать профессионально выглядящий продукт без дизайнера! Имея несколько высококачественных эталонных дизайнов и немного дизайнерской интуиции, вы можете создать что-то, что достигает порога «достаточно хорошего», когда продукт кажется законным и «настоящим».