Меню Закрити

Як можна покращити зовнішній вигляд Github

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

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

Проблема 1: вкладені рівні вкладок

Одразу почнемо з найбільшої проблеми — інформаційна ієрархія. Візьмемо вкладки. Наразі існує два рівні вкладок, один вкладений під іншим:

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

Як наслідок, виникає проста проблема у використанні: скажімо, я перебуваю у Wiki й мені потрібно бачити Releases. Що я повинен зробити? Немає видимої вкладки Releases, тому користувач має сам якось з’ясувати, що релізи є частиною Code? Це трохи безглуздо. Релізи так само є частиною Code, як Issues або Wiki.

Рішення тут полягає в тому, щоб зрівняти всі вкладки в один навігаційний елемент управління:

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

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

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

Проблема 2: надлишкові іконки

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

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

Пріоритизація або виділення одних елементів означає зниження пріоритетності інших. Не можна виділити все.

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

Будемо чесними: сфера використання GitHub досить абстрактна. Незалежно від того, наскільки ви вправні в дизайні й наскільки сильно старалися, вам не вдасться  створити класну іконку для коміту, релізу або проблеми (issue)… Класна іконка — така, яку інші люди впізнають і розуміють. А для репозиторіїв їх просто немає.

Це коміт?

Тож іконки для вкладок Github суто декоративні. Навіть Github затуманює їх:

Це свідчить про те, що й на їхню думку, майже неможливо зрозуміти, чому годинники зі стрілкою назад означають “Commit”. Github знає, що люди дивитимуться на підпис.

Але навіть будучи декоративним, вони все одно погані: іконка + текст + лічильник утворюють симетричну й слабку композицію:

Видаляючи іконки, ми:

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

Ура-ура-ура! Ось результат — вкладки без іконок:

Перевірте себе. Подивіться, чи можна знайти вкладку Releases без іконки й чи складніше це, ніж раніше. Не складніше, чи не так?

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

Іще примітка: мені довелося видалити вкладку Contributors (яка була насправді не вкладкою, а вкладеною з Insights й дублювалася в Code з якоїсь причини) для розміщення вкладки Settings (Налаштування). Не хвилюйтеся, пізніше ми до неї повернемося.

Проблема 3: лічильники популярності

Це “меню популярності”:

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

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

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

Проблема 4: невизначеність кнопки “Watch”

У кнопці “Watch” ми маємо класичну UX-дилему “кнопка або статус”. Кнопки показують нам, що можна зробити, але не повідомляють про поточний статус. Статус повідомляє про поточний стан, але не зрозуміло, як його можна було б змінити.

У випадку Github “Watch” має позначку на кнопках, але вона не діє як кнопка: натискання на неї не змусить вас дивитися репо. Це також не статус: якщо ви бачите “Watch”, це означає, що ви не слідкуєте за цим проектом. Те саме для двох інших статусів: вони не є ні кнопками, ані станами.

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

Кумедно, але Github уже використовує випадаюче меню! Нам просто потрібно його виправити, щоб воно працювало, як будь-який інший випадаючий список: показувало поточний стан. Просте виправлення:

Дрібниця, але дратує: цю “птицю” дуже важко помітити. Виділимо весь рядок:

Усе разом:

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

Ви вже тут? Чудово! Рухаймося далі.

Проблема 5: опис репозиторія

Це опис репозиторія:

Проблема з ним полягає в тому, що його розміщено під вкладкою Code. Це ж опис усього репо, а не лише його коду, так?

Щоб виправити це, перемістимо його над вкладками в область, що відноситься до всього репо.

Вона все ще потребує кількох змін.

По-перше, шрифт ні великий, ні малий (це 16 px, що стоїть між 18 px і 14 px). Дозвольте зробити його 14 px таким чином, щоб було лише два різних розміри шрифту. Також я впевнений, що не потрібно відображати “https: //” у URL-адресі:

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

Подивіться, ми знову виграли більше вертикального простору!

Проблема 6: видалення кольорового фону

Сині літери на блакитному фоні стало важче читати. Це тому, що вони були на #FFF, а тепер на #FAFBFC “ніжного сіро-блакитного кольору”.

Змінімо фон вкладки на #FFF:

Але чому взагалі виник цей фон? У чому його роль?

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

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

Але оскільки достатньо ми спростили весь стовпчик і видалили один проміжний шар, нам більше не потрібен цей колір. Натомість ми можемо насолоджуватися свіжим хрустким білим кольором:

І подивіться на все це вільне місце! Нарешті ми можемо побачити якийсь контент у верхній половині екрана.

Проблема 7: редагування опису

Невелика правка. Якщо ви є власником сховища, можете редагувати його опис і теми:

По-перше, ця кнопка дуже невдала — вона занадто далеко, її легко пропустити.

По-друге, окрема кнопка редагування для тем — це артефакт системи тем, який розроблявся в інший час, можливо, іншою командою. Не потрібно мати дві окремі кнопки.

Рішення? Скільки треба кнопок редагування? Я скажу — жодної.

“Але… Звідки беруться кнопки редагування?” – запитаєте ви.

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

Коли немає опису або тем, ми покажемо кнопку, щоб додати їх:

І якщо опис/розділи вже заповнені, перейдіть до “Налаштувань”, щоб змінити їх. Проблему вирішено!

Проблема 8: опис файлів

Традиційний Windows File разом із MacOS Finder створив простий шаблон для перегляду файлів — файли зліва, деталі справа.

Github вирішив скопіювати цей шаблон, але вони в якості деталей помістили несподівану річ — інформацію про дату зміни файлу.

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

Можливо, вони хотіли, щоб Github був про “git” (розподілена система управління версіями) більше, ніж про традиційний перегляд файлів, і це було єдине, про що вони могли думати? Так я думаю.

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

Це означає, що ми можемо позбутися описів, нічого не втративши:

Проблема 9: огляд репо

Коли ви потрапляєте до сховища, перша сторінка, яку ви бачите, не обов’язково має бути Code. Ми краще назвемо її “Огляд” — те, що швидко дає уявлення про поточний стан сховища.

Тепер сховище Github — не просто список файлів. Також ідеться про те, як ці файли змінюються із часом. Які нові функції було додано? Які помилки виправлено? Чи були нещодавно нові редакції? Усі вони так само важливі, як і самі файли.

Ось чому я пропоную додати список комітів на сторінку “Огляд” поруч із файлами.

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

А як щодо вільного простору справа? Там можна розмістити корисну статистику:

По-перше, я додав учасників (Contributors). Github — це все про людей і співпрацю, тому вони приділяють особливу увагу кнопкам Fork і PR. Адже люди є обличчям цієї співпраці. Вони вкладають свій вільний час та енергію, щоб написати цей код. Цілком справедливо бачити їхні обличчя.

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

Статистика щодо мов програмування була несправедливо прихована, тепер вона на передньому плані. Я також додав розмір коду в рядках коду — очевидне доповнення, якого Github досі не має.

Загалом, на мою думку, нова вкладка «Огляд» є більш корисною в щоденному використанні.

Проблема 10: контекстні кнопки

Кнопки “Створити новий файл”, “Завантажити файли”, а також “Знайти файли” стосуються файлів.

Проблема 11: приховане посилання для клонування

Github завжди показував URL-адресу для клонування безпосередньо на сторінці. Це було дуже зручно — можна було завантажити код без додаткових кліків.

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

Добре, що після переміщення кнопок файлів у нас удосталь місця для відновлення повної URL-адреси для клонування:

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

Остання проблема: застарілий вигляд

Ось такий вигляд Github мав у 2013 році:

Це скріншот із 2015 року:

І нарешті, такий вигляд тепер:

Як бачите, кольорова схема та основні елементи інтерфейсу не змінювалися суттєво з 2013 року.

Але, можливо, настав час виправити це? Позбутися градієнтів, сірих розмитих кольорів, непотрібних роздільників, додати трохи більше простору. Щось на зразок такого:

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

Наостанок

Поточний дизайн Github поруч із моєю пропозицією (натисніть, щоб відкрити в новому вікні):

Ми додали ще чотири файли на екран із тим же вертикальним розміром, 6 останніх змін, 3 окремі гілки проектів, 10 облич учасників, проектну діяльність та розширену статистику мови БЕЗ втрати інформації.

Якщо ви знаєте когось у Github, надішліть їм посилання на цю статтю. Можливо, комусь сподобаються мої ідеї і, зрештою, їх реалізують — хто знає?

Якщо ви знайшли помилку, будь ласка, виділіть фрагмент тексту та натисніть Ctrl+Enter.

1+

Повідомити про помилку

Текст, який буде надіслано нашим редакторам: