Этот последний довод, называемый еще обратной совместимостью (backward compatibility),[18] является самым слабым и может привести к абсурдным интерфейсам в виде собрания несовместимых методов. Однажды во время одного из длинных авиаперелетов нам пришлось приземлиться из-за плохой погоды. Пока мы ждали ее улучшения, я прошел в кабину пилотов, где смог изучить устройство автопилота. В нем имелось не менее пяти способов для ввода координат и столько же способов для включения большинства его функций. Когда я спросил пилота о причинах такой избыточности, она ответила, что автопилот сделан таким образом, чтобы функционально быть как можно более подобным автопилотам на других самолетах, на которых пилоты могли изучать данный прибор и тем самым избежать необходимости переучивания. Однако возникал вопрос относительно того, насколько такой подход можно считать правильным и насколько точно выполняется дублирование других автопилотов. Как она мне еще объяснила, пилоты должны изучать не только те небольшие, но, тем не менее, раздражающие различия между старой системой автопилота и ее эмуляцией на новой модели, но также и остальные четыре способа использования автопилота. То есть пилот обязан знать каждый аспект работы каждого элемента оборудования пилотской кабины. Более того, следует отметить, что многие новые функции автопилота имеются только в некоторых эмуляциях, и ранние модели автопилотов не содержат этих функций, т. к. и копируемые автопилоты их не имели.
Тактика гибридизации различных вариантов интерфейса, а вернее, сбрасывания всех методов подряд в одну кучу увеличивает время обучения, создает сложный в использовании автопилот и, как отметила упомянутый пилот, «создает путаницу в кабине и увеличивает вероятность ошибки». Хотя она и не сказала этого, но, вероятно, это также увеличивает стоимость и сложность приборов, руководств по их использованию и стоимость их обслуживания. То же касается любого интерфейса, который представляет собой совокупность разрозненных подходов, накопленных с течением времени, включая также Macintosh и Windows.
Для описания интерфейса, имеющего только один способ выполнения той или иной задачи, я использую термин монотонный, который все же не совсем удачен (см. приложение B, а также Alzofon и Raskin, 1985, с. 95). Монотонность – это вторая сторона отсутствия модальности. В интерфейсе, который не имеет режимов, данный жест пользователя может иметь один и только один результат: жест g всегда приводит к действию a. Тем не менее, вполне возможно, что другой жест h тоже может приводить к результату в виде действия a. Однако монотонный интерфейс допускает только один способ выполнения того или иного действия, т. е. в этом случае действие a может вызываться только лишь жестом g и более никаким другим. Интерфейс, который является полностью немодальным и монотонным, допускает только одно соответствие между причиной (командами) и следствием (действиями). Чем более монотонным является интерфейс с точки зрения пространства данной задачи, тем легче для пользователя сформировать автоматичность ее выполнения, которая, в конце концов, создается тем, что снимается необходимость выбирать способ достижения результата.
Другой причиной отсутствия монотонности в интерфейсе может быть нерешительность разработчиков. Я встречал случаи, когда проблема наличия каких-то двух и более вариантов, ни один из которых не имеет преимуществ по сравнению с другими, предусмотрительно «решалась» с помощью внедрения сразу всех этих вариантов. В пользу такого подхода обычно приводится довод о том, что пользователь в этом случае получает выбор, как будто бы пользователь является экспертом по интерфейсам и может сам выбрать самый эффективный вариант.
Общераспространенным мифом (более подробно о нем см. в разделе 3.6) является то, что интерфейсы для начинающих и опытных пользователей системы должны быть совершенно различными. Иногда разработчики говорят о том, что «необходимо найти компромисс между легкостью изучения интерфейса и общей скоростью работы системы» (Card, Moran, и Newell, 1983, с. 419). Это действительно может касаться каких-то особых моделей интерфейсов, но это необязательно имеет отношение ко всем интерфейсам вообще и в частности к тем видам интерфейса, которые обсуждаются в этой книге.
