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

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

Какие здесь могут возникнуть трудности?

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

Что делать?

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

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

К моему удивлению оказалось, что на вроде бы актуальный вопрос: «Как построить хорошую/красивую архитектуру ПО?» — не так легко найти ответ. Не смотря на то, что есть много книг и статей, посвященных и шаблонам проектирования и принципам проектирования, например, принципам SOLID (кратко описаны тут, подробно и с примерами можно посмотреть тут, тут и тут) и тому, как правильно оформлять код, все равно оставалось чувство, что чего-то важного не хватает. Это было похоже на то, как если бы вам дали множество замечательных и полезных инструментов, но забыли главное — объяснить, а как же «проектировать табуретку».

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

Данная статья является попыткой ответить на эти вопросы хотя бы в первом приближении.

Думаете над развитием новой идеи? Сначала ознакомьтесь с этим подробным руководством.



«У меня есть идея Х, что мне делать дальше?»

Первым шагом в запуске успешного стартапа является создание минимально жизнеспособного продукта (Minimum Viable Product, MVP). По сути, это означает подтверждение того факта, что существует рынок, который ваша компания сможет назвать «домашним» (основным) и найти на нем платежеспособных клиентов. То есть первым делом вам нужно найти первых покупателей и понять, за что они готовы платить.

Привет, Хабр! Время от времени для дизайнеров, исследователей и аналитиков (и граждан, им сочувствующих) мы проводим митапы под кодовым названием “QIWI Кухня”.



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

Темы докладов (как и презентации спикеров) — под катом. Там же и полные видео выступлений.

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

Это первая часть статьи, в которой будет много скучной, но конкретной практической информации по созданию компонентов в Figma, а также нюансы, подводные камни и реалии создания проектов с ограниченным бюджетом в провинциальной среде =)

Я — UX-дизайнер, и всегда работала одна. Но в прошлом году всё изменилось: в свой день рождения я прошла собеседование в ISPsystem и попала в продуктовую команду. Пришлось вникать в новое, учиться жить по скраму и спорить с суровыми программистами (конструктивно!). Теперь дизайн-процессы устаканились, я сама прошу ребят о честной критике, а разработчики используют мои прототипы как ТЗ. Подробнее об этом — под катом.

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

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



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

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

Вероятно, вы уже знакомы с блоковой моделью CSS для обычных элементов. Давайте начнем с аналогичного «общего обзора» для CSS Grid:


В основе структуры CSS Grid находится основной контейнер, представляющий собой обычный div, имеющий margin, border и padding. Для создания CSS grid контейнера добавим свойство display: grid. Элементы сетки — это потомки, размещенные внутри родительского контейнера. Они обычно определяются как список, описывающий header, sidebar, footer или другие аналогичные элементы макета сайта, зависящие от его дизайна.

Приветствую вас коллеги! Меня зовут Дмитрий Волков и я работаю в профессии больше десяти лет. Решил написать статью для тех, кто создает web и mobile дизайн в современных программах.

История об одном редизайне, который изменил подход к разработке в ISPsystem.



Я пришёл в ISPsystem в апреле 2016 г. На тот момент ситуация с продуктовым дизайном была следующая: решения по продуктам принимались руководством и программистами, никаких дизайнеров или проектировщиков не было. Ситуация на рынке требовала продуктов с «другими интерфейсами», поэтому руководство решило перепроектировать клиентскую часть BILLmanager. Это должно было стать пробным шаром, первой попыткой сделать что-то с новым дизайном.

На сайте Smashing Magazine выложены два новых полезных инструмента для мобильных разработчиков. Это набор заготовок для рисования набросков интерфейсов распространённых типов мобильных утсройств Outline и шаблоны для подбора размеров элементов тач-интерфейса с учётом разрешения и физического размера реальных устройств Tapsize. Оба набора предназначены для распечатки на бумаге.

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

Если в целом, ерундовая задача, правда? Но как сделать все идеально? Так, чтобы без простоев, чтобы не было расхождений в БД, чтобы не потерялись какие-нибудь файлики-аватарки-картинки, когда обновляется DNS запись IN A и у половины пользователей старый сайт, а у половины новый. А если это highload? Или сайт делало несколько поколений «лучших» программистов, считающих своим долгом создать новое подключение к БД в своем «модуле» для сайта. Наконец, если таких сайтов >10?

• Скопировать файлы
• Сделать дамб баз данных
• Развернуть на новом сервере
• На старом сервере заменить все коннекты к бд к новому
• Настроить DNS
• ...

Сколько это займет времени? Сколько драгоценных минут сайт не будет работать\не будет работать правильно?

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

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

Иногда заказчики писали свои цели в официальных документах к проекту. Иногда мне казалось, что я и так понимаю цели заказчика — они абсолютно очевидны. К чему уточнять очевидное? Разницу я почувствовал, когда начал применять Impact Mapping в работе.

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



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

Здравствуй, Хабр! Меня зовут Саша Отважный, я работаю команде Digital Business Platform Сбербанка и Сбертеха, и занимаюсь дизайном мобильных приложений и веб-проектов. Большая часть моей работы состоит из сборки прототипов разной степени детализации для разных целей. Новые инструменты и сервисы для дизайна и прототипирования выходят и обновляются каждый день. Я провёл полное и глубокое исследование инструментов, представленных сегодня на рынке, и помогу в них разобраться.

Я разбил список на три большие группы по функциональности и разберу каждую по отдельности:

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

Воксельная разработка

Бранислав: в 2000-2002 годах я участвовал в соревнованиях европейской демосцены. Я написал несколько 256-байтных демо (также называемых intro) под ником Silique/Bizzare Devs (см. «Njufnjuf», «Oxlpka», «I like ya, Tweety» и «Comatose»). Каждое из интро генерировало в реальном времени воксели или графику из облака точек. И воксели, и облака точек являются примерами сэмплированной геометрии.

Интро выполняли свою задачу всего в 100 инструкциях процессора, таких как ADD, MUL, STOSB, PUSH и им подобных. Однако из-за самой природы такого типа программ на самом деле десятки инструкций использовались просто для правильной настройки, а не для генерации самой графики. Тем не менее этих 50 с лишним инструкций, которые по сути являлись элементарными математическими операциями или операциями с памятью, оказалось достаточно для генерации довольно красивой подвижной 3D-графики в реальном времени. Все эти 256-байтные интро выигрывали с первого по третье места. Это заставило меня осознать, что если такую 3D-графику возможно создавать без полигонов, то в играх и других приложениях можно достичь гораздо большего с помощью того же принципа: использования сэмплированной геометрии вместо полигональных мешей. Решение заключается в простоте. Я понял, что доминировавшая тогда парадигма, основанная на сложных и фундаментально ограниченном (необъёмном) представлении данных, уже готова была упереться в потолок возможностей. То есть настало подходящее время испробовать эту «новую», более простую парадигму: объёмную сэмплируемую геометрию.

На конференции Monitorama Пит Чеслок из Threat Stack провел параллель между историей строительства шведского корабля «Васа» и провальными проектами по разработке. Делимся с вами отрывком его выступления.



Корабль «Васа» должен был стать главным боевым кораблем шведского флота, но затонул с порывом ветра при первом же выходе из гавани в 1628 году, 53 члена экипажа погибли. Выживший капитан был немедленно отправлен в тюрьму: на допросе он клялся, что пушки были надежно закреплены, и экипаж был трезв. После расследования никто не был наказан или признан виновным, и инцидент был классифицирован как «Воля Божья». Почему затонул корабль и причем тут управление проектами?

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

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