[Homeros] Q: Терминал в MacOS

[Lex]

Здравствуйте, Никита!

Интересную дискуссию вы тут затеяли. Не могу не присоединиться! :-)

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

07.11.2014 14:18, Nikita пишет:
> последней группе я бы отнёс две основные вещи:
> Во-первых, сама Mac OS исторически была ориентирована на мышку. Если 
> верить официальной биографии, то Джобс даже испытывал реальную 
> неприязнь к курсорным клавишам на клавиатуре.
> Полноценная навигация с клавиатуры в системе невозможна. Даже самые 
> банальные вещи без мышки там не сделать.
> В итоге, VoiceOver вынужден обходить это двумя путями: либо повальной 
> навигацией по экранным контролам, либо прямой эмуляцией мышиных 
> действий. Для VoiceOver является вполне рядовой ситуацией фиксировать 
> точку, затем эмулировать на ней зажимание мышки, потом фиксировать 
> вторую точку, эмулировать перетаскивание мышки на неё и отпускание. 
> Это реально те действия, которые должен достаточно часто выполнять 
> слепой пользователь OS X.


Здесь вы, на мой взгляд, немного покривили душой, ведь в voiceover есть 
функция перетаскивания, которая, по задумке, лишает пользователя 
необходимости куда-либо двигать мышь (даже програмно). Другое дело, что 
работает она через раз, если работает, и поэтому пользователь бывает 
вынужден прибегать к приведению мыши, но этот сценарий больше подпадает 
под первый пункт - баги, которые оперативно не исправляются. В самой 
концепции перетаскивания, на мой взгляд, нет ничего крамольного, и она 
доступна пониманию незрячего человека. В правильной реализации drag&drop 
в скринридере такая операция ни чем не отличается от копирования файлов 
в windows (control+c на файле, control+v в папке, куда нужно файл вставить).

> В Windows и обычно в оконных интерфейсах для Linux клавиатурное 
> управление дублирует практически всё, а в OS X даже между кнопками 
> диалога не всегда возможно переместиться с клавиатуры.

Такие случаи, скорее, представляют из себя отдельные баги, а не 
концептуальную проблему в целом. Диалоговые окна в OS X документировано 
позволяют двигаться между элементами по tab / shift+tab.

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

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

> Во-вторых, VoiceOver использует последовательную линейную навигацию по 
> экранным контролам. То есть мы открываем окно и дальше начинаем 
> последовательно перемещаться по всем его дочерним объектам.
> Одна из самых слабых мест этой идеи заключается в том, что в этой 
> цепочке объектов очень много хлама.
> Например, в углу окна, как правило, есть три маленькие цветные 
> кнопочки для закрытия, сворачивания и восстановления размера. 
> Очевидно, что они нужны далеко не всегда, а скорей даже иногда.
> С точки зрения визуальной работы они и не бросаются в глаза, потому 
> что находятся в углу. Но вот для пользователя VoiceOver они-то 
> попадают в цепочку навигации.

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

> В итоге, цепочка последовательного перемещения по экранным элементам 
> для слепого пользователя всегда начинается с этих самых кнопок. Потом 
> туда ещё попадает иконка программы, а уже только после всего этого 
> начинается актуальное содержимое окна.

У нас с вами разные OS X? Или, возможно, за это отвечает какаято 
настройка voiceover?

> В визуальном интерфейсе можно сделать элементы более акцентированными 
> и менее акцентированными, за счёт размеров, цвета, расположения. А вот 
> в невизуальном они получаются все одинаковой степени акцентированости.
> При полном переборе всех объектов окна с VoiceOver для нас одинаковую 
> значимость получают и второстепенные и первостепенные элементы, что, 
> на мой взгляд, является возможно даже самой страшной ошибкой 
> разработчиков Apple.
> Да, с одной стороны, мы вроде как достаточно неплохо защищены от того, 
> что есть риск пропустить какой-то элемент окна, но за это мы 
> расплачиваемся катастрофической потерей производительности из-за 
> необходимости продираться через все второстепенные элементы, а также 
> просто статические объекты типа меток label или иконок. 

Почему бы пользователю не использовать tab для навигации только между 
интерактивными элементами окна?

> Именно поэтому лично в моих глазах Luwrain на OS X намного более 
> востребован, чем на Windows, потому что он сможет предложить реально 
> более производительную альтернативу даже базовым задачам, типа чтения 
> почты, тогда как на Windows в таких вещах преимущества Luwrain для 
> меня как раз не очевидны, потому что там не всё так запущено, как на 
> OS X.

Не смотря на то, что я в целом согласен, что с графическим интерфейсом 
OS X порой управляться менее продуктивно, посравнению с Windows, мне 
кажется, что почтовое приложение mail.app здесь какраз демонстрирует 
исключение из правил.

> Есть и много других проблем реализации accessibility OS X, но это уже 
> отдельный и очень долгий разговор. Самые фундаментальные проблемы, на 
> мой взгляд, именно вот в том, что я описал.


Интересно было бы услышать ваше мнение и по поводу других, не изложенных 
вами проблем, а так же хотябы пару слов о плюсах, ведь они тоже 
присутствуют. Для разработчика вспомогательных технологий accessibility 
API в OS X - это как глоток свежего воздуха после зоопарка Windows.


Lex