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

Nikita nikita-mailings на rambler.ru
Пн Ноя 10 16:55:59 MSK 2014


Здравствуйте, Lex.

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

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

> в windows (control+c на файле, control+v в папке, куда нужно файл 
> вставить).

Я считаю, что копирование файлов через горячие клавиши или контекстное меню 
и перетаскивание их мышью в Windows - это две совершенно разные функции.
Поэтому нельзя говорить, что CTRL+C и CTRL+V - это какая-то особенно удобная 
реализация перетаскивания. Это именно дублирующая функция.
В Windows практически всё продублировано для клавиатурного управления, тогда 
как в Mac без мышки, trackpad или эмуляции мышки полноценно работать нельзя.

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

Только это сломано даже в некоторых родных меню, по-моему даже прямо в 
отдельных диалогах системных настроек.
Я сейчас загружен под Windows, так что мне лень делать reboot и искать 
конкретный пример, но неужели вы сами с этим не сталкивались? Это не такая 
уж и редкость даже в нативных приложениях. Особенно в офисном пакете.

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

Вы правы. Только если уж я вернулся к первому элементу, то они тут как тут.
К слову, отсутствие сквозной прокрутки в рамках цепочки навигации я тоже 
считаю проблемой как OS X, так и iOS.

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

Можно, но если это адекватно и полноценно работает в данном окне, тогда как 
это бывает поломано в Os X намного чаще, чем в Windows.

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

Ну это уже вкусовщина. Лично для меня почтовые клиенты - это вообще 
постоянная боль, в том числе и под Windows. Mail мне всё же не очень 
нравится, хотя я признаю, что это далеко не самое страшное в мире OS X.
Там бывают и совсем хорошие примеры. Тот же Skype, пожалуй, даже в чём-то 
лучше, чем под Windows. Ну про iTunes и говорить не приходится. :-)

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

Ну смотря что вы понимаете под "вспомогательными технологиями" в данном 
конкретном случае.
Если вы разрабатываете screenreader, то, наверное, да, универсальный 
accessibility API вам облегчит жизнь. Только вот сторонний screenreader под 
Mac OS X был давно, достаточно дорогой и убогий, а потом вообще умер, что и 
подтолкнуло Apple запилить VoiceOver, дабы не потерять контракты с 
образовательными учреждениями по Section 508. Продукт делался явно в спешке 
и во многом зрячими людьми без какого-либо тестирования на целевой 
аудитории.
Если же речь просто о работах по обеспечению доступности какого-то 
приложения, то не вижу существенной разницы.
Под Windows вы также просто из этого зоопарка выбираете одну технологию, 
например, UIA, после чего с её применением и пилите доступность. Поскольку 
чтецы сразу поддерживают несколько распространённых accessibility API, то 
поддержка одного из них будет достаточной.
Чисто абстрактно, да, это красивая история с одним общесистемным 
accessibility API, тогда как в Windows куча API, плюс отдельная стойка для 
костылей. Только вот если оценивать по конечному результату, то картина 
совсем другая.
Правда, ради справедливости стоит сказать, что многие проблемы VoiceOver не 
являются следствиями каких-то недостатков accessibility API, они чисто в 
голове разработчиков. Ну хотя бы систему клавиатурных команд уж можно было 
сделать лучше, а не это убожество.
Успехов. Никита. 



Подробная информация о списке рассылки Homeros