Наткнулся тут на одну любопытную штуку.
В своё время я зарегистрировался на careers.stackoverflow.com. И вот недавно решил ради любопытства пощупать этот сервис, дабы сравнить оный с нашими любимыми Работа.ру и т.п. Нашёл одну вакансию, предлагаемую известной (в Mac-мире) компанией CulturedCode. И очень мне понравилась их идея поиска соискателей.
Короче, ни слова о резюме. Ни слова об образовании. Ни слова о требуемом опыте работы. Никаких длиииинных списков обязательных умений и навыков.
Вместо этого они предлагают тебе скачать один их элементарный проект для OS X (или для iOS), который специально написан чрезвычайно примитивно (но при этом работает). И твоя цель состоит в том, чтобы улучшить этот проект, и отослать обратно им. Причём как именно улучшить, не уточняется... 
Согласитесь, здорово придумано. Лучше любых резюме и рекомендаций. Твой реальный опыт будет виден как на ладони.
Признаюсь вам честно: о нативности я думал много. И вот до чего додумался, тем и хочу поделиться.
Я выделил для себя два аспекта нативности графического интерфейса: нативность визуальная и нативность содержательная. Первый аспект связан с формой, а второй - с содержанием. Поясню...
Нативность визуальная относится к родному (для конкретной ОС) отображению графических элементов интерфейса. Например, в Qt 4.8 drag-n-drop курсор выглядит в OS X как кривая чёрно-белая стрелочка, загнутая направо. В то время как родным для OS X drag-n-drop курсором является прямая стрелка с зелёным плюсиком. Или, скажем, вертикальные скроллеры: в OS X Lion/Mountain Lion они должны быть полупрозрачными и автоматически скрывающимися, в то время как в Linux они постоянно присутствующие, да ещё и с дополнительными управляющими кнопками вверху и внизу. Вот это то, что я называю нативностью визуальной. Разумеется, эта нативность даже не обсуждается, она просто обязана присутствовать. К счастью, в Qt 5 с визуальной нативностью проблем нет. Ни в OS X, ни в Linux.
А вот с нативностью содержательной дело обстоит несколько иначе. Эта нативность основывается на так называемых HIG (Human Interface Guidelines). Для каждой из основных ОС написанные свои собственные HIG:
Естественно, между этими HIG-ами наличиствуют весьма весомые различия. И вот тут мы подходим к самому интересному.
Канонически считается, что если я разрабатываю программу для Linux, то при разработке графического интерфейса я обязан руководствоваться Gnome/KDE HIG, если же разрабатываю для OS X - то обязан руководствоваться OS X HIG, и так далее. А вот теперь я озвучу крамольную, прямо-таки еретическую мысль - это неверно.
Но неверно не в том смысле, что все эти HIG плохие. Вовсе нет! Напротив, многие принципы, изложенные в этих руководствах, великолепны. Говоря "неверно", я имел в виду, что при разработке графического интерфейса я должен руководствоваться не только HIG, но и чем-то другим. (Прошу запомнить эти слова, я поясню их ниже...)
Начну опять-таки с примеров. Вот, скажем, меню. Артём сказал о нём так:
... ожидаю состав главного меню вида File, Edit, View, ..., Help. Да и длинные названия меню, да еще и с пробелами не особо как-то...
Вероятно, мои слова удивят Артёма, но меню Ревизора не является нативным ни для Linux, ни для OS X. Подчеркну: содержание этого меню, а не его отображение. Отображение как раз полностью нативно, вплоть до выравнивания шорткатов и вида кликабельного пункта. А вот содержание - нет. Ибо как линуксовый, так и маковский HIG предписывают именно то содержание меню, о котором был упомянуто выше: File, Edit, View, Window...
Почему же я сознательно отошёл от этого стандарта? Потому что, во-первых, он не всегда применим, а во-вторых, он не всегда хорош.
Уже слышу вопрос: "Как это не всегда хорош? Ты что, Денис, считаешь себя умнее составителей этих HIG?!!" Поспешу ответить на этот вопрос. Помните, выше я сказал, что поясню свои слова:
... при разработке графического интерфейса я должен руководствоваться не только HIG, но и чем-то другим...
Так вот этим другим являются две книги:
Эти книги, особенно вторая, являются глубокими исследованиями в области взаимодействия человека и компьютера. Выводы, сделанные авторами этих книг, основаны на психологии и на специфике восприятия человеком визуальной информации, поэтому они не зависят ни от модных IT-трендов, ни от операционной системы, ни от сегмента конкретного программного продукта. Так вот должен сказать, что многие из принципов, заложенных во все современные HIG, являются абсолютно неверными, и их существование (по сей день) обусловлено лишь привычкой, а отнюдь не здравым смыслом или удобством.
Итак, вернёмся к меню. Вот скажем, меню File. Существование этого меню воспринимается чуть ли не как аксиома бытия, в то время как для большинства программ это меню не только не нужно, но и вредно.
В частности, для Style Revisor. Допустим, я добавлю меню File. Но что же будет означать это самое "Файл"? Речь идёт о какой-то работе с языковым плагином (ибо он является файлом)? Или о работе со стилевым расширением (ибо он также является файлом)? Или, может, о добавлении/удалении/изменении путей к файлам пользователя, которые должны быть отформатированы? Совершенно непонятно. То есть мы имеем дело с меню, название которого введёт пользователя в состояние сомнения.
На самом деле, меню File плохо подходит даже для простейшего редактора уровня Windows Notepad. Казалось бы, почему? Ведь там именно с (текстовыми) файлами и вся работа! А потому, что само понятие "файл" стало слишком обобщённым. И текст, и .exe-шник, и картинка, и фильм, и музыка - всё это файл. Понятие "файл" абсолютно обезличено, оно говорит лишь о коробке с байтами, сохранёнными в определённом формате.
Казалось бы, в чём проблема? Ну и пусть в Notepade будет меню File, ассоциированное с текстом, в каком-нибудь VLC - с музыкой или видео, а в Photoshop - с PSD-макетом! Однако возникает резонный вопрос: зачем тогда обобщать всё это безликим словом "File"? Пусть тогда будет "Image", и "Song", и "Video", и "Document". Ведь само понятие "файл" аппелирует лишь к (наиболее распространённому) техническому аспекту сохранения информации. В то время как понятие "Image" мгновенно вызывает в уме пользователя чётко определённую ассоциацию.
Вот, скажем, используемый мною графический редактор Pixelmator. В нём есть каноническое меню File, в котором присуствует не менее канонический пункт New...
Во-первых, почему File? Гораздо лучшим словом будет Image, потому что, запустив графический редактор, мы работаем не с файлами, а с изображениями. Да, каждое изображение является файлом, но это сугубо технический аспект, о котором пользователь вовсе не обязан думать.
Далее, File → New.... Что это значит, друзья? Что такое "New"? Да, мы (как опытные пользователи различных программ) уже привыкли к тому, что речь идёт о "Создании Нового файла". Но на самом деле фраза File → New... не такая уж и понятная. Гораздо более понятной является фраза Image → Create... Почему? Потому что слово "Create" - это глагол, а слово "New" - нет.
Общий вред меню File заключается в том, что оно постоянно вынуждает пользователя думать категориями файловой системы, а не категориями нужного ему (пользователю) конкретного результата. "Новый файл" или "Создать изображение" - хоть убейте, но второе значительно лучше.
Фактически, меню File - это пережиток прошлого. Однако все известные мне HIG предписывают наличие в программе меню File. И это неверно.
Теперь перейдём к не менее канонизированному меню Edit. Его тоже пихают везде и всюду, несмотря на то, что оно опять-таки подходит далеко не везде.
Вот, скажем, почтовая программа. Я использую идущую с OS X почтовую программу, которая так и называется Mail (кто бы мог подумать...). В ней тоже есть меню Edit. Захожу в него и вижу пункт Copy. Хм... Копировать... А, позвольте, копировать что? Текущее письмо? Или все письма в текущей папке? Или вообще все письма? А может, адресную книгу? Абсолютно непонятно. Более того, при нажатии на сей пункт программа зависла. Точнее, она начала-таки что-то копировать, но судя по всему это было нечто весьма большое, так что пришлось принудительно завершить программу.
Это наглядный пример неясности меню. Допустим, я вставлю в Style Revisor меню Edit. То есть "Редактировать". А что редактировать-то? Вид текущей структуры языка? Список путей к ревизируемым файлам пользователя? А может, редактировать некие настройки? Опять-таки неясно. Однако если пользователь видит пункт Look and feel, то, поскольку есть лишь один элемент интерфейса с точно таким же именем, он (пользователь) мгновенно понимает, к чему относится данное меню.
В большинстве случаев меню Edit ставит перед пользователем большой вопрос, потому что понятие "Редактировать" слишком расплывчато.
Все известные мне HIG предписывают наличие в программе меню Edit. И это неверно.
Теперь порассуждаем об именах пунктов меню. Все известные мне HIG предписывают, что имена эти должны быть короткими. Не спорю, в большинстве случаев вполне достаточно одного-единственного слова. Однако далеко не во всех.
Самый длинное имя пункта меню в Style Revisor звучит так: How to change this structure. Пять (!!) слов. Многие сказали бы, что это очень и очень плохо! Более того, я бы и сам раньше так сказал.
А вот теперь задумаемся. Почему имя пункта меню должно быть коротким? Мы что, экономим пиксели? Чушь. Это просто привычка из времён Windows 95. А здравый смысл говорит нам, что имя должно быть понятным. И если для того, чтобы быть понятным, оно должно состоять из четырёх слов - значит оно должно состоять из четырёх слов. Точка.
Однако некоторые HIG предписывают максимум 3 слова в имени любого пункта меню. И это неверно.
Теперь перейдём к кнопкам. Кнопки вездесущи, они есть везде и всегда. И в каждом из HIG есть довольно-таки большой раздел, посвящённый тому, какой именно дожна быть кнопка, чтобы быть самой правильной в мире.
Например, иконки на кнопках. Некоторые люди предлагали мне добавить в кнопки Style Revisor красивые иконки, мол, это "оживит интерфейс". А учитывая, что сейчас есть множество очень красивых наборов иконок (в том числе и бесплатных), проблема сия решается очень быстро. Однако я, взвесив все "за" и "против", категорически отказался от этой мысли.
Вот кнопки модального диалога, правильные с точки зрения Gnome HIG:
Да, выглядит симпатично. А вот теперь вопрос: если бы я убрал иконки с этих кнопок, оставив лишь текстовые метки, стало бы назначение этих кнопок менее понятным? Нет, не стало бы. Но если без этих иконок назначение этих кнопок осталось бы столько же понятным - тогда возникает вопрос, а зачем вообще нужны эти иконки? А они и не нужны вовсе. Они создают лишь "визуальных шум". Однако это нативно с точки зрения Gnome HIG.
Другой пример. Вот кусочек диалога с прогресс-баром, нативного для OS X Lion:
Видите, справа от прогресс-бара кружочек с крестиком? Это кнопочка остановки. Однако я в Style Revisor сознательно отошёл от этого стандарта и заменил оную кнопочку на обычную кнопку с текстовой меткой Stop. Почему? Потому что крестик гораздо больше ассоциируется с действием "закрыть/удалить" (например, вкладку в браузере), нежели с действием "остановить". Однако такая кнопочка с крестиком нативна с точки зрения OS X HIG.
Большинство HIG предписывают, что у модального диалога умолчальной (то есть нажимаемой по факту нажатия на клавишу Enter) кнопкой должна быть кнопка OK. О нелепости кноки с таким именем я уже писал ранее, однако повторю: наличие оной полностью нативно с точки большинства HIG. И это неверно.
Итог прост как валенок: содержательная нативность, предписывемая теми или иными HIG, не всегда применима и далеко не всегда хороша.
Да, я уже слышу возражение: "Всё это хорошо, Денис, но пользователи уже давно привыкли к меню File или Edit, равно как и к кнопке OK и т.п. вещам. А мы как разработчики интерфейса, направленного на удовлетворение нужд пользователя, обязаны следовать устоявшимся привычкам."
Привычки, конечно, учитывать нужно. Но далеко не все, ибо наряду с хорошими есть также привычки плохие. А плохие привычки не учитывать нужно, а изживать их.
Не согласны? Тогда взглянем на те абсурдности, которые присутствуют в некоторых программах из-за стремления к "привычности".
Skype. Почти все мы пользуемся этой программой. А вы когда-нибудь заглядывали в её меню? Если нет, давайте заглянем вместе.
Меню Файл → Пополнить счёт... Э-э, чего? Вообще-то пополнение счёта является финансовой операцией, которая никак, ну абсолютно никак не ассоциируется со словом "Файл". Абсурд.
Меню Файл → Выйти. Простите, выйти откуда? Из файла? На самом деле речь идёт о выходе из текущего аккаунта, но это опять-таки никак не ассоциируется со словом "Файл". Абсурд.
Меню Правка → Поиск пользователей и сообщений. Ну, поиск - дело понятно, но как это связано с понятием "Правка"? Никак. Опять абсурд.
Упомянутая выше Mail. Заглянем в её меню.
Меню Окно → Проверка подключения. Данный пункт проверяет поключения с почтовыми серверами имеющихся учётных записей, но как это связано с понятием "Окно"? Совершенно никак. Ещё один абсурд.
Google Chrome. Этот браузер тоже несовершенен.
Меню Файл → Новая вкладка. Простите, как открытие новой вкладки связано со словом "Файл"? Никак. Ещё один абсурд.
Все эти нелепые случаи явились результатом того, что авторы вышеупомянутых приложений стремились сделать "привычный интерфейс". Они следовали содержательной нативности тех или иных HIG, не особо задумываясь о том, как всё это будет выглядеть в глазах конечного пользователя.
Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer
