Редизайн Хрому на десктопі



На початку вересня цього в Windows, як частина 53-го оновлення, з'явився новий модифікований дизайн основного інтерфейсу Chrome, т. зв. «Chrome MD» (Material design). Він став останньою сходинкою трьохступеневої введення в дію нового дизайну, який був початий в релізі 51 з Chrome OS і Linux і був продовжений в релізі 52 з macOS. Windows стала вищою точкою цього процесу, і, оскільки Chrome не закінчиться ніколи, то мені здається, що зараз саме час озирнутися й поміркувати над цим процесом, який зайняв майже 2 роки і який дав деякі знання і досвід, корисні, можливо, і для вас.

Якщо ви читали мою попередню статтю про редизайн Chrome для Android, то побачите, що цей пост схожий на неї, хоча я спробував (може бути, не зовсім успішно) використовувати менше технічних подробиць. Крім того, зараз все помістилося в одну частину. Якщо ви не читали названу статтю, то я порекомендував би зробити це, оскільки вона є невід'ємною частиною роздумів про настільному комп'ютері (десктопі) і Chrome, тобто хронологічним попередником цієї статті.


Трохи про загальну
Я працював над браузером і операційною системою Chrome майже 5 років як візуальний конструктор-дизайнер. Доводилося ділити час між браузером і операційною системою, але поступово, в останній рік, я став займатися тільки ОС.

Ще в 2012 році один з моїх перших великих проектів в якості нового члена команди Chrome полягав у тому, щоб зробити тільки що перероблений основний користувальницький інтерфейс Chrome сумісним з дисплеями високого дозволу, такими як перший Macbook Pro Retina і перший Chromebook Pixel, який був полегшеної Гугл-версією сітчастого дисплея. Випуск Chromebook Pixel було розпочато у лютому 2013 року — трохи пізніше, ніж випуск Macbook Pro.

Я був новачком в Гугл, і цей досвід познайомив мене зі складністю і заплутаністю проектування браузера Chrome. Він також дозволив мені швидко ознайомитися з усіма проектними рішеннями, які були зроблені до цього.

Нашою метою в той час було не тільки принести новий дизайн входять в життя дисплеї з новим дозволом і коефіцієнтом щільності (1х і 2х), але й переосмислити і полегшити шлях співпраці з розробниками, організовуючи наш робочий процес і репозитарії цифрових об'єктів.

Ця потреба виникла через зростаючу необхідність зробити процес проектування Chrome більш відповідним вимогам завтрашнього дня. Швидкість, з якою Chrome зростав після своєї появи, не давала часу на доопрацювання різних аспектів на цьому шляху. Чим більше ми просувалися вперед, тим важче ставало вписуватися в нашу попередню роботу, що створювало затримки і т. н. борг проектування.

Через кілька місяців праць і зусиль після появи нового дизайну для екранів з звичайним дозволом чудове нове високе дозвіл, нарешті, пішла. Це виглядало так:



Я скористався можливістю провести інвентаризацію всього нашого репозитарію цифрових об'єктів (прим. 1 200 растрових зображень для десктопа) і організував його так, щоб мати можливість рухатися швидше в майбутньому. Думаю, це стане в нагоді в майбутніх розробках.

Цей дизайн залишався приблизно в незмінному стані 4 роки — до квітня 2016 року, коли вийшов Chrome MD для Chrome OS.

Синхронізація і планування
Тепер, коли Chrome підтримував дисплеї з високою роздільною здатністю, а наш процес був відпрацьований і діяв досить ефективно, прийшов час переключити нашу увагу на мобільні пристрої.

У той час (початок 2013 року) Chrome став за замовчуванням браузер на Android, версія планшетника була відсутня, і тільки що відбувся випуск на iOS.

Мобільні пристрої були в центрі моєї уваги з початку 2013 року і до оновлення Chrome Android на основі Material design (MD) у 2015 році. Однак це не означає, що нічого не робилося для настільного комп'ютера.

Складалося щось вельми цікаве: ми почали розглядати перехід настільних комп'ютерів і ноутбуків в стан, коли сенсорний екран більше не був винятковим атрибутом мобільного пристрою, а ставав частиною однієї з більш продуктивних платформ, таких як ноутбуки. Хоча були зроблені деякі спроби в попередні роки, це було перший раз, коли можливість мати сенсорний екран на ноутбуці представлялася реальністю, а не якоюсь дивиною або експериментом.

У мене був свій досвід в цій галузі, набутий на першій моделі Chromebook pixel, а іншими моментами, які викликали мій великий інтерес в той час, Windows 8 і виключно сильна рішучість компанії Майкрософт поставити вельми своєрідний користувальницький інтерфейс на новий гібридний типорозмір з моделлю Surface в якості основного пристрою.

Перша модель Chromebook Pixel (2013) з сенсорним дисплеєм високого дозволу


Перша модель Microsoft Surface і Windows 8 Metro mode»

Подвійність ОС, а також можливість вибрати користувальницький інтерфейс з великими сенсорними функціями як для сенсорних, так і для несенсорных пристроїв змусили мене задуматися про місце користувальницького інтерфейсу Chrome і про направлення його розвитку в цьому типі навколишнього середовища.

Нам вже довелося зіткнутися з такого роду питаннями на першому Chromebook Pixel і його сенсорному дисплеї, і вибір був зроблений покладатися на сенсорний дисплей тільки для прокрутки вмісту і для вторинних взаємодій, а не як основний метод введення. Позиціонування Pixel як, в основному, експериментального пристрою «для ентузіастів» дозволило нам не поспішаючи подумати, що, як і чому повинно впливати на наш користувацький інтерфейс.

Через деякий час ми вирішили створити те, що стало попередником сьогоднішнього «гібридного виду»: сенсорний вигляд.


Сенсорний вигляд став модифікацією звичайного основного інтерфейсу Chrome, що дозволяє ключовим елементам мати збільшені розміри і бути більш рознесеними, що зменшує ймовірність користувальницьких помилок при торканні.

Такий вид був застосований на деяких Chromebooks і в Windows 8.

Це був цікавий експеримент, і, оскільки він був недовгим, а сенсорний вид вікон був швидко скасовано і сама Windows 8 був переосмислений те, що збирався стати Windows 10, то було досить короткого ознайомлення з тим, що з'явилося на горизонті: демократизація «гібридних» або «перебудовуються» пристроїв і повільне, але неухильне розмивання межі між планшетниками і ноутбуками.

Адаптація до розвивається і росте категорії пристроїв: гібриди
Перемістимося швидко вперед до кінця 2014 року. Багато сталося в області проектування систем: Apple анонсував вихід операційної системи Yosemite (Йосеміті) з її стилем користувальницького інтерфейсу, преодолевающим розрив між macOS і iOS7, Google підготував випуск операційної системи Android Lollipop, що використовує нову мову візуального проектування: Material design.



Область проектування розвивалася, і, хоча компанії йшли своїм власним правилам і приписам, з'явилася загальна тема: ера скевоморфизма закінчувалася, витісняється «легшим» користувальницьким інтерфейсом, таким, що характеризується збільшенням кількості білого простору, зменшенням використання сильної тіні і тим, що багато хто з нас жартома охрестили як прекрасна (або, навпаки, ганебна) «ера плоского дизайну».

Windows придбала свій «сучасний користувальницький інтерфейс, Apple — свій «iOS UI», а Google — свій «Material Design». Як частина цього великого циклу оновлення, Chrome модернізував те, що пов'язано з мобільними пристроями, — iOS і Чоловічий.

Ми попрощалися з нашими сильними тінями, виділеннями і шумовими відеоефектами поверх наших градієнтів. Ми зробили більш різкими наші вкладки і вибрали набір піктограм у відповідності з керівними принципами проектування, діючими в Google. Новий Chrome був тут… однак, поки що не на десктопі.


Новий Chrome MD на планшетника

Майбутнє для користувача інтерфейсу настільного комп'ютера повільно знаходило форму і з'являлося більш ясне уявлення з цього питання. Windows і Google, з одного боку, намагалися розібратися з дизайнерської системою, яка здатна працювати з дисплеями всіх розмірів і форматів одночасно; Apple, з іншого боку, зі своїми своєрідними напрямками компонування працювала на базі вписування під кожну платформу та під кожен формат.

Саме в той час — майже два роки тому — був запущений процес редизайну Chrome для десктопа.

Гібридний тип компонування
Постійне нетривіальна справа, яким мені доводилося займатися всі роки роботи з Chrome і з яким має справу більшість проектувальників, — це управління цифровими об'єктами. Саме це послужило причиною впорядкування цифрових об'єктів, згаданого вище, що представляють собою прим. 1 200 растрових зображень для десктопа. Крім того, що цей процес був неймовірно захоплюючим, він просто необхідний, щоб працювати на різних платформах.

Chrome перспективи розробки інтерфейсної частини поширюється через 4 фреймворку / кодові бази: Views, спільно з Windows, Chrome OS і Linux (наш фреймворк для побудови користувацького інтерфейсу), Cocoa на macOS, Java для Android і Obj-C/Swift для iOS.

Щоб забезпечити працездатність і поліпшити довгострокове управління цифровими об'єктами, ми прагнемо зробити спільними для платформ якомога більше ресурсів проектування.

Наприклад, Windows, Chrome OS і Mac мають безліч загальних графічних об'єктів. Використання їх може бути різним, але растрові зображення є однаковими.

На мобільних пристроях ми також прагнемо проектувати і закладати цифрові об'єкти так, щоб забезпечити кросплатформенність та хоча Chrome для Android і iOS в чому різняться. Chrome для планшетников є гарним прикладом такого підходу. Запускається на iPad або на планшетника Android він виглядає дуже схоже.


Chrome для Android Chrome для iOS 9 (MD)


Chrome для планшетника Android (MD)


Chrome для iPad (MD)

Звичайно, є чимало ресурсів, специфічних для тієї чи іншої платформи, але ця фіксована система загальних елементів досягає своєї межі, і, коли доводиться мати справу з мультиплікаторами і типорозмірами (чи типами компонування), ситуація стає складнішою.

Ще до розгляду гібрида вона виглядає так:

Як видно, є комплект 2 типів компонування: сенсорна і несенсорная. Серед цих двох типів компонування є 2 основних мультиплікатора (1x і 2x) при розширеному повному числі 5-6 мультиплікаторів для кожної платформи:

— 100, 150, 200, 300, 400 для мобільного
— 100, 125, 150, 180, 200, 225 для настільного комп'ютера (десктопа) (в крайніх випадках на Windows)

Це вимагає створення такої кількості мультиплікаторів і цифрових об'єктів, що ми перестали розраховувати на масштабування для непарних мультиплікаторів, створюючи щось, що уступає ідеальної візуалізації.

У цьому контексті та у зв'язку із зростаючим попитом на сенсорні і перебудовувані пристрою ми, натхненні сенсорним виглядом, виявилися перед необхідністю знайти рішення для перебудовуються пристроїв, яке збиралися назвати «Гібрид», вводячи додаткову складність в нашу існуючу структуру:

Однак такий підхід мав потенціал створення нового набору цифрових об'єктів для експорту і управління, просуваючи наш поточний процес, який базується на растрових зображеннях, далеко за його межі.

І тоді прийшла програмна візуалізація.

Новий тип компонування, новий процес
«Гібридний вид» Chrome був початково розроблений для Chromebooks під впливом нашого попереднього продукту «сенсорний вид». Цього разу від нас вимагалося створити «гібрид» як частина редизайну, а не як якийсь додаток до вже існуючого інтерфейсу.

Для цього нам потрібні були дві речі:

  • Досить універсальний дизайн, здатний працювати як зі звичайним видом, так і з гібридним. Звичайний вигляд спочатку повинен був бути розгорнутий у основній частині наших користувачів.
  • Спосіб створення, експорту і введення наших цифрових об'єктів, який повинен був би елегантно вписатися в широкий тип компонування і область щільності пікселів настільного комп'ютера.
Нашу другу проблему вирішили Петер Кастинг, Еван Стейд і Террі Андерсон (технічний керівник проекту).

Я спочатку не був упевнений, що візуалізація форм (особливо вкладок Chrome) і піктограм може повністю програмно дати той рівень деталізації, який ми могли б забезпечити за допомогою .pngs. Я помилявся.

Chrome використовує графічну бібліотеку Skia. Після декількох спроб Петер знайшов спосіб прекрасно візуалізувати ключові елементи Chrome, такі як вкладки і запиту, без використання будь-якого типу растрового зображення. У свою чергу, Еван зробив перетворювач, здатний транслювати код .svg код Skia. .svg, по суті, повинен працювати як план, деякий набір інструкцій для програмної візуалізації.

Процес переходу від проектування до розробки був визначений наступним чином:

Проектувальники, дизайнери створюють .svg будь-якого розміру, необхідний як шаблон для візуалізації коду Skia. Це стосується як до форм, так і до піктограм. Такий шаблон при розробці повинен бути узятий і поміщений в Chrome, використовуючи Skia.

Тут наведена схема вкладок:


Вкладки зроблені з одного .svg для заповнення та іншого для обведення (лінії). Розробник потім бере .svg-код і змінює шляху до коду SKIA, додаючи належні колір і прозорість.

Нижче показаний код з прикладом піктограми, використовує інструмент автоматичного перетворення, сформований Еваном.



Цей метод привів до гігантського зниження використання растрових зображень в Chrome приблизно з 1 200 до 0!

Слід мати на увазі, що кожен варіант кнопок тепер обробляється через код, що ефективно усуває будь дублікати для виступаючого/нажатого стану, а також будь-яку необхідність застосовувати колір безпосередньо на об'єкті. Все це тепер обробляється в коді.

Додатковим і величезною перевагою прямого використання .svg є те, що ми опиняємося в стані керувати візуалізацією кожного елемента на базі кожного кількості точок на дюйм (PPI). Це означає, що при необхідності можна створювати піктограму, злегка відрізняється від 1x і 2x. Це — велика справа, оскільки десктоп має, в основному, 1x. Додатково ми можемо керувати візуалізацією для дробових мультиплікаторів, таких як 1,5, 1,25 і т. д., роблячи вигляд Chrome майже таким же, який можна отримати у всіх конфігураціях з непарним PPI.

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

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

Питання, який, як я вважаю, був у всіх візуальних проектувальників Chrome в той момент, полягав у наступному: «Що саме є особливостями Chrome?».

Є багато такого, що робить Chrome тим, що він є, але в той же час наша роль полягає в тому, щоб бути непомітними на тлі контенту або, іншими словами, щоб бути присутнім, але не стояти на шляху.
Ключовими елементами в нашому основному інтерфейсі є вкладки і піктограми. Chrome на мобільних пристроях вже використовував нові різкі краю вкладок на планшетниках, а також нову систему піктограм з керівництв по Material design (MD). У цьому контексті наша мета була:

  • Ввести нові форми вкладок на десктоп.
  • Ввести новий набір піктограм з MD, використовуючи розміри десктопа.
  • Узгодити і спростити нашу колірну палету і нашу систему темізаціі. Додатково: ввести в десктоп нову тему «dark» («темна») в режимі «інкогніто».
  • Запустити модернізацію елементів вторинного користувальницького інтерфейсу, таких як кнопки, панелі інструментів, що випадають таблички і т. п.
  • Створити більш сенсорну версію Chrome для перебудовуються пристроїв.
  • Створити набір правил для забезпечення узгодженості зі сторонньою ОС.
  • Ввести MD-анімацію, коли це можливо.
Загальна компоновка та розмір користувальницького інтерфейсу
При розробці основної компонування Chrome необхідно пам'ятати про один ключовий аспект: розмір користувальницького інтерфейсу. Він являє собою кількість пікселів, що використовуються для відображення нашого користувальницького інтерфейсу або, іншими словами, отнимаемых у контенту.

Висота pre-MD-конструкції без показу панелі закладок була 73 пікселя в ос chrome і macOS (включаючи кадр вікна) і 78 пікселів у Windows (включаючи також фрейм).

Вихідний кадр у Windows вище, ніж кадр у ос chrome і macOS. Більший розмір полегшує клацання по кадру і захоплення. См. порівняння macOS з Windows нижче, pre-MD:

Ця попередня версія компонування панелі інструментів Chrome була створена, коли дисплеї з високою щільністю пікселів ще не існували, тому вона була оптимізована для візуалізації на масштабі 100% з використанням непарних кількостей, завдяки чому можна було центрувати елемент на повний піксель.

Перше, що потрібно зробити, було використання парної сітки, полегшує перенесення компонування через різні мультиплікатори. У цьому випадку піктограми могли б розташовуватися на піксельною сіткою частіше, ніж на сітці проектування, заснованої на непарному числі.

Material design (MD) використовує квадрат з 8 точок у своїй сітки базових ліній. Ми використовуємо квадрат наполовину менше: 4 точки.

Завдання сітки і позиціонують елементів з кроком 4 точки надзвичайно допомогли отримати хороший баланс і витримати узгодженість компонування, типографіки і всього пов'язаного з піктограмами. Для балансу ми розділили користувальницький інтерфейс навпіл: вкладки + кадр вікна / панель інструментів.

Ось як це виглядає для звичайного інтерфейсу:

Як можна бачити на цій картинці 200% (або 2x) Chrome MD в ОС Chrome, панель розділена на дві частини по 36 точок кожна. Кожен ключовий елемент спирається на сітку з квадратом 4 точки.

Вкладки мають висоту 28 точок, так само як запиту. Ми залишили верхнє заповнення в 8 точок між вкладками і верхи кадру.

Якщо придивитися уважніше, то можна помітити, що лінії універсального вікна пошуку не вирівняні по сітці на цій картинці. Причина в тому, що ми використовуємо 1 піксель на товщину лінії незалежно від PPI, що дає більш світлий інтерфейс з витонченими лініями.

Недоліком цього методу є необхідність завжди пам'ятати, що простір, яке передбачалося заповнити більш товстою лінією (2 пікселя), тепер порожнє.

Можна також бачити, що ми пропонуємо лінію, додаючи 1 точку в нижній частині панелі інструментів, а не впечатывая її з міркувань балансу, фактично додаючи 1 точку до повної висоті 36+36 точок.

Нижче показаний наш гібридний користувальницький інтерфейс.


В гібриді ми зберегли рамкову заповнення (8 точок), збільшивши розмір вкладки та панелі інструментів на 4 точки. Результатом стала більш простора компонування 40+40.

Тут може здатися дивним, чому ми просто не використовуємо рекомендації з сенсорним майданчиків для Android або iOS (48 44, відповідно), щоб зробити елементи більш зручними для торкання пальцем. Насправді ми спробували це, але таке пряме використання йде врозріз з тим, чого гібрид намагається досягти.

Ми прагнемо до деякого виваженого компромісу між повністю сенсорних і несенсорним інтерфейсами, вишукуючи баланс між мінімізацією кількості користувальницьких помилок торкання і збереженням аспектів, пов'язаних з продуктивністю, очікуваної від компонування ноутбука.
На десктопі кожен піксель на рахунку, тому установка планшетного інтерфейсу на ноутбуці не розглядалася.

Нижче показані різні компонування — Chrome pre-MD, Chrome MD звичайна, гібридна і, нарешті, для планшетника; всі візуалізовані при 200% (xhdpi для Android).



Фактично розмір звичайної компонування MD (включаючи кадр вікна) на 2 пікселя менше розміру pre-MD ос chrome/macOS (71 проти 73). Однак, оскільки ми змістили користувальницький інтерфейс вгору на 3 пікселя у фреймі вікна, новий інтерфейс без урахування кадру вікна ми отримали фактично на 5 пікселів більше (60 проти 65).

Кожен піксель має виняткову цінність в Chrome, і кожен піксель на обліку. В ході редизайну кожне рішення за розміром приймалося з розглядом наступних факторів: діючий користувальницький інтерфейс, прийняття нової сітки і загальний баланс інтерфейсу.
Ця ж логіка застосовувалася до піктограм…

Аспекти, пов'язані з піктограмами
Вибір набору піктограм для використання був зроблений швидко.

Нам потрібно оновити численні ключові піктограми інтерфейсу, а також всі піктограми характеристик і властивостей по всьому продукту, і репозитарій піктограм від Material design пропонує саме їх. Таким чином, вони будуть повністю співпадати з піктограмами на наших мобільних продуктах — як iOS, так і Android.

Проте була одна проблема: розмір сітки. Сітка з квадратом 24х24 точки не відповідала досить щільному інтерфейсу, який ми мали намір створити (навіть враховуючи гібрид). Зрештою, вони були запропоновані для мобільних пристроїв.

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

Щоб забезпечити це і вписатися одночасно в сітку з квадратом 4 точки, ми використовували піктограми на базі 16х16 точок, як показано нижче:



Ми зменшили контейнер з 24 точок до 16 і додали деяку гнучкість відносно вихідного внутрішнього заповнення: заміна 2 точок 1-2 точки в залежності від піктограми для сітки піктограм Chrome. Причина цього гнучкого заповнення полягає в тому, що, беручи до уваги велику різноманітність піктограм, які ми збиралися використовувати, деяким з них може знадобитися додатковий простір для забезпечення візуальної роботи їх контурів при невеликих розмірах.

Перевагою такого зменшення розміру на цілих 33% було те, що ми отримали можливість використовувати масштабування прямо з піктограм Material. Це повинно дозволити значно поліпшити наш час доставки піктограм і підвищити масштабованість — при цьому візуалізація деяких значків відбувається за межами сітки, і тому значок виявляється трохи розмитим.

Хоча це було б цілком прийнятно на вторинних піктограмах, візуалізація всіх наших найбільш значущих піктограм має бути правильною і по пікселях гранично бездоганною. Тому ми повинні створювати (відтворювати) їх так, щоб усунути будь-які пікселі поза сітки, особливо при низьких значеннях PPI (точок на дюйм). См. наші піктограми «назад» внизу:



Як можна бачити, оскільки ми управляємо візуалізацією при будь-якому заданому значенні PP, ми видаляємо розмитість піктограми, викликану масштабуванням.

Ми також зробили товщину лінії піктограми трохи менше (2 пікселя при 100% і 3 пікселя при 200% порівняно з початковими 2 пікселями при 100% і 4 пікселями при 200%), оскільки я вважав, що товщина була дещо завищеною. Завдяки цьому вони стали більш елегантними і врівноваженими на нашому інтерфейсі.

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

Оскільки візуалізація здійснюється програмно, то ми змогли також усунути всі дублювання колірних станів; від нас потрібно тільки надати чорний .svg і вказати потрібний колір в коді.

Приємним додатковим бонусом програмної візуалізації є те, що ми тепер можемо — при необхідності — вирізати і вставляти піктограми (для заблокованих розширень і дозволів, наприклад) замість того, щоб експортувати заблокований і незаблокований варіант як окремі растрові зображення.

См. процес, показаний нижче:
Вирізання і вставлення піктограм

Нижче показана нова уніфікована система піктограм з кольоровою і вставний версіями. Вона дає уявлення про систему в цілому.


Тепер все, що стосується процесу створення піктограм, залагоджено. Подивимося, як вони вписуються в користувальницький інтерфейс.

Сенсорні майданчики і компонування
Оскільки піктограми засновані на компонуванні 16х16 точок, яка чудово вписується в 4-точкову сітку, задану раніше, то їх розподіл і розташування в інтерфейсі було, по суті, справою вибору належного розміру майданчиків для дотику або клацання як для звичайного, так і для гібридного виду.

У звичайному вигляді ми прийняли сенсорні майданчики 28x28 точок, зберігаючи піктограми 16х16 точок. Звичайно, подальше розташування проходить послідовно через всі звичайні компонування Chrome незалежно від платформи.

Нижче показаний Chrome ос chrome:


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

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

Ми спочатку зосередилися на висоті елементів, для якої ми вже визначили найбільш чутливі точки: вкладки і запиту.

Для обох висота була збільшена з 32 точок до 28. Додатково ми використовували спосіб, який збільшив сенсорну поверхню вкладки у фреймі, що додало 8 точок до розміру сенсорного майданчика.

У той час як піктограми зберегли свої сенсорні майданчики 28x28 точок, ми збільшили їх навколишнє кордон до 8 точок, що дало інтерфейсу більше простору і зменшило ймовірність користувальницьких помилок при торканні. Ті ж принципи діють для піктограм всередині універсального вікна пошуку (розширення і дозволу), а також для піктограм розширення.

Можна помітити, що, хоча розташування змінюється, піктограми зберігають свій розмір. Ми послідовно використовуємо для піктограм розмір 16х16 точок. Це мінімізує кількість цифрових об'єктів проектування, вимагають обслуговування, що спрощує масштабування надалі і повторне використання якихось характеристик і властивостей.

Нижче наведений вигляд повного гібридного основного інтерфейсу:


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

Раніше створення піктограм, що не входять в MD, тривало роками, що надзвичайно ускладнювало підтримку послідовного набору розмірів. На цей раз ми навіть відновили наші вимоги до піктограмі розширення на 16х16 точок замість 19x19. Ми також переопределили спосіб вставки, використовуючи ту ж методику обрізання, яка була нами застосована для заблокованого дозволу.



Нарешті для користувачів, які бажають завжди бачити свою панель закладок, ми підправили її так, що вона тепер не викликає зоровий дисбаланс або зсув в обох компоновках.

Нижче див. приклад на Mac для звичайної компонування, на Windows і Chrome OS — для гібридної.
Звичайна компонування Chrome macOS — показана панель закладок


Mac до його звичайного розміру додано: 28 точок, щоб вписати сенсорні майданчики кнопок панелі інструментів 28x28 точок.

Windows і Chrome у звичайній або гібридної компонуванні працюють трохи інакше.



Ми додали панель закладок висотою 24 точки, щоб збалансувати додаткову висоту кадру Windows. Оскільки ос chrome використовує ту ж реалізацію, що і Windows, маємо той самий розмір.

Ми продовжуємо експериментувати з цією компонуванням на ос chrome. Час покаже, виправдалося прагнення отримати належний баланс між сенсорною і несенсорной компоновками. Тому, поки ми не отримаємо більш глибоке розуміння звичок і потреб наших користувачів на платформі Windows, ми будемо продовжувати поставляти звичайну компонування за замовчуванням на всі пристрої з Windows. Однак сенсорні пристрої з ос chrome будуть отримувати гібридну компонування за замовчуванням.

Якщо є бажання спробувати самому, то просто увійдіть у розділ прапорців Chrome (chrome://flags) і встановіть прапорець UI Layout in the browser's top chrome («Компонування користувальницького інтерфейсу у верхній частині браузера Chrome) на «Touch» («Дотик»).



Запиту, що випадає табличка з результатом та індикатори захищеності
Є дві вимоги до проектування компонування універсального вікна пошуку і випадає таблички:

  • Приділити особливу увагу статусу захищеності.
  • Забезпечити користувачеві швидкий доступ до інформації або URL.
Запиту є, ймовірно, найбільш важливою функцією Chrome. Він являє собою шлюз до результатів пошуку Google, до мережі, а також до їх власним закладках та архіву. Він також є єдиним місцем, де ми можемо чітко показати статус захищеності якогось домену, спробувати ефективно захистити користувача від численних мережевих загроз, використовуючи активну блокування, пасивну індикацію і навчання.

З цією метою візуальний проектувальник Макс Уолкер працював разом з Алексом Ейнслі, керівником Chrome UX, і службою безпеки Chrome у напрямку додавання в наш запиту нової модифікованої системи індикатора захищеності. Було зроблено наступне:

  • Ми замінили піктограму за замовчуванням «сторінка» на інформаційну кнопку, запрошує користувачів клацнути, щоб відредагувати дозвіл сайту і щоб зрозуміти статус захищеності домену, на який користувач входить. В цю категорію потрапляють незашифровані HTTP-сторінки.


  • Статус «Захищено» або «Зелений замок» тепер діє тільки для захищених HTTPS сайтів. Це підтримує захищені домени, які використовують шифрування.

Захищено Захист підтверджена сертифікатом

  • Можна згадати, що статус захищеності в Chrome кілька років тому був жовтим. Зараз всі сайти з порушеним https або представляють загрозу отмаркированы червоним. Якщо Гугл знає, що домен являє собою фішинговий сайт, то ми повністю також блокуємо доступ до нього.


Макс погодив типографіку нашої сертифікації з URL-текстом і використовував нову колірну схему. Він також модифікував наші замки, надавши їм більш приємний вигляд.

Прямо пов'язана з цим і випадає табличка універсального вікна пошуку (контейнер з результатами, який ви отримаєте після введення запиту). Табличка істотно не змінилася при розглянутої переробці. Ми змінили багато, пов'язане з піктограмами, а також колірну схему, але основними є наступні дві зміни: нова компоновка для гібрида і — що більш важливо — вбудовані відповіді.

Вбудовані відповіді, звані також «попереджувальні відповіді», являють собою відображення, в основному, Гуглом або Хромом, шуканої вами інформації до того, як ви фактично натисніть Enter для підтвердження запиту. Наприклад, якщо ви введете «weather in los ang» запиту, то Chrome запропонує вам наступне:



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



Так цей запит виглядає у звичайній компонуванні:


А тут на іншому запиті (на цей раз за акціями) можна побачити відміну гібридної компонування із збільшеною висотою рядка для поліпшення дотику.



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

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

Кольори і доступність
Крім щільності компонування іншим важливим елементом є колір.

Chrome MD для настільного комп'ютера пройшов через ті ж зміни, що раніше Chrome для Android. Нам потрібні більш уніфіковане керівництво за кольором і послідовна і, що більш важливо, доступна колірна схема.

Звичайно, найбільш помітна зміна, що кидається в очі при відкриванні Chrome, — це сама зміна кольору інтерфейсу.

Балансування кольору основного інтерфейсу виявилася завданням, що вимагає витонченості, більшою мірою, чим мені це уявлялося спочатку.

Основний користувальницький інтерфейс складається з трьох ключових елементів:

  • Фрейм, створюваний самою ОС, залежить від платформной бази.
  • Активна вкладка і панель інструментів. Сюди входять обрана вкладка, прикріплена до омнибоксу, і елементи управління.
  • Неактивна(і) вкладка(и).
Для нормальної роботи ці три елементи повинні мати належний контраст. Трудністю, з якою виявилося нелегко впоратися, стало те, як надати дизайну більш однорідний, більш сучасний вигляд при досить сильному обмеження по контрасту.

Інше, про що довелося думати, стала тема. Настільний комп'ютер на відміну від мобільних пристроїв підтримує темизацию. Ми повинні були враховувати це і поліпшити її, якщо це можливо.

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

Нижче показана трирівнева структура Chrome для обох видів:


Наша колірна система основного інтерфейсу наступна:


Mac і Chrome OS є досить простими, оскільки ми управляємо кольором кадру OS безпосередньо, просто додаючи розмиття фону на Mac.

З Windows ситуація дещо складніша, оскільки користувач або система можуть встановити майже будь-який колір в якості кольору кадру. Тому ми продовжували те, що ми робили досі, граючи з непрозорістю, щоб змішувати наш колір з тим, що видає система.
См. порівняння внизу: у той час як в mac і Chrome OS неактивні вкладки використовують непрозоре фарбування, для Windows ми знижуємо заповнення неактивних вкладок і кнопки нової вкладки до 78%.


Фарбування звичайного основного інтерфейсу в macOS, Windows і Chrome

Щоб збалансувати нову колірну тему, ми значною мірою залежимо на використання лінії. Оскільки лінія має товщину 1 піксель незалежно від щільності пікселів, то її прозорість була трохи підправлена так, щоб лінії не виглядали занадто темними при 1х або занадто світлими при 2х. Це має місце як для звичайного виду, так і для «інкогніто».


Chrome macOS при 200% і 100%. Обидві лінії мають товщину 1 піксель.

Доступність завжди була частиною мережевої архітектури Chrome, чи це стосується боку контенту з сумісністю a11y або сторони користувальницького інтерфейсу.

В останні два роки зусилля в цьому напрямку стали ще більше. Правда, на візуальній стороні наша колірна схема вимагає нового проходу, щоб зробити її простіше і відповідає правилам WCAG 2.0 для хорошого контрасту.

Ми переконалися, що вся наша типографіка, а також все, що пов'язано з піктограмами, має рівень не менш АА або контрастність 4:5:1:


Рекомендую чудовий інструмент для тестування коефіцієнта контрастності: leaverou.github.io/contrast-ratio
Безпосередньо пов'язана з цим наша програмована візуалізація дозволяє нам фарбувати піктограми динамічно на основі коефіцієнта контрастності, що не тільки означає поліпшення виду тим, створених для Chrome, але і поліпшення їх доступності.

Як можна бачити нижче, завдання теми «Dark theme V3» («Темна тема V3») перемикає піктограми на білий режим, а випадає табличку — автоматично на темний.

Це є прямим позитивним результатом функціональної візуалізації та введення нашого режим «інкогніто».



Анімація
Анімація є великою частиною того, про що думають люди, описуючи «Material design», особливо на мобільних пристроях. Добре спроектована анімація на цьому типорозмірі може, дійсно, надати додатком особливий шарм і розширити можливості більш ефективного використання. За умови, що ви як проектувальник не будете надмірними, можна доставити користувачам задоволення, а також допомогу і просторову обізнаність, використовуючи легкі підказки і своєрідне чітке рух інтерфейсу.

Але коли справа стосується настільного комп'ютера і діючого на ньому підходу «пріоритет миші і клавіатури» на великому дисплеї, то ситуація дещо змінюється.

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

При всьому нашому бажанні, щоб сенсорна і несенсорная платформи були більш узгодженими за своєю концепцією і властивостями, якісь особливості, які є необхідними і привабливими на мобільному пристрої, можуть виявитися незручними або навіть заважають для вирішення вашої задачі на настільному комп'ютері.

Десктоп для Chrome завжди був націлений на ефективність та швидкість роботи. Неприпустимо, щоб якийсь рух, якась анімація заважали виконання вашого завдання, тому більшість виведених інтерфейсом зображень з'являється на дисплеї без затримки або з мінімальною кількістю руху.

Візьмемо для прикладу нашу випадає табличку універсального вікна пошуку. Трохи анімації спочатку могло б здатися гарною справою, але, якщо ви викликаєте цю табличку по сто разів на день, то ви швидко зненавидите проектувальників за секунди, віднімає у вас, припустимо, ковзаючу анімацію з поступовою появою зображення.

Тому табличка з'являється миттєво, так само як і меню.

Так як же ввести деякий шарм «Material design», пов'язаний з рухом, на платформу, яка, здається, досить вороже сприймає анімацію? Її можна додати такі елементи користувальницького інтерфейсу, на роботу яких вона не може вплинути негативно; саме тому ми експериментували з «ефектом мерехтіння» на наших кнопках.

На десктопі клацання миші може викликати безліч дій, і їх стає ще більше при його об'єднанні з сенсорними здібностями гібридних пристроїв. Деякі з таких стану навіть не існують на мобільних пристроях. До них відносяться наступні:

  • Виділене стан
  • Активний стан
  • Одиночне клацання / дотик (onClick-відпускання)
  • Одиночне клацання / дотик для активації (кнопка переходить в стан «активний» після відпускання)
  • Довгий час клацання (натискання та утримання правої кнопки миші) / дотик для активації (тільки для елементів, що показують опції у відповідь на цю операцію)
Ми використовували для всієї нашої анімації розходиться сплеск брижів з Material design. Простий сплеск кольору розходиться з місця клацання миші або місця дотику.

Оскільки стану выделенности відсутні в специфікації MD, то перше, що нам потрібно зробити, було комбінування їх з брижами. Ми зробили сплеск брижів розбіжним квадратним станом выделенности, зрушуючи його межі назовні. У разі просте виділення + одиночне клацання при неактивному стані картинка виглядає так:



Тут показано, як це виглядає на панелі інструментів:



Для операцій «одиночне клацання для активації» і «довгий клацання / натиснуто для активації» нам потрібно скомбінувати брижі з звичайним кінцевим станом кнопки, активним станом, яке являє собою сірий заокруглений прямокутник, аналогічний нашому станом выделенности.

З цією метою ми разом з командою Material design розробили певний морфінг на брижах. Нижче показана реалізація на мобільному пристрої:



На десктопі при операції «одиночне клацання для активації» ми зберігаємо розтікання брижів при розширенні, однак, коли брижі досягає своєї вищої точки, ми трансформуємо її у квадрат замість продовження «сплеску». Це виглядає так:



Результат операції «довгий клацання / дотик для активації» дуже схожий на описаний вище, але в цьому випадку ми сповільнюємо розширення брижів.



Нарешті для нашої панелі закладок ми ввели заливающую брижі. Цей тип брижів являє собою розширюється еліпс, заповнює обмежену поверхню. У нашому випадку ми комбінуємо брижі зі станом выделенности, щоб створити виділене стан наших закладок, як показано нижче:



Коротке зауваження: ми вирішили не переносити «ефект мерехтіння» на macOS, оскільки він представляється зайвим на цій платформі. Ми вибрали тут те, що закладено в ОС.

З позиції розробки Бен Рутсиг запізнювався з виконанням модернізації системи брижів з нуля на наших платформах десктопів.

З позиції проектування початкові попередні анімаційні зображення та специфікації були швидко зведені разом з використанням Hype 3.

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

З цим типом анімаційної роботи розробник діяв як справжній дизайнер-проектувальник.
Що далі?
Після завершення готових до введення специфікацій і макетів для основного інтерфейсу я спробував себе трохи по вторинному інтерфейсі Chrome.

Ми включаємо в цю категорію всі ті елементи Chrome, які не розташовуються на поверхні, а саме: меню, діалоги, випадають таблички, інформаційні панелі, браузерна закладка find-in-page і полку завантаження. Деякі, схоже, вже з'явилися, деякі з'являться, ймовірно, скоро:


Нова інформаційна панель, що використовує не рекомендовані зараз кнопки.


Нова полку завантаження, наявна в Windows

Я не буду показувати це тут, щоб не послабити враження від майбутніх оновлень, але, якщо ви затятий користувач Chrome, то ви, можливо, увімкнули кілька прапорців, показують, що команда Chrome наполегливо працює, щоб внести нове покращене взаємодія у вторинний користувальницький інтерфейс, а також у внутрішні сторінки Chrome, як показані нижче:


Нова внутрішня сторінка «Історія»


Нова внутрішня сторінка «Спадні завантаження»

Оскільки моя участь в браузері Chrome закінчується з цим проектом основного інтерфейсу, я був би радий бачити, що команда Chrome має для майбутнього Chrome на десктопі і мобільному пристрої.

Отримані уроки та перші відгуки на випуск
Завершуючи, я хотів би поділитися деякими з уроків, які я отримав під час цього проекту, а також певною реакцією на реліз, як внутрішньої, так і зовнішньої; сподіваюся, що це буде корисно вам в ваших проектах.

1. Розробники — великі проектувальники, дизайнери
Ми багато розмовляємо в наших дизайнерських колах аргументи, повинен проектувальник-дизайнер програмувати. Є безліч розрізняються думок з цього питання, і причина в тому, що не існує простого визначення ролі проектувальника-дизайнера.
Однак ми майже не говоримо про зворотне: повинен розробник займатися проектуванням-дизайном?

У кінцевому рахунку, саме він є виробником і, певною мірою, «дизайнером» вашого продукту, саме тим, хто перетворює цей продукт в реальну річ. Іноді як проектувальник-дизайнер я відчуваю, що все, що ми робимо, є спробою «підробити» або «імітувати» кінцевий результат. Якомога швидший перехід до головного — до перевірки продукту в реальному середовищі, в реальному коді — має велике значення.

У цьому проекті багато хто з моїх пропозицій були відкинуті розробниками, які не тільки дали більш якісні рішення, але і реалізували і відпрацювали їх краще, ніж я зміг би зробити. Я маю на увазі, насамперед, програмовану візуалізацію (досягнення Петера Кастингу) і проектування анімації (керував Бен Рутсиг). Їх знання програмування було вкрай важливим для розуміння проекту, завдяки чому був не тільки змінений дизайн, але і була змінена суть самого проекту — з візуального вдосконалення користувальницького інтерфейсу на переробку основи.

Кожен є проектувальником-дизайнером. Ідеї не обмежені посадою. Якщо вам пощастить працювати з мотивованим і зацікавленим розробником, то ви зможете побачити, що людина іноді може бути більш кращим проектувальником-дизайнером, ніж ви.
2. Залучайте розробників у справу як можна раніше
В даному випадку вони були залучені з самого початку і були невід'ємною частиною процесу розробки дизайну та концепції. Як я згадав раніше, їх зацікавленість видати найкращий дизайн за найкращі технічні рішення призвела до того продукту, який є сьогодні. Підтримання постійного контакту було ключовим елементом реалізації проекту.

Вам не обов'язково потрібно розуміти процес програмування, більш важливо розуміти людей, які роблять це.
3. Треба розуміти, коли треба бути жорстким, а коли можна розслабитися
Виконуючи надзвичайно точну за характеристиками роботу необхідно, однак, в деяких випадках відкрити вашу напрацювання для зворотного зв'язку; нові ідеї можуть вивести ваш проект на інший рівень. Поки ваш кінцевий проект залишається вірним своєї первісної мети або наміру, дайте можливість іншим людям увійти в ваш процес та покращити ваш проект.

4. Остерігайтеся неприйняття змін
Коли ви модифікуєте якийсь продукт, особливо якщо він вже існує деякий час, ви зіткнетеся з тим, з чим зіткнулися багато хто з нас: неприйняття змін. Тоді будьте обережні. Іноді ваш проект може бути, насправді, неважливим, але в більшості випадків проста зміна чого-то виявляється достатньою, щоб ініціювати саму різну — від помірної до екстремальної — реакцію користувачів.

Її нерідко — надзвичайно важко отримати, і з нею надзвичайно важко боротися. В даному зміну дизайну додавання декількох пікселів викликало довгі дискусії і суперечки.

Я не буду говорити неправду — у мене немає чарівного рішення, але є дещо, що можна зробити, щоб мінімізувати неприйняття змін:

  • Спілкуйтеся з вашою аудиторією. Завжди будьте готові пояснити своє бачення тим, хто хотів би почути, особливо якщо вони є вашими зацікавленими особами.
  • Будьте наполегливими. Дуже корисно для справи твердо вірити в ваш вибір. Не будьте впертими, але будьте впевненими.
  • Будьте завжди добре підготовленими. Коли хтось бажає обговорити деякі ваші проектні рішення, будьте готові підтримати їх фактами, результатами досліджень (коли це можливо) або минулим досвідом. Якщо ви опинитеся в ситуації, коли не знайдете, що заперечити, то, може бути, над викладеним думкою варто задуматися.
  • Пам'ятайте, що деякі справи вимагають часу. Ймовірно, найбільш перешкоджає і викликав у мене найбільше хвилювань аспектом виявився той, що деякі речі просто вимагають часу на їх зміну. Чим більше продукт, тим більше часу потрібно на його зміну. Знайдіть щастя в маленьких перемогах і зрозумійте, що ваше творіння ніколи не буде дороблене до кінця.


5. Керуйте своїм очікуванням
Коли оновлення пішло в життя, самий жорсткий відгук, який я отримав, був: «Що це?». Це — справедлива зворотний зв'язок, по-моєму. Проект зайняв час, і він не став візуальної революцією. Я хотів би думати, що, якщо ви вдивіться в деталі, то ви, можливо, побачите, як багато уваги і зусиль ми вклали.
Найбільші удосконалення, внесені цим проектом редизайну, знаходяться всередині. Це, насамперед, технічне досягнення.

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

Власне знаходження задоволення від вашої роботи і її результату важливіше, ніж пошук визнання цього від інших. Якщо ви дійсно і чесно задоволені тим, що ви зробили, то у вас все добре.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.