Жанр: Учеба
Дизайн пользовательского интерфейса
...ие кнопки не подразумевают подписей (которые в диалоговых
окнах ничего не стоят, принося в то же время явную пользу).
Обратите внимание, что на панелях инструментов чекбоксы и радио
кнопки могут быть кнопками прямого действия.
Списки
Все часто используемые списки функционально являются вариантами чек
боксов и радиокнопок. Скорость доступа к отдельным элементам и нагляд
ность в них принесены в жертву компактности (они экономят экранное
пространство, что актуально, если количество элементов велико) и расши
ряемости (простота загрузки в списки динамически изменяемых элементов
делает их очень удобными при разработке интерфейса, поскольку это
позволяет не показывать пользователю заведомо неработающие элементы).
Списки бывают пролистываемыми и раскрывающимися, причем пролис
тываемые могут обеспечивать как единственный (аналогично группе
радиокнопок), так и множественный выбор (a la чекбокс); раскрывающиеся
же работают исключительно как радиокнопки. Но сначала необходимо
рассказать об общих свойствах всех списков.
Ширина. Ширина списка как минимум должна быть достаточна для
того, чтобы пользователь мог определить различия между элементами.
В идеале, конечно, ширина всех элементов должна быть меньше ширины
списка, но иногда это невозможно. В таких случаях не стоит добавлять к
списку горизонтальную полосу прокрутки, лучше урезать текст элементов.
Для этого нужно определить самые важные фрагменты текста (например,
для URL это начало и конец строки), после чего все остальное заменить
отточием (...).
Поскольку нужно максимально ускорить работу пользователей, необхо
димо сортировать элементы. Идеальным вариантом является сортировка
по типу элементов. Если же элементы однотипны, их необходимо сорти
ровать по алфавиту, причем списки с большим количеством элементов
полезно снабжать дополнительными элементами управления, влияющими
на сортировку или способ фильтрации элементов. Если можно определить
наиболее популярные значения, их можно сразу расположить в начале
списка, но при этом придется вставлять в список разделитель, а в систему -
обработчик этого разделителя.
Пиктограммы.
Уже довольно давно в ПО нет технических проблем с
выводом в списках пиктограмм отдельных элементов. Однако практически
никто этого не делает. Это плохо, ведь пиктограммы обеспечивают сущест
венное повышение субъективной привлекательности интерфейса и скани
руются быстрее "голого" текста.
WWW.UIBOOK.RU | ВЛАД В. ГОЛОВАЧ | ДИЗАЙН ПИ: ЭЛЕМЕНТЫ УПРАВЛЕНИЯ
Раскрывающиеся
списки
Самым простым вариантом списка является раскрывающийся список.
Помимо описанных выше родовых достоинств списков, раскрывающиеся
списки обладают одним существенным достоинством. Оно заключается в
том, что малая высота списка позволяет с большой легкостью визуально
отображать команды, собираемые из составляющих.
Рис. 36. Пример визуальной сборки команды из составляющих. Данный метод значи
тельно проще для понимания, нежели, например, ввод положительного значения для
смещения вверх и отрицательного значения для смещения вниз без поддержки
раскрывающимся списком. Справа на иллюстрации крутилка (см. стр. 74).
Раскрывающийся список, как правило, вызывает две проблемы, одна
появляется преимущественно в ПО, другая - в интернете.
Первая проблема заключается в том, что иногда отсутствие места на
экране не позволяет использовать ни чекбоксы с радиокнопками, ни
пролистываемые списки множественного выбора. Приходится делать
раскрывающийся список, в котором помимо собственно элементов есть
"мета элемент", включающий все элементы из списка. Этому элементу
часто не дают названия, оставляя строку списка пустой, что неправильно,
поскольку требует от пользователя слишком глубокого абстрагирования.
Такой мета элемент нужно снабжать названием, например, Все значения или
Ничего
В интернете проблема иная. Раскрывающийся список часто используется
как навигационное меню. Это изначально неправильно, поскольку
содержимое такого меню не видно сразу и уж тем более им трудно
индицировать пользователям, в каком разделе сайта они находятся. Это,
впрочем, не главное. Большая проблема заключается в том, что список
снабжают скриптом, который запускается сразу по выбору значения. Такой
метод имеет два недостатка. Во первых, список исторически не является
элементом управления прямого действия (как и чекбокс, например), что
приводит к потере пользователями чувства контроля над системой. Во
вторых, раскрывающиеся списки довольно сложны, так что пользователи
часто совершают моторные ошибки при выборе нужного элемента. Пос
кольку эта ошибка не может быть обнаружена системой и не всегда обна
руживается пользователями, часты ситуации, когда пользователь (как ему
кажется) выбирает один раздел, а перемещается в другой, что совсем
нехорошо. Таким образом, навигационные раскрывающиеся списки нужно
снабжать кнопкой, которая и будет запускать действие, запускать же
действие сразу после выбора элемента в списке нельзя.
WWW.UIBOOK.RU | ВЛАД В. ГОЛОВАЧ | ДИЗАЙН ПИ: ЭЛЕМЕНТЫ УПРАВЛЕНИЯ
Пролистываемые
списки
Другим, более сложным вариантом списка является пролистываемый спи
сок. Пролистываемые списки могут позволять пользователям совершать
как единственный, так и множественный выбор. Одно требование приме
нимо к обоим типам списков, остальные применимы только к одному типу.
Размер.
По вертикали в список должно помещаться как минимум четыре
строки, а лучше восемь. Напротив, список, по высоте больший, нежели
высота входящих в него элементов, и соответственно, содержащий пустое
место в конце, смотрится неряшливо. Требование выводить полоски
прокрутки в больших списках кажется моветоном, но забывать о нем не
следует.
Списки единственного выбора. Список единственного выбора явля
ется промежуточным вариантом между группой радиокнопок и раскрываю
щимся списком. Он меньше группы радиокнопок с аналогичным числом
элементов, но больше раскрывающегося списка. Соответственно, исполь
зовать его стоит только в условиях "ленивой экономии" пространства
экрана.
Рис. 37. Список единственного выбора. Обратите внимание, что в ситуациях, когда все
элементы помещаются в список без пролистывания, список работает в точности как
группа радиокнопок.
Списки множественного выбора. С точки зрения дизайна интерфей
сов, списки множественного выбора интересны, прежде всего, тем, что их
фактически нет в интернете. Технически создать список множественного
выбора непроблематично, для этого в HTML есть даже специальный тег.
Проблема в том, что такой список в браузере будет выглядеть как список
единственного выбора, более того, чтобы выбрать несколько элементов
пользователю придется удерживать клавишу Ctrl. Это значит, что восполь
зоваться таким списком сможет только малая часть аудитории (и даже
наличие подсказки у списка положения не исправит). Из за такой убогой
реализации списков браузерами, использовать их, как правило, оказы
вается невозможно. Приходится использовать чекбоксы1.
Рис. 38. Список множественного выбора с чекбоксами.
Гораздо лучше обстоят дела в ПО. Возможность безболезненно выводить
в списке чекбоксы позволяет пользователям без труда пользоваться спис
ками, а разработчикам - без труда эти списки создавать.
. В принципе, с появлением слоев, внедренных окон (IFrame) и Macromedia Flash,
появилась возможность самостоятельно создавать такие списки и в интернете.
К сожалению, это довольно трудоемкое занятие, к тому же запрограммировать
все возможности списка (например, перемещение по списку с клавиатуры)
практически нереально.
WWW.UIBOOK.RU | ВЛАД В. ГОЛОВАЧ | ДИЗАЙН ПИ: ЭЛЕМЕНТЫ УПРАВЛЕНИЯ
Комбобоксы
Комбобоксами (combo box), называются гибриды списка c полем ввода:
пользователь может выбрать существующий элемент, либо ввести свой.
Комбобоксы бывают двух видов: раскрывающиеся и расширенные. Оба
типа имеют проблемы.
Рис. 39. Раскрывающийся комбобокс с установленным фокусом ввода (слева)
и расширенный комбобокс (справа).
У раскрывающегося комбобокса есть проблемы. Во первых, такие комбо
боксы выглядят в точности как раскрывающиеся списки, визуально отли
чаясь от них только наличием индикатора фокуса ввода (да и то, только
тогда, когда элемент выделен). Это значит, что полноценно пользоваться
ими могут только сравнительно продвинутые пользователи. В этом нет
особой проблемы, поскольку комбобоксом все равно можно пользоваться,
как обычным списком. Во вторых, что гораздо хуже, раскрывающиеся
комбобоксы отсутствуют в интернете как класс. Поддержки их нет ни в
браузерах, ни в HTML.
Проблемы расширенных комбобоксов, напротив, совершенно иные. Их
с трудом, но можно реализовать в интернете (через JavaScript). Они имеют
уникальный вид, отличающий их от остальных элементов управления. Зато
их сравнительно трудно (хотя и гораздо легче, чем в интернете) реализо
вать в ПО. При этом расширенный комбобокс потребляет много места на
экране.
Поскольку комбобоксы являются гибридами списков и полей ввода, к
ним применимы те же требования, что и к их родителям.
Поля ввода
Вместе с командными кнопками, чекбоксами и радиокнопками, поля ввода
являются основой любого интерфейса. В результате требований к ним
довольно много.
Размеры. Основная часть требований к полям ввода касается размера.
Понятно, что размер по вертикали должен быть производным от размера
вводимого текста - если текста много, нужно добавить несколько строк
(нарушением этого правила регулярно грешат форумы, заставляющие
пользователей вводить сообщения в поля ввода размером с ноготь).
С размерами по горизонтали интереснее. Конечно, ширина поля должна
соответствовать объему вводимого текста, поскольку гораздо удобнее вво
дить текст, который видишь. Менее очевидным является другое сообра
жение: ширина поля ввода не должна быть больше объема вводимого в поле
текста, поскольку частично заполненное поле выглядит как минимум
неряшливо.
Ширина поля ввода не должна быть больше максимальной длины строки
Отдельной проблемой является ограничение вводимого текста. С одной
стороны, ограничение хорошо для базы данных. С другой стороны, всегда
найдутся пользователи, для которых поле ввода с ограничением вводимых
символов окажется слишком маленьким. Поэтому этот вопрос нужно
решать применительно к конкретной ситуации.
WWW.UIBOOK.RU | ВЛАД В. ГОЛОВАЧ | ДИЗАЙН ПИ: ЭЛЕМЕНТЫ УПРАВЛЕНИЯ
Рис. 40. Пример полей ввода, больших объема вводимых в них информации. Мало
того, что такие поля выглядят неряшливо, так они ещё и обманывают пользователей,
показывая, что пользователь ввел не всю информацию. Вдобавок, после заполнения
поля приходится самому перемещать фокус ввода, хотя с этим справилась бы
и система. РОЛ
Если же суммировать информацию из двух предыдущих абзацев, можно
определить самую большую ошибку, которую разработчики допускают при
создании полей ввода. Всякий раз, когда ширина поля ввода больше макси
мального объема вводимого в него текста, и при этом объем вводимого
текста ограничен, пользователи неприятно изумляются, обнаружив, что
они не могут ввести текст, хотя место под него на экране имеется.
Соответственно, вообще нельзя делать поле ввода шире максимального
объема вводимого в них текста.
Подписи.
Вопрос "где надо размещать подписи к полям ввода?" является
одним из самых популярных среди программистов: битвы сторонников
разных подходов, хоть и бескровны, но значительны. Аргументов и подхо
дов тут множество, моё личное мнение заключается в том, что, поскольку
восприятие подписей занимает определенное время, которого жаль, лучше
всего действует следующее простое правило: в часто используемых экранах
подписи должны быть сверху от поля (чтобы их было легче не читать), в
редко же используемых подписи должны быть слева (чтобы всегда воспри
ниматься и тем самым сокращать количество ошибок).
Подписи к полям ввода имеют определенное отличие от других подпи
сей. В полях ввода подписи можно размещать не рядом с элементом, а внут
ри него, что позволяет экономить пространство экрана. Подпись при этом
выводится в самом поле ввода, точно так же, как и текст, который в него
нужно вводить. Необходимо только отслеживать фокус ввода, чтобы при
установке фокуса в поле убирать подпись. Это решение, будучи нестандарт
ным, плохо работает в ПО, но неплохо работает в интернете. Если очень
жалко экранное пространство, этим методом стоит пользоваться.
Крутилки
Крутилка (spinner, little arrow) есть поле ввода, не такое универсальное, как
обычное, поскольку не позволяет вводить текстовые данные1, но зато
обладающее двумя полезными возможностями.
Рис. 41. Крутилка.
Во первых, чтобы ввести значение в крутилку, пользователю не обяза
тельно бросать мышь и переносить руку на клавиатуру (в отличие от обыч
ного поля ввода). Поскольку перенос руки с место на место занимает срав
нительно большое время (в среднем почти половину секунды, см. "Предска
зание скорости" на стр. 120), к тому же ещё и сбивает фокус внимания,
отсутствие нужды в клавиатуре оказывается большим благом. Во всяком
случае, ввод значения в крутилку с клавиатуры достаточно редок, т. е. поль
зователи воспринимают крутилки целиком и полностью положительно. Во
. Точнее, позволяет, но при этом оказывается ничем не лучше обычного поля
ввода.
WWW.UIBOOK.RU | ВЛАД В. ГОЛОВАЧ | ДИЗАЙН ПИ: ЭЛЕМЕНТЫ УПРАВЛЕНИЯ
вторых, при вводе значения мышью система может позволить пользова
телям вводить только корректные данные, причем, что особенно ценно,
в корректном формате. Это резко уменьшает вероятность человеческой
ошибки. Таким образом, использование крутилок для ввода любых
численных значений более чем оправдано.
К сожалению, в интернете нет специального элемента для крутилки. Сде
лать элемент, похожий на крутилку, можно без труда, создав список множес
твенного выбора высотой в один элемент, но ввод в него с клавиатуры будет
невозможен. К счастью, крутилку можно с относительно небольшими затра
тами сделать в Macromedia Flash.
Ползунки
Как и ранее описанные элементы управления, ползунки позволяют пользо
вателям выбирать значение из списка, не позволяя вводить произвольное
значение. Возникает резонный вопрос: зачем нужен ещё один элемент
управления, если аналогичных элементов уже полно. Ответ прост: ползун
ки незаменимы, если пользователям надо дать возможность выбрать
значение, стоящее в хорошо ранжирующемся ряду, если:
значений в ряду много (см. рис. 42)
нужно передать пользователям ранжируемость значений.
Рис. 42. Примеры ползунков. Видно, что количество параметров в ползунке может
быть весьма значительным.
необходимо дать возможность пользователям быстро выбрать значе
ние из большого их количества (в таких случаях ползунок оказывается
самым эффективным элементом, хотя и опасен возможными
человеческими ошибками).
Ползунки имеют интересный аспект. Их можно также использовать для
выбора текстовых параметров, но только в случаях, когда эти параметры
можно понятным образом отранжировать. Случаев таких немало, напри
мер, "завтрак", "обед" и "ужин", при отсутствии внешней связи ранжиро
ванию поддаются вполне.
WWW.UIBOOK.RU | ВЛАД В. ГОЛОВАЧ | ДИЗАЙН ПИ: МЕНЮ
Меню
При упоминании применительно к интерфейсу термина меню, большин
ство людей немедленно представляют стандартные раскрывающиеся меню.
В действительности, понятие меню гораздо шире. Меню - это метод взаи
модействия пользователя с системой, при котором пользователь выбирает
из предложенных вариантов, а не предоставляет системе свою команду.
Рис. 43. Стандартное раскрывающееся меню.
Соответственно, диалоговое окно с несколькими кнопками (и без
единого поля ввода) также является меню.
Рис. 44. Это тоже меню.
В настоящее время систем, которые не использовали бы меню в том или
ином виде, практически не осталось. Объясняется это просто. Меню
позволяет снизить нагрузку на мозги пользователей, поскольку для выбора
команды не надо вспоминать, какая именно команда нужна и как именно её
нужно использовать - вся (или почти вся) нужная информация уже содер
жится на экране. Вдобавок, поскольку меню ограничивает диапазон дейст
вий пользователей, появляется возможность в значительной мере изъять
из этого диапазона ошибочные действия. Более того: меню показывает
пользователям объем действий, которые они могут совершить благодаря
системе, и тем самым обучают пользователей (в одном из исследований
было даже обнаружено, что меню является самым эффективным средством
обучения1). Таким образом, в большинстве систем меню является объек
тивным благом (они неэффективны, в основном, в системах с внешней
средой или течением времени).
WWW.UIBOOK.RU | ВЛАД В. ГОЛОВАЧ | ДИЗАЙН ПИ: МЕНЮ
Типы меню
Существуют несколько различных таксономий меню, но основной интерес
представляют только две из них. Первая таксономия делит меню на два
типа:
Статические меню, т. е. меню, постоянно присутствующие на экране.
Характерным примером такого типа меню является панель
инструментов.
Динамические меню, в которых пользователь должен вызвать меню,
чтобы выбрать какой либо элемент. Примером является обычное
контекстное меню.
В некоторых ситуациях эти два типа меню могут сливаться в один:
например, меню, состоящее из кнопок доступа к меню (см. стр. 67), могут
работать и как статические (пользователи нажимают на кнопки) и как
динамические (пользователи вызывают меню).
Вторая таксономия также делит меню на два типа:
Меню, разворачивающиеся в пространстве (например, обычное
раскрывающееся меню). Всякий раз, когда пользователь выбирает
элемент нижнего уровня, верхние элементы остаются видимыми.
Меню, разворачивающееся во времени. При использовании таких
меню элементы верхнего уровня (или, понимая шире, уже пройден
ные элементы) по тем или иным причинам исчезают с экрана.
Например, в предыдущей иллюстрации диалоговое окно с меню
перекрыло элемент управления, которым это меню было вызвано.
Каждый тип меню в обеих таксономиях имеет определенные недостатки.
Статические меню из первой таксономии, как правило, обеспечивают высо
кую скорость работы, лучше обучают пользователей, но зато занимают мес
то на экране. С динамическими меню ситуация обратная. Во второй
таксономии первый тип (меню, разворачивающиеся в пространстве)
обеспечивает большую поддержку контекста действий пользователей, но
эта поддержка обходится в потерю экранного пространства. Второй тип
более бережно использует пространство, но зато хуже поддерживает
контекст.
Реальность, впрочем, оказывается несколько шире обеих таксономий.
Например, мастер (см. "Последовательные окна" на стр. 98), являясь и
динамическим меню из первой таксономии, и разворачивающимся во
времени меню из второй, не оказывается более быстрым, чем, например,
раскрывающееся меню. Но объем и специфика входящих в него элементов
управления не позволяют, как правило, сделать из него какое либо другое
меню, например, раскрывающееся.
Поэтому очень полезно научиться анализировать влияние и взаимо
проникновение разных типов меню, а также осознавать их место в интер
фейсе. Например, контекстное меню на ином уровне абстракции оказыва
ется временным (т. е. динамическим) диалоговым окном, только с нестан
дартной структурой. Понимание этой структуры позволяет определить,
какие элементы управления, помимо кнопок, можно использовать в таком
меню, чтобы оно обрело как достоинства меню, так и достоинства диало
гового окна. К сожалению, объем этой книги не позволяет более полно
описать эту тему. Поэтому в этом разделе будут описаны только главные и
контекстные меню.
. Diana Parton, Keith Huffman, Patty Pridgen, Kent Norman, and Ben Shneiderman.
Learning a Menu Selection Tree: Methods Compared. Behaviour and Information
Technology, () , pp. .
WWW.UIBOOK.RU | ВЛАД В. ГОЛОВАЧ | ДИЗАЙН ПИ: МЕНЮ
Устройство меню
На эффективность меню наибольшее влияние оказывают устройство
отдельных элементов и их группировка. Несколько менее важны другие
факторы, такие как выделение элементов и стандартность меню.
Устройство
отдельных элементов
Самым важным свойством хорошего элемента меню является его название.
Название должно быть самым эффективным из возможного. В отличие от
кнопок в диалоговых окнах, элементы главного меню практически никогда
не несут на себе контекста действий пользователя, просто потому, что в
любой момент времени доступны все элементы. Это значит, что к наимено
ванию элементов меню нужно подходить весьма тщательно, тщательней,
нежели ко всему остальному.
Впрочем, помимо тщательности (и таланта, к слову говоря) нужно ещё
кое что. Обязательно нужно убедиться, что выбранное название понятно
целевой аудитории. Сделать это просто - пользователю нужно сообщить
название элемента и попросить его сказать, что этот элемент меню делает.
Нелишне заметить, что функциональность, не отраженная названием
элемента, с большой степенью вероятности не будет найдена значительной
частью аудитории. Поэтому не стоит умещать в диалоговое окно какую либо
функцию, если её существование в этом окне невозможно предсказать,
глядя на соответствующий элемент меню.
Не делайте элементов меню, часть функциональности которых не влезает
в текст элемента
Особо стоит остановиться на склонении текста. В отличие от диалого
вых окон, в которых кнопки прямого и отложенного действия выглядят и
действуют по разному, в меню нет четкой разницы между этими элемен
тами. Единственным способом разграничения этих элементов является
текст, так что нужно очень тщательно подходить к тому, чтобы элементы,
запускающие действия, были глаголами в форме инфинитива (как команд
ные кнопки). Впрочем, часто глагол приходится выкидывать вообще,
чтобы переместить значимое слово ближе в начало текст элемента. Нужно
это, чтобы повысить скорость распознавания. Повысить её можно всего
одним способом: главное (т. е. наиболее значимое) слово в элементе должно
стоять в элементе первым. Обратите внимание, что короткий текст элемен
та, без сомнения, быстро читаясь, совершенно необязательно быстро
распознается. Поэтому не стоит безудержно сокращать текст элемента:
выкидывать нужно все лишнее, но не более.
Пиктограммы в меню. Пиктограммы в меню, если они повторяют
пиктограммы в панели инструментов, обладают замечательной способ
ностью обучать пользователей возможностям панели. Помимо этого они
здорово ускоряют поиск известного элемента и точность его выбора, равно
как и общую разборчивость меню. Таким образом, пиктограммы в меню
объективно хороши (только стоят дорого, к сожалению). Это очевидный
факт. Теперь менее очевидный: пиктограммы лучше работают, когда ими
снабжены не все элементы. Когда все элементы имеют пиктограммы, раз
борчивость каждого отдельного элемента падает: в конце концов, пикто
граммы всех ненужных в данное время элементов являются визуальным
шумом. Когда же пиктограммами снабжены только самые важные эле
менты, их разборчивость повышается (а разборчивость остальных не
понижается), при этом пользователям удается легче запоминать коорди
наты элементов ("элемент сразу под второй пиктограммой").
Не снабжайте пиктограммами все элементы меню, снабжайте только
самые важные
Переключаемые элементы. Особого внимания заслуживают случаи,
когда меню переключает какие либо взаимоисключающие параметры,
например, показывать или не показывать палитру. Тут есть несколько
WWW.UIBOOK.RU | ВЛАД В. ГОЛОВАЧ | ДИЗАЙН ПИ: МЕНЮ
возможных способов. Можно поместить перед переключателем галочку,
показывая, что он включен (если же элемент снабжен пиктограммой,
можно её утапливать). Заранее скажу, что это лучший метод. Можно не
помещать галочку, зато инвертировать текст элемента: например, элемент
Показывать сетку
превращается в Не показывать сетку. Это плохо по многим
причинам. Во первых, в интерфейсе желательно не употреблять ничего
негативного: в меньшей степени потому, что негативность слегка снижает
субъективное удовлетворение; в большей степени потому, что она снижает
скорость распознавания текста (главное слово не первое, нужно совершить
работу, чтобы из отрицания вычислить утверждение). Во вторых, если
изъять "не" и переформулировать одно из состояний элемента, пользова
телям будет труднее осознать, что два разных элемента на самом деле есть
один элемент. Таким образом, галочка предпочтительнее.
Всегда формулируйте текст в интерфейсе без использования отрицаний
Предсказуемость действия.
Пользователей нужно снабжать чувством
контроля над системой. Применительно к меню это значит, что по виду
элемента пользователи должны догадываться, что произойдет после
выбора. Сделать это неимоверно трудно, поскольку на экране нет места под
такие подсказки. Можно сделать только одно, но сделать это нужно
обязательно: нужно показать пользователям, какой элемент запускает
действие или меняет параметр, а какой открывает окно c продолжением
диалога. Почти во всех ОС стандартным индикатором продолжения диа
лога является многоточие после текста элемента, так что пользоваться этим
признаком стоит везде, включая интернет. Также необходимо показывать,
какой элемент срабатывает сразу, а какой открывает элементы меню
нижнего уровня (в любой ОС это делается автоматически, в интернете
нужно не забывать делать это вручную).
Это же правило касается и гипертекстовых ссылок вообще (они тоже
меню). Пользователи испытывают значительно большее чувство контроля,
когда имеют возможность предсказать, куда их ссылка приведет (при этом
снижается количество ошибочных переходов). Таким образом, нестан
дартные ссылки (т. е. ссылки на другой сайт, на почтовый адрес, на файл, на
узел FTP, на долго загружающуюся страницу и т.д.) полезно снабжать
...Поділитися у соцмережах
