15 мая 2011 в 00:07

Дизайн контекстных меню tutorial

Представляю вашему вниманию перевод статьи под названием "Context Menu design" от Hagan Rivers. Перевели в компании UXDepot специально для пользователей Хабрахабра с одобрением компании Two Rivers Consulting Corporation.


Что такое контекстное меню?


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



Контекстное меню сообщения в Apple Mail (слева) и Windows Mail (справа).




Стоит ли использовать контекстные меню?


Контекстные меню подходят не для всех приложений. Я настоятельно не советую использовать их для интернет-магазинов, как, например, Lands End или Amazon. Я также не советую использовать контекстные меню для потребительских сайтов, не требующих сложных взаимодействий: банковских сайтов, сайтов знакомств, даже для Facebook.

Cчитаю, что контекстные меню наиболее эффективны в серьезных корпоративных приложениях, которые пользователь использует часто и в которых хорошо разбирается. В таких приложениях контекстные меню чрезвычайно полезны. Почему?

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

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

Однако даже в таких приложениях вы можете заметить что многие пользователи вообще не пользуются контекстным меню. В большинстве своем это та же группа пользователей, которая также не использует горячие клавиши. Поэтому следует смириться с тем, что не все ваши пользователи будут пользоваться контекстными меню, и создавать свой продукт исходя из этих соображений (об этом дальше).

Итак, если вы твердо решили что без контекстного меню вам не обойтись, то давайте подумаем как нам правильно его сделать.




Как вызывается контекстное меню?


Традиционно в Windows-приложениях контекстное меню вызывается наведением курсора на объект и кликом по нему правой кнопкой мыши. В MacOS-системах пользователь также может использовать правую кнопку мыши или же может кликнуть по объекту левой кнопкой, зажав при этом кнопку Control. Обычно это действие называется просто «правый клик».

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

Небольшое замечание: В мире устройств с сенсорным экранами (таких, к примеру, как iPad), у нас нет курсора, который можно навести на объект. В таком случае можно быстро назвать три возможных способа указывать на объект:
  • Показывать контекстное меню сразу после нажатия на объект (однако это может раздражать)
  • Показывать контекстное меню после нажатия пальцем и удержания нажатия на долю секунды (в таком случае всегда возникает проблема неочевидности, но это лучше чем первый вариант)
  • Добавление контрола, который вызывает контекстное меню (возможно, это лучший путь решения проблемы — о нем рассказано ниже).




Контекстное меню для графического файла в MacOS X (слева) и Windows Vista (справа).




Добавление элемента для вызова контекстного меню


В некоторых веб-приложениях есть элемент интерфейса, нажатие по которому вызывает контекстное меню. Он обычно называется «иконкой меню» — это иконка, изображающая стрелочку вниз, которая находится прямо возле названия (или изображения) объекта.

При использовании такого контрола пользователь может нажать левой или правой кнопкой мыши, чтобы открыть контекстное меню (никогда не используйте наведение мышкой в качестве способа открытия меню). Худшее, что вы можете сделать в данном случае это не показывать меню только потому, что пользователь нажал по контролу не правой кнопкой мышки, а левой.



Контрол меню, показывающий что в данном случае меню доступно.

Если вы собираетесь использовать контрол меню, то стоит сделать так, чтобы нажатие на него отличалось от нажатия на сам объект. В примере выше если пользователь кликает где-нибудь в строке Ahmed Hassain, то он просто выделяет всю строку Ahmed Hassain, однако если он кликает по иконке меню для этой строки, то он получает контекстное меню (и строка не выделяется).
Кроме того, пользователь также должен иметь возможность просто кликнуть правой кнопкой в любом месте строки, чтобы открыть контекстное меню — без необходимости нажимать на иконку.

Стоит ли использовать контрол меню? Оно отлично решает одну из больших проблем с контекстными меню: многие пользователи не знают, что контекстное меню доступно. В веб-приложениях пользователи часто предполагают что контекстного меню нет (его иногда нет даже в десктопных приложениях).

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

Большая проблема с иконкой меню состоит в том, что она часто повторяется на экране и засоряет его. Решить эту проблему можно, показывая иконку только тогда, когда курсор мыши наводится на объект.



Контрол меню, который появляется при наведении курсором мыши.

Еще одна проблема контрола меню заключается в том, что его сложно прикрепить к некоторым объектам. Возьмем, к примеру, контекстное меню для тулбара: тулбар сам по себе является большим элементом интерфейса, и не совсем понятно, куда в нем ставить контрол меню, так чтобы было понятно, что здесь есть меню. Поэтому, контролы меню работают далеко не везде.




Что должно содержаться в контекстном меню?


Контекстное меню должно содержать команды, которые относятся к выделенному элементу. Это означает что оно может содержать команды из строки меню или панели инструментов, которые можно применить к выделенному элементу.

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

Вот, к примеру, три контекстных меню для выделенного фрагмента текста: в Dreamweaver, Microsoft Word и Apple Pages. Меню Dreamweaver пытается быть похожим на швейцарский складной ножик и предлагает все возможные команды в одном контекстном меню. Из-за этого оно получается настолько большим, с кучей вложенных списков, что им становится трудно пользоваться. Лично я избегаю вызывать контекстное меню в Dreamweaver.

В нем наиболее часто используемые функции (например «Копировать» или «Вставить») располагаются ближе к концу списка. В Word и Pages наоборот, часто используемые команды выносятся наверх списка, а команды, содержащие вложенные списки — в конец. Они также отобрали для меню только самые важные функции, и лучше организовали их.

Если вы хотите сделать свое контекстное меню удобнее, оставьте в нем только 60% самых важных команд вместо всех 100%. Если в одном меню попытаться уместить все важные команды, то это не приведет ни к чему хорошему — размеры меню увеличатся, а удобство его использования и скорость работы с ним наоборот, снизится.
Помните: главная причина, по которой контекстные меню вообще используются — это возможность сэкономить время пользователя.



Контекстные меню в Dreamweaver, Microsoft Word и Apple Pages

Контекстное меню не должно содержать команды, не относящиеся к выделенному объекту (такие, например, как «Обновить страницу»). Концентрируйтесь на тех командах, которые были бы полезны для работы с тем объектом, на который наводит пользователь.

Когда возможно, группируйте команды в блоки от 1 до 6 штук в каждом. Отделяйте блоки линиями. Наиболее часто используемые команды следует выносить наверх списка, наименее часто используемые — убирать вниз. Если команда используется особенно редко, то, возможно ей не место в контекстном меню.

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

Помимо этого вы можете использовать нестандартные элементы меню.
Например, вместе с контекстным меню в Microsoft Word 2007 открывается плавающая палитра, а в контекстном меню файла в Mac OS есть специальные цветные кнопки выбора цвета ярлыка. Только потому что мы говорим «меню», не значит что оно должно быть ограничено только текстом.



Контекстное меню может быть больше чем просто список команд

В контекстном меню не могут содержаться уникальные команды, свойственные только для него. Другими словами, любая команда контекстного меню должна быть доступна также другими способами: на панели инструментов, строке меню или в любом другом месте на экране. Помните, что большая часть пользователей скорее всего ни разу не откроет контекстного меню в вашем приложении. А это означает, что они не увидят команду, которая присутствует только там.

Обычно я помещаю «команду по умолчанию» первой в контекстном меню. Это та команда, которая совершится при двойном клике на объекте (например, команда Open в контекстном меню файла). Если у объекта нет команды по умолчанию, концентрируйтесь на самых используемых командах.

Вы можете использовать название объекта в контекстном меню для того, чтобы сделать команды понятнее. Например, вместо названия команды «Открыть» вы можете использовать словосочетание «Открыть Скриншот.png». При использовании этого приема бывает сложно найти золотую середину — нужно сделать меню достаточно самоочевидным, но не слишком многословным. Меню в Mac OS содержит название объекта в одних командах, и не содержит в других.

В своих контекстных меню я не использую иконки. Честно говоря, я вообще не использую их в своих приложениях — по моему мнению они засоряют интерфейс и не несут особой пользы (примечание переводчиков — о_О). Однако это только мое мнение, а вы решайте сами.
В контекстных меню многих приложений нет указания горячих клавиш возле команд. Думаю, что это сделано затем, чтобы меню казалось легче. Здесь так же решать вам.




Что насчет нескольких выделенных объектов?


Обычно контекстное меню вызывается для одного выделенного объекта, но что делать, если пользователь выбрал несколько объектов, и потом открывает контекстное меню? Давайте рассмотрим несколько примеров.

Представим что у нас есть шесть объектов: четыре папки (А, В, С, D) и два графических файла (Е и F).



Папки и файлы в Windows




Пример 1


Пользователь выбирает папки A, B, C, а затем вызывает контекстное меню, находясь мышкой на папке D (важно: папка D изначально не была выбрана). В таком случае для объектов А, В, и С необходимо отменить выделение и открыть контекстное меню только на выделенном D.






Пример 2


Если пользователь выделяет А, В и С, а затем вызывает контекстное меню, находясь мышкой на С, то сначала мы должны определить, являются ли А, В и С объектами одного типа. Говоря иначе, у всех этих объектов одинаковое меню? Если да, то все просто: сделайте, чтобы все команды в этом меню применялись ко всем выделенным объектам.

Если, к примеру, это будет команда «Открыть», то она должна открыть все три объекта. Если есть команда, которую нельзя применить больше чем к одному объекту, то нужно сделать команду неактивной, не убирая ее из меню.



Ранее я говорил о том, что мы можем написать «Открыть Скриншот.png» вместо «Открыть» для того, чтобы помочь пользователю понять, к чему команда применяется. Точно так же в нашем случае мы можем написать «Открыть 3 объекта» — это поможет понять, что действие применяется ко всем выделенным объектов. В нашем случае контекстное меню может выглядеть следующим образом:
  • Открыть 3 объекта
  • Удалить 3 объекта
  • Копировать 3 объекта
Подобный подход использует Apple в Mac OS X, однако она не использует такой подход повсеместно. Я не могу понять почему в контекстном меню встречается словосочетание «Сжать 3 файла», но нигде не говорится «Открыть 3 файла». Странно.




Пример 3


А теперь давайте рассмотрим случай, когда пользователь выбирает несколько разнородных объектов, например папки А, B и графический файл Е. Как вы понимаете, контекстные меню для папок и графических файлов совершенно разные.
Это так называемое смешанное выделение. В примере ниже вы можете увидеть контекстное меню для папки (слева) и для изображения (справа) — они сильно различаются.



Контекстное меню Windows для папок (слева) и графических файлов (справа)

Что же нам делать в случае смешанного выделения, какое контекстное меню использовать? Самый распространенный ответ — показывать контекстное меню для того объекта, на который пользователь навел курсор мыши.




Используйте контекстное меню объекта, на который наведен курсор мыши


Например, пользователь выбирает А, В и E смешанным выделением и вызывает контекстное меню на Е. Контекстное меню, которое вы видите это контекстное меню для Е (вы всегда будете видеть контекстное меню для объекта, на котором расположен курсор мыши).

Слева: Выделена папка А, показывается контекстное меню для папки.
В центре: Выделено изображение Е, показывается контекстное меню для графического файла Е.
Справа: Выделаны две папки (А и В) и графический файл Е, показывается контекстное меню для файла Е.



Контекстное меню в случае смешанного выделения

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

С другой стороны, если пользователь вызовет меню для E и выберет команду, которая не может примениться к A и B, она применится только к E. Если пользователь выберет команду «Экспорт», и она может примениться только к E, только E будет экспортировано.

На двух рисунках ниже показано одно и то же выделение: A, B и E. На рисунке слева открыто контекстное меню на B, и мы видим меню для папок. На рисунке справа у нас выделены те же объекты, но меню открыто на E, и поэтому мы видим меню для файла изображения.



Вы будете удивлены — такой подход используется в подавляющем большинстве приложений, которыми вы регулярно пользуетесь. Задумайтесь об этом: если вы выберете команду «Удалить», то ожидаете, что удалятся все три объекта.
Это одна из тех вещей, которые звучат сложно, но работают для пользователей.

Проблема с таким подходом состоит в том, что он не всегда предсказуем. Выбирая «Экспорт» вы не знаете точно, какие из объектов будут экспортированы. Вы можете быть уверены в принципах работы такого подхода только в тех приложениях, которые уже хорошо знаете.
Для того, чтобы избавиться от такого несоответствия, я еще раз могу предложить использовать понятное название команд, например:
  • Удалить 3 файла
  • Экспортировать Скриншот.png
Думаю это сильно улучшит и упростит ситуацию.

Этот подход имеет одну сложность в реализации — вам нужно пройтись по всем командам во всех контекстных меню и подумать, какие команды можно применить в смешанных выделениях, а какие нельзя. Чем более похожи контекстные меню для разных объектов, тем проще будет эта задача для вас. В Mac OS X контекстные меню для папок и файлов почти одинаковые, что сильно упростило жизнь Apple.



Смешанное выделение и контекстные меню в OS X

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




А что если сбрасывать выделение?


Если пользователь выделяет несколько объектов (например, А, В и Е), а затем вызывает контекстное меню на любом из объектов, выделение сбрасывается. Выделяется объект, на котором пользователь вызвал меню, и меню применяется только для этого объекта.

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




А что насчет построения нового меню?


Другим решением проблемы может стать создание нового контекстного меню, содержащего только команды, подходящие одновременно для всех выделенных объектов.

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

И что хуже всего — такой подход плох для самих пользователей. Это нестандартное решение и оно отторгается людьми. Пользователь в меню опирается на позиционную память (определенные паттерны, которые наш мозг формирует для облегчения сканирования интерфейса), то есть он помнит ГДЕ в меню находятся команды.

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




Выводы


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

Если вы не уверены — проведите несколько юзабилити-тестов и убедитесь, что пользователи хотя бы пытаются их открыть. Если тестеры выполняют повторяющиеся рутинные задачи и ни один из них ни разу не открыл контекстного меню, оно не нужно.

Цель создания контекстного меню — экономия времени. Создавайте их такими, чтобы они действительно экономили время. Делайте их короткими и хорошо организованными.
Подумайте над путями совершенствования дизайна контекстного меню.

Я упоминала несколько идей: добавление контрола меню, который появляется при наведении мыши на объект; указание в меню, какие объекты затронет та или иная команда. Я уверена, возможностей для развития очень много. Не стесняйтесь брать за основу эту «стандартную» формулу и усовершенствовать ее.

PS от переводчиков: Надеюсь, вам понравилась статья. Мы будем рады, если вы укажете нам на ошибки в переводе, чтобы мы могли их оперативно исправить. Пишите мне в личку, пожалуйста :)
Автор: @DezmASter
UXDepot
рейтинг 32,17
Компания прекратила активность на сайте

Комментарии (70)

  • +3
    Интересно, если речь идет о веб-приложении, то какое контекстное меню откроется при правом клике, меню браузера или меню самого приложения?
    • +2
      Зависит от контекста и ситуации. Скажем, Google Docs открывает своё, однако в большинстве веб-приложений оно не пригодилось бы :)
      • +2
        А как интересно браузер с приложением распределяют какое контекстное меню показывать? Простите за дилетантский вопрос, но разве контекстное меню браузера не «главнее» контекстного меню любого приложения?
        • +5
          Приложение может повесить свой обработчик на правый клик, замещающий стандартный. Некоторые браузеры в настройках позволяют в настройках игнорировать такой обработчик и тогда всегда будет стандартное, чтобы разработчик не хотел.
          • +1
            Спасибо.
          • +1
            Еще большой вопрос — какое меню правильно выводить. Мне кажется, что если пользователь работает с браузером, то и меню должно быть от браузера. И незачем его на что-то другое заменять.
            • +2
              Согласен с вами. Жутко не нравится, когда это меню подменяется. Например, мне хочется выделить текст и выбрать в контекстном меню моего браузера пункт меню «Search Google for 'the text'», а вместо нужного мне меню иногда вылезает что-то другое.
            • +6
              Имхо, контекстные меню в веб-приложениях стоит делать, если они типа «эмуляторов» сложных десктопных приложений, в которых пользователь действительно долго работает, а не «серфит».
              • 0
                Если приложение занимает все рабочее пространство пользователя, больше ничем он не пользуется, открыть ничего в соседней вкладке не может — тогда согласен (при условии, что функции стандартного меню браузера пользователю в процессе работы не нужны).

                Если же браузер используется и для других задач, то зачем предлагать пользователю что-то работающее по нестандартным правилам?
                • +4
                  Каждый разработчик сам отвечает на этот вопрос. Хорошо, если ответ не «я узнал, что у себя в блоге можно сделать своё контекстное меню» :)

                  Вот я использую гуглдоки периодически, в браузере меньше десятка вкладок открытых не бывает, но вопроса зачем в гуглодоках они сделали меню у меня не возникает. Возникает почему в гмыле не сделали?

                  Но вообще да, для изменения существующего интерфейса нужные веские причины. Причём если в десктопных приложениях контекстное меню (или что-то другое) можно сделать почти везде, т. к. оно не изменяет интерфейс, а расширяет его, то в браузерах это именно изменение, а ещё точнее замена и решать вопрос делать её или нет надо не из принципа «а почему бы нет, раз есть такая возможность».
                  • +1
                    < решать вопрос делать её или нет надо не из принципа «а почему бы нет, раз есть такая возможность» >

                    Полностью согласен! Примерно так и говорю программерам, когда предлагают очередную прикольную «штуку» наворотить, потому что она прикольная и в модном фреймворке есть.
          • 0
            чтобы разработчик не хотел.
            <sarcasm>И что, правда помогает, перестают хотеть?</sarcasm>
            «Что бы разработчик ни хотел».
            • +1
              Посыпаю голову пеплом… Не стал вчитываться и искать потенциально «дырявые» места перед отправкой.

        • +2
          Помимо того, что сказали выше. В админке битрикса реализовано неплохое решение: на некоторых элементах вызывается свое контекстное меню, но можно открыть контекстное меню браузера зажав Ctrl при его вызове. Либо в настройках можно переключить на обратный режим, когда контекстное меню CMS будет открываться при Ctrl+«правый клик».
    • +14
      Только бы не флэша! Как оно меня бесит.
      • +6

        Оказывается у флеша также разные контекстные меню 0_о
      • +13
        А мне оно помогает определить является ли нужный мне объект флешем.
        • +6
          Мне тоже. Определить и матюгнуться.
  • –9
    Небольшой оффтопик—насколько же лучше Windows смотрятся контекстные меню в MacOS! Причина очевидна: текст на Маке занимает бОльшую часть меню, в сравнении с Windows; больше и разборчивей шрифт, меньше отвлекающих элементов. На винде много места «гуляет». Не увидев эти две картинки вместе, ранее этого не осознавал.
    • +19
      Позвольте с вами не согласиться. Разумно оставленное пространство позволяет быстрее читать команды и упрощает позиционирование курсора. Почему-то многие дизайнеры боятся пустого пространства, а совершенно зря.

      В Mac OS контекстное меню исторически используется крайне ограничено (кнопка то на мышке одна была много лет), поэтому до таких тонкостей оно и не вылизано.

    • +15
      Небольшой оффтопик к оффтопику — насколько же лучше MacOS смотрятся контекстные меню в Windows! Причина очевидна: текст на Винде занимает небольшую часть меню, в сравнении с MacOS; отличные иконки и шрифт, которые помогают цепляться глазу и не перечитывать заново каждый раз текст. На маке много места «зажато». Не увидев вашего комментария, ранее этого не осознавал.
      • +3
        Насколько же лучше смотрятся контекстные меню! Причина очевидна!
    • +7
      Я, ярый эпплофил, негодую по поводу меню. В целом, у Apple оно мне нравится больше (я же эпплофил), но вот в Win элемент Свойства ВСЕГДА расположен в самом конце, в него очень легко целиться (даже если высота меню всегда разная). В МакОС же — нет, нужно всегда выискивать этот пункт (Я про Get Info, View Options и прочее сейчас говорю).
      • +3
        Да, наверное, Вы правы, приятнее глазу != удобнее в использовании.
      • +6
        а вот меня в меню на маке раздражает то, что если ты промахнешься мимо пункта меню и нажмешь на какую-либо белую область меню, то оно пропадет.
        ИМХО это не совсем удобно.
        • +2
          Категорически с вами согласен!
        • +1
          да! что б ее :(
      • +3
        ⌘I – Свойства, ⌥⌘I – Инспектор. Всегда и везде.
        • +35
          Выглядит как выдержки из инопланетно-русского словаря.
          • +2
        • 0
          я в курсе, но иногда же хочется и мышкой повозюкать:)
    • 0
      Вообще то в плане интерфейса MacOS сильно отстает от Windows… к сожалению.
      Железо у них красивое, а вот интерфейсы хромают. (За исключением iOS)
      • +3
        *Поперхнулся чаем*

        Чего-чего? Это где МакОС внезапно отстает от Винды?

        • 0
          Как только надо сделать что-то сложнее, чем открыть файл, макос ВНЕЗАПНО начинает сильно отставать.
          • 0
            Примеры, сестра, примеры! ©
  • +1
    Увы, очень редко встречается возможность кастомизации контекстного меню. Файловые менеджеры чуть ли не единственное исключение, и то кастомизация весьма ограниченная часто.
  • +1
    Странно… статья вроде за 2011 год, а скриншот из Windwos Vista? Может лучше на Windows 7 заменить?

    А по поводу статьи — жаль не упомянули хороший совет про то, что при проектировании его неплохо ориентироваться на тех, кто работает в основном с клавиатуры. Это и возможность вызова через спец-клавишу (справа от правого Alt), и подсветка/подчеркивание букв выбора элемента меню (напр "Открыть").

    Я лично просто очень часто пользуюсь контекстным меню когда работаю почти без мышки (даже в том же Far-e многие операции удобней через него делать).
    • +3
      Есть подозрение, что в оригинале статьи скриншоты были именно из Висты.
      • +2
        Ну вот я и говорю — очень странно что в марте 2011 (Written by Hagan on March 23, 2011) пишут статьи со скриншотами Windows Vista вместо Windows 7.
        • +3
          Если я ничего не путаю, то и МакОС там не нова: очень похожа на Леопард (хотя актуален Снежный Леопард), автор жесткий консерватор :)
        • +1
          А вы не думали, что ему может нравится виста, и он не собирается переходить на семерку, или собирается, но не было повода? Или в момент написания статьи под рукой был только компьютер с установленной вистой?
          ps. а если есть возможность, можете показать разницу между контекстным меню висты и семерки(и если есть возможность — то и хр)?
          • +1
            Честно говоря — даже на секунду не подумал бы что кому-то может нравиться Виста. Даже работники Майкрософт на официальных конференциях (включая для Майкрософт Партнеров, на которых я бывал) заявляют что Виста была ошибкой и отчаянно советуют переходить всем кто ее использует на Вин7.

            Разницу не знаю — просто в тексте статьи упоминается Vista, что меня удивило.

            Скорее всего статья писалась несколько лет назад или использовались материалы, подготовленные тогда и автору лень было актуализировать материалы.
            • +3
              Еще бы они не советовали переходить на новую версию винды. Появится следующая версия — они также будут убеждать, что семерка безнадежно устарела и новая версия намного лучше. При всех недостатках висты я знаю людей, которые либо недавно сделали апгрейд, либо еще не делали, потому что за компом они работают, а не играют в апгрейды, а новая ось стоит неплохих денег, которые можно потратить на что-то еще.
            • +1
              У меня на ноуте предустановленна виста, сносить не собираюсь — так и останется второй системой
            • +1
              Тем не мение у нескольких доклдачиков на Миксе были Висты. Так что оффициальная версия, и личные пристратия это две большие разницы.
        • 0
          Ну не хочет/не может человек обновить винду. Я вот тоже решил не обновлять.
          • –1
            «Не ставьте ось до второго сервис-пака!»
            • 0
              Я вторую ось откатил до XP и не перейду на Висту даже если у неё 2-й сервис-пак вышел :)
              • –2
                Сам сижу на ХР, джу второй сервис пак семерочки.
                • 0
                  Я не жду, меня концепция не устроила, а не баги-глюки-недоделки, хотя когда буду (увы, похоже, не «если») обновлять, то рассматривать буду именно 7, а не висту или 8 (разве что она нарушит традицию, что каждая вторая версия юзабелена :) )
  • +5
    среди способов вызова контестного меню позабыли про соответствующую кнопку на клавиатуре.

    кстати, насколько я помню, на экранной клавиатуре она тоже присутствует, а значит это можно рассматривать как еще один способ вызова контекстного меню на устройствах с сенсорными экранами: выделил объект коротким нажатием, вызвал меню кнопкой на экранной клаве
  • +6
    АААА, на эппле что, реально такие шрифты?
    • 0
      (пожав плечами) ну да, а что такого?
      • +5
        они же мыльные, будь-то у меня -5
        • +1
          Тоже подобное сглаживание режет глаз.
          • +2
            на сколько я понимаю, это даже не сглаживание, а радуга
            • +2
              в винде тоже радуга у него, да менее заметно
              habreffect.ru/files/dae/cad1e442e/snag_110515_183140.png
              • 0
                в винде она глаз не режет. Я боюсь, что радуга есть даже у меня на никсах, но она тут хоть глаз не режет.
                • 0
                  Собственно, ее и не может не быть в случае использования subpixel rendering (== ClearType & аналоги)
            • +1
              О какой радуге речь? У меня 2 догадки:
              — У вас из-за маленького размера окна браузера картинки в посте показываются не в масштабе 100%, отчего вы видите не все пиксели.
              — У вас другая ориентация субпикселей на мониторе, нежели у человека делавшего скриншот.

              Вообще, конечно, на Маках субпиксельное сглаживание не слишком «резкое», крайние пиксели не так заметно меняют свой цвет, как на Винде. Даже не знаю, почему вам кажется с точностью наоборот.
              • 0
                В винде такой вырвигласзный рендеринг только в оффисе, по крайней мере так было когда я видел минду и оффис.
                • –1
                  Что значит «когда я видел»? А сейчас в топике вы не видите скриншотов из Винды? «У вас картинки плохо прорисовываются»?
                  • –1
                    Я говорю про текст, набранный в Оффисе, а не про меню.

                    Впрочем, если это успокоит ваши душевные бури, то я признаю, что в эппл отличное и прекрасное сглаживание и уберегу вас от выстраивания фантастических версий, почему у меня все плохо, а у всего мира все хорошо.
        • +3
          Вы знаете, я не вижу ни радуги, ни мыла (может, потому что за маком).
          • –1
            у вас еще и картинки плохо прорисовываются? :) Простите, но там явное мыло.
            • +2
              Разные мониторы, разные цветовые профили. До снежного барса к примеру гамма на маках довольно сильно отличалась от виндоус (2.2 против 1.8), поэтому на одной системе можно было видеть вечерний пейзаж на фото, а на другой это походило лишь на черный квадрат. У меня где-то валяется даже фото, когда я через КВМ подключил макмини к PC с каким-то простеньким 17" монитором, смотрелось все действительно странно.
              • –1
                видимо то, что у меня мылит на эппле просто не видно из-за гаммы.
        • 0
          Дело привычки.
  • 0
    По-поводу меню для нескольких разнородных объектов. Считаю, что надо выводить только общие для всех элементов команды. Чтобы победить проблему изменяющегося меню, можно показывать стандартное для конкретного элемента контекстное меню, только с задизейбленными «необщими» позициями. ИМХО, такая практика используется и достаточно успешно.
  • 0
    Маленькое дополнение: очень удобно, когда наиболее часто использующиеся пункты находятся наверху, и при этом порядок пунктов инвертируется, когда меню вынуждено развернуться вверх, а не вниз. Это было моё самое большое нарекание к Open Office, когда я сдуру попытался им воспользоваться :)

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Самое читаемое Разное