Привет

Не так давно в рекламе узнал я о чудо-школе School 21. Первое впечатление от всего прочитанного сложилось замечательное. Никто тебя не трогает, дают задания, ты спокойно всё делаешь. Тут и работа в коллективе, и интересные знакомства, и 2 практики в крупнейших it компаниях страны, да плюсом все бесплатно с проживанием в общежитии (Казань). В общем, это был мой шанс! Сам я уже достаточно долго занимаюсь разработкой, работаю в небольшой it компании, занимаюсь как фронтом, так и бэком, проще говоря, что такое функция я знаю. Но на данным момент чувствуется определенный барьер. Иногда появляется кучу работы, иногда так много всего на изучение, что сложно за что-то взяться. Да и связи полезные завести было бы неплохо. Я твердо решил — нужно поступать.

Прослушав вебинар «How Google Tests Software» я был так вдохновлен, что решил записать некоторые тезисы. Эта статья и есть мой конспект. Прежде всего, я должен внести ясность относительно ее содержания. Это не дословный перевод. Здесь описаны только те вещи, которые показались мне важными. Проще говоря, здесь описано не все, что прозвучало в вебинаре. Так же существует вероятность, что я понял что-то не до конца или даже понял неправильно. Поэтому горячо рекомендую прослушать вебинар самостоятельно.
Его ведет Джэймс Витакер, который в данный момент занимает пост технического директора по тестированию ПО в Google. Джэймс совместно с коллегами готовится выпустить одноименную книгу. В ней можно будет получить исчерпывающую информацию о том, как проводят тестирование GoogleMaps, Google+, ChromeOS, Android и т.д…

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

“Это унылое диалоговое окно действительно нужно?”

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


Когда-то все продукты Google выглядели по-разному плохо. Даже один продукт на разных платформах выглядел неконсистентно.

Все стало меняться в 2011 году, когда в Google начали усиленно работать над унификацией визуальной части экосистемы своих продуктов и назвали все это Project Kennedy.

Axure

• Действительно ли этот продукт не более чем инструмент прототипирования?
• Может ли UI designer полностью перейти на работу в Axure, отказавшись от других инструментов?
• Какие сильные и слабые стороны у этой программы?

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

Автор: Анастасия Режепп, глава дизайн-студии DataArt.

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

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

Что значит “lean”

Слово “lean” переводится на русский как «тощий», «худой», «постный». Если переводить этот термин более специальным образом, то — «бережливый», «экономный», «минималистический». Например, уже есть термин «бережливое производство» — перевод английского “lean production”. Бережливое производство подразумевает постоянное устранение всех видов потерь — это достигается, в том числе, максимальной ориентацией на потребителя. То же самое верно и для подхода бережливого (тощего) UX-дизайна.

Принципы бережливого UX-дизайна

Когда мы следуем методу тощего UX-дизайна, есть несколько моментов, на которые стоит обратить внимание:

• Мы понимаем целевую аудиторию и ее проблемы.
• Мы создаем MVP (Minimum Viable Product — минимально жизнеспособный продукт).
• Мы работаем короткими итерациями.
• Мы постоянно тестируем нововведения на пользователях и, если что-то не так, быстро откатываемся.
• Мы работаем командой: UX-проектировщики, дизайнеры, разработчики и тестировщики работают вместе и постоянно обмениваются мнениями и задачами.

Краткое содержание второй части: редизайн раздела “Сделки” (воронка продаж), подбор цветов для всех стадий, отступы — воздух — свобода… Упс… Клиент, ты серьёзно? Взять и запихать теперь всё в 1370х768?!.. Прощайте “отступы — воздух — свобода”… Пришлось перейти в “сжатый” стиль.

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

В мае на Google I/O мы впервые увидели Material Design 2.0. Команда Google провела крупный рефакторинг и выпустила обновленную библиотеку дизайна. В ней появились новые компоненты и анимации. Мы следим за развитием Material Components с самого начала. Сейчас все находится на стадии RC1, и уже скоро выйдет в релиз. Под катом обзор новых и обновленных UI-компонентов для тех, кто еще не пробовал их в работе, но интересуется.

Когда люди говорят о постановке задач — они очень любят вспоминать про SMART.
Ну, дескать, цель должна быть Specific, Measurable, Attainable, Relevant, Time-bound.
И есть даже удивительные люди, которые пытаются это пихать программистам.

Но есть задачи, а есть задачи. И между ними большая разница!

Иногда я спрашивал себя и Гугл: «Почему мне бывает стыдно быть верстальщиком». Ну, знаете, когда не мог на глазок определить, какой передо мной шрифт: open sans с font-weight: bold, или open sans bold с font-weight: normal — либо случайно узнавал, что «ой, забыли тебе сказать, масштаб был не 1920x1080, а 2560x1440».

Обычно ж как — скидывают .psd и крутись как хочешь.



Весной 2015-го, придя в uKit, я узнал о Sketch — и увидел, как шаблоны стали появляться с красивыми и одинаковыми метками размеров относительно друг друга и очень подробным описанием.

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

«Всем привет, меня зовут Егор Камелев и сегодня я расскажу вам…»
Если вы уже слышали эти слова, то, скорее всего уже встречались с одним или несколькими из моих обучающих видео по работе в Axure. Прошло уже довольно много времени с тех пор, как я добавил первое из них (тогда ещё для Акшуры какой-то древней версии), и я решил сделать некий сводный список того, что уже есть, чтобы вам не пришлось мучиться с поиском на моём канале. Да, конечно, в этом списке только те ролики, которые имеют отношение в Акшуре седьмой версии! Итак, поехали.

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

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

Когда какого-нибудь ленивого журналиста осаждают мрачные предчувствия по поводу Алексы от Amazon или Google Home, он пишет что-то в духе: «Даже Оруэлл не мог предвидеть, что мы сами пригласим Большого Брата к себе домой». При этом он упускает один важный момент: виртуальные ассистенты — это не первый случай, когда мы оказались готовы променять приватность на удобство. Началось все еще в начале 2000-х, когда люди в обмен на доступ к продуктам Google и более таргетированную рекламу выложили компании всю информацию о себе.



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

На текущий момент каждую секунду в Google поступает 40 000 поисковых запросов, то есть 3.5 миллиарда в день и 1.2 триллиона в год. Когда вы вбиваете что-то в Google, ваш запрос отправляется в центр данных, где тысяча компьютеров производят отбор результатов и отсылают вам обратно итоговую выдачу. Вся процедура обычно занимает меньше чем пятую долю секунды. Но вот о чем не подозревает большинство людей: параллельно с этим «за кулисами» происходит другой, еще более молниеносный и загадочный процесс — там разворачивается аукцион.

^{Одно из изданий этой механики}

Есть колода из 100 карт с натуральными числами от 1 до 100, каждого по одному. Вы и второй игрок берёте по 3 карты из этой колоды. Задача — одну за одной выложить их на стол в порядке возрастания. Но нельзя меняться информацией между собой и показывать карту до момента, пока она не будет положена на стол. То есть нельзя говорить, стучать по столу, подмигивать и так далее — ничего нельзя.

Если в конце игры 6 карт выложены правильно, оба игрока выигрывают. В момент, когда первая же карта ложится неправильно — оба игрока проигрывают.

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

Не спешите под кат, сначала подумайте чуть-чуть, пожалуйста.

Известный специалист по безопасности Трой Хант уже несколько лет поддерживает сайт Have I Been Pwned (HIBP) с миллионами записей об украденных аккаунтов. Каждый может проверить там свой email на предмет утечки. Трой Хант следит за хакерскими форумами, покупает базы данных, которые выставляют на продажу, иногда эти базы присылают ему бесплатно. Но он никогда не видел, чтобы на продажу выставляли такую огромную базу, как нынешняя Коллекция № 1 (Collection #1).

Гигантский архив содержит 2 692 818 238 записей с адресами электронной почты и паролями.

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

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

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

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

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

Введение

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

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

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

Итак — эти 7 правил:

1. Скука убивает
2. Прежде чем начать, выясните точно для себя, какие действия вы ожидаете от читателя, осилившего ваш труд
3. Пишите в соответствии с правильно сформированной структурой
4. Избегайте неоднозначных местоимений
5. Ясность = иллюстрации + слова
6. Когда имеете дело с понятиями, концепциями и т.п., используйте логическую иллюстрацию и пример
7. Не опасайтесь переделок