Комментарии 27
Посмотрел видео «Новичок» и ожидал, что после того как появилась рабочая область, надо будет выбирать из левого меню иконки и выполнять какие то действия. Ну это видимо из «Фотошопа» и «Ворда» привычка. Какого же было мое удивление, что они не нужны и надо «кликать» на рабочую поверхность для работы. Мне кажется есть куда еще стремиться.
*сорри, промахнулся с ответом
Вы правы, кликать нужно (и можно) именно на панель слева. В CTP версии мы для простоты, а также заполнения пустоты, сделали эти же кнопки в рабочем пространстве. У нас уже есть прототип нового дизайна, поправим это к релизу (возможно бете).
*сорри, не кликнул на «ответить»
*сорри, не кликнул на «ответить»
Ребята, вы молодцы :-) Единственный нюанс — скроллбар выполняет не только функцию управления, но и функцию уведомления о том, что часть данных скрыта. Если вы скрываете скроллбар, то нужно иным способом уведомлять о переполнении. Например, классический приём с тенюшкой.
Спасибо!:) Да, этот момент с индикацией «заполнения» является узким местом. Рад, что Вы заметили. Затенение — хороший вариант для обсуждения с дизайнером, но скорее всего ему не понравится «замыливание») В данный момент по нашей статистике, лишь единичные наши пользователи не очень довольны отсутствием видимости скрола, поэтому мы пока не зафорсили фикс этой проблемы. То, что есть над чем подумать — это факт.
НЛО прилетело и опубликовало эту надпись здесь
Да, безусловно Ваше замечание верно.
Статистикой мы можем называть лишь количество запросов нам в поддержку. На этот вид скрола был всего один запрос (такой скрол мы впервые внедрили около 2 лет назад в нашем старом вьювере аналитических панелей).
Но Вы правы насчёт того, что это может быть проблемой. Некоторые коллеги мне говорили про это, я убеждал их, что навести мышь — не трудно:) Нужно будет подумать, как это решать. Сейчас наведение мышки его показывает. Теоретически может быть опция типа «всегда показывать скрол» (тем более наш продукт — ASP.NET контрол).
Статистикой мы можем называть лишь количество запросов нам в поддержку. На этот вид скрола был всего один запрос (такой скрол мы впервые внедрили около 2 лет назад в нашем старом вьювере аналитических панелей).
Но Вы правы насчёт того, что это может быть проблемой. Некоторые коллеги мне говорили про это, я убеждал их, что навести мышь — не трудно:) Нужно будет подумать, как это решать. Сейчас наведение мышки его показывает. Теоретически может быть опция типа «всегда показывать скрол» (тем более наш продукт — ASP.NET контрол).
Почему вы считаете что у пользователя есть мышь? Он вполне может работать с планшета.
На планшете у нас «родной» скрол (по крайней мере на iOS и Surface). И здесь уже вопрос привычки — мы не можем менять нативное поведение.
В общем-то конечно на тач устройстве может быть ситуация, когда будет работать наш скрол. Это может быть банально тач-монитор. Здесь проблема будет, бесспорно. Пользователю придётся «тыкать» в элемент, чтобы понять, что он показан не полностью.
«При этом ни в коем случае не слушать, что они просят», собственно это и есть ответ на вопрос, почему нет «волшебных интерфейсов». Разработчики наверняка уверены, что их текущий интерфейс лучше всего отвечает поставленным задачам. А пользователи? Ну так, они сами не знают чего хотят:)
Лично для меня интерфейс iOS — волшебный. Описанный наш — я верю, близок к волшебному:)
Конкретно по Вашему предложению — пользователи не знают чего хотят, но они могут сказать «Вау! Вот оно!» — и когда таких пользователей достаточное количество, это и есть тот случай, когда интерфейс можно назвать «волшебным» (на мой взгляд).
Чтобы пользователи так сказали, опять же лично я уверен — разработчикам нужно знать все описанные в источниках принципы и понимать как это воплотить в жизнь.
Конкретно по Вашему предложению — пользователи не знают чего хотят, но они могут сказать «Вау! Вот оно!» — и когда таких пользователей достаточное количество, это и есть тот случай, когда интерфейс можно назвать «волшебным» (на мой взгляд).
Чтобы пользователи так сказали, опять же лично я уверен — разработчикам нужно знать все описанные в источниках принципы и понимать как это воплотить в жизнь.
По иронии судьбы прочитал эту статью, в то время как на ноутбуке обновлялась Windows 10. На экране в течение > 40 минут виднелись две строки:
И никакого индикатора выполнения! Ни графического, ни числового. Что мне оставалось думать, когда 40 минут на быстром железе с SSD происходит непонятно что?
Configuring Windows updates
Do not turn off your computer
И никакого индикатора выполнения! Ни графического, ни числового. Что мне оставалось думать, когда 40 минут на быстром железе с SSD происходит непонятно что?
Вот вы упоминаете Тафти и тут же показываете аналоговые индикаторы, которые не умещаются в блок. Разве это волшебно?
Индикаторы (если Вы имеете ввиду Gauges) обычно нуждаются в дополнительной настройке под отведённую область. У нас сейчас есть 2 вида индикаторов — круговые и горизонтальные. Круговые позволяют изменять угол от 90 градусов до 360. Горизонтальные («градусники») обычно занимают весь прямоугольник. Размер занимаемой области настраивается ползунками лэйаута.
Или возможно Вы хотели бы видеть другие виды индикаторов?
Или возможно Вы хотели бы видеть другие виды индикаторов?
'Горизонтальные' — сорри, я имел ввиду линейные, они могут быть и вертикально ориентированными.
Я имею в виду стрелочные индикаторы, их использование оправдано, когда у вас много свободного места на экране и его можно занять украшательствами, но вы положили их в блок, который из-за размера индикатора получил скроллбар, а это не согласуется с принципом «больше полезных данных / меньше чернил».
Это вполне решается респонсивным отображением индикатора в зависимости от размера блока — либо мы его уменьшаем в размерах, либо заменяем на другой тип вплоть до текста, но избавляемся от скролла.
Это вполне решается респонсивным отображением индикатора в зависимости от размера блока — либо мы его уменьшаем в размерах, либо заменяем на другой тип вплоть до текста, но избавляемся от скролла.
Дело в том, что это просто демо-пример конкретной аналитической панели, в которой индикаторы я расположил так специально для этого видео, чтобы показать скрол не только в гриде. Я согласен, что здесь может возникнуть когнитивный диссонанс. Вы правы, именно с точки зрения визуализации данных вообще — это неудачный пример. Конечно же, скролы в индикаторах — это жестоко:) Но это не относится напрямую к нашему интерфейсу.
Мне кажется, что вся ваша работа над статьей перечеркнута одной неправильной картинкой про тропинки и дорожки. Разве у тропинки нет дизайна? Или у дорожки нет user experience? Если же вы говорите о usability, то подумайте о случае с тропинкой, если пойдет дождь и все превратится в грязь.
Похоже, Вы не верно поняли мысль, отображённую на этой известной картинке: спроектированная дорога не отражает опыт использования, пользователь выбирает путь обхода реализованного функционала, реализация не отражает его ментальную модель.
Я слышал, что в одном из московских ВУЗов перед тем, как делать дорожки, ректор сказал — «пусть сначала люди походят, где будут тропинки — там и сделаем». В реальных устройствах с интерфейсом такой подход редко осуществим, поэтому мы говорим о «desire lines». Более подробно здесь: Батлер Д., Лидвелл У., Холден К. 'Универсальные принципы дизайна', Питер, 2012; стр. 76.
Я слышал, что в одном из московских ВУЗов перед тем, как делать дорожки, ректор сказал — «пусть сначала люди походят, где будут тропинки — там и сделаем». В реальных устройствах с интерфейсом такой подход редко осуществим, поэтому мы говорим о «desire lines». Более подробно здесь: Батлер Д., Лидвелл У., Холден К. 'Универсальные принципы дизайна', Питер, 2012; стр. 76.
Пока я только понял, что на картинке неверные подписи. И писал я именно об этом. Или вы несогласны?
Вообще, это известная картинка, не я её придумал, есть куча мест, где она приводится в пример, есть указанный выше справочник, где подобное также приводится в пример.
Да, на мой взгляд подписи верные. На картинке показано, что User Experience= опыт использования (т.е. как людям удобно/соответствует их представлениям), отличается от задуманного разработчиками Design'а. У меня здесь сомнений нет.
Да, на мой взгляд подписи верные. На картинке показано, что User Experience= опыт использования (т.е. как людям удобно/соответствует их представлениям), отличается от задуманного разработчиками Design'а. У меня здесь сомнений нет.
Ну знаете, заборы тоже все исписаны, а толку там не много (:
Давайте я еще раз напишу свои мысли, а вы мне скажете, где я не прав.
*Design* — не то как выглядит, а то как работает. И тропинка, и дорожка работают (я могу воспользоваться обоими вариантами). Мы не говорим о том, какой из них лучше. Мы говорим о терминах. И дизайн есть у каждого из этих решений.
*User Experience* — это опыт взаимодействия и только так. Весь спектр эмоций и переживаний, которые у меня возникли при взаимодействии с конкретным объектом или системой. Я чувствую неровности на тропинке, или чувствую стыки плиток на дорожке. Но в обоих случаях есть чувства и эмоции. Следовательно, у обоих решений есть свой собственный User Experience.
И User Experience — это совсем не опыт использования. Дон Норман приводит отличный пример с соковыжималкой. У него отличный опыт взаимодействия с ней, но по факту он ей даже не пользовался. Следовательно, опыт взаимодействия и опыт пользования — разные вещи. Могут совпадать, а могу и нет.
То, что вы называете _удобно_ — *это usability*.
Что мы имеем в сухом остатке:
Оба решения имеют design и user experience. Однако, одно из решений более удобное, потому что экономит время. Поэтому правильными будут подписи «More usable» и «Less usable». И то, при определенных условиях.
Давайте я еще раз напишу свои мысли, а вы мне скажете, где я не прав.
*Design* — не то как выглядит, а то как работает. И тропинка, и дорожка работают (я могу воспользоваться обоими вариантами). Мы не говорим о том, какой из них лучше. Мы говорим о терминах. И дизайн есть у каждого из этих решений.
*User Experience* — это опыт взаимодействия и только так. Весь спектр эмоций и переживаний, которые у меня возникли при взаимодействии с конкретным объектом или системой. Я чувствую неровности на тропинке, или чувствую стыки плиток на дорожке. Но в обоих случаях есть чувства и эмоции. Следовательно, у обоих решений есть свой собственный User Experience.
И User Experience — это совсем не опыт использования. Дон Норман приводит отличный пример с соковыжималкой. У него отличный опыт взаимодействия с ней, но по факту он ей даже не пользовался. Следовательно, опыт взаимодействия и опыт пользования — разные вещи. Могут совпадать, а могу и нет.
То, что вы называете _удобно_ — *это usability*.
Что мы имеем в сухом остатке:
Оба решения имеют design и user experience. Однако, одно из решений более удобное, потому что экономит время. Поэтому правильными будут подписи «More usable» и «Less usable». И то, при определенных условиях.
*похоже опять промахнулся с ответом, сорри
Здесь не последние в России специалисты по интерфейсам (Артём Горбунов, Константин Горский) немного обсуждают термин «User Experiece». Расхождений с «опыт использования» я не вижу, хотя «опыт взаимодействия» — это перевод русской Википедии, я не вижу здесь критичных различий.
Здесь подробно обсуждается отличие концептуальной модели (собственно то, что спроектировали инженеры и дизайнеры) и ментальной модели.
Повторюсь, картинка показывает задуманную инженерами реализацию и то, что хотят пользователи (если выражаться неакадемическими терминами). На мой взгляд Вы «ищете чёрную кошку в тёмной комнате, когда её там нет». Но я ни в коем случае Вас не осуждаю, в целом Ваше понимание надписей я осознал, но я бы лишь не делал столь широкий вывод о перечёркивании работы над статьёй.
Здесь подробно обсуждается отличие концептуальной модели (собственно то, что спроектировали инженеры и дизайнеры) и ментальной модели.
Повторюсь, картинка показывает задуманную инженерами реализацию и то, что хотят пользователи (если выражаться неакадемическими терминами). На мой взгляд Вы «ищете чёрную кошку в тёмной комнате, когда её там нет». Но я ни в коем случае Вас не осуждаю, в целом Ваше понимание надписей я осознал, но я бы лишь не делал столь широкий вывод о перечёркивании работы над статьёй.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Волшебный интерфейс