Всё нижеизложенное является продуктом жизнедеятельности моего мозга и предоставляется «как есть».
User-allowed policy — это только что придуманный мною термин для обозначения того, чего можно позволять пользователю на интерфейсе, а чего нельзя. Если кто-то знает термин получше, расскажите, порадуемся вместе. Гугл, Вики и другие источники тактично промолчали.
В наше вебдванольное время лояльность и удобство для пользователя зачастую становятся фетишем. В своё время полистав (но так, к сожалению, и не прочитав) книгу Круга «Не заставляйте меня думать», я был поражён её названием. Фантазия услужливо предоставила мне картинку: миллионы пользователей сёрфят Сеть пользуясь только спинным мозгом и не подключая головной. Я конечно догадываюсь, что книга не так проста, как мне показалось, но первая реакция была именно такой.
Под вынесенным в название топика термином подразумевается не набор соглашений между пользователем и ресурсом предоставляющим интерфейс, а принципы построения интерфейса, цель которых ограничить пользователя от бездумных и хаотичных действий, которые не принесут пользы как самому пользователю, так и администрации. Зачастую, причиной появления таких действий является стремление создать максимально удобный интерфейс, понимая под этим минимизацию количества кликов.
Яркий пример — поливариантные контролы. Проще говоря, ссылка Добавить в друзья! (восклицательный знак в конце обязателен!), которая для добавленного принимает вид Убрать из друзей :(. Вебдваноль и AJAX сделали всё, для того чтобы добавить/убрать можно было бы легко, единым кликом. После добавления мы обзавелись новым френдом, а ссылка, как и положено послушному поливариантному контролу должна перейти в противоположное (или альтернативное) состояние…
Должна ли? Представим себе ситуацию более подробно. Пользователь в процессе изучения интерфейса может кликнуть на ссылку раз десять, просто для того, чтобы понаблюдать процесс изменения. В древности, когда асинхронных запросов не существовало, пользователя сдерживала перспектива втыка на перезагрузку страницы. AJAX же освободил пользователя от этого.
Это и есть место для user-allowed policy. Ссылка не превращается, а просто дизэйблится, становится текстом, альтернативный вариант появится только после перезагрузки. Кстати, удобный способ дизэйблить подобные ссылки (кроме чистки onclick, ясен пень): убивать аттрибут HREF. Это превращает ссылку в безвредный якорь при минимальном количестве движений со стороны JS и, кроме того, оставляет содержимому все его стили, которые могли бы полететь, замени мы тег на SPAN или что-то вроде.
Думаю, что примеров для применения user-allowed policy можно найти массу. Предлагаю высказываться и обсуждать.
User-allowed policy — это только что придуманный мною термин для обозначения того, чего можно позволять пользователю на интерфейсе, а чего нельзя. Если кто-то знает термин получше, расскажите, порадуемся вместе. Гугл, Вики и другие источники тактично промолчали.
В наше вебдванольное время лояльность и удобство для пользователя зачастую становятся фетишем. В своё время полистав (но так, к сожалению, и не прочитав) книгу Круга «Не заставляйте меня думать», я был поражён её названием. Фантазия услужливо предоставила мне картинку: миллионы пользователей сёрфят Сеть пользуясь только спинным мозгом и не подключая головной. Я конечно догадываюсь, что книга не так проста, как мне показалось, но первая реакция была именно такой.
Под вынесенным в название топика термином подразумевается не набор соглашений между пользователем и ресурсом предоставляющим интерфейс, а принципы построения интерфейса, цель которых ограничить пользователя от бездумных и хаотичных действий, которые не принесут пользы как самому пользователю, так и администрации. Зачастую, причиной появления таких действий является стремление создать максимально удобный интерфейс, понимая под этим минимизацию количества кликов.
Яркий пример — поливариантные контролы. Проще говоря, ссылка Добавить в друзья! (восклицательный знак в конце обязателен!), которая для добавленного принимает вид Убрать из друзей :(. Вебдваноль и AJAX сделали всё, для того чтобы добавить/убрать можно было бы легко, единым кликом. После добавления мы обзавелись новым френдом, а ссылка, как и положено послушному поливариантному контролу должна перейти в противоположное (или альтернативное) состояние…
Должна ли? Представим себе ситуацию более подробно. Пользователь в процессе изучения интерфейса может кликнуть на ссылку раз десять, просто для того, чтобы понаблюдать процесс изменения. В древности, когда асинхронных запросов не существовало, пользователя сдерживала перспектива втыка на перезагрузку страницы. AJAX же освободил пользователя от этого.
Это и есть место для user-allowed policy. Ссылка не превращается, а просто дизэйблится, становится текстом, альтернативный вариант появится только после перезагрузки. Кстати, удобный способ дизэйблить подобные ссылки (кроме чистки onclick, ясен пень): убивать аттрибут HREF. Это превращает ссылку в безвредный якорь при минимальном количестве движений со стороны JS и, кроме того, оставляет содержимому все его стили, которые могли бы полететь, замени мы тег на SPAN или что-то вроде.
Думаю, что примеров для применения user-allowed policy можно найти массу. Предлагаю высказываться и обсуждать.
