Comments 24
А еще интересно было бы рассмотреть интерфейс с точки зрения опыта пользоветеля, особенно это касается сложных многофунциональных систем. Например прятать какую-то часть функционала от новичка, и постепено добавлять с ростом его навыков пользования системой.
Согласен. Это вполне вписывается в эту концепцию. Так же добавлю, что как один из путей развития автоматической настройки интерфейсов можно подумать о accessibility. Скажем на входе в систему человек указывает свои возможности и интерфейс под них подстраивается. Но для меня эта история ещё только впереди)
А служба поддержки и даже сами разработчики через некоторое время сойдут с ума (у Иванова кнопка есть, а у петрова, а у инденера тех поддержки вообще другая форма открывается).
Во избежание этого настройки UI пользователя должны уходить на сервер разработчика (или иным образом быть ему доступны).
UFO just landed and posted this here
Ваше замечание валидное. Подобное тоже приходило мне в голову, но такое поведение кажется уж очень сложным, то есть спроектировать систему таким образом логически не просто.
А вообще я думаю названия менять не стоит. За определённой функцией в системе спрятано определённое действие. Имя должно отображать суть этого действия. Если названия меняются, а функция остаётся прежней, то больше похоже на логическую ошибку.
А вообще я думаю названия менять не стоит. За определённой функцией в системе спрятано определённое действие. Имя должно отображать суть этого действия. Если названия меняются, а функция остаётся прежней, то больше похоже на логическую ошибку.
Тоже мне проблема.
В опере престо видимые пользователю именования пунктов меню можно было переименовать как угодно — потому что на уровне движка броузер для менюшек оперировал уникальными системными идентификаторами.
Соответственно саппорт накатывает свой профиль с соответствием идентификатор-именование и видит свои стандартные наименования.
В опере престо видимые пользователю именования пунктов меню можно было переименовать как угодно — потому что на уровне движка броузер для менюшек оперировал уникальными системными идентификаторами.
Соответственно саппорт накатывает свой профиль с соответствием идентификатор-именование и видит свои стандартные наименования.
Я думаю во времена консоли и перехода к графической оболочке так же были подобные мнения.
Просто система в целом должна быть для этого подготовлена, это же пока размышления )
Просто система в целом должна быть для этого подготовлена, это же пока размышления )
В точку! В первое время мы столкнулись с зачатками этой проблемы, но об этом во второй части) Эта же про теорию и возможности.
Сразу скажу, что адекватный вариант решения тут один — зайти от лица пользователя (скажем access code какой-нибудь на один час). Но в любом случае при таком подходе требуется иметь очень грамотный штат тех. поддержки, которая будет в курсе работы принципов и механик настройки интерфейса
Сразу скажу, что адекватный вариант решения тут один — зайти от лица пользователя (скажем access code какой-нибудь на один час). Но в любом случае при таком подходе требуется иметь очень грамотный штат тех. поддержки, которая будет в курсе работы принципов и механик настройки интерфейса
UFO just landed and posted this here
В этом стремлении к идеалу главное всегда помнить простую вещь — всем не угодишь никогда. Вот парни из одной редмондской компании очень хорошо это понимают.
Тут немного мерзкой действительности — когда у всех всё «одинаковое», и у одному неудобно, то это его проблема. А когда всё у всех разное, но один не смог найти свой идеал — это ваша проблема. А у вашей компании есть ресурсы решать такие проблемы?
Тут немного мерзкой действительности — когда у всех всё «одинаковое», и у одному неудобно, то это его проблема. А когда всё у всех разное, но один не смог найти свой идеал — это ваша проблема. А у вашей компании есть ресурсы решать такие проблемы?
Боюсь «мерзкая действительность» действительно существует.
Что же про ресурсы, то мы их на решение таких проблем не имеем. И да, сейчас мы придерживаемся схожего с вами мнения про удобство и не удобство одинаковых интерфейсов для разных пользователей.
Но это, кстати, решаемая проблема. Можно возложить настройку на пользователя. И это имеет сплошные плюсы. Все детали будут во второй статье.
Что же про ресурсы, то мы их на решение таких проблем не имеем. И да, сейчас мы придерживаемся схожего с вами мнения про удобство и не удобство одинаковых интерфейсов для разных пользователей.
Но это, кстати, решаемая проблема. Можно возложить настройку на пользователя. И это имеет сплошные плюсы. Все детали будут во второй статье.
Рабочий стол на компе или телефоне — пример такого гибкого интерфейса. Когда разные кластеры пользователей используют разный функционал продукта — это самое лучшее решение.
У каждого на телефоне разный набор иконок, но ни у кого это не вызывает вопросов.
Вопросы у вас будут возникать когда вы не найдете настройки вайфая там где они должны быть.
Я понимаю ваши опасения, но как я писал выше, гибкость системы в руках её разработчиков. Если проектирование будет таким, что всё скачет перед глазами пользователя, то тут уж не вина концепции, а, как говорил мой преподавать, «кудрявые ручки».
Хочу отметить, что эта статья про размышления и без неё я не мог позволить себе говорить о практической части. Во второй части я расскажу что сделал, чтобы избежать подобных проблем с вайфаем.
Хочу отметить, что эта статья про размышления и без неё я не мог позволить себе говорить о практической части. Во второй части я расскажу что сделал, чтобы избежать подобных проблем с вайфаем.
Отличное замечание! Примерно о подобном и пойдёт речь во второй части. Особенности мобильного телефона и рабочего стола в том, что пользователь сам настраивает себе окружение. Тут важно понимать, что система предлагает ему такую возможность.
Тут следует упомянуть управляемый интерфейс от 1с, где пользователь сам может настраивать (скрывать, перетсавлять, задавать условное оформление) элементы интерфейса.
Вы правы, в общем в этом направлении мы и пошли. Во второй части я расскажу о подходе и гипотезах, которые мы проверяли, а так же о том, что мерили как это отразилось на пользователях.
Можем копнуть глубже и вспомнить microsoft office, который еще в 98 версии позволял вынести нужные значки в быстрый доступ, а лишнее убрать
Я не претендую на уникальность разработки, скорее хочу подчеркнуть, что вижу ценность в том, чтобы софт был максимально полезен и не отвлекал людей от их основного рода деятельности. Люди любят свою работу, но случается, что процессы и софт вокруг приносят сплошное разочарование от процесса.
Можем копнуть глубже и вспомнить microsoft office, который еще в 98 версии позволял вынести нужные значки в быстрый доступ, а лишнее убрать
Я не претендую на уникальность разработки, скорее хочу подчеркнуть, что вижу ценность в том, чтобы софт был максимально полезен и не отвлекал людей от их основного рода деятельности. Люди любят свою работу, но случается, что процессы и софт вокруг приносят сплошное разочарование от процесса.
Вообще не вижу проблемы, многий софт (не мобильный) давно так умеет, но 99,9% пользователей этим не пользуются. Настройка меню (т.е. функционала) под себя (и/или в зависимости от роли) присутствует очень давно и очень много где.
Далее, даже если пользователь может переименовать (вместо — «Файл->Открыть» хочет — «Планетарные->Вжухнуть»), то пусть делает что хочет. Нажатие кнопки, ярлыка, картинки и т.д. не должно вызывать функцию напрямую, а должно генерировать событие с уникальным ID, которое обрабатывается основным потоком и уже выполняет функцию. И тогда можно пользователю хоть самому рисовать интерфейс. Хочешь это будет пункт меню, хочешь ярлычок, а можно и параллельно.
И, как уже говорил выше, все это давно есть и применяется. Но обычно в корпоративной среде, обычным пользователям это мало интересно.
Далее, даже если пользователь может переименовать (вместо — «Файл->Открыть» хочет — «Планетарные->Вжухнуть»), то пусть делает что хочет. Нажатие кнопки, ярлыка, картинки и т.д. не должно вызывать функцию напрямую, а должно генерировать событие с уникальным ID, которое обрабатывается основным потоком и уже выполняет функцию. И тогда можно пользователю хоть самому рисовать интерфейс. Хочешь это будет пункт меню, хочешь ярлычок, а можно и параллельно.
И, как уже говорил выше, все это давно есть и применяется. Но обычно в корпоративной среде, обычным пользователям это мало интересно.
>Настройка меню (т.е. функционала) под себя (и/или в зависимости от роли) присутствует очень давно и очень много где.
К сожалению тренд ориентирован на то что пользователя старательно приучают к мысли что жрать надо что дают, настраивать ничего нельзя, а те кто хочет что-то менять — это какие-то фрики.
К сожалению тренд ориентирован на то что пользователя старательно приучают к мысли что жрать надо что дают, настраивать ничего нельзя, а те кто хочет что-то менять — это какие-то фрики.
Но обычно в корпоративной среде, обычным пользователям это мало интересно.
Наш опыт показывает противоположное: у нас много положительной обратной связи от обычных пользователей (doers). Но опять же, подчеркну, что эта статься не только про настройку интерфейса, а про возможности которые открываются, если вести разработку продукта таким образом.
Sign up to leave a comment.
Персонализированный интерфейс. Часть 1. Плюсы и минусы концепции