Избавиться от градиента, бледных цветов, ненужных разделителей: концепт редизайна страницы репозитория на GitHub Статьи редакции

Перевод материала создателя Fira Code, DataScript, Rum Никиты Прокопова.

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

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

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

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

К тому же ими неудобно пользоваться. Допустим, я нахожусь в разделе Wiki, мне надо посмотреть раздел Releases. Что делать? Я не вижу нужную мне вкладку и мне каким-то образом надо догадаться, что она вложена во вкладку Code (?), а это не совсем логично. Вкладка с релизами — такая же часть кода, как и вкладка Issues или Wiki.

Решение — разместить все вкладки в один навигационный элемент управления.

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

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

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

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

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

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

Ещё один вариант плохих иконок: если они плохо выражены графически, читать надписи всё равно придётся, а значит, иконки бесполезны.

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

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

Поэтому иконки вкладок несут в себе исключительно декоративную функцию. Не верите — посмотрите, что делает сам GitHub. Их иконки тусклые:

Это явный показатель: они знают, что невозможно догадаться, почему иконка раздела commit — это идущие в обратную сторону часы. GitHub знает, что люди всё равно будут читать надписи.

Но даже если они нужны просто для красоты, они все равно плохие. Иконка, надпись, счётчик — это симметричная и некрасивая композиция:

Убрав иконки, мы:

• получаем много свободного горизонтального пространства;
• улучшаем дизайн;
• избавляемся от визуального шума.

Преимущество, преимущество и преимущество! Вот конечный результат — вкладки без иконок:

Проверьте, можете ли вы найти вкладку с релизами без иконки? А раньше это сделать было сложнее? Было, правда?

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

Ещё хочу заметить, что мне пришлось убрать вкладку Contributors («Разработчики»), которая не являлась вкладкой как таковой, а была вложена во вкладку Insights и по какой-то причине продублирована во вкладке Code. Это было сделано, чтобы поместилась вкладка «Настройки». Не волнуйтесь, позже мы разберемся, что делать с разработчиками.

Вот как выглядит «меню самолюбования»:

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

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

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

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

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

Это и не статус: если вы видите надпись "Watch", это не означает, что вы подписаны на репозиторий. То же самое с двумя другими статусами: они не кнопки, но они и не отражают состояние.

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

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

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

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

Всё вместе пока выглядит вот так:

Вот как выглядит описание репозитория:

А вот в чём проблема: почему описание находится под вкладкой кода? Это же описание всего репозитория, а не только кода.

Чтобы исправить это, расположим его над вкладками, в область, которая относится ко всему репозиторию:

Осталась ещё пара штрихов.

Во-первых, шрифт описания не крупный и не мелкий (его размер составляет 16 пикселей, шрифт названия репозитория — 18, а шрифт вкладок — 14). Давайте сменим его на 14-пиксельный, чтобы на странице было только два заметных шрифта. Ещё я думаю, что нет необходимости переносить «https://» в ссылку:

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

Посмотрите, мы освободили ещё больше вертикального пространства!

Синие теги на синем фоне труднее читать. Это связано с тем, что раньше они были на фоне #FFF, а теперь они на фоне GitHub #FAFBFC под названием «очень светлый грязно-синий».

Давайте изменим цвет фона тега на #FFF:

Но почему этот фон вообще был нужен? В чём заключалась его задача?

Я думаю, что GitHub добавил его, потому что структура элементов меню стала слишком трудной для восприятия, и разработчикам пришлось добавить визуальные подсказки, чтобы пользователю было легче «разделить их». Самое верхнее меню выделено чёрным с той же целью — визуальное разделение. Посмотрите, они тратят значительную часть экрана размером 768 пикселей только на навигацию.

Когда меню разделено на уровни, оно не выглядит таким пугающе трудным. Без фона оно выглядело бы неорганизованно.

Но так как мы уже упростили всю строку меню и убрали один уровень в середине, выделение цветом потеряло смысл. Теперь можно насладиться белоснежным фоном:

И обратите внимание, сколько свободного места. Наконец-то в верхней части экрана тоже можно увидеть основное содержимое.

Небольшое изменение. Если пользователь — создатель репозитория, он может редактировать и его описание, и теги:

Во-первых, кнопка «Редактировать» очень неудобно расположена: слишком далеко и незаметно.

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

Решение? Сколько же кнопок для редактирования должно быть? Я думаю, ноль.

«Но куда же деть кнопки редактирования?» — спросите вы.

Дело в том, что описание и теги важно заполнить только тогда, когда человек создаёт репозиторий. После этого они редко меняются.

Когда описание и теги ещё не созданы, будет отображаться кнопка для их добавления:

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

У стандартного «Проводника» Windows, как и у Finder на MacOS выстроена простая структура для просмотра файлов: файлы — слева, сведения о файле — справа.

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

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

Возможно, они хотели, чтобы GitHub был больше похож на Git, чем на обычный просмотр файлов, и ничего лучше не придумали? Я придерживаюсь этой теории.

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

«Изменение разметки» это не описание папки «Документы». «Мне тоже нужен такой отладчик» в папке «Инструменты» — мне-то какая разница?

Вывод: можно избавиться от этих сведений без каких-либо важных потерь:

Когда открываешь репозиторий, первой страницей не обязательно должна быть Code. Лучше назвать ее "Overview" (общий вид), быстрый взгляд на которую поможет понять, что происходит.

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

Поэтому мое предложение — добавить список последних внесённых изменений на страницу Overview, рядом со списком файлов.

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

А что делать со свободным пространством справа? Можно расположить там полезную статистику:

Для начала я добавил разработчиков. Самое важное в GitHub — это люди и сотрудничество, поэтому они выделяют столько места на кнопки Fork и PR. Но люди — это главное в сотрудничестве. Они тратят своё время и силы на разработку этого кода. Было бы здорово посмотреть на их лица.

Функция активности относительно новая и не отображалась на странице репозитория — до настоящего момента. Она помогает увидеть динамику проекта.

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

Я считаю, что новая вкладка Overview намного полезнее в повседневном использовании.

Кнопки «Создать новый файл», «Загрузить файлы» и «Найти файлы» относятся к работе с файлами, поэтому логичным решением будет переместить их туда, где они нужны: в раздел «Файлы».

Раньше у GitHub ссылка на рабочую копию была прямо на странице. Это было очень удобно — если нужен был код, не надо было никуда переходить.

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

Но теперь, когда мы переместили кнопки работы с файлами, у нас достаточно места на полноценную ссылку на рабочую копию:

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

Вот так GitHub выглядел в 2013 году:

А вот скриншот 2015 года:

Вот как сервис выглядит сейчас:

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

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

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

Вот дизайн GitHub на данный момент рядом с тем, что предлагаю я:

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

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

#github #редизайн