Понятно, что компьютеры везде, это неизбежно.
Дело в интерфейсе, элементы которого должны наследовать свойства реального мира.
К примеру, в чем причина успеха мультитача? В том, что работа с ним гораздо ближе к реальному миру (листание, перемещение), чем нажатия на виртуальные кнопки или кнопки мышки.
Как нет аналогии? Я же привел пример работы с реальным документом.
Какая память предков? Я до сих пор пользуюсь бумагой и ручкой, и вроде даже я не один такой.
Интерфейс использует метафоры из реального мира — рабочий стол, корзина, документы и т.д., чтобы пользователю можно было быстрее адаптироваться к этому интерфейсу. Если вы больше времени проводите в реальном мире, то реальные вещи будут всегда «ближе».
Каким бы ни был удобным интерфейс, если он использует метафоры из непонятного мне опыта, то это будет сродни изучению чего-то совершенного нового и ни о каком удобстве уже речь идти не будет — будет одно раздражения от незнания что же нужно делать.
Меня вообще диалоги сохранения бесят. Неужели трудно сохранить данные автоматически?
Есть простая аналогия с реальным миром — работа с документом за обыкновенным рабочим столом.
Было бы не круто, если бы каждый раз после письма рабочий стол не пускал меня и спрашивал хочу ли я сохранить то, что написал. А потом ещё ещё выдвигал ящики, предлагая мне туда их положить.
Я сам хочу решать, что я хочу делать. Захочу встану и уйду — письмо будет лежать у меня на столе. Хочу выкину его. Хочу положу в папочку. А захочу начну новое.
Почему-то все полагают, что задачи программы важнее моих собственных.
Спасибо за совет, хотя, вероятно, я вряд ли им воспользуюсь. Есть вещи которые я готов потерпеть три секунды (которые иногда для меня все тридцать). Но практически всегда я с небольшим удовольствием устанавливаю дополнения, просто потому, что вся эта процедура мне малоприятна. И как пользователю, и как программисту.
Ожидание, как мне кажется, негативно влияет на удовлетворенность продуктом. Как и «естественное» (запрос к серверу, сохранение на диск), так и в искусственное. Ведь в данном случае, как опытный пользователь, я знаю чего хочу. Неопытный, в любом случае будет сначала изучать этот диалог.
Установка дополнений у FireFox вообще отдельная песня.
[user mode]
Нужна его найти в одном из 7 меню; затем «получить» всплывающее окно (у меня оно выскочило на основном мониторе, браузер был на втором); затем нужно понять, что тебе нужно («Расширения», «Темы» или «Плагины»); понять, что нужен поиск; установить, глядя на окно установки так долго, что даже не заметив как пройдет эти пять (три?) секунд.
А затем нужно ещё перезагрузить.
А я всего-то хотел заблокировать рекламу. [/user mode]
Понятно, что мы этого не заметим, мы привыкли и многое делаем на автомате и многое сделаем быстрее.
Разработчики стараются всяческими способами привлечь внимание к тому, что происходит. С помощью диалогов, всплывающих окон, изменение формы, цвета. В общем, всячески уменьшить время полезной работы пользователя, которое он тратит на то, что хочет («Я хочу прочитать веб-страницу»), и увеличивает время на совсем не нужные вещи («Нет, я не хочу делать тебя стандартным браузером!», «Нет, я не хочу работать в автономном режиме!», «Да, я уверен, что хочу передавать данные в сеть!», «Нет, я не хочу, чтобы ты запоминал мои данные!»), которые нужно осмыслить и совершить действие.
Удовольствие от таких продуктов мало, причем имеет зависимость от опыта пользователя. Опытные пользователи достаточно «легко» пройдут такие диалоги, может быть испытывая легкое раздражение, неопытные же будут вынуждены читать и думать.
Всем разработчика нужно помнить, что нужно создавать продукты с наименьшим когнитивным сопротивлением, чтобы пользователь не «продирался сквозь колючки», а как минимум, делал нужную работу, а ещё лучше получал при этом удовольствие от того, насколько он это круто делает.
Изменение геометрии кнопки интересный эксперимент, но мне не слишком понравилась реализация с дизайнерской точки зрения. Тут же возникает вопрос — если вы хотите совершить действие (в данном случае удалить), то почему она «колючая»? Это же положительно (в том смысле, что приводит к выполнению, в отличие от соседней) действие.
Кроме того, многие опытные пользователи используют расположение кнопок, как карту в сознании, с помощью которой они преодолевают эти «ужасные» диалоги, то есть отмены слева, кнопка совершения действия — справа. А что если таких кнопок будет несколько? Иначе может быть только в диалогах с двумя кнопками, большее двух кнопок может ввести пользователя в заблуждение.
И даже привыкнув и поняв, он научиться преодолевать ваши диалоги не замечая колючих кнопок. Сами вспомните, как вы удаляете файлы из корзины. Будете ли вы каждый раз читать, что там написано если там будет такая колючка?
В общем, это интересно, но нужно крепко подумать, при неумелом использовании это может превратиться в хаос.
Опять-таки, не буду спорить, это вопрос идеологический. Замечу только, что это расширенный язык разметки. Что и как выглядит решает CSS, а HTML, который мы получаем на выходе из XSLT, отвечает за данные.
Зря вы так, фреймворк отличный, я, кстати и поддержку XSLT (серверную, конечно) к нему прикрутил через переопределение класса представления.
В общем, его надо уметь готовить :-)
Не могли бы вы пояснить почему?
Условия это прерогатива только бизнес-слоя?
А если мне надо присвоить класс для элемента, в зависимости от входящих данных?
А если мне нужно поменять название класса, мне нужно будет лезть в бизнес-логику где и менять название?
Хотелось бы оправдаться за фразу «иногда для одного HTML тега столько наворотишь».
Я имел ввиду ситуации, когда, например, тег или атрибуты зависят от параметров, тогда приходится применять xsl:if или xsl:choose, что увеличивает размер кода. В итоге для одного элемента можно получить десяток строчек кода.
В других шаблонизаторах будет также, но в XSLT каждое такое условие или решение — это тег, что увеличивает размер кода и визуально это выглядит довольно громоздко.
У нас была программная обработка и формирование главных шаблонов на уровне серверного языка (PHP), поэтому сами такое не писали. «Рядовые» программисты писали XSL (и частично XML) для отдельных модулей/действий.
А вообще, связка XML/XSLT и так довольно муторна — иногда для одного HTML тега столько наворотишь.
Но гибкая и требует грамотного подхода, абы как не сделаешь.
За что до сих пор и люблю. :-)
Насчёт непрактичного синтаксиса спорить не буду, как говорится, suum cuique, а вот поддержки браузеров нет, это правда.
В своё время выбрали серверную обработку XSLT и сопутствующие вкусности, добавили кеширование и вуаля…
Опять же, каждому своё.
Дело в интерфейсе, элементы которого должны наследовать свойства реального мира.
К примеру, в чем причина успеха мультитача? В том, что работа с ним гораздо ближе к реальному миру (листание, перемещение), чем нажатия на виртуальные кнопки или кнопки мышки.
Какая память предков? Я до сих пор пользуюсь бумагой и ручкой, и вроде даже я не один такой.
Интерфейс использует метафоры из реального мира — рабочий стол, корзина, документы и т.д., чтобы пользователю можно было быстрее адаптироваться к этому интерфейсу. Если вы больше времени проводите в реальном мире, то реальные вещи будут всегда «ближе».
Каким бы ни был удобным интерфейс, если он использует метафоры из непонятного мне опыта, то это будет сродни изучению чего-то совершенного нового и ни о каком удобстве уже речь идти не будет — будет одно раздражения от незнания что же нужно делать.
Есть простая аналогия с реальным миром — работа с документом за обыкновенным рабочим столом.
Было бы не круто, если бы каждый раз после письма рабочий стол не пускал меня и спрашивал хочу ли я сохранить то, что написал. А потом ещё ещё выдвигал ящики, предлагая мне туда их положить.
Я сам хочу решать, что я хочу делать. Захочу встану и уйду — письмо будет лежать у меня на столе. Хочу выкину его. Хочу положу в папочку. А захочу начну новое.
Почему-то все полагают, что задачи программы важнее моих собственных.
Ожидание, как мне кажется, негативно влияет на удовлетворенность продуктом. Как и «естественное» (запрос к серверу, сохранение на диск), так и в искусственное. Ведь в данном случае, как опытный пользователь, я знаю чего хочу. Неопытный, в любом случае будет сначала изучать этот диалог.
[user mode]
Нужна его найти в одном из 7 меню; затем «получить» всплывающее окно (у меня оно выскочило на основном мониторе, браузер был на втором); затем нужно понять, что тебе нужно («Расширения», «Темы» или «Плагины»); понять, что нужен поиск; установить, глядя на окно установки так долго, что даже не заметив как пройдет эти пять (три?) секунд.
А затем нужно ещё перезагрузить.
А я всего-то хотел заблокировать рекламу.
[/user mode]
Понятно, что мы этого не заметим, мы привыкли и многое делаем на автомате и многое сделаем быстрее.
Но мы же делаем продукты для пользователей?
Разработчики стараются всяческими способами привлечь внимание к тому, что происходит. С помощью диалогов, всплывающих окон, изменение формы, цвета. В общем, всячески уменьшить время полезной работы пользователя, которое он тратит на то, что хочет («Я хочу прочитать веб-страницу»), и увеличивает время на совсем не нужные вещи («Нет, я не хочу делать тебя стандартным браузером!», «Нет, я не хочу работать в автономном режиме!», «Да, я уверен, что хочу передавать данные в сеть!», «Нет, я не хочу, чтобы ты запоминал мои данные!»), которые нужно осмыслить и совершить действие.
Удовольствие от таких продуктов мало, причем имеет зависимость от опыта пользователя. Опытные пользователи достаточно «легко» пройдут такие диалоги, может быть испытывая легкое раздражение, неопытные же будут вынуждены читать и думать.
Всем разработчика нужно помнить, что нужно создавать продукты с наименьшим когнитивным сопротивлением, чтобы пользователь не «продирался сквозь колючки», а как минимум, делал нужную работу, а ещё лучше получал при этом удовольствие от того, насколько он это круто делает.
Прощу прощения за длинный комментарий.
Кроме того, многие опытные пользователи используют расположение кнопок, как карту в сознании, с помощью которой они преодолевают эти «ужасные» диалоги, то есть отмены слева, кнопка совершения действия — справа. А что если таких кнопок будет несколько? Иначе может быть только в диалогах с двумя кнопками, большее двух кнопок может ввести пользователя в заблуждение.
И даже привыкнув и поняв, он научиться преодолевать ваши диалоги не замечая колючих кнопок. Сами вспомните, как вы удаляете файлы из корзины. Будете ли вы каждый раз читать, что там написано если там будет такая колючка?
В общем, это интересно, но нужно крепко подумать, при неумелом использовании это может превратиться в хаос.
В общем, его надо уметь готовить :-)
Условия это прерогатива только бизнес-слоя?
А если мне надо присвоить класс для элемента, в зависимости от входящих данных?
А если мне нужно поменять название класса, мне нужно будет лезть в бизнес-логику где и менять название?
Я имел ввиду ситуации, когда, например, тег или атрибуты зависят от параметров, тогда приходится применять xsl:if или xsl:choose, что увеличивает размер кода. В итоге для одного элемента можно получить десяток строчек кода.
В других шаблонизаторах будет также, но в XSLT каждое такое условие или решение — это тег, что увеличивает размер кода и визуально это выглядит довольно громоздко.
Я думаю, для некоторых это отталкивающий фактор.
А вообще, связка XML/XSLT и так довольно муторна — иногда для одного HTML тега столько наворотишь.
Но гибкая и требует грамотного подхода, абы как не сделаешь.
За что до сих пор и люблю. :-)
В своё время выбрали серверную обработку XSLT и сопутствующие вкусности, добавили кеширование и вуаля…
Опять же, каждому своё.
Просто и как Ленин завещал :-)