Русский
Русский
English
Статистика
Реклама

Ui/ux

Figma делаем дизайн компонентов, пригодный для экспорта в код

15.02.2021 08:08:38 | Автор: admin

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

Начнём с простого

Нарисуем лист вью с иконкой, и сгенерируем вёрстку.

Так выглядит примерная структура нашего элемента списка - слева иконка, и далее текст.

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

Так, со структурой разобрались, поняли что нам примерно нужно сделать, теперь приступаем непосредственно к дизайну. Для этого мы возьмём один элемент, и сделаем его на основе компонентов Фигмы и применим к нему Auto layout. Сначала объединим текст и иконку, добавим отступы, сделаем выравнивание по высоте в середине, и по левому краю. Получится так

Далее нам нужно создать два элемента, расположить их друг под другом по высоте, и объединить их Auto layout. В целом всё кажется готовым, но на самом деле, если вы поменяете длинну текста, то элементы не будут гибко подстраиваться друг под друга.

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

В результате у нас должен получиться такой вот список.

Запускаем генератор кода.

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

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

Так, всё работает, кроме иконок, которые нам нужно копировать как SVG и вставить в наш код. Делается это вот так

Заменяем наши иконки в вёрстке (я вставил прям в разметку, но вы можете и так как вам удобно - по url на пример.).

Получаем результат, который идентичен нашему в Фигме.

Подробнее про Auto layout тут.

Результат тут.

Сложнее. Рисуем карточку товара.

Нашей целью будет сделать так, чтобы при генерации кода, наша карточка была выполнена на основе display: flex; - CSS модели, для построения гибких контейнеров.

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

Моя сгенерированная разметка доступна по ссылке ниже. Вы можете посмотреть и попробовать сами.https://play.tailwindcss.com/2VhmQJIJDl

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

Подробнее..

Разработка интерфейса Драйва отзапуска стартапа доглубокого анализа UI. Доклад Яндекса

07.11.2020 12:07:53 | Автор: admin
Первая версия сервиса Яндекс.Драйв была запущена за два месяца после начала разработки, а затем практики пришлось постепенно менять. Руководитель мобильной разработки Драйва Кирилл Кожухар обсудил все шаги при создании и проработке дизайна, поделился своим видением того, как приложение должно эволюционировать, и проанализировал, как менялся UI.

Всем привет, меня зовут Кирилл, я занимаюсь iOS-версией Яндекс.Драйва. Мы решили подготовить не совсем технический доклад, обсудить то, как развивается проект на самых ранних этапах, когда только все начинается, закладывается. Это так называемый этап MVP.

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

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

Стоит рассказать для тех, кто не в курсе, что такое Яндекс.Драйв. Это такой сервис каршеринга, который сейчас работает в трех городах России в Москве, Санкт-Петербурге и Казани. (...)



Россия сейчас является самым быстрорастущим рынком каршеринга в мире. На Москву приходится порядка 77% всего российского автопарка. То есть 77% автомобилей каршеринга сконцентрировано в России. И чтобы построить такой сервис, требуется очень много времени и огромное количество ресурсов, как человеческих, так и финансовых.



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

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

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

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



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

И сама разработка. Тут все понятно, это люди, которые непосредственно реализовывают все на практике и гарантируют, что все будет работать. У команды, которая онлайн, как правило, вырабатывается классический подход. Мы так его называем, это подход к разработке продукта, который практикуется, наверное, в процентах 90 всех компаний.



Это примерная схема, не надо воспринимать ее строго. Product owner все планирует и отвечает за продукт. Помощники, то есть менеджеры, разрабатывают фичи, придумывают, как это будет работать, занимаются планированием. И есть сама мобильная разработка.

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

У этой системы, наверное, все хорошо, раз она применяется в 90% стартапов и сервисов. Но нам примерно полтора года назад, когда мы запускались, это не подходило. У нас было крайне мало времени, два месяца, и 18 человек в команде. Из них пять человек отвечали за разработку. Нам нужно было запустить сервис с нуля.

Мы поняли, что нужно как-то это оптимизировать. У нас на старте не было менеджеров как таковых. Product owner взаимодействовал сразу с мобильной разработкой, с дизайном, с серверной разработкой. Таким образом мы экономили на общении, это нам помогало.

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



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

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

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

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

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



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

У нас релизный цикл был дней пять. Мы выпускали в течение пяти дней обновление приложение для магазина. Через пять дней после этого мы опять выпускали обновление. Это позволило нам довольно часто пушить обновление и очень сильно менять приложение.

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

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

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

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



Изначально мы хотели сделать так, чтобы разработка фич на обеих платформах была параллельной.

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

После того, как мы отдаем это в iOS-разработку, фича реализовывается и отдается в Q&A. Параллельно начинается ее разработка для Андроида. Когда Q&A все протестировали на iOS, они начинают тестировать то, что сделали Андроид-разработчики. Таким образом мы оптимизировали время, это позволило нам не простаивать в плане тестирования.

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



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

Все изменения, которые мы вносили, были свободными. Есть два типа команд, которые что-то разрабатывают.

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

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

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



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

Это самая первая версия дизайна, которую мы выпустили в продакшен. Просто ужасно, если сейчас посмотреть. Тогда нас это это устраивало: как уже сказал, прошло всего два месяца, мы были заняты решением проблем. Главное, что мы выпустили приложение и все замечательно, все работало, нажималось. Но как только стали появляться первые проблемы, мы поняли, что очень сильно ошиблись с UI. Как только стали получать первый фидбек, пришло осознание проблем. И проблемы, которые были у этого UI, были довольно-таки простые.

Первая проблема акцент пользователя.

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



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

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



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



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



Последняя проблема последовательность. Пользователь, находясь на этом экране и на других также, не понимал, что ему нужно сделать. Было слишком много путей развития User flow. Это нужно было менять, преобразовывать и устранять. Решения всего этого довольно-таки банальны, мы не стали придумывать ничего нового.



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

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

Третий и четвертый пункт довольно новые вещи, которые мы позаимствовали у прогрессивной части дизайна: морфирование интерфейса и контекст действий.

Морфирование интерфейса появилось совсем недавно. Это когда вы пытаетесь перевести свой интерфейс из одного состояния в другое, но переводите его не моментально, не через какой-нибудь fade in/fade out, а делаете это выделением общих элементов и переносом их из одного состояния в другое.

В Android для этого есть transition API. В iOS такого API нет, но Apple сами используют этот подход в приложении Photos. Они используют scaling: когда вы переходите от года к месяцу, от месяца к неделе и от недели ко дню, то весь интерфейс скейлится. И это было довольно забавно поначалу. Но потом все поняли, что это работает и этим удобно пользоваться. Такой же подход мы попытались использовать у себя.

Четвертое контекст действий. Это когда вы разрабатываете UI, не просто прорабатывая экраны, а решаете проблемы. Вы выделяете какие-то user flow, своеобразные user-сценарии, которые позволяют вам решать какую-то проблему.

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

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



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

Естественно, этот интерфейс не позволяет вам добавлять слишком много объектов на карту: если у вас больше 100 машин на карте, все превращается в кашу. Мы решили разбить уровень зума на несколько элементов, частей.

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

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

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

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

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

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



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

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



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

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

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

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

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

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

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

Это решило проблему. Мы увеличили конверсию в заказ, поскольку наша теория о том, что пользователи очень часто выбирают машину, основываясь на цене, была верной. Таким образом мы проверили ее на практике.

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

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



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

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

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

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



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

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

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

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

Мы ничего не придумали и просто написали максимально официальным языком, как это делают в объявлениях: Уважаемые краткосрочные арендаторы автомобилей! Раздел будет закрыт по усмотрению администрации. И подпись Администрация. Мы еще хотели шрифт Comic Sans добавить, но это было бы слишком.



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

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

У нас примерно в течение года после старта вообще не было код-ревью. Потому что не было проблем, которые это код-ревью могло решить. Вот, собственно, и всё.
Подробнее..

Супераппы мертвы. Да здравствуют супераппы! Доклад Яндекса

28.12.2020 10:22:36 | Автор: admin
Всем привет, меня зовут Илья Богин, я руковожу отделом разработки мобильного портального приложения Яндекса и Яндекс.Браузера для Android/iOS. В докладе на конференции YaTalks я решил поговорить о том, что сейчас понимается под супераппами, какие задачи они решают, чем отличаются азиатские и российские подходы к созданию супераппов. Еще я поделился опытом своей команды: какие технические вызовы бросает суперапп, может ли в этой роли выступать веб-платформа, что мы поняли в процессе разработки и почему в итоге решили, что мы не суперапп.

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

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

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



Мне подсказывают, что не все знают мордорский диалект. Что ж, у меня есть стихотворный, красивый, поэтический перевод на русский язык. Думаю, все догадались, что речь идет о том самом стихе о кольце всевластия. При чем здесь суперапп? Суперапп по концепции очень похож на кольцо всевластия.



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

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



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



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

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

Мы можем перейти к конкретным примерам. На азиатском и южноамериканском рынке эти системы супераппов развиваются очень активно. На российский рынок они стали проникать чуть позже, только начинают развиваться. В качестве классического примера закрытой экосистемы можно представить приложение Яндекс Go, которое выросло из приложения Яндекс.Такси. (...)



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

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

Технические вызовы при создании супераппа


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

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



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



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

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

Следующий момент, который я бы обязательно включил в понятие качественного user experience это широкий доступ сервисов к нативным возможностям девайса. Современный мобильный телефон или планшет очень мощное устройство с большим количеством дополнительных нативных возможностей. Нативная оплата: Apple Pay, Google Pay, Huawei Pay; куча дополнительных инструментов, гироскопы, AR. И конечно, чем больше возможностей мы даем сервисам внутри нашего супераппа, тем более качественные и инновационные сервисы мы сможем давать нашим пользователям.

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

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



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

Вроде бы понятный подход, но он имеет свои минусы. Да, у вас получается максимально идеальный look and feel. Но представьте, что таких сервисов у вас сто или двести. Или не дай бог, тысяча. Если мы говорим, например, о WeChat, Dianping или о приложении VK, то сервисов может быть очень много, число может исчисляться тысячами. Вы встаете перед дилеммой: либо вы пытаетесь интегрировать большое количество внешнего UI что, наверное, рано или поздно просто станет невозможным; либо вы пытаетесь предоставить им некий общий UI, который они будут пытаться кастомизировать под себя. Это тоже может быть не так просто.

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

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

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

Мы долго думали. Вначале долго обсуждали, холиварили при выборе подхода, но в какой-то момент нам пришлось сказать самим себе: alea iacta est, жребий брошен, Рубикон перейден. Мы выбрали технологию. Думаю, вы уже догадались: мы выбрали интеграцию сервисов в виде веба.

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



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

Второй важный момент. Сервис, который к нам въезжает, не дублирует свой код между платформами: веб, iOS, Android. У него есть единое представление. Это единое представление он использует как в вебе, в любых браузерах, так и внутри нашего супераппа на платформе iOS или на Android. Но как мы уже упоминали, выбор похода интеграции через веб-сервис ставит очень тяжелые задачи, связанные с улучшением технологических характеристик, потому что скорость, плавность, нативность UI все это очень сильно проседает.

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



Кто-то скажет, что современные веб-движки прекрасно справляются с веб-контентом и такой проблемы вроде бы уже не должно существовать. Веб отображается быстро и работает замечательно. Да, я бы тоже хотел сказать, что ситуация выглядит так, но, к сожалению, бесстрастная статистика говорит нам в том числе и об обратном. Например, если посмотреть не время получения первого байта. Это время установки соединения, прогрузки веб-движка. Оно может в среднем превышать 2,5 с. А если у вас еще нет ни одного байта, вам нечего отобразить, кроме какого-нибудь красивого спиннера или splash screen.

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

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

Систему Native Cache мы построили на самом нижнем возможном уровне. Он просто подменяет контент, который идет из запроса.



Таким образом мы не тратим дополнительное время на установку и перехват соединения, как это было бы в сервис-воркере. Чем сайт более SPA-oriented, тем больше контента мы можем предзакешировать. Чем он более SSR-oriented тем меньше. Но наши измерения показали, что даже в случае тяжелых SSR-сайтов кеширование в Native Cache подресурсов, статических картинок, стилей позволяет сильно сократить время загрузки. А главное сделать его максимально независимым от скорости сетевого соединения. Для остальных этапов мы тоже предложили решения, дополнительные оптимизации, связанные с нашим движком. На данный момент мы считаем, что проблему скорости загрузки, скорости показа контента мы очень сильно улучшили внутри нашего супераппа. Выбор веб-подхода был оправдан. Мы смогли решить те технологические проблемы, которые он за собой повлек.

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



Думаю, вы легко догадаетесь, какие оказались наиболее важными. Это вещи, связанные с авторизацией, с проведением платежей, с заполнением из профилей пользователей значений при оформлении заказа. Из дополнительных вещей, интересных и необычных, я бы отметил такую publisher specific identifier. Это возможность идентификации пользователя внутри одного publisher сервиса между устройствами.

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

Перейдем к следующей, достаточно интересной теме UX.

UX супераппа. Айсберги на горизонте


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

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



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

Но есть маленький подвох. Если мы выбираем этот путь, то начинаем отрисовывать этот элемент поверх веб-контента. Значит, мы можем конфликтовать с тем, что находится под этим элементом. Там тоже могут быть элементы управления. Это вроде бы очень небольшая область, сколько там, 50 на 100 пикселей.

Но как оказалось на практике, это очень используемая область в тех сервисах, которые хотели к нам въехать. Для них это была просто гигантская головная боль. Мы к ним приходили и говорили: интеграция практически элементарна, вам нужно написать манифест, в котором вы описываете ресурсы для хранения в Native Cache, использовать JS API, который предоставит вам возможности использования нативных элементов авторизации или платежей, и все будет замечательно. Мы забыли упомянуть, что нужно еще оставить небольшое место под наш нативный элемент. Сервисы начинали хвататься за голову: у нас там на тысячах страниц есть наши элементы управления, и мы будем переделывать это целый год.

Мы поняли, что если хотим, чтобы сервисы въезжали к нам быстро и удобно, нам нужно что-то делать и придумывать другое решение. Следующим решением было возможно, кто-то уже догадался, поскольку в Яндекс Go вы это видели миллион раз. Шторки. То есть концепция следующая: контент выезжает в виде шторки, и эту шторку вы можете смахнуть после завершения работы или приспустить, чтобы получить доступ к дополнительной шапке например, с элементами управления или с дополнительным описанием сервиса.

Тут, казалось бы, мы решили предыдущую проблему. Мы никогда не перекрываем контент сервиса, он может въезжать к нам без изменений внешнего вида. Но к сожалению, механика взаимодействия со шторкой рождает дополнительные проблемы. В первую очередь она конфликтует с pull-to-refresh. Стандартное движение, которое привычно пользователю для обновления контента: немного оттянуть контент и магия, он начинает перезагружаться.



Нам приходится отключать pull-to-refresh. Также бывают сложные скроллы внутри контента: вертикальные или горизонтальные галереи, а в самом тяжелом случае карта. Это бесконечно скроллируемый контент. Вам нужно каким-то образом уметь взаимодействовать с этими картами, с такими бесконечными областями для скролла.

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

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

К чему мы пришли? Мы пришли к full screen-контенту с навигационной панелью, которая возникает снизу. Это очень похоже на веб-табы, которые и так уже существуют в браузерах, в том числе в Яндекс.Браузере и в приложении Яндекс. Тут мы предоставляем сервису максимум области для контента. Мы не перекрываем его, но, к сожалению, у нас теряется та самая некая выделенность сервиса по сравнению с обычными веб-сайтами. То есть мы хотели предоставить ему дополнительный внешний вид, дополнительную изюминку. Но к сожалению, в этом решении мы от этого отказываемся. И за счет навигационной панели снизу начинаем немного подрезать видимую область сервиса. Он может предоставить своим пользователям чуть меньше контента, доступного при первом старте.



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

Веб в целом как суперапп


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

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



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

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

Последний и самый важный момент: мы хотим, чтобы наша экосистема, наш суперапп не был завязан на конкретное приложение, а был доступен из любого веб-браузера. Если сервис загружается внутри нашего супераппа, внутри поискового приложения Яндекс или Яндекс.Браузера, мы используем как раз все те оптимизации, о которых я рассказывал, чтобы сервис работал быстро и качественно. Мы используем Native Cache и дополнительное JS API, которое пробрасывает взаимодействие пользователя в нативные интерфейсы. Пример нативная авторизация.





Мы используем дополнительные оптимизации на уровне движка веб-рендеринга. Но если пользователь заходит к нам через обычный внешний браузер, он по-прежнему может использовать те же самые возможности, которые реализованы другими средствами. Эти средства, может быть, менее эффективны, но при этом все равно реализовывают те возможности, ради которых пользователь приходил и ради которых сервис интегрировался в нашу экосистему. Мы можем использовать сервис-воркеры вместо Native Cache, использовать веб-реализацию JS API, который будет проводить это все через JS-средства и через веб-взаимодействие. И у пользователя будет возможность использовать нашу экосистему и входящие в нее сервисы через любой мобильный браузер, поддерживающий современные технологии.

Таким образом, наш суперапп вырастает из приложений, сбрасывает с себя оболочку нативного приложения и живет полноценно во всем вебе.

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

Чем сейчас неудобен хабровый WYSIWYG-редактор

29.01.2021 18:07:40 | Автор: admin

На Хабре ввели новый WYSIWYG-редактор постов, а старый позже отключат. Идея в том, чтобы пользователям не требовалось иметь дела с HTML-тегами, и публиковать записи свободно мог любой не-айтишник. Но вот вопрос: не доставит ли это неудобств айтишникам?

Я ничего не имею против HTML-тегов. А вот возню с мышкой не люблю, предпочитая клавиатуру. И, попользовавшись новым редактором, ощутил, что лично мне стало неудобнее. В его текущем виде он рассчитан не на таких людей, как я.

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


Мой сценарий

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

Поэтому я давно радовался, что Хабр поддерживает Markdown и HTML. И поэтому полюбил писать хабрапосты в редакторе vim, он как раз про эффективную клавиатурную работу. Оформлял в основном с помощью Markdown, а где его возможностей не хватало, добавлял HTML-теги: например, чтобы текст обтекал картинку или для оглавления поста. Работа над постом может выглядеть так идеальный дзен, ничто не отвлекает, есть только я и текст:

Мне не мешало, что vim не может показывать иллюстрации. Я подбирал нужные изображения, загружал их на Habrastorage, а дальше в нужные места текста вместо картинки вставлял сразу маркдаун-ссылку на неё.

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

Во многих случаях до публикации давал текст кому-то на ревью, тогда есть промежуточная стадия: сначала скопировать его вместе с Markdown-кодом в Google Docs (там людям проще), а уже оттуда после правок на Хабр.


В чём боль

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

1) Markdown-штуки срабатывают, когда пишешь в самом редакторе, но вот если хочешь скопипастить в него готовый текст с уже проставленной разметкой это как повезёт. То есть, если хочу использовать Markdown, желательно писать посты прямо на Хабре, а не в vim с его великой системой хоткеев. Меньше клавиатуры и терминала, больше мышки и браузера.

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

3) Если для Markdown хотя бы заявили поддержку, то в случае с HTML сказали только об уходе от него. А ведь с его помощью пользователи Хабра реализовывали целый пласт возможностей. Хочешь, чтобы текст обтекал картинку не справа, а слева? Хочешь подзаголовок определённого цвета? Хочешь сделать кликабельную картинку? Хочешь вручную задать ей размеры? Markdown всего этого сделать не даёт.

4) Каким-то из пропавших HTML-возможностей сделали альтернативные реализации, но порой неудобные. Например, оглавление поста. Раньше в vim писал тег <anchor> у каждого подзаголовка. Теперь предлагается делать в хабровском редакторе так: добраться в тексте до нужного места, вызвать меню, выбрать вариант якорь, затем ткнуть мышкой в сам якорь (с клавиатуры это сделать нельзя), а затем почему-то ещё раз ткнуть мышкой над ним в поле укажите id якоря (с клавиатуры это сделать тоже нельзя).

И повторить всё это по числу подзаголовков (например, 10 раз). Объём раздражающей мышиной возни ощутимо возрос.

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

Это всё не считая мелких багов, их-то можно просто репортить. Перечисленные выше вещи выглядят не столько багами, сколько ожидаемым поведением: не знаю, решат позже изменить ситуацию или нет. И в сумме они вызывают ощущение тебе с твоими vim и Markdown тут не рады, слушай песню "Валенки" и редактируй WYSIWYG в браузере.

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

Чего хотелось бы

Кто-то тут мог бы полезть на баррикады: Это ужасно, IT-ресурс отходит от интересов IT-специалистов ради каких-то людей, которые не могут осилить HTML. Редактор постов должен быть рассчитан на ценителей кода, чтобы приманивать опытных IT-специалистов, которым есть чем поделиться. А остальные пускай отсеиваются, уровень контента только повысится. Верните всё как было.

С таким радикальным подходом я не согласен. Во-первых, на сайте есть разделы вроде дизайн и научпоп, так что польза WYSIWYG понятна: человек, далёкий от HTML, может при этом писать отличные тексты о космонавтике.

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

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

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

А ещё, по-моему, возможно было бы порадовать айтишников следующим образом: не только работать над визуальным редактором, но и возродить закрытое на реконструкцию API Хабра. Был бы очень рад, если бы после сочинения текста в vim мог прямо из терминала командой отправить его в хабрачерновики. А потом открыть на сайте и там уже при необходимости поправить что-то в WYSIWYG-режиме. И для загрузки картинок был бы рад тому же.


Нужен фидбек

Но тут у меня возник вопрос: нужно ли такое кому-то, кроме меня? Может быть, все рады новому редактору, а я со своим сочинением постов в vim выгляжу вот этим странным пользователем из комикса xkcd?

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

  • Пробовали ли вы новый редактор и как вам?

  • Подходит ли вам оформление в WYSIWYG-режиме, или предпочитаете Markdown/HTML?

  • Подходит ли вам писать пост прямо на Хабре, или предпочитаете отдельные текстовые редакторы?

  • При появлении у Хабра API стали бы вы пользоваться им, или взаимодействовали бы с сайтом только через браузер?

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

Я пишу здесь для блога компании JUG Ru Group. Мы делаем конференции для разработчиков, но сами далеко не все разработчики. И среди моих коллег, постящих что-то на Хабр, часть никогда не открывали vim и пишут тексты в человеческих редакторах вроде Google Docs. Казалось бы, вот они должны быть рады новому WYSIWYG-редактору: можно в Google Docs сделать всю вёрстку визуально, а потом просто скопипастить на Хабр.

Но знаете, что оказалось? Работая с прежним хабровским редактором, коллеги без проблем разобрались в Markdown и так его полюбили, что не хотят от него отказываться. Им тоже хочется надёжного переноса Markdown-разметки. И тоже пока что ощущение шага назад, а не шага вперёд.

Поэтому хочется разобраться, чтобы получился шаг вперёд для всех.

Подробнее..

Чем неудобен хабровый WYSIWYG-редактор

29.01.2021 20:06:23 | Автор: admin

На Хабре ввели новый WYSIWYG-редактор постов, а старый позже отключат. Идея в том, чтобы пользователям не требовалось иметь дела с HTML-тегами, и публиковать записи свободно мог любой не-айтишник. Но вот вопрос: не доставит ли это неудобств айтишникам?

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

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


Мой сценарий

Как и многие в IT, я люблю эффективное управление с клавиатуры (чем меньше мышиной возни, тем лучше) и язык разметки Markdown. WYSIWYG мне не требуется: вёрстка хабрапостов такая несложная, что картина рендерится просто в голове, остаётся только проверить перед публикацией.

Поэтому я давно радовался, что Хабр поддерживает Markdown и HTML. И поэтому полюбил писать хабрапосты в редакторе vim, он как раз про эффективную клавиатурную работу. Оформлял в основном с помощью Markdown, а где его возможностей не хватало, добавлял HTML-теги: например, чтобы текст обтекал картинку или для оглавления поста. Работа над постом может выглядеть так идеальный дзен, ничто не отвлекает, есть только я и текст:

Мне не мешало, что vim не может показывать иллюстрации. Я подбирал нужные изображения, загружал их на Habrastorage, а дальше в нужные места текста вместо картинки вставлял сразу маркдаун-ссылку на неё.

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

Во многих случаях до публикации давал текст кому-то на ревью, тогда возникала промежуточная стадия: сначала скопировать всё в Google Docs (там людям удобнее), а уже оттуда после правок на Хабр.


В чём боль

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

1) Markdown-штуки срабатывают, когда пишешь в самом редакторе, но вот если хочешь скопипастить в него готовый текст с уже проставленной разметкой это как повезёт. То есть, если хочу использовать Markdown, мне желательно писать посты прямо на Хабре, а не в vim с его великой системой хоткеев. Меньше клавиатуры и терминала, больше мышки и браузера.

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

3) Если для Markdown хотя бы заявили поддержку, то в случае с HTML сказали только об уходе от него. А ведь с его помощью пользователи Хабра реализовывали целый пласт возможностей. Хочешь, чтобы текст обтекал картинку не справа, а слева? Хочешь подзаголовок определённого цвета? Хочешь сделать кликабельную картинку? Хочешь вручную задать ей размеры? Markdown всего этого сделать не даёт.

4) Каким-то из пропавших HTML-возможностей сделали альтернативные реализации, но порой неудобные. Например, оглавление поста. Раньше в vim писал тег <anchor> у каждого подзаголовка. Теперь предлагается делать в хабровском редакторе так: добраться в тексте до нужного места, вызвать меню, выбрать вариант якорь, затем ткнуть мышкой в сам якорь (с клавиатуры это сделать нельзя), а затем почему-то ещё раз ткнуть мышкой над ним в поле укажите id якоря (с клавиатуры это сделать тоже нельзя).

И повторить всё это по числу подзаголовков (например, 10 раз). Объём раздражающей мышиной возни ощутимо возрос.

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

Это всё не считая мелких багов, их-то можно просто репортить. Перечисленные выше вещи выглядят не столько багами, сколько ожидаемым поведением: не знаю, решат позже изменить ситуацию или нет. И в сумме они вызывают ощущение тебе с твоими vim и Markdown тут не рады, слушай песню "Валенки" и редактируй WYSIWYG в браузере.

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

Чего хотелось бы

Кто-то тут мог бы полезть на баррикады: Это ужасно, IT-ресурс отходит от интересов IT-специалистов ради каких-то людей, которые не могут осилить HTML. Редактор постов должен быть рассчитан на ценителей кода, чтобы приманивать опытных IT-специалистов, которым есть чем поделиться. А остальные пускай отсеиваются, уровень контента только повысится. Верните всё как было.

С таким радикальным подходом я не согласен. Во-первых, на сайте есть разделы вроде дизайн и научпоп, так что польза WYSIWYG понятна: человек, далёкий от HTML, может при этом писать отличные тексты о космонавтике.

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

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

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

А ещё, по-моему, возможно было бы порадовать айтишников следующим образом: не только работать над визуальным редактором, но и возродить закрытое на реконструкцию API Хабра. Был бы очень рад, если бы после сочинения текста в vim мог прямо из терминала командой отправить его в хабрачерновики. А потом открыть на сайте и там уже при необходимости поправить что-то в WYSIWYG-режиме. И для загрузки картинок был бы рад тому же.


Нужен фидбек

Но тут у меня возник вопрос: нужно ли такое кому-то, кроме меня? Может быть, все рады новому редактору, а я со своим сочинением постов в vim выгляжу вот этим странным пользователем из комикса xkcd?

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

А напоследок поделюсь уже имеющимся фидбеком, который показывает, что грань между айтишным и не-айтишным подходами вообще не такая строгая, как кажется. Я пишу здесь для блога компании JUG Ru Group. Мы делаем конференции для разработчиков, но сами далеко не все разработчики. И среди моих коллег, постящих что-то на Хабр, часть никогда не открывали vim и пишут тексты в человеческих редакторах вроде Google Docs. Казалось бы, вот они должны быть рады новому WYSIWYG-редактору: можно в Google Docs сделать всю вёрстку визуально, а потом просто скопипастить на Хабр.

Но знаете, что оказалось? Работая с прежним хабровским редактором, коллеги без проблем разобрались в Markdown и так его полюбили, что не хотят от него отказываться. Им тоже хочется надёжного переноса Markdown-разметки. И у них тоже от нового редактора пока что ощущение шага назад, а не шага вперёд.

Поэтому хочется разобраться, чтобы получился шаг вперёд для всех.

Подробнее..

Забытые корни популярных иконок

05.02.2021 12:22:10 | Автор: admin


Популярная шутка утверждает, что наши дети воспримут 3,5-дюймовую дискету как распечатанный на 3D-принтере значок сохранения. Действительно, растёт поколение, не знающее объекта, с которого срисовали эту пиктограмму.

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

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

Медиакнопки без автора


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

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

История происхождения этих иконок первую очередь связана с самими устройствами воспроизведения. В типичный медиаплеер встроены графические кнопки с символами перемотки, будто мы до сих пор читаем магнитную ленту. Удобнее было бы иметь кнопки перехода на 10 секунд вперёд или назад, а не перемотки. Но мысленная аналогия с магнитной лентой оказалась настолько удачной, что образы пережили сам формат.


Контрольная панель немецкого магнитофона AEG FT4, который производился с 1939 по 1941 год. Никаких иконок, только краткие подписи. Фотография Музея магнитной аудиозаписи в Остине, штат Техас

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


Панель управления магнитофона Ampex AG-440, модель 1967 года. Профессиональный сегмент и назначение только для внутреннего рынка США избавляли от необходимости переводить надписи. Фотография сайта Audiofanzine

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


Швейцарский магнитофон Revox F36 1962 года. Возможно, из-за двуязычности страны происхождения производитель задумался нанести на корпус графические символы, а не надписи текстом. Фотография сайта Reverb

К семидесятым глобализация и завоевание мирового рынка наконец вынудили подумать про единый стандарт. В 1973 году Международная электротехническая комиссия выпустила документ IEC 417. Стандарт фиксировал графические символы, многие из которых широко использовались и до этого.

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

Попытки есть. Несколько сайтов ошибочно утверждают, что иконки придумал несуществующий шведский дизайнер Филип Ульссон (Philip Olsson) во время стажировки в Японии по окончании его обучения в Королевском технологическом институте. На деле это обрывок информации из Википедии, который в 2012 году добавил викивандал под именем Phlopydisk. Судя по его аккаунтам в Сети, Филип зачем-то вставил своё имя в статью.

Треугольник воспроизведения указывает направо. Туда же движется лента при проигрывании звука. Если речь идёт про катушечный магнитофон с автореверсом, то кнопок воспроизведения иногда две. На магнитной ленте в этом случае 2 (моно) или 4 (стерео) дорожки. В дизайне укоренился лишь один вариант кнопки проигрывания: указывающая слева направо.


Продвинутый бобинник Pioneer RT-909 продавался уже в закат эпохи ленты, с 1978 года. Фотография Walkman Archive

Кнопка паузы похожа на символ цезуры ||, который ставят в тексте для указания паузы. Также она напоминает символ последний в японском слове (кугири), означающем место для отдыха или знак пунктуации.

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

Цвет кружка кнопки записи был продиктован традицией: красной индикацией обозначали прямой эфир.


Кнопки управления Grundig TK46, магнитофон производили с 1962 по 1964 год. Уже здесь используется красный кружок, хотя в остальном корпус обильно испещрён английскими глаголами. Модель для рынка Германии производилась с надписями на немецком. Фотография Relics & Rarities

Символы из стандарта IEC 417 (также известен как IEC 60417:1973) постепенно распространились по всему миру. На это ушло не одно десятилетие, и часто рядом соседствовали значки и буквы. Но простота значков победила.

А нарисовать интуитивные пиктограммы не так-то просто. В том же документе IEC 417 у привычных треугольников, квадрата и кружка есть аналог, который изображает действия с лентой и сами катушки. К этому аналогу прибегала, к примеру, советская техника: вместо значка 5107B на кнопке воспроизведения стоял похожий на очки 5096, вместо двух паралелльных вертикальных полосок 5111B магическая руна 5111A и так далее.


Советский кассетный магнитофон Квазар-303 выпускался с 1985 года, когда на Западе уже устоялись простые треугольники, квадраты и круги для пиктограмм. Фотография Виртуального музея отечественной радиотехники XX века

Скандинавский след


Символом в macOS обозначают клавишу Command. Как и для многих других особенностей интерфейса Apple, история этого значка восходит к дизайнеру Сьюзен Кэр.

В августе 1983 года команда разработки программного обеспечения Apple Macintosh заметила, что нужна специальная клавиша для вызова команд из строки меню. Разработчики решили поставить иконку компании небольшое яблочко. Так уже поступили с клавиатурой Lisa.


Клавиатура компьютера Apple Lisa. Изображение из архива Bitsavers

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

Внезапно взбунтовался руководивший работами Стив Джобс. Возможно, он увидел программу MacDraw, в которой пунктов меню было по-настоящему много. Он ворвался в здание офиса и потребовал прекратить упоминать логотип Apple всуе.

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

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

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

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


Клавиатура Apple M0110 от оригинального Macintosh. Фотография Deksthority

Сам Джобс покинул Apple в 1985 году и основал собственную компанию NeXT Computer. На клавиатурах NeXT командная клавиша помечена зелёной надписью Command.

Уже в 1986 году в Apple IIGS на клавишу рядом к символу достопримечательности добавили логотип компании. Так сделали для сохранения совместимости с предыдущими поколениями Apple II. В 2007 году логотип компании вновь исчез. На тот момент NeXT уже как десять лет вошла в состав Apple, а Джобс вновь влиял на любые процессы.

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



Составная руна в логотипе стандарта передачи данных по беспроводной связи комбинирует символ младшего футарка хагалаз () и беркану (). Вместе они образуют инициалы HB [Harald Bltand] короля Дании и Норвегии Харальда I Гормссона Синезубого, в честь которого и назвали стандарт. Как и связывающий устройства враждующих производителей протокол Bluetooth, этот правитель X века объединил соперничающие княжества Скандинавии.

А вот прозвище Синезубый Харальдс получил, вероятно, не за синие, а потемневшие зубы. Но логотип Bluetooth толкует цвет буквально.

Новейшие потеряшки


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

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

Автор трёх полосок Норм Кокс, один из разработчиков первого в мире графического интерфейса Xerox Star. Как рассказывает создатель элемента, в своей работе он руководствовался ограничениями дисплеев. Требовалась хорошо различимая и запоминающаяся пиктограмма, которая будет имитировать вид открываемого списка элементов. А в квадрате 1616 пикселей с градациями серого особо не разгуляться.


Скриншот из видеоролика. Видео смонтировано в 1990 году, но дата указывает на внутреннюю демонстрацию Xerox 1981 года. Слово гамбургер не звучит: элемент называют кнопкой меню

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

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

Отследить дальнейшее распространение иконки несложно. Гамбургер появился на самих смартфонах 17 июня 2009 года в приложении голосовых заметок в iOS.



Возможный кандидат среди сторонних приложений Tweetie, первый клиент Twitter руки известного разработчика iOS Лорена Брихтера. Tweetie вышел в 2008 году, и на тот момент Брихтер работал в Apple

Поиски гамбургера шли по пути упрощения. Facebook в 2008 году добавила иконку с сеткой квадратиков 23, а через год её поменяла на 33. В 2010 году в интерфейсе приложения девять квадратиков сменили на три полоски.


Интерфейс приложения Facebook для iOS, 2008 год

Растущий темп современности стирает историю не только у изобретения 40-летней давности. В веб-интерфейсах нет стандартизированной иконки расшарки контента, хотя кандидаты находятся. Заметное распространение получили три точки, соединённые линиями, будто иллюстрирующие граф.



Её создатель веб-разработчик Алекс Кинг, создатель плагина ShareThis для WordPress. В ноябре 2006 года Кинг задался вопросом, нужна ли дополнению специальная иконка. 4 декабря 2006 года веб-разработчик публикует первый вариант, который затем лишь незначительно модифицирует утолщает рёбра графа, чтобы их было лучше видно в маленьком размере.



Кинг удачно предугадал необходимость в новом символе. К концу 2006 года Алекс открыл веб-сайт Share Icon Project, в котором призывал пользоваться этим логотипом для указания действия расшарки, и выложил архив с изображениями. Алекс объявил, что лицензирует иконку сразу под 4 свободными лицензиями: GPL, LGPL, BSD и Creative Commons Attribution 2.5.

Пиктограмма получила распространение: меньше чем через год ей начал пользоваться Google в своём интерфейсе. В сентябре 2007 года Алекс Кинг объявил, что продаёт логотипы ShareThis одноимённой компании виджетов соцсетей.

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



Без истории развития стандарта логотип Ethernet понять тяжело: это какие-то квадратики, которые почему-то общаются по одному кабелю. Реальная витая пара идёт от устройства к устройству.


Порт Ethernet и его логотип

Но всё встанет на свои места, если вспомнить, что в 10BASE5, первом стандарте Ethernet, к общему коаксиальному кабелю вампирчиками подключались до 100 узлов.


В логотипе наверняка есть что-то от набросков автора стандарта Ethernet Роберта Меткалфа

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

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

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



На правах рекламы


Эпично! Мощные серверы на базе новейших процессоров AMD EPYC для размещения проектов любой сложности, от корпоративных сетей и игровых проектов до лендингов и VPN.

Подробнее..

Нужно ли дизайнеру интерфейсов понимать вёрстку?

13.02.2021 10:18:35 | Автор: admin

Вы верно поняли, тут речь пойдёт именно о тех людях, которые делают дизайн интерфейсов. Я порой вижу вопросы на тему: Нужно ли понимать дизайнеру вёрстку? и Почему вы делите дизайнеров на Ui, UX, итд?. В этой статье я отвечу на эти вопросы. Маленькая затравка для продолжения - да, эти два вопроса отвечают друг на друга. О том, кто такие дизайнеры интерфейсов, и что они делают в рамках разработки приложений, мы разбирали в прошлой статье.

UPD: Расшифровка того, кто такой Ui/Ux дизайнер по ссылке выше.

Нужно ли уметь верстать?

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

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

Что делать дизайнеру который не понимает вёрстку? - тут ответ очевиден Нужно разбираться в том, что ты делаешь. Это вопрос компетентности, и ответственности за свои решения, которые должны иметь твердое основание.

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

Почему делят дизайнеров на Ui, Ux, продуктовых, рекламных и так далее ?

Если вы читали ответ на предыдущий вопрос, то вы примерно уже догадываетесь о том, почему дизайнеры интерфейсов, это не тоже самое, что дизайнеры печатной продукции, и другие История IT такова, что постоянно нужно развиваться и учиться новому, без этого есть большой шанс стать неактуальным. На заре зарождения веб интерфейсов дизайном занимались люди, которые сайты разрабатывали, была даже такая профессия Веб мастер. Сейчас, если делать так, как делали в начале нулевых - то дизайнер рискует остаться не у дел. Веб мастера переквалифицировались в фронтендеров, с их большим зоопарком фреймворков, технологий по типу Blazor, и и много чего еще Сейчас веб разработчику, для успешной карьеры, мало знать лишь ванильный JS и JQuery. Так и выводим, что дизайнер, который разрабатывает интерфейсы, знает помимо обязательной для всех видов дизайнеров базы - Теории дизайна, цвета, композиции еще и технические детали в виде Системного подхода, верстки, принципов работы клиент-серверных приложений, принципов работы запросов и ответов, структуры JSON объектов. Справедливо будет уточнить, что не очень нужно знать всё это на уровне профессиональной разработки, а хотя бы на уровне базовых принципов и механизмов работы. Этим собственно и делятся дизайнеры между собой - дополнительными, отраслевыми навыками.

Выводы

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

Обращайтесь только к квалифицированным специалистам.

Подробнее..

Перевод Как визуализируют своевременность данных в Airbnb

18.03.2021 18:13:59 | Автор: admin

Команды Airbnb собрались вместе, чтобы за год создать SLA Tracker визуальный аналитический инструмент, помогающий формировать культуру своевременности данных. Этот информационный продукт позволил нам разрешить и систематизировать следующие вопросы своевременности набора:

  1. Когда считать, что набор опоздал?

  2. Какие данные часто опаздывают?

  3. По какой причине набор опоздал?

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


Данные запаздывают

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

Для своевременной поставки данных Airbnb мы стремимся к тому, чтобы владельцы каждого промежуточного шага фиксировали соглашения об уровне обслуживания (SLA) по доступности данных к конкретному времени. Например, владелец набора обещает, что метрика "бронирование" будет содержать самые актуальные данные к 5 утра по UTC, и если набор к этому времени недоступен, то он опоздал.

Как часто наборы опаздывают?

Сначала мы решили, что, опираясь на представление отчёта, Report поставщики данных должны понимать, когда данные выгружены и как часто они соответствуют SLA (рис. 1).

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

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

Рис. 1 SLA Report предоставляет высокоуровневый обзор производительности SLA по спискам наборов. Каждая строка содержит индикатор состояния последнего раздела данных, а также гистограммы, отражающие данные о времени выгрузки (красные столбцы показывают дни, когда время выгрузки не соответствует SLA).Рис. 1 SLA Report предоставляет высокоуровневый обзор производительности SLA по спискам наборов. Каждая строка содержит индикатор состояния последнего раздела данных, а также гистограммы, отражающие данные о времени выгрузки (красные столбцы показывают дни, когда время выгрузки не соответствует SLA).

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

Отчётность только вершина айсберга

Хотя Report сильно упрощает понимание того, действительно ли набор опаздывает, это представление не решило главные проблемы SLA:

  • Каково разумное SLA набора?

  • Как понять причину опоздания?

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

Рис. 2 Пример происхождения данных набора "A". "A" зависит от "B", который зависит от "C" и "D", и так далее.Рис. 2 Пример происхождения данных набора "A". "A" зависит от "B", который зависит от "C" и "D", и так далее.

Таким образом, наличие одного набора неразрывно связано с иерархически сложным "происхождением" других наборов. Чтобы установить реалистичное SLA, нужно учитывать дерево зависимостей, которое иногда состоит из 100 сущностей, а также их SLA.

Добавим к этому сложности: когда что-то идёт не так, попытка сопоставить иерархические зависимости со временной последовательностью даёт результат: SLA упущено и ничего не видно. Трудно рассуждать о причинах в такой ситуации. Инструментальная оснастка Airbnb позволила дата-инженерам выявлять проблемы в конвейере одной команды; сделать то же самое на конвейерах нескольких команд экспоненциально сложнее.

Почему набор опоздал?

Ранний дизайн

Чтобы поставщики данных видели зависимости набора и временные рамках этих зависимостей, разработано представление о происхождении набора Lineage.

Информация о происхождении данных это от 10 до 100 таблиц, а каждая таблица это 30 дней исторических данных, а также SLA и связей между ними, поэтому мы нуждались в краткой форме представления, а это от 1,000 до 10,000 отдельных точек данных.

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

Рис. 3 Ранняя разведка с акцентом на происхождение набора. В каждой графе указано историческое время выгрузки каждого набора данных в более крупном конвейере.Рис. 3 Ранняя разведка с акцентом на происхождение набора. В каждой графе указано историческое время выгрузки каждого набора данных в более крупном конвейере.

Фокус на времени с помощью представления Timeline

Затем мы сместили акцент на последовательности во времени. Чтобы представлять последовательности, мы создали диаграмму Ганта, включающую зависимости (рис. 4) с такой функциональностью:

  • Каждая строка представляет набор в смысле происхождения, конечный набор расположен наверху.

  • У каждого набора есть горизонтальная полоса, отображающая начало, продолжительность и время окончания задачи обработки данных в пределах выбранных дат или времени.

  • Если набор имеет SLA, время обозначается вертикальной линией.

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

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

  • Выделенные дуги представляют важнейшие узкие места.

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

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

Ищем иголку в стоге сена "узкие" места

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

Рис. 5 Сравнение всей линии происхождения (слева, n=82) и отфильтрованного пути к "узкому" месту (справа, n=8). Пути узких мест значительно улучшают соотношение сигнал шум и облегчают поиск проблемных этапов больших конвейерах.Рис. 5 Сравнение всей линии происхождения (слева, n=82) и отфильтрованного пути к "узкому" месту (справа, n=8). Пути узких мест значительно улучшают соотношение сигнал шум и облегчают поиск проблемных этапов больших конвейерах.

Погружение в историческое представление (Historical)

Итак, узкое место выявлено. Теперь важный вопрос вызвана задержка на этом этапе длительностью самой работы или замедлениями в зависимостях? Ответ на этот вопрос помогает поставщикам данных понять, нужно ли оптимизировать именно их конвейер, или, чтобы сократить время SLA, нужны переговоры с владельцами зависимостей. Чтобы позволить отслеживать причины, мы построили подробное представление выполнения выгрузки набора, показывающее длительность и выполнения, и задержки (рис. 6).

Рис. 6 Исторические распределения времени выполнения и задержек помогают быстро отличить SLA (красным цветом) из-за позднего начала вверху и сравнить с длительным выполнением внизу. Объединив эти взаимодополняющие представления в SLA Tracker, мы получаем полную перспективу своевременности данных (рис. 7).Рис. 6 Исторические распределения времени выполнения и задержек помогают быстро отличить SLA (красным цветом) из-за позднего начала вверху и сравнить с длительным выполнением внизу. Объединив эти взаимодополняющие представления в SLA Tracker, мы получаем полную перспективу своевременности данных (рис. 7).Рис. 7 Трекер SLA состоит из нескольких представлений. Представление Report даёт обзор состояния набора данных, Lineage позволяет провести анализ первопричин времени выгрузки, а Historical фиксирует исторические тенденции в подробностях.Рис. 7 Трекер SLA состоит из нескольких представлений. Представление Report даёт обзор состояния набора данных, Lineage позволяет провести анализ первопричин времени выгрузки, а Historical фиксирует исторические тенденции в подробностях.

Процесс и оснастка

Почти год мы потратили на разработку концепции, проектирование, создание прототипов и внедрения SLA Tracker в производственную среду. Большая часть этого времени потрачена на разработку API данных в UI и на итерации Lineage.

Чтобы упростить Report, мы использовали статические конструкции и прототипы экранов с хот-спотами (инструмент Clickthrough Prototypes) и универсальные поддельные данные. В альфа- и бета-релизах мы выполняли итерации визуального языка, то есть визуализировали данные так, чтобы их было проще охватить и понять (рис. 8).

Рис. 8 Эволюция визуального отображения времени выгрузки; отображены текущее и типичное время.Рис. 8 Эволюция визуального отображения времени выгрузки; отображены текущее и типичное время.

Совершенно иначе мы подошли к проектированию Lineage. Его информационная иерархия продиктована формой данных. Таким образом, критично прототипирование на выборках реальных данных. Мы разработали эти прототипы на TypeScript, используя низкоуровневый набор компонентов визуализации visx для React, этот набор позволяет повторно использовать код при внедрении в производственную среду (рис. 9).

Рис. 9 Эволюция диаграммы Ганта Lineage (слева направо): первые ящики с усами, множество промежутков; простые промежутки с дугами зависимостей; упрощение поиска узких мест.Рис. 9 Эволюция диаграммы Ганта Lineage (слева направо): первые ящики с усами, множество промежутков; простые промежутки с дугами зависимостей; упрощение поиска узких мест.

После обретения уверенности в нашей визуализации, но до внедрения в производственную среду мы доработали визуальные элементы статических макетов в Figma (рис. 10).

Рис. 10 Разработка простого, но согласованного языка дизайна (слева) во всех представлениях SLA Tracker (справа) помогла сбалансировать плотность информации, сделав элементы более понятными.Рис. 10 Разработка простого, но согласованного языка дизайна (слева) во всех представлениях SLA Tracker (справа) помогла сбалансировать плотность информации, сделав элементы более понятными.

Заключение

В этом проекте мы применили визуализацию данных и UI/UX-дизайн междисциплинарную область, которую называем "Data Experience", в отношении важных проблем своевременности данных, требующих глубокого понимания сложной временной и иерархической информации. Это позволило сделать анализ своевременности данных доступным даже в сложной экосистеме данных крупной компании. Для разработки сложных инструментов визуального анализа требуются время и итерации, но результат работы может принести большую пользу.
Если хотите научиться работать с данными не хуже специалистов из Airbnb то приходите учиться. Будет сложно, но интересно!

Узнайте, как прокачаться в других специальностях или освоить их с нуля:

Другие профессии и курсы
Подробнее..

Figma плагины для продуктового дизайна. Локальный топчик с видео-инструкцией

25.05.2021 16:13:10 | Автор: admin

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

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

В конце статьи будет ссылка на видео-инструкцию.

Иерархия библиотек вOzon

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

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

Сейчас унас вOzon есть несколько типов библиотек:

  • Атомарные токены дизайн-системы.

  • Молекулярные библиотеки сэлементами интерфейса. Изних собираются экраны сценариев.

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

Библиотечная иерархияБиблиотечная иерархия

Рабочие лошадки иудобные пони

Нохватит зауми! Вперёд кхит-параду. Ида, тут будут представлены иплатные сокровища, ночто значат деньги, когда дело касается Продукта иПродуктивности.

Master

Community

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

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

Копируем одну изформ ивставляем её всценарную библиотеку. Делаем компонент ипубликуем. Запускаем команду Pick Target Component изарсенала плагина Master. Возвращаемся вфайл сценария ивыделяем все наши формы. Запускаем команду Link Objects toTarget Component.

Дапребудет стобой сила, Master!

Design System Organizer

Community

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

Тут унас локальные цветовые итипографские стили. Надо привязать ихктакимже библиотечным. Идём вбиблиотеку изапускаемDSO. Заходим вцветовые стили, выделяем нужную группу ивыбираем извыпадающего меню Set AsTarget. Возвращаемся внаш файл, запускаем DSO ивыбираем Relink Styles. Бум! Стили теперь тянуться изкомандной библиотеки. Такимже образом перелинковываем другие стили или компоненты.

Style Organizer

Community

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

Вот тут унас типичная ситуация. Наглазок всё впорядке, нотакли это? Стартуем Style Organizer. Ивидим, что один изчёрных квадратов имеет локальный стиль, второй библиотечный, атретий вообще без стиля. Можно пробежаться посписку ошибок вручном режиме, сшивая стили, аможно нажать Auto Fix Color иStyle Organizer будет действоватьсам.

Similayer

Community

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

Давайте выделим слово Zen синего цвета, вне зависимости отстиля текста. Выделяем один синий Zen изапускаем Similayer. Выбираем параметры Fill Style иText Characters.

Удобненько!

Instance Finder

Community

Ищет ивыделяет только инстансы. Зато делает это шустрее Similayer иработает повсему документу, анепоодной странице.

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

Select Layers

Community

Ещё один незаменимыйвыделятель. Чаще всего ловлю им слои по названию (он поддерживает частичное вхождение запроса). В отличииотSimilayer, SelectLayersне требует выделять образец для поиска соответствия и, что крайне важно, может искать только в выделенном.

Вот тут унас мега-вариант инпута. Выделяем поля пароля изапускаем плагин. Пишем название нужного слоя ивуаля! Можем поменять иконку, например.

Sorter

Community

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

Если попытаться пронумеровать экраны, нерасставив ихвпанели слоёв, получим хаос. Нуок. Выделяем все экраны, запускаем команду Sort Position ипосле этого уже штатный Rename Selection.

Порядочек.

Quantizer

Community

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

Выделяем, что нужно, истартуем Quantizer. Сделаем колонки сотступами по40px.

Кстати, вызнали, что можно таскать объекты всетке закруглые маркеры вцентре? Аменять отступ, хватаясь замаркеры между? Если делать это сShift, шаг будет кратен вашему Nudge Amount.

Swap

Community

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

Выделяем два объекта, запускаем команду Swap и, собственно, всё.

Layer Counter

Community

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

Если снять галку Include Nested Layers, увидим только количество выделенных фреймов.

Retextifier

Community

Может массово заменять текст ввыделенных блоках. Ноесть досадный недочёт при работе вWindows лишний перевод строки, скоторым можно бороться внешними средствами, заменив символ \n на\r или прогнав текст через сам плагин.

Замечательный инструмент, если умеешь импользоваться иутебя macOS.

НаmacOS: копируем текст, например, колонку изGoogle-таблицы. Выделяем целевые текстовые слои изапускаем плагин. Вставляем текст комбинацией Cmd+Shift+V.

Если увас Windows, действуем немного сложнее. Сначала вставляем скопированный текст вфайл Figma. Выделяем его, запускаем Retextifier, копируем итутже вставляем текст, жмём Change. Копируем изменённый текст, далее действуем как наmacOS. Надеюсь, автор плагина что-то придумает поповоду этого недоразумения.

Copy and Paste Text

Community

Вотличие отпредыдущего, этот плагин вставляет вовсе выделенные слои одинаковый текст избуфера. Безусловно полезно.

Копируем нужный текст, выделяем целевые слои, запускаем команду Paste Text

Find & Replace

Community

Поиск изамена потекстовым слоям споддержкой регулярных выражений (Regex). Для тех, кто умеет врегулярки ипонимает, как это круто.

Сейчас мыпоменяем местами буквы ицифры. Запускаем плагин, включаем поддержку Regex ипишем регулярное выражение. Найти (.*)-(.*) изаменить на$2-$1.

Мистика!

Nisa Text Splitter

Community

Разрезает текстовый блок настроки, сортирует, сшивает, расставляет буллиты имногое другое. Рекомендую.

Давайте расставим фильмы похронологии. Запускаем Nisa Text Splitter ирежем наш блок настрочки. Сортируем поалфавиту Sort byalphabet исшиваем обратно водин блок Join text. Внутри плагина ещё много другой годноты. Например, сразу делать Auto Layout изнарезанного текста.

Change Text to Layer Name

Community

Несамый необходимый штепсель, ночастенько выручает. Меняет текст наназвание слоя. Использую всвязке соштатным Rename Selection.

Выделяем текстовые блоки, применяем Rename Selection, оставляем старое название, добавляем кнему дефис иномер. Запускаем команду Change Text toLayer Name.

Математично!

Data Roulette

Community

Когда работаешь над продуктом, утебя есть постоянно используемые наборы данных. Эти наборы накапливаются икочуют изпродукта впродукт. Data Roulette позволяет хранить ихвGoogle-таблицах ирандомно заполнять ими макеты. Итекстами, ифотками.

Делаем Google-таблицу. Линк нанеё добавляем вData Roulette. Называем целевые слои всоответствии сназваниями колонок таблицы поставив вначало решётку. Можно сделать это вмастер-компоненте. Помере необходимости добавляем вGoogle-таблицу новые колонки.

Рулетка рулит!

Content Reel

Community

Для того, кому лень возиться сGoogle-таблицами, Microsoft наплагинил Content Reel. Только нужно залогиниться. Тогда можно будет создавать свои наборы данных.

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

Copypasta

Community

Очень часто нужно что-то добавить навсе экраны сценария. Водно итоже место. ИCopypasta прекрасно решает эту задачку.

Выделяем нужную деталь, запускаем Copypasta, жмём Save selection, выбираем целевые экраны, Duplicate Layers.

Шикарно.

Safely Delete Components

Community

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

Safely Delete Components удаляет неиспользуемые мастер-компоненты. Ноэтот плагин нужно использовать состорожностью. Нестоит запускать его вбиблиотеках.

После переноса компонентов всценарную библиотеку, выделяем компоненты локальные изапускаем Safe Delete.

SBOL-Typograph

Community

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

Божечки-Ёжечки!

Хорошо, ногдеже тот самый плагин?

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

Всем удачи напродуктовом фронте!

P.S.: Видео-версию статьи можете посмотреть намоём YouTube-канале.

P.P.S.: Ясерьёзно про комментарии.

Подробнее..

Топ-5 софт-навыков дизайнера в банке

04.06.2021 14:18:19 | Автор: admin

Соавтор:Кузнецова Юлия Андреевна - UX-писатель Экосистемы РСХБ

Каким должен быть дизайнер в банке, чтобы и продукт хороший создавал, и коллеги не жаловались. Смотрим через призму софт-навыков вместе с UX-дизайнерами РСХБ.

#1 Коммуникабельность: не просто коллега человек

Дизайнер отличная профессия для интровертов. Рисуешь интерфейсы, слушаешь музыку, ни с кем не общаешься На самом деле, нет!

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

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

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

#2 Презентация: готов объяснить свою работу

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

Крутой дизайнер умеет переключить фокус с творческого и ранимого художника на хладнокровного адвоката. Если кто-то говорит: Это плохо сделано, это не значит, что ты плохой. Это значит, что коллега видит в данном решении слабые стороны. Продвинутый дизайнер отключает эмоции и включает голову. Объясняет и обосновывает свою позицию. Задаёт вопросы, внимательно слушает, делает все, чтобы добраться до истины и хорошего продукта.

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

#3 Аналитика: думает не только о красоте

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

Хороший дизайнер постоянно анализирует, как пользователи будут взаимодействовать с интерфейсом, удобно ли ему переводить деньги другу, перечислять зарплату сотрудникам или подавать заявку на кредит.

С одной стороны, ты должен на интуитивном уровне понимать психологию взаимодействия с интерфейсом. А с другой всегда остаешься скептиком и тестировать свои гипотезы. Порой пользователи воспринимают ту или иную функцию абсолютно непредсказуемо и не понимают твоей задумки. Одна только фраза Мне нравится. Думаю пользователям понравится тоже не поможет. Нужна аналитика. Много аналитики.

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

#4 Понимание бизнес-процесса: переводит с банковского языка на человеческий

Юный дизайнер: мастерски работает в Фигме, любит компоненты, боготворит филигранную верстку.

Продвинутый дизайнер: понимает, как устроен бизнес и финансы.

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

Знает о банке

Знает о пользователе

как устроены процессы внутри банка

над чем работает банк

какие боли клиентов решает

как себя позиционирует и каких принципов придерживается

как работают конкуренты

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

с какими проблемами сталкивается

что делает, чтобы решить эти проблемы

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

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

#5 Любознательность: постоянно учится новому

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

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

Подробнее..

Дайджест интересных материалов для мобильного разработчика 386 (15 21 марта)

21.03.2021 16:08:22 | Автор: admin
В нашей новой подборке троя в библиотеке, автотестирование и полезные протоколы, уязвимости Android и снижение комиссии Google Play, борьба с читерами, человеческое общение, цена покупок, Nest с радаром и многое другое. Подключайтесь!



Этот дайджест доступен в виде еженедельной рассылки. А ежедневно новости мы рассылаем в Telegram-канале.

iOS

Память в Swift от 0 до 1
Погружение в автотестирование на iOS. Часть 4. Ожидания в XCUITest
Работа с сложными JSON-объектами в Swift (Codable)
Коста Элефтериу, создатель FlickType, подал в суд на Apple
Александр Зимин: история победы в Telegram Contest 2021
Библиотека XcodeSpy заражает разработчиков с Xcode трояном
Количество работающих в экономике iOS-приложений в Европе выросло на 7%
Swift 5: полезные протоколы, чтобы писать как профессионал
Реверс-инжиниринг Bluetooth-устройств
Как уменьшить и оптимизировать размер iOS-приложения?
Создание настраиваемого UITextField с помощью Combine
Глубокое погружение в Функции в Swift
Список UICollectionView с интерактивным кастомным заголовком
Чистый Swift: объяснения и шаблоны
Тестирование push-уведомлений в iOS в конвейерах CI/CD
Протоколы в Swift
Реализация модификатора OnChange в SwiftUI для iOS 13
Xcodes.app: много Xcode на выбор

Android

Выходим на рынок Huawei, или Как мы адаптировали приложение для работы с HMS
Большой разговор с новым Kotlin Project Lead Романом Елизаровым
Готовьсь, цельсь, пли! Как не обжечься при сборке Gradle-приложения, и настолько ли всё серьезно?
0x7E5 Рассуждения о главном
Борьба за жизни переменных. Или как я попытался упростить жизнь Android разработчикам
Материалы митапа для андроид-инженеров: поиск проблем сборки, защита от них и работа с Gradle
Уязвимости Android 2020
Android запрещенные приемы
От компьютеров к мобильным устройствам: вывод игр на новые платформы
Android Broadcast: Собеседование в прямом эфире 2. Livecoding. Middle Android Dev
Android Broadcast: новости #7
Плитки в Wear OS открыли для всех
Google снижает комиссию Play до 15%
Компилируйте меньше с SOLID
Использование возможностей дизайн-языка Android
Добавьте вашему приложению жизни
Как мы разработали компонент, который повысил удобочитаемость, масштабирование и тестирование
10 ошибок, которые я сделал как Android-разработчик, но вы не должны
Лучшая обработка состояний между ViewModel и Composable
Создаем приложение с несколькими темами на Android
11 самых популярных библиотек Kotlin на 2021 год
Создаем плагин Android Studio Show layout bounds
Давайте сделаем приложение с таймером обратного отсчета с помощью Android Compose
Tinder-Like: Tinder на Jetpack Compose
Jetpack Release Tracker: отслеживание AndroidX
SegmentedProgressBar: прогресс-бар как в историях Instagram

Разработка

Первые пять шагов для перелома ситуации с читерами в PvP-шутере
Детские шалости: как Roblox стала одной из самых дорогих игровых компаний современности
Минимальное PWA
Автоматизация тестирования мобильных приложений. Часть 2: предусловия, верификация элементов и независимость шагов
Курс тестировщика пройден. А дальше что?
Мобильное настоящее М.Видео: телепортация была стремительной
Flutter вот-вот завоюет Web
Как все-таки экономить на мобильной разработке?
С чего начать изучение Flutter в 2021 году
Адаптация таблиц под мобильные устройства
Обзор мобильного приложения Team
Самый полный список метрик тестирования на русском языке
Podlodka #207: дебаггинг
Flutter Dev Podcast #26: Flutter 2.0
Redmadrobot открывает весеннюю стажировку
Aurora UI: новый визуальный тренд на 2021 год
LinearB объясняет происходящее в проектах разработки
Дизайн приложений: примеры для вдохновения #36
Верхняя или боковая панель навигации: что лучше подходит для вашего продукта?
Как улучшить понимание интерфейса с помощью интуитивных действий
Принципы психологии, которые следует знать каждому продуктовому дизайнеру
Kotlin Multiplatform панацея для разработки мобильных приложений?
5 наиболее часто задаваемых вопросов в собеседованиях программистов в Amazon
Расширения Visual Studio Code для повышения производительности в 2021
Мой опыт собеседования в Google
Будущее приложений: декларативные UI и Kotlin MultiPlatform
Как сделать UI-звуки для игры
10 шаблонов проектирования, которые должен знать каждый архитектор ПО
UX-советы по оптимизации встроенных покупок в играх
Как работать с трудными людьми в программных проектах
Закон Теслера. Вот почему вы не можете сделать UX проще.
Мои 3 самые большие неудачи как разработчика
5 способов увеличить скорость разработки
4 необычных способа улучшить свои навыки программирования
Взламываем код-интервью с помощью этих 5 реальных функций
5 главных ошибок, которые я совершил, когда был нубом в программировании
Clone Wars: клоны популярных проектов

Аналитика, маркетинг и монетизация

Маркетологи в мобайле: Максим Шатерник (Gameloft)
myTracker интегрировался с Google AdMob
Mobile People Talks: Анализируй это аналитика мобильных приложений
Как мы делаем Sleepy: монетизация, первая сессия и paywall
Hi Marley: человеческое общение
Gucci начинает продажи виртуальных кроссовок
Средняя цена на покупки в приложениях выросла на 50% с 2017 года
Apple согласилась на предустановку российских приложений
Основные метрики мобильного приложения

AI, Устройства, IoT

Видеоаналитика М.Видео-Эльдорадо: 30 000 камер, 1 компьютер и нейросеть
Bluetooth Low Energy: подробный гайд для начинающих. Bluetooth Mesh
Google выпускает новый Nest Hub с радаром

< Предыдущий дайджест. Если у вас есть другие интересные материалы или вы нашли ошибку пришлите, пожалуйста, в почту.
Подробнее..

Дайджест интересных материалов для мобильного разработчика 389 (5 11 апреля)

11.04.2021 14:15:43 | Автор: admin
В новом выпуске делаем таб-ба с нестандартной кнопкой и кастомные переходы, эволюционируем декларативные фреймворки и готовимся к I/O 2021, доказываем разработку и отказываемся от стандартных теней. Все это и многое другое в этом дайджесте!



Этот дайджест доступен в виде еженедельной рассылки. А ежедневно новости мы рассылаем в Telegram-канале.

iOS

Настало время офигительных историй. Кастомные транзишены в iOS. [2/2]
Как реализовать таб-бар с нестандартной кнопкой: CAShapeLayer и UIResponderChain
Работа с Bluetooth в iOS
5 секретов, о которых iOS-разработчики вам не скажут
Понимаем параллельную разработку в iOS
SwiftUI: как сделать снимок экрана с содержимым ScrollView?
Создание системы лицензирования для платных приложений на Swift
Плавный скроллинг в iOS
Hive: игра Улей для iOS
IrregularGradient: анимированные градиенты

Android

Rust включили в список основных языков для разработки платформы Android
Android 12 Developer Preview: готовим приложение к новым обновлениям
Эволюция декларативных UI-фреймворков: от динозавров к Jetpack Compose
Жизнь без AppStore и Google Play: работаем с Huawei Mobile Services и AppGallery
MotionLayout + RecyclerView = красивые анимированные списки
Разбираем ELM архитектуру в рамках мобильного приложения
Простой вариант разношерстного recycler view на шаблоне Посетитель
Конференция I/O 2021 пройдет в мае в виртуальном формате
Google Play Store обновил дизайн
Android Broadcast: GraphQL для мобильных разработчиков. Стоит ли использовать REST?
Android Broadcast: новости #8
Мой опыт работы с Flutter как Android-разработчика
Изучение Jetpack Compose создание простого приложения с таймером
Создание уровня данных репозиторий с помощью корутин в Kotlin
Решайте мобильные продакшен проблемы как Шерлок
GitHub Actions: автоматизируйте рабочий процесс сборки и выпуска Android-приложений
Запомните {mutableStateOf ()} шпаргалка
Шумный код с Kotlin Scopes
10 отличных идей для улучшения времени сборки Gradle
Switch Snake: змейка из переключателей
Holi: цвета Jetpack Compose
Uinspector: иерархия представлений

Разработка

Доказательная разработка или как data-driven подход добавил смысла работе
Как мы изменили пайплайн создания контента в PvP-шутере и забыли про кранчи
Почему мы отказались от стандартных теней Unity для мобильных шутеров и вместо этого написали свои
Вам звонок. Как выстроить отношения между QA и техподдержкой
Как написать плагин для Фигмы: проблема, MVP, решение
История одного видео редактора
Как сократить стоимость мобильной разработки
Как мы сделали мобильное приложение для курьеров ВкусВилл за 9 дней
Синтезатор на Unity 3D
Снова про UI\UX дизайн в 1С или как ускорить разработку мобильных приложений
Podlodka #210: технический консалтинг
7 из 10 программистов жалуются на переработки
Objective-C выпал из топа рейтинга TIOBE, а Fortran вернулся
Zoom выпустил Video SDK
Mail.ru Group запустила совместный редактор кода
Google представил аудиокодек Lyra на основе ИИ
4 ошибки, которые я сделал как программист, но мне пришлось стать техническим директором, чтобы увидеть их
Почему изучение программирования не поможет сохранить ваше рабочее место
Дизайн приложений: примеры для вдохновения #39
Рекомендации по проектированию автозаполнения (autosuggest)
10 лучших UI-китов в Figma для вашего проекта
30 самых популярных вопросов на собеседовании по программированию в Apple (с решениями)
Почему менеджеры по-прежнему хотят писать код
Как мы сделали из членов команды Airbnb мобильных инженеров
Как добиться успеха на кодинг-интервью в 2021 году
Лучший технический стек для разработки мобильных приложений в 2021 году
Эволюция написания современных мобильных приложений
8 обязательных расширений для Flutter-разработчиков
5 лучших навыков Senior-программистов
Маркетинг для инди-разработчиков: исследование рынка
Ежедневный стендап пустая трата времени
Ключевой фреймворк, который я использовал, чтобы изучать любые новые технические навыки
5 лучших практик для создания эффективных кнопок
Дизайн взаимодействий это больше, чем просто пользовательские потоки и клики
Прекратите добавлять комментарии к вашему коду
Полезный фреймворк для именования ваших классов, функций и переменных
Как зарабатывать на программировании
Создание красивого интерфейса во Flutter
Архитектура технологического стартапа, состоящего из одного человека

Аналитика, маркетинг и монетизация

Гайд по мобильной рекламе для тех, кто задумался о монетизации
Как мобильное приложение помогло ВкусВиллу стать лидером по количеству заказов продуктов онлайн
Разработка, аналитика и атрибуция. Какие сервисы нужны для мобильного приложения в 2021?
Маркетологи в мобайле: Николай Липкин (Яндекс.Медиасервисы)
Epic и Apple готовятся к суду
Mem получает $5.6 млн на ведение заметок
Bunch: ассистент по лидерству
Charles получает инвестиции на разговорную коммерцию
Самые скачиваемые приложения в марте 2021
Supercell делает еще три Clash-игры
Руководство по продуктовым метрикам

AI, Устройства, IoT

HMM: ловим мошеннические транзакции
Wi-Fi розетка с управлением через Интернет за 60 минут
Чем мобильные разработчики заряжают девайсы: 10 новых качественных аксессуаров с AliExpress

< Предыдущий дайджест. Если у вас есть другие интересные материалы или вы нашли ошибку пришлите, пожалуйста, в почту.
Подробнее..

Дайджест интересных материалов для мобильного разработчика 390 (12 18 апреля)

18.04.2021 12:07:38 | Автор: admin
В этом дайджесте рассматриваем новые подходы к спискам и коллекциям, вопросы автогенерации музыки и написание безболезненных unit-тестов, спиннеры и иконки, рост приложений, вентиляторы, генерацию идея для игр и многое другое!



Этот дайджест доступен в виде еженедельной рассылки. А ежедневно новости мы рассылаем в Telegram-канале.

iOS

Связанные неявные выражения в Swift 5.4
Подходы к спискам на UICollectionView
В App Store обнаружили казино, которые притворяются детскими играми
Apple анонсировала конференцию Spring Loaded 20 апреля
Apple работает над комбинацией Apple TV и HomePod
Apple не выпускает iMessage на Android, чтобы пользователи не уходили с iPhone
Более эффективный/быстрый способ получить средний цвет изображения
Представляем Коллекции в Swift
Миграция вашего приложения на Swift Package Modules
Как вложить UITableView в UICollectionViewCell и сделать как у Trello
Создание, анимация и настройка кругов в Swift
5 советов по написанию чистого Swift-кода
Встроенный инструмент рефакторинга Xcode великолепен
Объяснение каждого протокола SwiftUI
UIKit Live Preview для UIViewController и UIView
Руководство по iOS-архитектуре MVVM+Coordinators
Создание нативного обмена сообщениями через Firebase с помощью SwiftUI
CollectionViewPagingLayout: красивые UICollectionView
FDWaveformView: визуализация звука для iOS
3D Flip menu: трехмерное меню

Android

Как портировать SDK Flutter на ТВ-приставку для разработки и запуска приложений Android TV
Практическое использование автогенерации музыки
In-App-Review. Фильтруем негативные отзывы
Пишем unit тесты так, чтобы не было мучительно больно
Стилизуя нестандартно
Реализация Undo в Snackbar на Jetpack Compose
Coroutines: хаотичное изучение
Android Jetpack Compose: простая анимация
Stateful Android приложение с MVI (MODEL VIEW INTENT)
Насколько подробно вы можете ответить на эти вопросы как Android-разработчик?
Compose CameraX в Android
Использование DataStore с сериализацией Kotlin
Кеширование в процессе Android-сборки
Пример против MVI архитектуры
Современный способ передачи данных между фрагментами
Android Tool: упрощение работы с adb и fastboot
BlurShadowImageView: красивые тени для изображений

Разработка

Повышаем качество кода с Dart Code Metrics
Препродакшн игровых проектов: как оценить объем работ на старте и не сгореть к дедлайну
Cordova. Опыт Enterprise-проекта
Уродливый API
Судно на воздушной подушке на Unity 3D
История одного личного кабинета, который помог нам сделать 15 000 курьеров и сборщиков немного счастливее
Регдоллы на Unity 3D
Русские программисты не сдаются
Podlodka #211: Haskell
Рабочий день разработчика гипер-казуальных игр
Дизайн приложений: примеры для вдохновения #40
Google запустил бесплатный курс по Python на Coursera
Полезный фреймворк для именования ваших классов, функций и переменных
Прекратите использовать спиннеры есть кое что получше
Проектирование циферблата CASIO для Apple Watch
Советы по дизайну лучших интерфейсных иконок
Как улучшить навыки дизайна с помощью насмотренности
5 основных продуктовых фреймворков
3 основных урока, извлеченных из создания приложения
Полное руководство разработчика по качеству кода
Книги по программированию, которых не существует (но мы все читали)
Чистая архитектура для корпоративного мобильного приложения
Руководство разработчика приложений для собеседований по системному дизайну
Как я сделал игру за 35 часов
Пять вещей, которые я узнал после решения более 500 вопросов Leetcode
10 бесплатных инструментов для создания пользовательских интерфейсов
Советы по созданию качественного приложения с Firebase
Почему @protocol все поменяли для Flutter-разработчиков?
Как синдром самозванца может помочь вам стать лучшим разработчиком
Создание Age of Empires II
Почему некоторые разработчики избегают головной боли магазинов приложений, оставаясь только в Интернете
Как создавать лучшие иконки
Провал одного технического интервью научил меня большему, чем прохождение трех
Психологические принципы для каждого продуктового дизайнера
7 лучших советов и рекомендаций по работе с Dart для более чистых Flutter-приложений
Резюме, которое привело меня в FAANG
19 реалистичных привычек для улучшения разработки
Замена React Native на Kotlin Multiplatform в Wantedly

Аналитика, маркетинг и монетизация

Как мы достигли 1 млн скачиваний с нулевым бюджетом
На какие языки стоит перевести игру в 2021: обзор от Alconost
Рост мобильных приложений 2020 Отчет Adjust и Facebook
Litoff и App Annie: загрузки финансовых приложений в 2020 выросли на 15%
Исследование AppsFlyer: процент ATT-согласия намного выше, чем ожидалось
Bethesda тестирует Mighty DOOM
Canvas Medical: хороший UI для медицины
7 простых способов ранжироваться в сторе выше
Измените свой дизайн для глобальной аудитории: исследование кросс-культурного UX-дизайн
Как продать мобильное приложение?
Европейские шпили: как наше приложение доехало до Германии и Польши
5 лучших инструментов продуктовой аналитики 2021
Удерживаем пользователей как Amazon, Spotify и др.

AI, Устройства, IoT

Зачем все ставят вентиляторы в туалет или как мы решили сделать умный вентилятор, история по DIY
Edge платы для домашнего Computer Vision
Чем Tarantool круче Redis'а для IoT-сервисов
Создание своей оценочной платы для микроконтроллеров
Война миров во вселенной IoT/IoE доколе?
ИИ-платформа генерации идей для игр Ludo вышла из бета-версии
NVIDIA выпустила диалоговый фреймворк Jarvis

Предыдущий дайджест. Если у вас есть другие интересные материалы или вы нашли ошибку пришлите, пожалуйста, в почту.
Подробнее..

Дайджест интересных материалов для мобильного разработчика 393 (10 16 мая)

16.05.2021 14:08:59 | Автор: admin
В этом дайджесте процесс загрузки iPhone и организация стриминга на нем же, борьба App Store с разработчиками мошенниками, концепции Jetpack Compose и обзор Android Automotive OS, этический антидизайн, вопросы АТТ-согласия и многое другое.



Этот дайджест доступен в виде еженедельной рассылки. А ежедневно новости мы рассылаем в Telegram-канале.

iOS

Процесс загрузки iPhone. Часть 1: Boot ROM
Видео-стриминг на iOS по RTMP
Фантомные типы в Swift
Пошаговый урок: как начать делать что угодно для Touch Bar
Core Data + Repository pattern. Детали реализации
Построение графиков в SwiftUI
Apple подчеркивает усилия по борьбе с мошенничеством в App Store
В App Store работает более 500 модераторов и они проверяют более 100,000 приложений в неделю
Акторы в Swift: практический пример
Локализация строк и управление версиями в iOS с помощью Firebase
Замена селекторов замыканиями в UIButton
Создание собственного парсера Markdown с нуля на Swift
Поиск Spotlight для ваших приложений
Важность новых технологий в iOS-разработке
Как использовать Firebase в новом жизненном цикле приложения SwiftUI
BodyProgress: физические упражнения на SwiftUI
TOCropViewController: удобный кроп для изображений

Android

Как использовать облачную ферму устройств Huawei для тестирования и отладки в Android Studio
Как мы создали облачный сервис для управления и контроля за маршрутами обходов на предприятиях
Концепции Jetpack Compose, которые должен знать каждый разработчик
Jetpack Paging 3: пагинация на Android
Масштабирование архитектуры в Lyft с Денисом Неклюдовым
Обсуждаем Kotlin 1.5 и что будет в Kotlin 1.6
Вышла превью-версия Jetpack Compose для веба
Обзор Android Automotive OS
Адаптация вашего приложения под Android 11
Наш опыт миграции на корутины с RxJava
Bottom Navigation и Navigation Drawer с помощью Scaffold из Jetpack Compose
Руководство по архитектуре, рекомендованной Google для Android-приложений
Фоновый инспектор задач
Навигация: вложенные графы и тег включения
KMMT: шаблон приложения на Kotlin Multiplatform Mobile
ModernStorage: простая работа с данными

Разработка

Этический антидизайн. Разработка продуктов, которые не вызывают привыкания
Мобильные приложения перестали быть подходящей идеей для стартапов
Мобилка hh.ru теперь и в Беларуси: как жить, когда команду раскидало
Разработка первой игры на Construct 3
Углубленный анализ тестирования виджетов во Flutter. Часть II. Классы Finder и WidgetTester
Исследование движения глаз для улучшения здоровья и доступности
Podlodka #215: тест-менеджмент
Распродажа Azure Cloud Computing в Humble Bundle
Niantic расширяет доступ к своей платформе Niantic Lightship AR
Snapchat открывает Creator Marketplace
YoYo Games запустила игровое руководство по GameMaker Studio 2
Sendbird предлагает API для групповых голосовых и видео звонков
Дизайн приложений: примеры для вдохновения #42
Почему важно применять междисциплинарный подход в дизайне
Как лучше управлять бизнес-логикой в приложениях Flutter
Системный дизайн дейтинг-приложений
Дорогостоящие ошибки: почему нам пришлось отказаться от Firebase
10 трюков с Figma, о которых я хотел бы знать раньше
От нуля до MVP за 3 месяца с Flutter
Урок номер один, который я усвоил, управляя небольшой командой разработчиков
11 хитростей искусства гугления для разработчика
Как мы достигли скорости записи 1.4 миллиона строк в секунду

Аналитика, маркетинг и монетизация

7 подсказок, как создать и улучшить Battle Pass в вашей игре
Маркетплейс одежды Vinted получил 250 млн при оценке в 3.5 млрд
GasBuddy: бензин рядом
AppsFlyer: процент ATT-согласия в России достигает 42%
Flurry: согласие на отслеживание дали только 5% пользователей iOS
Сезонность проекта: не бойтесь летнего спада
Как мы достигли 1 миллиона загрузок с нулевым бюджетом
Kakao приобретает платформу микрочтения Radish
IronSource запускает аналитическую платформу LiveGames для гиперказуальных игр

AI, Устройства, IoT

Использование LoRa для интеграции кота в IoT
Монетизация машинного обучения: как превратить данные в деньги
Linux Foundation запускает AgStack Foundation для сельского хозяйства

Предыдущий дайджест. Если у вас есть другие интересные материалы или вы нашли ошибку пришлите, пожалуйста, в почту.
Подробнее..

Дайджест интересных материалов для мобильного разработчика 394 (17 23 мая)

23.05.2021 20:21:44 | Автор: admin
На этой неделе у нас новая Google I/O, доступность iOS, банки и штаны, автотесты и разумные A/B-тесты, методы атрибуции, свободная Цивилизация и многое другое.



Этот дайджест доступен в виде еженедельной рассылки. А ежедневно новости мы рассылаем в Telegram-канале.

iOS

Обертки свойств в Swift с примерами кода
Крейг Федериги назвал уровень безопасности Mac неприемлемым
Учебный курс Разработка приложений для iOS с использованием SwiftUI
Книга Про доступность iOS
Как создать приложение с использованием SwiftUI и CoreData
Swift инструмент автоматической стилизации кода в 2021
Советы iOS-разработчикам в 2021 году
App Thinning: синхронизация локализованных строк в Outlook для iOS
13 полезных методов работы с массивами в Swift
Вертикальный пейджинг в SwiftUI
SwiftUI + Core ML+ ARKit создаем приложение для определения объектов для iOS
Создаем утилиту командной строки с помощью Swift Argument Parser
Мои приложения в топе инструментов разработчиков (магазины приложений для iOS и Mac): я заработал 60 долларов
База данных Notion + iOS
Прохождение туториала Scrumdinger по SwiftUI от Apple
Взламывая iOS-интервью
Самые популярные тенденции в разработке приложений для iOS в 2021
MediumCup UI: стакан на SwiftUI
LocalConsole: консоль в приложении

Android

Банки ультимативно лезут к нам в штаны личную жизнь
Почему Kotlin хуже, чем Java?
Рисуем светом: длинная выдержка на Android
Google I/O 2021: что нового для Android-разработчиков (полный обзор)
То, чего нам так не хватало: Render Effect в Android 12
Google I/O: что нового представили Android-разработчикам
Производительность Android Runtime vs NDK
Пример модульного андроид приложения с помощью Navigation component и Koin (DI)
Developer Keynote с Google I/O 21
I/O 21: обновление Firebase
I/O 21: Android 12 Beta 1
I/O 21: 3 миллиарда устройств на Android
I/O 21: разговорный ИИ LaMDA
I/O 21: Flutter 2.2
I/O 21: Wear OS 3.0
I/O 21: Material You новый язык дизайна
Инструменты статического анализа для Android
Jetpack Compose: стили и темы
Понимаем паттерн MVVM для Android в 2021 году
Бесконечные списки с автоматической прокруткой с RecyclerView и LazyLists в Compose
Разрабатываем HelloAR в Android Studio с помощью ARCore и Sceneform
Миграция с LiveData на Kotlin Flow
Современный сплеш скрин в Android
Как мы улучшили процесс code review в инженерной команде Android
Kotlin SharedFlow или как я прекратил использовать RxJava и полюбил Flow
Интеграция Dagger 2 и Jetpack Compose
Лучшие практики View Binding
Исследуем новые тактильные функции в Android 12
Movies: кино на основе MVVM

Разработка

Три паттерна для улучшения работы с автотестами
Ремастеринг игрового контента, или как создать 800 единиц контента за семь месяцев
Flutter: флип-анимация
Wild Horizon или как осуществляется на практике мечта игродела
Все, что вы хотели знать про диалоговый UX/UI в проектировании чат-ботов
Mobile People Talks: Legacy
Podlodka #216: типографика
Исследование: кто находит работу после онлайн-обучения
Дизайн приложений: примеры для вдохновения #43
Google запустил курсы для технических писателей
Задачи с собеседований: размен
No-code платформа разработки приложений Adalo получила $8 млн
Книги о программировании на Python в Humble Book Bundle
Работает не трогай: как Snapchat переписал свое приложение для Android
10 уроков по UX дизайну, которые я хотел бы усвоить раньше
3 способа самостоятельно радикально улучшить свои навыки программирования
10 потрясающих шрифтов Google, которые вы будете использовать в 2021 году
Coinbase успешно перешел на React Native
5 самых сложных вопросов по программированию из интервью FAANG
Что не так с Flutter
5 лучших сервисов AWS для запуска любого проекта
Как развить сверхчеловеческую концентрацию при написании кода
Unciv: открытая Цивилизация

Аналитика, маркетинг и монетизация

Время деньги: анализируй А/В-тесты разумно
Какие ошибки совершает аналитик в первые полгода работы и как их избежать
Хочу всё знать о клиенте! Или как обогатить сухие факты DWH цифровыми путями и свойствами клиента из Amplitude
Игровая экономика: игры free-to-play
Somewhere Good: анти-социальная сеть
По данным Post-IDFA Alliance, UA затраты на Android выросли на 21% после внедрения iOS 14.5
Анализируем iOS 14.5: методы атрибуции
Как создавать эффективную видеорекламу для приложений
Быстрый рост неигровых приложений с Wow-booster
Нативная реклама мобильных приложений в TikTok
Все приложения делают это: крадут друг у друга. Как это влияет на мобайл и ASO?
Калькулятор экономики для мобильных подписок

AI, Устройства, IoT

Ребята взломали машину для мороженого и начали холодную войну с её производителем
Интервью с менеджером проектов АСУ: цифровизация, интернет вещей и умные города
Snap представил AR-очки Spectacles
Дата сайентисты вымрут через 10 лет
Сбер запускает набор Kidsar для AR-приложений на SberPortal
Как сделать монитор качества воздуха с помощью Raspberry Pi Zero W

Предыдущий дайджест. Если у вас есть другие интересные материалы или вы нашли ошибку пришлите, пожалуйста, в почту.
Подробнее..

Дайджест интересных материалов для мобильного разработчика 395 (24 30 мая)

30.05.2021 20:12:29 | Автор: admin
В этом дайджесте переезд на Swift и 36 секунд доступности, валидация встроенных покупок и кросс-системное тестирование, симпатичный чейнджлог, проблемы с неткодом, переезд Coinbase на React Nativeи многое другое!



Этот дайджест доступен в виде еженедельной рассылки. А ежедневно новости мы рассылаем в Telegram-канале.

iOS

Как Лёня с React на Swift переезжал
Доступность на iOS началась с 36 секунд
Самые популярные SDK после выхода iOS 14.5
Всемирная конференция Apple для разработчиков начнётся 7 июня и пройдёт в онлайн-формате
Эван Шпигель поддержал налог App Store и меры защиты Apple
Как управлять поведением клавиатуры в iOS-приложениях
MVP архитектура для iOS
Как разрабатывать приложения для iOS без Mac
Как использовать SnapKit в ваших iOS-приложениях
Как использовать Firebase Remote Config с Swift 5
3 способа стилизации представлений SwiftUI
HMS ML Kit: перевод в реальном времени (iOS Swift)
ScrollingContentViewController: простое создание скроллируемого View
NotificationToast: тосты для iOS
CalendarKit: календарь для iOS, iPadOS и macOS

Android

Интеграция и серверная валидация инаппов для стора Google Play как защититься от читеров
Обновляемся на новую версию API Android по наставлению Google
Создаем приложение для Android быстро и просто
Почему Kotlin лучше Java?
Особенности тестирования Android без Google-сервисов
Получаем результат правильно(Часть2). FragmentResultAPI
Как начинающему Android-разработчику прокачать свои навыки: 5 open source проектов для изучения
Полезные расширения Kotlin для Android
Hilt стабилен. Более простая инъекция зависимостей на Android
Повышаем уровень своего класса данных Kotlin с помощью расширений
Историческое введение в модель реактивного состояния Compose
Совершенно новое Состояние в Jetpack Compose
Улучшение преобразования кода Java в Kotlin: пример
Структурированный параллелизм в действии
Начните отсюда: 5 упражнений для подготовки вашего приложения к работе с большими экранами
Начинаем работать с WorkManager
Простые инструментальные тесты (UI-тесты) для Android в 2021 году
Введение в Security By Design
KodeEditor: редактор кода для Android
SuperForwardView: перемотка в стиле Netflix

Разработка

Почему мы решили создать отдел кросс-системного тестирования
Лаги, джиттер и потеря пакетов: откуда берутся проблемы с неткодом и как их решать
7 QA-шных грехов, которые помогут или помешают тестировщику (стать тем, кем ты хочешь)
За что банит Apple(и Google)
Как написать симпатичный чейнджлог: опыт Авито
Без тимлида не обойтись, а что насчет техлида?
Как сохранить нервы тестировщика или ускорить регресс с 8 до 2 часов
Как я хотел поработать нативным Android разработчиком, но устроился Flutter разрабом
Dart: Быстрые неизменяемые коллекции
6 способов снизить когнитивную нагрузку от интерфейса
Podlodka #217: фасилитация
Flutter Dev Podcast #27: как работает рендеринг UI
Как Coinbase перешел на React Native
Stack Overflow запустил новый ежегодный опрос разработчиков
Fuchsia получила свое первой устройство
Мой SaaS добился MRR $12.5K за один месяц: вот чему я научился
Куда уходят программисты?
Онлайн-конференция Google for Games Developer Summit 2021 пройдет в июле
Проблема дизайна это сами дизайнеры
Пользователям плевать на дизайн: как устроен хороший UX на самом деле
Хотите стать лучшим UX дизайнером? Создавайте эмоциональный дизайн
Лучшие языки программирования для изучения в 2021 году
10 вещей, которые хорошо знают опытные разработчики
Почему софтверные компании часто отвергают хороших программистов
Наплевать на доступность
Самые востребованные языки программирования в 2021 году
Избегайте блокировки CI/CD делайте свои сборки более портативными
Flutter: CRUD с использованием Firebase Cloud Firestore
Одна привычка, чтобы стать лучшим разработчиком
Что нового во Flutter 2.2
Библиотека разработчика от Google

Аналитика, маркетинг и монетизация

Датасет о мобильных приложениях
Реклама мобильных игр в первом полугодии 2021: мировая статистика
RevenueCat закрыл Серию B при оценке в $300 млн
Платформа отладки Lightrun получила $23 млн
Платформа потери веса Noom привлекла $540 млн
Тренды мобильных приложений 2021: отчет Adjust
Дейтинг-приложения предложат улучшения прошедшим вакцинацию
Google запускает рекламные кампании приложений на десктопах
Netflix думает над выходом на игровой рынок
Одних технологий недостаточно: что раздражает рекламный рынок в Apple и как она зарабатывает на закрытости системы

AI, Устройства, IoT

ML: нечеловеческие технологии для человеческих цен
TinyML. Сжимаем нейросеть
SberCloud + Intel oneAPI = льготное облако для ML-разработчиков
IBM разработала датасет Project CodeNet для обучения ИИ программированию
Как сделать бизнес на AR/VR
Mail.ru Group открыла новый набор на бесплатное обучение в Академию больших данных MADE
Microsoft использовала GPT-3 для создания кода на естественном языке
Best Buy начинает продажи смартфона для пожилых

Предыдущий дайджест. Если у вас есть другие интересные материалы или вы нашли ошибку пришлите, пожалуйста, в почту.
Подробнее..

Дайджест интересных материалов для мобильного разработчика 379 (25 31 января)

31.01.2021 18:12:32 | Автор: admin
В этом выпуске выпиливание Realm и создание виджетов, секреты приготовления BLE и уменьшения ANR в шесть раз, вопросы навигации и развития в Android-разработке, подготовка к собеседованию и работа мобильной розницы во время карантина. Все это и многое другое в новом дайджесте!



Этот дайджест доступен в виде еженедельной рассылки. А ежедневно новости мы рассылаем в Telegram-канале.

iOS

Быстрый, простой, сложный: как мы выпилили Realm
HexThrees моя первая законченная игра
Как создать виджет для iOS 14 (и не удалить его у пользователей при обновлении)
Погружение в автотестирование на iOS. Часть 2. Как взаимодействовать с ui-элементами iOS приложения в тестах
MFS паттерн построения UI в iOS приложениях
Паттерн MFS для табличных представлений в iOS приложениях
Apple внедрит защиту конфиденциальности ранней весной
Apple приглашает на онлайн-конференцию Создание отличных виджетов
Twitter открыл Text Editor API для iOS-разработчиков
Приложение-песочница: как iOS-разработчики автоматизируют рутинные задачи
Введение в Core Graphics
7 расширений Swift, которые должен использовать каждый iOS-разработчик
Профилирование SwiftUI приложений с помощью Инструментов Xcode
Как символизировать логи сбоев в iOS
ToastUI: тосты для SwiftUI
XCMetrics: анализ логов Xcode

Android

Приложение отвечает: как мы уменьшили количество ANRs в шесть раз. Часть 2, про исправление ошибок + Часть 1
Как обойти проверку на Рутинг устройства, обхитрив библиотеку RootBeer?
Android Bluetooth Low Energy (BLE) готовим правильно, часть #4 (bonding)
Ликбез по Navigation Component: тем, кто пропустил все туториалы
Navigation Component и multi backstack navigation
Автоматизация публикации приложения в Google Play при помощи Jenkins
Safe Args?? верный помощник Navigation Component
Как развиваться в Android-разработке и где брать новые знания
Android Broadcast: превращаем Android приложение в Kotlin Multiplatform
Обновление FragmentViewBindingDelegate: ошибка, унаследованная от AutoClearedValue)
Использование Hilt ViewModelComponent
Обработка ответов из сети для Android-проектов с помощью Sandwich
Epoxy создание декларативных и повторно используемых компонентов пользовательского интерфейса
Unity как библиотека: добавьте функции Unity в ваше Android-приложение
Решение архитектурных проблем в мобильных приложениях с Bluetooth Low Energy
Android TopSheet реализация
Машинное обучение в Android с помощью TensorFlow Lite
Поиск ошибок в приложении для Android
9 распространенных ловушек при Android-собеседовании
ComposeSlackDesktop: Slack на Jetpack Compose

Разработка

Менеджер приложений для Windows Mobile
Работа с асинхронностью в Dart
Кроссплатформенный мультиплеер на Godot без боли
Онбординг нового разработчика с помощью Ansible
Все, что вам нужно знать о маршрутизации между страницами в Flutter
Podlodka #200: как учить языки программирования
make sense podcast: О процессах в продуктовых командах
Моя подготовка к собеседованию в Google
Платформа Ludo помогает придумывать идеи игр с помощью ИИ
Дизайн приложений: примеры для вдохновения #29
Задачи с собеседований: ветер
Яндекс открывает набор в летние школы разработки и дизайна
Почему красивое кажется удобным: разбираем интерфейсы с точки зрения науки. Часть 1
5 мощных IDE, о которых никто не говорит
Не просто пишите код, решайте проблемы
Разбираем блестящий и простой дизайн Tinder
Создание приложения для криптовалюты с помощью Flutter
10 непростительных фраз, которые не надо говорить на собеседованиях
Мобильные приложения больше не являются хорошей идеей для стартапов
Как разместить Docker сервер многопользовательской игры Unity в облаке Google
5 простых способов улучшить навыки отладки
3 простых метода для улучшения навыков программирования
Где лучше работать продуктовому дизайнеру? Дизайн-агентство vs. продуктовая компания
Цепочка ответчиков iOS: UIResponder, UIEvent, UIControl и как их совместить
10 лучших бесплатных инструментов для разработки игр в 2021 году
5 шаблонов проектирования, которые должен знать каждый программист
Худшая ошибка, которую вы можете сделать во время технического интервью
Ray: трассировка лучей в ASCII

Аналитика, маркетинг и монетизация

Разумный женский календарь: как делают приложение 1 в категории Здоровье и фитнес
Google Play разрешает игры на деньги еще в 15 странах
Charlie: игровое избавление от долгов
Почти все российские государственные приложения передают данные сторонним компаниям
Руководство маркетолога по новостному приложению 1 в Китае: Toutiao
Literati получил $40 млн на развитие книжного клуба
Симуляторы показали наибольший рост доходов в США
В какие игры еще играют пользователи: исследование AppsFlyer
Маркетологи в мобайле: Виталий Шахматов (Hoff)
Bodyguard: автоматическое удаление негатива
Голосовой чат Clubhouse получает инвестиции и начинает монетизацию
Персонализация предложений в мобильном приложении и интернет-магазине: кейс ВсеИнструменты.ру

AI, Устройства, IoT

Системы контроля управления доступом в IoT умеем, знаем, практикуем
OpenCV проводит конкурс пространственного ИИ
Google открывает Tilt Brush
Как сделать IoT-устройство

< Предыдущий дайджест. Если у вас есть другие интересные материалы или вы нашли ошибку пришлите, пожалуйста, в почту.
Подробнее..

Дайджест интересных материалов для мобильного разработчика 380 (1 7 февраля)

07.02.2021 20:15:43 | Автор: admin
В новом дайджесте уязвимости в Android, сокращение аналитического трафика и жидкие персонажи, AR-маски и страдания Senior-а, работа с привычками, лучшие издатели года и многое другое!



Этот дайджест доступен в виде еженедельной рассылки. А ежедневно новости мы рассылаем в Telegram-канале.

iOS

Apple выпускает бета-версию iOS 14.5 и бета-версию macOS 11.3 для разработчиков
Треть iOS-разработчиков неправильно описывает использование конфиденциальных данных
Ленивая навигация в SwiftUI
Интеграция SpriteKit в приложение
Как создать представление коллекции карт в стиле Revolut на iOS
Как масштабировать изображение внутри заголовка TableView
Обрабатываем корутины Kotlin Multiplatform в Swift Koru
Как начать машинное обучение с помощью Swift и TensorFlow
Составная архитектура одна из лучших архитектур для SwiftUI
Когда писать self в Swift
SwiftUI и Core Data: путь MVVM
Создание мобильного чата с использованием Realm
Субмодули для Xcode
MortyUI: GraphQL + SwiftUI
Wyler: запись экрана на iOS

Android

Как root-права и альтернативные прошивки делают ваш android смартфон уязвимым
Android Academy. Вы все пропустили! Но это не точно
Android Broadcast: новости #2
В 2020 году Google выплатил рекордные 6.7 млн долларов за поиск уязвимостей
Harmony OS оказалась Android
Telegram начинает конкурс для Android-разработчиков
7 распространенных ошибок, которые легко сделать с Android Fragment
Плохие расширения Kotlin
Моделирование состояния UI на Android
Android тогда и сейчас: навигация
Нарушение Null-Safety в Kotlin с помощью циклических ссылок
Масштабируемое изображение с Jetpack Compose
9 любимых расширений Android KTX
Можно ли доверять измерениям времени в Profiler?
Модуляризация приложений Android в 2021 году
Расширения Kotlin
GaugeProgressView: круговой индикатор для Android
Bouncy: отскок для RecyclerView

Разработка

Как мы просто сократили объем входящего в дата-центр трафика на 70%
Китайцы создали альтернативу Android и iOS на Ubuntu для смартфонов и планшетов
UI-элементы и жесты в мобильных приложениях
Как мы научили мессенджер ТамТам распознавать адреса в тексте
Жидкий персонаж на Unity 3D
Использование сервисов и обработка их результатов в Xamarin
Бильярд на Unity 3D
Обзор технологий трекинга: AR Маски
Envoy как универсальный сетевой примитив
Чего ждать от коробочных приложений?
Flutter ListView и ScrollPhysics: Детальный взгляд
Эффект дождя. Частицы в Unity 3D
Podlodka #201: End-to-end ML
Дизайн приложений: примеры для вдохновения #30
МВД хочет добавить в приложение определение номеров мошенников
Задачи с собеседований: футбол с одной монеткой
5 страданий Senior-разработчика
Kite запустил Team Server для автодополнения кода на предприятиях
7 самых известных или дорогих ошибок в программном обеспечении
Шаблоны проектирования: 5 самых известных
Яндекс открывает набор на летние стажировки
Mail.ru Group открывает набор на бесплатные курсы по программированию и автотестированию
Годовой отчет Liftoff о трендах мобильной рекламы и приобретения пользователей
Blue Chips экономическая стратегия для мобильных устройств
Как создать продуманный дизайн push-уведомлений
Фундаментальные принципы дизайна темной темы
AppDynamics представила решение для защиты приложений от киберугроз
Итоги Flutter Warsaw 2020
Вопрос на техническом интервью после которых я сразу отказываюсь
Эффект мерцания в Flutter
Condensation: распределенная база с безопасностью

Аналитика, маркетинг и монетизация

Bold: фитнес для пожилых
make sense: О работе с Retention, эффективных триггерах и формировании привычек
Telegram обогнал TikTok и стал самым скачиваемым приложением в январе 2021
LOVEMOBILE #11: Аналитика в Estee Lauder
AppLovin покупает Adjust
Отчет Состояние дейтинга 2021
Cutback Coach: умеренное потребление алкоголя
App Annie назвала топ паблишеров года
Facebook тестирует уведомление пользователей об использовании данных в iOS
Новые правила Apple изменят мобильную рекламу навсегда. Разработчики узнали об этом в июне, но только 13% подготовились
Its a good choice: грамотная аллокация бюджета при привлечении новых пользователей. Кейс Rate & Goods и Rocket10
Как продвигать инди-приложения? Бюджетные способы и кейсы
Тенденции UI/UX-дизайна 2021 года и как заставить их работать на вас
Перестаньте спрашивать своих пользователей, чего они хотят

AI, Устройства, IoT

Bluetooth Low Energy: подробный гайд для начинающих. Соединения и сервисы
Курсы и книги для изучения data science c нуля
Собираем нейросети. Классификатор животных из мультфильмов. Без данных и за 5 минут. CLIP: Обучение без Обучения + код
Интернет вещей по-русски. Канальный уровень OpenUNB. Общие положения и адресация устройств
Клавиатура для обучения слепой печати бьет током при ошибках
Facebook разрешил загрузку в Oculus через App Lab
Azure Quantum открыли для разработчиков
ARKit и бизнес: как разработчики используют дополненную реальность в серьезных задачах
Предсказываем рост популярности GameStop в 20 строк кода
Определение звуков с помощью глубокого обучения
8 примеров использования машинного обучения в финансах и финтехе

Предыдущий дайджест. Если у вас есть другие интересные материалы или вы нашли ошибку пришлите, пожалуйста, в почту.
Подробнее..

Снова про UIUX дизайн в 1С или как ускорить разработку мобильных приложений

09.04.2021 04:13:25 | Автор: admin

Ранее делился тем, как мы решаем проблему отсутствия UI\UX дизайна в 1С с помощью Java Script и React.js. Сегодня обсудим роль и влияние дизайна на скорость разработки и внедрений мобильных приложений на 1С.

Для чего вообще заниматься дизайном, если и так все хорошо на рынке ИТ, спрос велик, работы валом и т.д.?

Три ключевые причины:

  1. Снизить себестоимость, за счет многократных доработок\переделок, когда Заказчик (внутренний\внешний) видит продукт, только после разработки, а не ДО разработки, когда может хоть как-то повлиять.

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

  3. Ускорить внедрение разработанного ПО и снизить нагрузку на техническую поддержку, как свою, так и Заказчика.

Технология разработки, когда до начала программирования, быстро, просто и дешево дизайнишь прототип (MVP), в online обсуждаешь, согласовываешь и сдаешь заказчику, после чего начинаешь кодить зарекомендовала себя на все 100%.

Более того, был опыт, когда задизайнили идею надстройки\расширения к типовой конфигурации, запустили рассылку по внутренней базе и получили тут-же лиды = $!

Как тебе такое Илон Маск? Зерокодинг воплати!

В мобилке тема UI и UX дизайна, прототипирования, MVP стоит ещё острее чем в десктопе. Так, года два назад, обратился в ряд компаний с ТЗ на мобильное приложение и все мне предложили примерно следующий порядок реализации проекта:

Этап 1. Исследование и составление ТЗ

Сбор и формализация требований;

Разработка и проектирование прототипа приложения;

Разработка и проектирование UX/UI интерфейсов ключевых экранов приложения;

Подготовка ТЗ с описанием принципа работы функционала.

Этап 2. Разработка приложения на основании документации, составленной на этапе 1.

2.1. Разработка серверной части:

2.2. Разработка клиентской части:

.

2.3. Тестирование и отладка:

..

2.4. Публикация мобильного приложения в Store:

.

Этап 3. Передача исходных материалов проекта.

Попробовал, и понял на сколько круто, быстро, удобно! Во-первых, был впечатлен конкретным дизайнером в конкретной компании, звали Олеся. Понимала мои запросы с полуслова, сама предлагала кучу классных дизайн-решений, у меня слюнки текли и хотелось уже быстрее дождаться разработки и получить долгожданный прототип. Во-вторых, я участвовал сам в создании своего детища, сам решал, как будут называться кнопки, что будет в результате их нажатия и т.д., конечно 80-90% решений было за Олесей, но те 10% влияния, что я оказывал были ценны для меня. В-третьих, мы были на одной волне с разработчиками, ведь уже не только куча текста было написано, но и был кликабельный прототип, ожидание и реальность сошлись на много быстрее и четче!

Создавая мобильные приложения на платформе 1С, приходится сразу кодить\конфигурировать. Продвинутые компании юзают не привычный 1С-му глазу Axure или Figma, долго настраивают, готовят UI Kitы и только после этого дизайнят интерфейс 1С, как из конфигуратора. Все это долго.. нудно и посильно не всем с коробки, короче "Такси - сел и поехал" не получается ;-)

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

Технологии и архитектура уже известные:

Frontend

В основе лежит Single Page Application подход и фреймворк React.

ru.reactjs.org

Для реализации UI конструктора форм возьмем Material UI.

material-ui.com/ru

Сетка для проектирования форм и реализации колонок будет взята тоже из Material, но потребует настройки.

material-ui.com/ru/components/grid

Примеры реализации аналогичной идеи Drag&Drop создания макета из элементов:

github.com/chriskitson/react-drag-drop-layout-builder
github.com/kiho/react-form-builder
github.com/saravananangu/react-drag-drop-form-builde


Backend
На первом этапе достаточно использовать serverless подход и взять Google Firebase за основу.

В дальнейшем начнем разработку собственного backend-приложения на Node.js.

Архитектура:

Что пока получается:

На этот прототип понадобилось 10 минут:

Оказалось, что реализовывать инструмент прототипирования мобильной платформы 1С в разы сложнее десктопа, ведь логика элементов мобильных форм 1С платформы куда сложнее чем десктоп, так же есть особенности растягивания элементов по размеру экрана и т.д. и т.п. Пока тестируем на внутренних проектах и на ряде клиентов, но в целом, технология так же себя оправдывает: разработка и сдача работ заказчику увеличивается минимум на 25-30%, но есть одно НО: нужно выращивать компетенции дизайнера внутри, привлекать консультантов внешних, из мира web и мобильной разработки, в итоге появляются внутренние 1С:Дизайнеры ;-)

Всем успешных проектов, мира и добра!

Подробнее..

SVGator.com на практике

20.05.2021 18:13:57 | Автор: admin

Привет, мы дизайнеры экосистемы Своё для фермеров и банковских сервисов Россельхозбанка. Рассказываем, зачем нам понадобился SVGator.

Как мы пришли к SVGator.com

Digital-рынок сегодня насыщен хорошими решениями, тренды не стоят на месте, одним
из доминантных признаков качества становится анимация интерфейса. В рамках разработки группы продуктов Своё и банковских сервисов Россельхозбанка мы с командой рассматривали
различные решения.

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

Что за зверь и какие задачи решает

SVGator.com это web-платформа для создания svg-анимаций, то есть svg-файлов со встроенными анимациями, которые без каких-либо проблем интегрируются в html. Можно задать последовательную обработку таких анимаций. Возможен экспорт как js, так и чистым CSS. Возможности js немного шире, но разница не существенная.

В рамках продуктов группы Своё мы создавали различные анимации для лоадеров, микроэлементов (таких как стрелка дропдауна), логотипов и элементов оформления. Мы ещё находимся на стадии экспериментов с SVGator, но уже чётко понимаем, в каких моментах он имеет преимущества и что можно создать с его помощью:

Небольшие функциональные элементы интерфейса. Например, интерактивные состояния компонентов и вытекающая микроанимация

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

Элементы дизайна. Например, иллюстрации

Интерфейс и функционал

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

Инструмент включает в себя следующие функции: работа с размером, положением, поворотом, наклоном, цветом, прозрачностью, а также богатый функционал для работы с обводкой. Помимо этого, поддерживается работа с масками и векторами движения. Этого достаточно для работы с классическими решениями анимации. Ещё один важный момент работа с easing, которые также встраиваются в svg-файл. Это упрощает работу на этапе front-end, и дизайнеру не приходится тревожить разработчика скоростью анимации.

Механика работы несколько отличается от привычных решений After Effects, вы выбираете необходимый элемент в меню слева и добавляете на него нужный эффект. После этого слой появляется в области таймлайна и можно менять значения, добиваясь нужной анимации. Сами значения находятся на панели справа. Easing могут быть привязаны как ко всему таймлайну, так и к конкретному отрезку между keyframes.

Чем svg отличается от sequence, gif, video? А также основные конкуренты:
Lottie и Keyshape

Ключевые преимущества svg вес, отсутствие api и возможность давать плавную анимацию. Разберём каждую из альтернатив.

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

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

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

Lottie. Это один из ключевых конкурентов SVGator. Компания раньше вышла на рынок и имеет значительно больше почитателей. Плюс возможности анимации значительно больше, поскольку базовая анимация собирается в Аfter Еffects, а lottie является своего рода оболочкой для такой анимации. Но для работы с данным решением необходимо предустановить api на платформу, что не всегда хорошо для продакшена больших нагруженных систем.

Keyshape. Очень близкая по возможностям платформа, различия лишь в деталях. Текущий функционал Keyshape несколько выше и позволяет делать экспорт чистым svg + css. К недостаткам можно отнести её стационарность и возможность работать исключительно на macOS.

Вот поэтому и стоит обратить внимание на SVGator. Плавные анимации, реализованные кодом, кроссплатформенные, без каких-либо api и с нормальным весом.

SVGator в экосистеме Своё

На наших продуктах Своё Фермерство, Своё Жильё, Своё Родное, Монеты, Подбор персонала, Своё Село и т.д. уже присутствуют наработки в SVGator: лоадер, интерактивные состояния компонентов, логотипы, а также иллюстрации для оформления разделов. Мы планируем увеличивать их долю и продолжать экспериментировать.

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

Перспективы

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

Объёмные решения склонны к излишней нагрузке системы и могут стать камнем преткновения. Поэтому в наших планах использовать этот инструмент поступательно, небольшими шагами, анимируя поначалу небольшие элементы.

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

Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru