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