Предлагаю вашему вниманию перевод очень крутой статьи по анимации интерфейса.
The ultimate guide to proper use of animation in UX автора Taras Skytskyi.



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

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

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

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


В основе статьи доклад Антонины Хисаметдиновой с Heisenbug 2017 Moscow, которая занимается проектировкой пользовательских интерфейсов в компании Собака Павлова.

Кроме того, на Медиуме есть цикл статей «Руководство по проектированию ошибок». Цикл еще не дописан до конца, но дает более полную и цельную картину по теме статьи.

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

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

Бродя по просторам PHP документации случайно наткнулся на две функции: imagegrabwindow и imagegrabscreen. Они умеют делать скриншоты в Microsoft Windows.
Заинтересовало. Кончилось дело тем, что был написан скриптик генерирующий полный скриншот любого сайта.
Итак нам необходимы:

• Internet Explorer ActiveX component и документация к нему.
• PHP 5.2.2+

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

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

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

---

Шутка, написанная гарнитурой Times, на 10 % смешнее той, что написана гарнитурой Arial. Почему? Чёрт знает. Лучшее объяснение, которое я видел: юмор ассоциируется с агрессией, с остротой, с остроумием — а Times выглядит более острым, чем Arial.

Ещё один любопытный эксперимент, в котором участвовало 45 тыс. человек. Заходишь на сайт, тебе показывают статью Дэвида Дойча, британского физика. В статье автор пишет, что сегодня очень трудно внезапно умереть. Например, от инфекционного заболевания или в уличной драке. Лет сто назад это случалось намного чаще. Главный вывод статьи — сейчас мир безопасен как никогда. В среднем, конечно, ведь где-то постоянно идут локальные военные конфликты.

В мире современных веб-технологий все стремительно развивается и меняется. Пару лет назад совершенно нормальным было по запросу клиента рендерить DOM структуру на сервере (например, при помощи PHP) и отдавать уже полностью сформированную страницу. Сейчас все чаще появляются сайты c полным отделением фронтенда (Angular, React, Vue.js...) от бэкенда (некие API эндпоинты), где на фронтенде почти весь контент формируется посредством скриптов, а сервер отдает только данные по запросу. Тут можно было бы упомянуть SSR (Server Side Rendering), но не об этом данное произведение.

В любые времена перед разработчиками и владельцами сайтов стояла непростая задача: доставить контент как можно быстрее, как можно большему количеству клиентов. Одно из самых правильных решений — использовать CDN (Content Delivery Network) для раздачи статичных файлов. В случае с динамическим рендером страниц на сервере мы должны были ограничиваться небольшим списком объектов, которые можно было разместить в CDN: таблицы стилей, файлы скриптов, изображения. Однако, фронтенд, написанный на Angular (React, Vue.js...), статичен целиком, включая индексную страницу. Вот тут и возникает мысль: а почему бы не организовать раздачу через CDN всего фронтенда?

В данной статье пойдет речь о настройке комплексного решения для разработки, контроля версий, автоматической сборки и доставки статического сайта с использованием Gitlab CI, Amazon S3 и Amazon CloudFront. Также речь пойдет о настройке сопутствующих вещей: git, безопасное соединение по протоколу HTTPS, доменная почта, DNS хостинг, бэкенд сервер…

Если вас заинтересовала эта тема, добро пожаловать под кат. Осторожно! Много скриншотов.

Если вы не изучали JavaScript с самого начала, то осваивать его современную версию сложно. Экосистема быстро растёт и меняется, так что трудно разобраться с проблемами, для решения которых придуманы разные инструменты. Я начал программировать в 1998-м, но начал понимать JavaScript только в 2014-м. Помню, как просматривал Browserify и смотрел на его слоган:

Browserify позволяет делать require («модули») в браузере, объединяя все ваши зависимости

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

Цель статьи — рассказать о контексте, в котором инструменты в JavaScript развивались вплоть до 2017-го. Начнём с самого начала и будем делать сайт, как это делали бы динозавры — безо всяких инструментов, на чистом HTML и JavaScript. Постепенно станем вводить разные инструменты, поочерёдно рассматривая решаемые ими проблемы. Благодаря историческому контексту вы сможете адаптироваться к постоянно меняющемуся ландшафту JavaScript и понять его.

Перед вами — первый материал из серии, посвящённой разработке полноценного веб-приложения, которое называется Budget Manager. Основные программные средства, которые будут использованы в ходе работы над ним — это Node.js для сервера, Vue.js для фронтенда, и MongoDB в роли базы данных.



Эти материалы рассчитаны на читателей, которые знакомы с JavaScript, имеют общее представление о Node.js, npm и MongoDB, и хотят изучить связку Node-Vue-MongoDB и сопутствующие технологии. Приложение будем писать с нуля, поэтому запаситесь любимым редактором кода. Для того, чтобы не усложнять проект, мы не будем пользоваться Vuex и постараемся сосредоточиться на самом главном, не отвлекаясь на второстепенные вещи.

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

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

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

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

Так как у нас много продуктов и сервисов, а дизайн в этих продуктах и сервисах сильно отличается, мы решили его унифицировать и привести к единому UI. Зачем? Все просто: такой подход дает возможность оптимизировать работу отдела, сосредоточить дизайнеров на UX, ускорить процесс разработки и запуск новых продуктов, снизить нагрузку на отделы тестирования и значительно сократить количество багов на стороне front-end. В этой статье я расскажу о нашем опыте, остановлюсь на инструментах и покажу, как устроена библиотека изнутри.

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

Разрабатывать веб-фронтенд, придерживаясь JavaScript-экосистемы, всех этих новомодных штучек и пафосных фреймворков, может быть пугающим занятием, если не сказать больше. Я давно уже хотел окунуться в это, и наконец собрался с духом. К концу этой статьи, надеюсь, вы узнаете что-нибудь новое, или хотя бы чуть больше отточите свои навыки веб-разработки. Какая ирония, что длина статьи и обширное количество информации тоже могут отпугивать. Но я очень надеюсь, что вы найдёте время осилить хотя бы интересующие вас главы. В конце каждого раздела есть абзац TL;DR, так что вы можете быстро ориентироваться в содержании.

Авторы статьи: Юрий Ветров, Артём Гладков, Евгений Долгов и Андрей Сундиев

Несколько лет портальная дизайн-команда Mail.Ru Group занимается обновлением и унификацией продуктов. У нас сформировалась дизайн-система, на которой работают медиа-проекты, мобильный веб и частично productivity-сервисы (постепенно подключаются и другие продукты), сформировался стиль пиктограмм и иллюстраций, стандартизируются промо-письма и промо-сайты. Конечно, ещё не во всех сервисах всё хорошо, а где-то первый редизайн не решил всех проблем, но огромный рывок за прошедшие годы трудно не заметить. Чтобы ускорить процесс обновления и сделать нашу работу публичной, мы открываем наружу часть нашей дизайн-системы Paradigm.

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

Светлана Шаповалова, редактор «Нетологии» адаптировала заметку Quincy Larson, в которой он представил три возможных пути становления веб-разработчика: для фронтенда, бекэнда и DevOps.

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

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

Введение.

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

1. Введение, знакомство с tensorflow и базовыми алгоритмами (эта статья)
2. Первые нейронные сети
3. Свёрточные нейронные сети
4. Рекуррентные нейронные сети

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