Как мы можем улучшить #LinuxUsability на рабочем столе? Если вы переходите от части 1, части 2, части 3, части 4 и части 5 к этому выпуску этой серии и теперь думаете, что UX - это все о сахарных поверхностных конфетах для глаз - Не бойтесь: в этом выпуске мы более глубоко заглянем под капот рабочего стола Linux.

Большинство людей ошибаются, думая, что дизайн - это то, на что он похож. Люди думают, что это фанера - дизайнерам вручают эту коробку и говорят: «Сделайте так, чтобы она выглядела хорошо!» Мы не так думаем о дизайне. Дело не только в том, как это выглядит и на что похоже. Дизайн - это то, как это работает.

"Источник"

Давайте приступим.

Перетащите и отпустите

Ранний Macintosh

На ранних версиях Macintosh каждое приложение состояло из одного файла. Вот скриншот ранней разрабатываемой версии исходного системного программного обеспечения Macintosh начала 80-х:

Обратите внимание, что «Mac Stuff» - это содержимое загрузочной дискеты, которая содержит операционную систему (называемую «SYSTEM»), графический файловый менеджер (называемый «FINDER»), приложение (называемое «MacPaint») и несколько документы.

Чтобы «установить» приложение, вы просто скопировали его файл на другую дискету - готово! (В то время в Macintosh жестких дисков не было.)

С тех пор все только усложнялось - до наших дней. Давайте постараемся вернуть эту простоту!

NeXTSTEP и Mac OS X

В NeXTSTEP, предшественнике Mac OS X, а также сегодняшних macOS и iOS, приложения содержались в каталогах, которые заканчивались на .app - файловый менеджер рассматривал бы их как монолитные объекты, даже если на самом деле они содержали все файлы, составляющие приложение. . Это позволило легко перетаскивать приложения:

Когда NeXTSTEP превратился в Mac OS X, то же самое произошло и с этим удобным способом «установки» приложений перетаскиванием. Вы загружаете образ диска и перетаскиваете содержащееся в нем приложение (которое, как вы уже догадались, представляет собой gedit.app пакет) в папку «Applications»:

Обратите внимание, что это работает в macOS, но с настоящим GNOME в Linux… это не так просто!

Рабочий стол Linux сегодня

Возьмем, к примеру, GNU Emacs. На его домашней странице вы найдете ссылки для загрузки двоичных файлов для Windows и macOS. Тем не менее, пользователям Linux остается исходный код, для которого им необходимо загрузить и установить компилятор, настроить и скомпилировать исходный код.

Особенно со всем, что имеет в названии «GNU», «мы создаем только исходный код, мы не создаем двоичные файлы и не поддерживаем конечных пользователей» - частое, но опасное мнение. Фактически, одни из лучших прикладных проектов, которые создают наиболее удобное программное обеспечение, - это те, которые ежедневно взаимодействуют со своими конечными пользователями «Обычный Джо».

Да, и это не просто GNU Emacs, приложение, предназначенное для разработчиков. Возьмите GIMP, популярное приложение для творческих художников:

TL;DR:

Если вы используете Linux, «скомпилируйте самостоятельно» или «получите из своего дистрибутива». Если вы используете macOS, удачи. Если вы работаете в Windows, то загрузите EXE прямо здесь.

Это шаблон!

Для разработчика двоичные файлы без исходного кода бесполезны (это мысль Ричарда Столлмана). Но в равной степени для пользователя исходный код без двоичных файлов бесполезен (это мое заявление).

«Получите это из своего дистрибутива или скомпилируйте самостоятельно». Это распространенный ответ в мире Linux, но это совершенно неудовлетворительный ответ, потому что:

  • Дистрибутив обычно имеет устаревшую версию (особенно это касается дистрибутивов уровня Enterprise и Long Term Stable), и
  • «Обычный Джо» не знает и не должен знать, что такое компилятор, как установить необходимые зависимости времени сборки и скомпилировать сложную программу, такую ​​как GIMP.

К счастью, есть некоторые авторы приложений, которые заботятся о впечатлениях своих пользователей, например Krita, профессиональная бесплатная программа для рисования с открытым исходным кодом, созданная художниками, которые хотят видеть доступные инструменты для рисования для всех:

Как они это делают? Удивительно похоже на простую «установку» приложения перетаскиванием на Mac в 1984 году: вы просто загружаете один-единственный файл со страницы загрузки Krita, даете ему разрешение на выполнение и запускаете его.

Думайте о AppImage как о Linux-аналоге EXE для Windows и DMG для macOS - но лучше.

На этом история не заканчивается. Что, если появится новая версия, которую художник может захотеть протестировать, не отказываясь полностью от старой «рабочей лошадки» (от которой он ежедневно зависит в своей творческой работе)?

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

Боковое примечание: Практически все приложения, которые я использую (от веб-браузера и графических приложений до инструментов 3D-печати), являются кроссплатформенными приложениями, доступными для Windows, macOS и Linux. Так почему же люди до сих пор тратят свое время на написание приложений, которые работают только в Linux или, что еще хуже, только в одном дистрибутиве?

Дополнительное примечание: Ни одно из приложений, которые я использую, недоступно в самой последней версии в моем дистрибутиве (которая, как оказалось, является долгосрочной стабильной). К счастью, все они предоставляют AppImages (от веб-браузеров, графических приложений до 3D печатных инструментов). (Приглашаем вас проверить ссылки в предыдущем предложении.)

Авторы приложений должны стремиться к кроссплатформенности и предоставлять официально поддерживаемые двоичные версии для Linux, как они это делают для Windows и macOS. Они не должны делегировать задачу по доставке (и поддержке!) Программного обеспечения другим. Авторы приложений должны нацеливаться на самые старые, все еще поддерживаемые дистрибутивы Long Term Stable и Enterprise в качестве целей для запуска своих последних приложений. Для этого авторы приложений могут использовать такие инструменты, как AppImageKit и linuxdeployqt (полное раскрытие: автор является ведущим разработчиком).

Изящная обработка известных файлов

Вот что произойдет, если дважды щелкнуть приложение Linux, в котором не установлен бит «исполняемый файл»:

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

Первоначально я думал, что это просто оплошность и ее можно быстро исправить. Но, очевидно, это преднамеренно - похоже, не все в мире Linux для настольных ПК хотят максимально упростить задачу.

По словам кого-то, кто разговаривал с некоторыми разработчиками GNOME, включая сотрудника Red Hat Карлоса Сориано,

Весьма вероятно, что очень скоро Nautilus больше не сможет запускать программы двойным щелчком по ним, даже если у них ДЕЙСТВИТЕЛЬНО есть разрешение на выполнение. Это означает, что вопрос о запросе разрешения на выполнение является спорным, потому что программа все равно не запустится.

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

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

Настольные компьютеры Linux должны более корректно обрабатывать файлы распространенных форматов, например, исполняемые файлы ELF, загруженные из Интернета, в которых отсутствует исполняемый бит.

Файловые ассоциации

На Mac Launch Services содержит информацию о типах файлов и приложениях, которые следует использовать для их открытия в базе данных, хранящейся в

/private/var/folders/**/**/-Caches-/com.apple.LaunchServices-*.csstore

Но как пользователь вы никогда не увидите эти команды на Mac, поскольку все «просто работает» с перетаскиванием. В то время как их нет на рабочем столе Linux, где вам нужно бороться с текстовыми файлами, которые необходимо установить в дополнение к приложению, полностью разрушая парадигму перетаскивания для работы с приложениями. Стиль работы Linux по-прежнему происходит из тех времен, когда системы управлялись администратором, который использовал инструменты диспетчера пакетов, и с тех пор ни разу не изменился.

Посмотрите, насколько далеко продвинулся NeXT в 1989 году:

Если вы его пропустили: Прочтите текст о Каталоге приложений на скриншоте выше. Это намного более продвинутый, чем то, что есть у наших настольных компьютеров Linux сегодня, почти 30 лет спустя! (С appimaged мы теперь приносим что-то похожее на мир Linux, но это далеко от того, чтобы быть глубоко интегрированным в каждый рабочий стол Linux, и он все еще борется с теми же старыми статическими текстовыми файлами, с которыми должны жить современные рабочие столы Linux. .)

На рабочем столе Linux systemd или что-то в этом роде должно быть расширено для управления базой данных ассоциаций файлов, типов mime, значков и т. больше не приходится иметь дело с текстовыми файлами вручную. И, пожалуйста, сделайте его настоящим стандартом XDG, а не снова и снова: Red Hat против Canonical, GNOME против KDE, Gtk + против Qt.

Файловая система

Загадочные сокращенные каталоги

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

Тем не менее, в Linux мы придерживаемся стандарта иерархии файловой системы, который был разработан для всего, кроме удобного для человека. Все начинается с того факта, что жесткий диск с самого начала загроможден множеством каталогов, из-за чего компьютеру кажется, что он занят своими собственными сложными вещами, а не находится только там для пользователя. Такие имена, как /usr, которое, по мнению 99% моих друзей-не-компьютерщиков, означает пользователь и /etc, которое звучит как разные дополнительные вещи, обязательно отпугивают простые смертные. (Системные ресурсы Unix? И так далее? Отредактировать для настройки?)

Я должен признать, что Windows получила это право рано, имея один каталог C:\\Windows, который дает понять, что все вещи Windows находятся там. Почему у нас нет /Linux или /System, которые инкапсулируют все, кроме файлов пользователей?

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

hier (7) описание структуры файловой системы, существовавшее с момента выпуска Version 7 Unix (в 1979 г.)

Никто не думал о мобильных телефонах или даже о ноутбуках, когда это было изобретено в семидесятых годах. Это было разработано, когда еще были выделенные системные администраторы для всех систем.

Но почему мы не можем двигаться дальше?

Когда NeXT выпустила NeXTSTEP в 1989 году, они унаследовали часть иерархии файловой системы Unix, но решили скрыть ее от просмотра в обозревателе каталогов (предшественник Finder):

В NeXTSTEP 0.8 этого не было:

Даже Apple упустила возможность, хотя, когда они создавали Mac OS X с использованием частей пользовательского пространства FreeBSD, они, должно быть, были хорошо осведомлены о катастрофе UX, которую представляет собой иерархия файловой системы Unix. Что они с этим сделали?

Как объяснил выпускник Apple Вильфредо Санчес на конференции USENIX 2000:

По соглашениям BSD, которые столь же разумны, как и любые соглашения Unix, файлы располагаются в соответствии с функцией; вы можете поместить программу в /usr/bin, значки в /usr/share/photoshop, подключаемые модули в /usr/libexec и так далее. Хотя у этого подхода есть определенные преимущества, проблема с этим подходом заключается в том, что файлы разбросаны по диску, что несколько затрудняет установку и удаление программного обеспечения. Это можно решить, используя схему установщика пакетов с квитанциями и т. д., но это легко сломать, если пользователь использует другие установщики или обходит программу установки, развернув tar-архив.

Можно подумать, что они это исправили. Нет: Они решили оставить беспорядок как есть и просто скрыть его от глаз пользователей, сделав каталоги Unix невидимыми. Возможно, они спешили выпустить Mac OS X. В некоторых случаях лучше скрыть сложность, чем раскрыть ее, но все же лучше убрать сложность. А иногда нужны большие ходы.

Войдите в GoboLinux:

GoboLinux - это альтернативный дистрибутив Linux, который переопределяет всю иерархию файловой системы. В GoboLinux вам не нужна база данных пакетов, потому что
файловая система - это база данных: каждая программа находится в своем собственном каталоге,
например /Programs/Xorg-Lib/7.7 и /Programs/GCC/6.2 .0.

Источник: Домашняя страница GoboLinux

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

Мы должны согласовать иерархию файловой системы, которую люди могут понять интуитивно. GoboLinux здесь лидирует.

/ Usr merge, которого на самом деле не было

Затем есть дублирование между /usr/{bin,lib} и /{bin,lib}, которое во времена initramfs больше не имеет технической причины для существования. Почему мы все еще используем это, несмотря на попытки Харальда Хойера и Кей Сиверс покончить с этим?

Мы должны, наконец, закончить. Fedora здесь лидирует.

Иконки

Почему в бинарных файлах Linux до сих пор нет ресурсов значков? Не то чтобы никому и в голову не пришло ...

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

Клавиатура

На Mac, чтобы ввести '', вы нажимаете Shift-`три раза. В Linux - шесть раз. Если вы не переключите настройки клавиатуры на «нет мертвых клавиш». В этом случае вы больше не можете вводить é. Что полностью работает на Mac. Почему вообще есть опция «nodeadkeys»?

Для тех, кто любит приключения, попробуйте «Мертвые ключи от солнца» и «Мертвые могилы». Что за черт?!? «Остальные из нас» не понимают этой чуши. «Простые смертные» просто хотят, чтобы это работало.

Почему это не может просто работать, не требуя от пользователя выбора между вредителями и холерой (как на Mac)?

Неужели рабочий стол Linux обречен становиться все более сложным?

Скрывать сложность и приукрашивать ее (да, я смотрю на вас, GNOME Software), на мой взгляд, не решение. Я считаю, что делать вещи управляемыми людьми - это так.

Как мы можем вернуть простоту Mac 1984 года на современные настольные компьютеры Linux?

(РЕДАКТИРОВАТЬ январь 2019 :) Похоже, не все согласны с моими соображениями здесь и с твитами #LinuxUsability, что нормально, но они, по-видимому, также думают, что я тролль:

Эта статья является частью серии (часть 1, часть 2, часть 3, часть 4, часть 5, часть 6) о #LinuxUsability.

Пробоно - основатель и ведущий разработчик проекта AppImage. Скриншоты NeXTSTEP были сделаны на машине с Linux Live ISO с использованием Предыдущего эмулятора NeXTSTEP AppImage. Krita AppImage для кошек от David Revoy, использовано с разрешения художника.