Дизайн Алина Окунева
9 808

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

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

В закладки
Аудио

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

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

Проблема первая: вложенные вкладки

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

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

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

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

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

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

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

Проблема вторая: лишние иконки

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Проблема третья: счетчики самолюбования

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

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

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

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

Проблема четвёртая: неясность кнопки Watch

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

В случае 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 #редизайн

{ "author_name": "Алина Окунева", "author_type": "self", "tags": ["\u0440\u0435\u0434\u0438\u0437\u0430\u0439\u043d","github","fff","fafbfc"], "comments": 64, "likes": 33, "favorites": 43, "is_advertisement": false, "subsite_label": "design", "id": 60244, "is_wide": true, "is_ugc": true, "date": "Tue, 05 Mar 2019 13:26:10 +0300" }
{ "id": 60244, "author_id": 258318, "diff_limit": 1000, "urls": {"diff":"\/comments\/60244\/get","add":"\/comments\/60244\/add","edit":"\/comments\/edit","remove":"\/admin\/comments\/remove","pin":"\/admin\/comments\/pin","get4edit":"\/comments\/get4edit","complain":"\/comments\/complain","load_more":"\/comments\/loading\/60244"}, "attach_limit": 2, "max_comment_text_length": 5000, "subsite_id": 199114 }

64 комментария 64 комм.

Популярные

По порядку

Написать комментарий...
38

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

Ответить
9

ага, дизигнер предложил освободить нмного места поэтому впихнул еще информации, логика, че

Ответить
2

Как мне кажется, просто нить потеряна, не рассчитали под какую аудиторию продукт и что им на самом деле нужно. Банальный пример GitLab, продукт крутой, но сильно перегружен и люди все равно используют GitHub за его простоту и понятность.

Ответить
1

Комментарии к посту на HN, в итоге подтвердили мою мысль.

Ответить
34

Аватарки важнее описания коммитов, прекрасно.
Осталось добавить сториз в гитхаб.

Ответить
4

Commit Stories было бы круто. "Пацаны, ща в пабе, пивас отличный, смотрите как я закоммитил"

Ответить
1

MS же добавлял сториз в Skype, так что не удивлюсь.

Ответить
0

И благополучно их убрал. Так что они теперь ученые.

Ответить
0

Они просто решили подождать пару лет, как обычно 😂

Ответить
1

И фильтры, вот это будет пушка.

Ответить
35

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

Ответить
25

Надеюсь Ваши идеи никогда не воплотятся в жизнь.

Ответить
1

либо ишак, либо падишах

Ответить
16

Алина, я не дизайнер, я разработчик.

И я искренне рад, что вы не работаете в Github. Пожалуйста, продолжайте свое творчество в продуктах для людей, не трогайте наши инструменты.

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

Почти все что вы убрали, потому что решили что оно лишее - важно.
Все что вы добавили, потому что решили что оно необходимо - не важно и может быть спрятано максимально глубоко в труднодоступных местах.

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

99% сценариев использования репозитория - это использование для ежедневной работы, где важно видеть когда в последний раз изменилась папка/файл и почему.
Мне не нужно видеть список комитов на главном экране.
Если я работаю только с Wiki - значит я technical writer и мне вкладка code и все что под ней крайне не интересно
Если я работаю только с issues - значит я QA и мне вкладка code и все что под ней крайне не интересно.
Если я разработчик, то я либо использую вкладку code я навигации по коду и по вкладкам внутри code, или я работаю исключительно внутри pull requests (и в этот момент времени мне не нужен быстрый доступ куда либо под вкладкой code)
Мне не нужен блок со статистикой, потмоу что я каждый день работаю с этим репозиторием и я знаю эту статистику на изусть.

Вообще, в целом, как разработчику, в болшинстве случаев, мне интересна только вкладка "Pull requests" и все, остальное может быть где угодно.
Если я QA мне интересно только issues в большинстве случаев
Если я technical writer мне интересно только wiki в большинстве случаев

В целом, ваши правки сильно оторваны от контекста. В дизайне продукта очень важен контекст в котором находится продукт, вы как дизайнер должны не просто тупо открыть книгу по UI/UX и выполнять чеклист оттуда, а сначала погрузится в контекст продукта, а потом голово, самостоятельно создавать уникальный для текущего контекста и текущего продукта чеклист.

Ответить
7

Это же перевод. А автор оригинального материала как раз разработчик и активный участник комьюнити https://github.com/tonsky

Ответить
0

да, да, уже отписал, что мой комент не Алине.

Ответить
0

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

Ответить
0

Да, вы правы, я за восемь лет разработки продуктов, которыми по сей день пользуются десятки тысяч людей, + большим портфолио провальных проектов, ни в чем не разобрался :)

Плюсанул вам комент

Ответить
0

Увидел, что это перевод. Алина, сори, комент значит не вам. Пусть тогда Никита лучше поставит большую плашку "ПЕРЕВОД" над постом чем раскрашивает молотки в розовый, потому что это fancy :)

Ответить
0

При чем тут Никита вообще? На этом ресурсе статью перевела и разместила Алина, максимум, что сделал Никита — на почте ответил "да" на вопрос, можно ли взять его статью.

Ответить
0

Что? Мой комент к статье, автор стати - Никита. Вот причем он тут.

Ответить
1

и поймите, бОльшая часть работы в Github происходит в закрытых репозиториях компаниями с наемными разработчиками, все ваши изменения просто убирают важную для работы информацию и добавляют нечто что просто интересно каким то залетным людям (которых в приватных репах нет)

Ответить
0

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

Ответить
0

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

Ответить
15

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

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

Ниже еще есть блок readme в котором 80% смысла страницы и сосредоточено.

P.S и прекратите уже выдавать бледный текст в тонкой рамке за кнопку

Ответить
3

и прекратите уже выдавать бледный текст в тонкой рамке за кнопку

Вы ничего не понимаете в дизайне, ведь кнопки, которые выглядят как кнопки - это устаревший дизайн! Это же ведь так ужасно, когда что-то давно не менялось, все к этому привыкли и пользуются на интуитивном уровне! Ведь сейчас же уже %номер_текущего_года%! Ни в коем случае нельзя допускать, чтобы пользователь привыкал к интерфейсам, ведь пользователь должен страдать. Любоваться нашим прекрасным новым плоским дизайном с отступами в половину площади экрана и с 15 шрифтом для контента и страдать.

По-моему, логика большинства редизайнеров именно такая. Я никак иначе не могу объяснить то, что "давно ничего не меняли" выдаётся за реальную проблему, которая требует скорейшего решения.

Ответить
2

На самом деле за это и ценишь Github. Они не гонятся за модой и даже если и меняют интерфейс, то делают это постепенно, не ломая людям привычный рабочий Flow. Самое драматичное изменение, которое помню - это смена header с белого на черный. Люди даже делали плагины для Chrome, чтобы вернуть старый дизайн логотипа.

Ответить
0

Они не гонятся за модой и даже если и меняют интерфейс

И есть Гитлаб, который, если послушать рассказы Умпутуна, чуть ли не в каждом минорном релизе что-то ломает.

Ответить
7

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

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

Как раз это нужно, чтобы быть в курсе изменений в проекте.

Ответить
2

Не дали дописать))))

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

Ответить
5

Избавиться от градиента

Градиентом выделены кнопки-действия
бледных цветов, ненужных разделителей

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

Вообще охренеть можно. А GitHub для кого работает, если не для программистов???

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

Ответить

3

дизайнеру нужно было остановиться перед тем как он начал городить три этих блока Files Commits Statistics. до этого момента все было разумно. просто освежить в конечном итоге стилистически и все

Ответить
2

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

Если работаешь не один или много модулей в проекте, то это первое, на что ты будешь смотреть после выбора ветки

Ответить
2

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

Ответить
2

Потерялся фокус. Дизигнеры Github не просто так проигнорировали #FFFFFF в верхнем блоке. Работа с цветовым контрастом очень важна, чтобы сохранить правильные акценты и структурировать страницу. То же и с градиентными кнопками. Да, в эпоху flat дизайна градиенты смотрятся пережитком прошлого, но это не отменяет их высокую юзабельность. Когда программист, пишущий код уже 12-й час к ряду зайдет на Github, он будет безумно рад градиентам, ибо не будет тратить силы на поиск нужной кнопки.

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

Ответить
0

Лезть можно, но только собрав достаточно отзывов и сделав 1000 правок до финального релиза.

Ответить
1

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

весь мир это вложенные структуры

Ответить
1

А мне понравилось. Сложность реализации в том, что по ту сторону сидят пользователи с девизом "работает - не трогай", поэтому и такая пассивность и агро на ваше желание улучшить UI их инструмента (самое забавное, что с репозиториями они работают НЕ через веб, поэтому непонятны их стоны и угрозы).

Но, само собой, такие изменения надо выкатывать порциями и смотреть, как они будут восприниматься юзерами.

Ответить
0

Комментарий удален по просьбе пользователя

Ответить
1

Очень рад что автор статьи (оригинала) не имеет никакого отношения к GitHub и его дизайну.

Ответить
1

Где-то до "проблемы" пятой было хорошо (вкладки), но потом буэ началось

Ответить
1

Результат выглядяит как смесь iOS и последнего блевотного дизайна гугла

Ответить
0

Помянем старый скруглённый дизайн GMail. Надеюсь, они к нему когда-нибудь вернутся.

Ответить
1

Статистика на вкладке Overview - перебор, мне кажется. В остальном - очень понравилась концепция.

Ответить
1

Мм... вроде бы как ход рассуждений и корректировок был такой красивый и последовательный, а потом БАЦ - и дизайн просто развалился. Основные три колонки просто сливаются, их тяжело разделить взглядом. Нужно как-то разделить их, имхо

Ответить
1

бл*ть не трогайте один из лучших дизайнов, еще и крейглист задизайнте ага

Ответить
1

Надеюсь никто в Microsoft/GitHub этого не увидит:
1. Целевая аудитория? Нет, не слышал. Из инструмента для разработчиков получился сайт для хипстеров.
2. Заменить 2-х уровневую иерархию 10 табами? Правило Миллера про 7 +- 2 пунктов?
3. Пытаться освободить место, но не убрать рекламу Visual Studio Extension?
И этот человек считает себя UX-дизайнером?

Ответить
1

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

Ответить
0

Вы прочитали эссе "Одиннадцать надуманный проблем или как из удобного инструмента для разработчиков сделать неюзабельное ми-ми-ми". Помню, как дизайнеры добрались до SourceTree... :(

Ответить
0

Могу согласиться с пунктом про релизы. Явно не на своём месте и я постоянно его ищу. Хуже только новый поиск в разделе Stars.

Ответить
0

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

Ответить
0

Одна мелкая деталь, котроая характеризует дизайн в целом: таймлайн с коммитами выглядит как разделитель колонок, тем самым ломая всю геометрию страницы. Вроде колонок три, а выглядят как две. Не, так самолёт не летает =)

Ответить
0

Ну, какбэ...

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

А вообще ставим расширение my-style, например, и делаем для ЛЮБОГО сайта тот стиль, который вам нравится.

Ответить
0

Думаю, всю ту информацию, которую можно и так локально через git посмотреть, нужно выпилить в первую очередь. А вообще война против градиентов нелепая. Кто-то пустил тренд и давай все дизайнеры выпиливать градиенты налево и направо. Своё мнение-то есть?

Ответить
0

Не дай бог никому такой редизайн. Все элементы болтаются на выжигающем глаза полотнище.

Ответить
0

Крутая статья!

Ответить
0

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

Ответить

0

Быть дизайнером: раз в пару лет вводить тренд на плоскость, а потом снова от него уходить. В межсезонье делать то же самое с закруглениями углов.

Ответить
0

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

Ответить
0

1. Всё что сделали с шапкой было ок, кроме перекрашивания кнопок в ярко синиий.
2. Overview вообще не понравился, провал какой-то.

Ответить
0

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

Ответить
0

Я бы после такого редизайна перешёл на гитлаб полностью.

Ответить
0
{ "page_type": "article" }

Прямой эфир

[ { "id": 1, "label": "100%×150_Branding_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox_method": "createAdaptive", "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "ezfl" } } }, { "id": 2, "label": "1200х400", "provider": "adfox", "adaptive": [ "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "ezfn" } } }, { "id": 3, "label": "240х200 _ТГБ_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fizc" } } }, { "id": 4, "label": "240х200_mobile", "provider": "adfox", "adaptive": [ "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "flbq" } } }, { "id": 5, "label": "300x500_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "ezfk" } } }, { "id": 6, "label": "1180х250_Interpool_баннер над комментариями_Desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "h", "ps": "bugf", "p2": "ffyh" } } }, { "id": 7, "label": "Article Footer 100%_desktop_mobile", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fjxb" } } }, { "id": 8, "label": "Fullscreen Desktop", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fjoh" } } }, { "id": 9, "label": "Fullscreen Mobile", "provider": "adfox", "adaptive": [ "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fjog" } } }, { "id": 10, "disable": true, "label": "Native Partner Desktop", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fmyb" } } }, { "id": 11, "disable": true, "label": "Native Partner Mobile", "provider": "adfox", "adaptive": [ "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fmyc" } } }, { "id": 12, "label": "Кнопка в шапке", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "p1": "bscsh", "p2": "fdhx" } } }, { "id": 13, "label": "DM InPage Video PartnerCode", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox_method": "createAdaptive", "adfox": { "ownerId": 228129, "params": { "pp": "h", "ps": "bugf", "p2": "flvn" } } }, { "id": 14, "label": "Yandex context video banner", "provider": "yandex", "yandex": { "block_id": "VI-223676-0", "render_to": "inpage_VI-223676-0-1104503429", "adfox_url": "//ads.adfox.ru/228129/getCode?pp=h&ps=bugf&p2=fpjw&puid1=&puid2=&puid3=&puid4=&puid8=&puid9=&puid10=&puid21=&puid22=&puid31=&puid32=&puid33=&fmt=1&dl={REFERER}&pr=" } }, { "id": 15, "label": "Плашка на главной", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "p1": "byudx", "p2": "ftjf" } } }, { "id": 16, "label": "Кнопка в шапке мобайл", "provider": "adfox", "adaptive": [ "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "p1": "byzqf", "p2": "ftwx" } } }, { "id": 17, "label": "Stratum Desktop", "provider": "adfox", "adaptive": [ "desktop" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fzvb" } } }, { "id": 18, "label": "Stratum Mobile", "provider": "adfox", "adaptive": [ "tablet", "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fzvc" } } }, { "id": 19, "label": "Тизер на главной", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "p1": "cbltd", "p2": "gazs" } } } ]
Команда калифорнийского проекта
оказалась нейронной сетью
Подписаться на push-уведомления
{ "page_type": "default" }