Комментарии

вы абсолютно правы. Потому что дизайн (очередное заимствованное слово) переводится как «проектирование». В самом широком смысле этого слова.

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

И если так судить, то дизайнеру в этом мире нет места. Или, быть может, хороший дизайнер это и есть инженер?

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

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

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

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

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

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

Ещё один более древний и примитивный пример — точильный камень (колесо). Уже даже в раннем средневековье было много разновидностей и механизмов такого колеса:

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

Всё это были разные типы интерфейсов.

Так вот, когда изобретатель очередного точильного камня думал:

— будет ли он сидеть и сам нажимать педаль
— или он упростит механизм, но приставит раба который будет раскручивать колесо рукой,

то в тот момент он был UX дизайнером.

А тот человек, который думал, какой величины будет камень, какого цвета выбрать дерево для подставки и чем скрепить деревянные жерди (гвоздями или кожаными жгутами?) и какой длины будет ручка, был UI дизайнером.

И тот способ, каким бы вы затачивали меч — назывался бы интерфейс.

Разница между UX и UI в том, что UX дизайнер планирует то, как вы будете взаимодействовать с интерфейсом и какие шаги вам нужно предпринять, чтобы сделать что-то. А UI дизайнер придумывает, как каждый из этих шагов будет выглядеть. Как видите из примеров выше, UX и UI так тесно связаны, что иногда грань между понятиями смывается. Поэтому и UX, и UI обычно занимается один дизайнер и его профессия пишется через /.

В последнее время популяризация профессии UX/UI дизайнера связана скорее с развитием цифровых технологий. А вот именно тот «бум» (когда мы стали видеть термин «UX/UI» в каждом втором объявлении о работе) связан с самим названием, которое кто-то придумал совсем недавно.

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

UX и UI — это не тренды. Технологи развиваются. Спрос на сайты растёт. Цифровые приложения появляются как грибы. А инструменты дизайна и разработки упрощаются настолько, что уже практически любой человек без знания программирования может «на коленке» сделать сайт-визитку. Вот только этот сайт должен как-то выглядеть. И не просто как абстрактный каркас из текста и кнопок. Тут программистам и нужна помощь UX/UI дизайнера.

Разделение на веб-дизайнеров и UX/UI дизайнеров появилось с развитием интернета. Со временем понадобились более узкие специалисты, которые делали бы интерфейсы именно для веб-сайтов.
Да, UI/UX дизайн — это более широкое и емкое понятие чем веб-дизайн.

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

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

Я хочу раз и навсегда поставить точку и простым понятным языком объяснить, что значит «UX/UI дизайн».

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

Цель UI/UX дизайнера — довести пользователя до какой-то логической точки в интерфейсе. Сделать так, чтобы пользователь достиг своей цели.

Что такое UX/UI, прямым текстом
(в этом разделе будут банальные фразы)

UX — это User Experience (дословно: «опыт пользователя»). То есть это то, какой опыт/впечатление получает пользователь от работы с вашим интерфейсом. Удается ли ему достичь цели и на сколько просто или сложно это сделать.

А UI — это User Interface (дословно «пользовательский интерфейс») — то, как выглядит интерфейс и то, какие физические характеристики приобретает. Определяет, какого цвета будет ваше «изделие», удобно ли будет человеку попадать пальцем в кнопочки, читабельным ли будет текст и тому подобное…

UX/UI дизайн — это проектирование любых пользовательских интерфейсов в которых удобство использования так же важно как и внешний вид.

Что такое UX и UI дизайн, другими словами

Прямая обязанность UX/UI дизайнера — это, например, «продать» товар или услугу через интерфейс. Именно на основе работы UX/UI дизайнера пользователь принимает решение: «Быть или не быть?» Нравится или не нравится. Купить или не купить.

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

UX/UI дизайн не относится только к смартфонам и веб-сайтам. Более того, профессия UX/UI дизайнера существовала с незапамятных времен. Просто раньше она так не называлась. Точнее, раньше она вообще никак не называлась, а была частью других профессий.

Вот первый пример: когда Вильгельм Шиккард в 1623 году изобретал арифмометр, он уже был UX/UI дизайнером.

Иногда нет необходимости в промежуточной среде.

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

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

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

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

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

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

Обычно это организационный процесс в первую очередь. Можно добавить новое поле, старое пометить deprecated и запланировать удаление через 1-3 года. Из минусов — бекенд одновременно поддерживает два поля. Из плюсов — обратная совместимость и контролируемый процесс перехода.

Разницы между GraphQL и REST в данном случае нету, подход и там и там применим.

Сами разработчики GraphQL как раз не поддерживают идею api versioning и смотрят в сторону mutable схемы в общем случае.

Расскажите, пожалуйста, как происходит процесс изменения схемы GraphQL. Вот, к примеру, есть система «на бою», у нее сотни клиентских приложений, у каждого клиентского приложения тысячи юзеров. И в какой-то момент какое-то поле в схеме GraphQL (скажем, идентификатор клиентского приложения, оно во всех запросах присутствует) вдруг должно быть изменено. Скажем, раньше это был простой строковый идентификатор, а теперь нужно передавать объект из двух полей: GUID и строковый идентификатор. Как это изменение должно выкатиться на прод, не задев все клиентские приложения?

Как Вы в своих реальных рабочих проектах с этим справляетесь?

Просто в REST со стандартом проблема, его по сути нет. Есть рекомендации и устоявшаяся практика. Чем Вам Method+URL+параметр не нотация?

Потому что «нотация» GraphQL создана из рассчета, что у нас волшебный сервер, который одинаково эффективно возвращает запрошенные данные. И пофиг как там GraphQL ложится на внутреннюю предметную область, аппаратные ограничения, уже реализованные способы доступа к объектам. За исключением простых случаев, ситуация когда фронтендщики диктуют схему доступа к данным, пусть и прекрываясь технологией, черевата проблемами с производительностью и неоптимальной организацией хранения данных. Потому что для фронтендщика не будут видны под капотом ключи MySQL, лимиты на внешние апи, внутренная организация кэширования. И REST, на мой взгляд, куда лучше справляется как с учетом этих особенностей, так и защитой фронтеднщиков от этих ненужных деталей.

К тому же олновесная реализация нотации GraphQL для всех сущностей системы может стоить дорого. А реализация ограниченного подмножества будет по сути не особо отличаться от REST. Только вместо ендпоинтов для сущностей нужно будет создавать ресолверы для новых сущностей.

А вот возможность получить на сервер запрос всех полей и связанных с ними записей думаю сильно плохо скажется на его здоровье. Интересно посмотреть статистику отказа в обслуживании таких endpoint’ов.

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

Просто в REST со стандартом проблема, его по сути нет. Есть рекомендации и устоявшаяся практика. Чем Вам Method+URL+параметр не нотация?

В REST вы тоже можете собирать с многих сервисов. Некоторые даже делают это в API gateway.

А вот возможность получить на сервер запрос всех полей и связанных с ними записей думаю сильно плохо скажется на его здоровье. Интересно посмотреть статистику отказа в обслуживании таких endpoint’ов.

Единая нотация

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

Возможность указания только тех полей, что нужно

В REST это тоже делалось задолго до создания GraphQL. Параметр fields в конце URL.

Можно за один запрос получить данные с разных backend-ов

Обожаю этот аргумент! Вы когда-нибудь писали кастомный резолвер, который вам соберет сложный объект по нескольким микросервисам? Это одинаковая головная боль, что для REST, что для GraphQL. Только в случае последнего вам придется писать резольвер по-настоящему общего назначения, который будет работать для всех полей и связанных объектов, и потом решать проблемы производительности с этим чудом. В случае REST такие вещи хотя бы ограничивают универсальность применения одним ендпоинтом и доступными для него спидхаками и упрощениями выборки.

Можно получать связанные данные (пользователь + его заказы, например)

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

Запросы к бекендам могут параллелиться без изменения логики в клиенте

Чтобы что?

Плюсы GraphQL:

— Единая нотация
— Возможность указания только тех полей, что нужно
— Можно за один запрос получить данные с разных backend-ов
— Можно получать связанные данные (пользователь + его заказы, например)
— Запросы к бекендам могут параллелиться без изменения логики в клиенте

Но есть и минусы:

— Секурити, точнее отсутствие
— Своя нотация запросов
— Нельзя указать * для полей — обязательно перечислять
— Скорость ниже, чем прямой вызов (но может быть быстрее за счёт параллелизма)

Вообще для UI подход GraphQL оказался очень удобным даже не смотря на минусы.

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

Сдается мне, это придумали фронтедщики, чтоб не пинать бэкендщиков по каждому чиху.

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

Что использовать в работе

Итак, REST API применяют, если:
— работают с небольшими программами, где нужно обрабатывать простые данные
— пользователи работают с ними одинаково
— нет требований к сложным запросам

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

Что использовать в работе

Итак, REST API применяют, если:
— работают с небольшими программами, где нужно обрабатывать простые данные
— пользователи работают с ними одинаково
— нет требований к сложным запросам

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

Что использовать в работе

Итак, REST API применяют, если:
— работают с небольшими программами, где нужно обрабатывать простые данные
— пользователи работают с ними одинаково
— нет требований к сложным запросам

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

Основным минусом REST API считают создание множества эндпоинтов. Работать с ним — это как уточнять что-либо в разных компаниях. Нужно звонить всем по очереди.

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

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

Архитектурный стиль GraphQL позволяет сделать запросы за один раз. Клиент передаёт названия трёх мест, запрашивает нужные данные и ждёт. GraphQL выполнит все запросы и принесёт данные из разных адресов.

GraphQL: стандарт и его особенности

GraphQL — язык запросов для управления данными графов. Он использует разные виды протоколов для передачи информации. GraphQL в основном возвращает ответы в JSON.

Главное отличие GraphQL от REST API в том, что все данные клиент может выбрать всего одним запросом, даже если они будут располагаться в разных источниках. А в REST API придётся сделать выборку и извлекать их уже оттуда.

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

GraphQL имеет три главных блока:

— Queries — запросы

— Schema — схема. Описание типов объектов и полей, принадлежащих каждому объекту

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

Для работы с графовым языком запросов есть утилита GraphiQL. Разработчик интегрирует её с Endpoint GraphQL. Он отправляет запрос серверу на предоставление своей схемы — вы получаете интерфейс для проведения тестов и изучения запросов.

Если с формированием запросов всё понятно, давайте посмотрим основные блоки кода для схем:

— Character — вид среды GraphQL

— Fields (например, name и address) — поля, заполняемые в виде объекта Character. Их находят в ответе на запрос. Каждое поле возвращает то значение, которое обрабатывает

Разберём поля подробно, потому что они составляют значительную часть возвращаемой информации. Итак, они могут быть скалярного вида, объектом, типом ввода, перечисления, объединения и интерфейсом.

Например, скалярные виды — это:

— String — определённые символы в коде UTF-8

— Int — 32-битное целое число

— Float — цифра с плавающим разделительным знаком

— Boolean — логическая информация: true или false

— ID — уникальный идентификатор. Нужен для повторной выборки объекта

GraphQL умеет анализировать синтаксис и проверять формы собственной схемой. Этот API может показаться сложным на стадии создания приложения, но подобное разделение на отдельные элементы — интересная возможность для анализа синтаксиса — позволяет получать чёткие ответы на запросы без дополнительных выборок, в отличие от REST API.