Привет, All!

При борьбе за производительность системы, родился способ, выяснить качество UI. Надо всего-лишь сделать, чтобы время реакции системы на каждое действие пользователя занимало секунд 10. Тогда, качество UI можно легко оценить по накалу глаз пользователей

Например, это покажет, выполняется ли классическое требование, чтобы проведение множества одинаковых операций над разными объектами требовало не больше чем на 20% времени больше, чем одной операции над одним объектом. Если интерфейс сделан в виде списка объектов, по каждому из которых надо щелкнуть мышкой и выбрать действие — то общее время сразу будет равно 10 с * количество объектов. А если интерфейс построен таким образом, что надо выбрать операцию, а потом просто отметить все требуемые объекты — то время останется на уровне 10 с. Думаю, понятно, какой бухгалтер прибежит (позвонит) в техподдержку первым А когда система работает так как надо, разница может быть незаметна и не вызовет раздражения.


Сорри, если идея не новая). И можно это проверять не на пользователях, а на тестерах — это гуманнее.

S>При борьбе за производительность системы, родился способ, выяснить качество UI. Надо всего-лишь сделать, чтобы время реакции системы на каждое действие пользователя занимало секунд 10. Тогда, качество UI можно легко оценить по накалу глаз пользователей

Ерунда. Качество UI определяется не столько количеством физических действий, сколько затраченной умственной энергией пользователя.

Конечно, эти параметры связаны, но очень нелинейно.

Распространенная ошибка — оптимизировать UI, стремясь исключительно к уменьшению количества «кликов».

Таким образом легко сделать UI, непонятный для пользователя, когда ему приходится мучительно напрягать мозг, пытаясь понять, как сделать то или иное действие.

Пример: горячие клавиши.

Если вы попробуете построить весь UI только на горячих клавишах, количество физических действий в нем, конечно, будет минимальным.

Однако пользователь вряд ли скажет вам спасибо.

Здравствуйте, Аноним, Вы писали:

S>>При борьбе за производительность системы, родился способ, выяснить качество UI. Надо всего-лишь сделать, чтобы время реакции системы на каждое действие пользователя занимало секунд 10. Тогда, качество UI можно легко оценить по накалу глаз пользователей

А>Ерунда. Качество UI определяется не столько количеством физических действий, сколько затраченной умственной энергией пользователя.

Это тоже. Одно другое не исключает.

Здравствуйте, Аноним, Вы писали:

А>Если вы попробуете построить весь UI только на горячих клавишах, количество физических действий в нем, конечно, будет минимальным.

А>Однако пользователь вряд ли скажет вам спасибо.

Спорно. Пользователи они, знаете ли, разные. И юзабилити, дизайн программы должен исходить от целевой группы пользователей. То что подходит кассирам, клеркам в банке, программистам, может не подойти домохозяйке. Из личного наблюдения: если у пользователя есть программа с которой он работает 60-80% своего времени, то играют роль две вещи:
1. Быстрота получения нужного результата
2. Насколько система удобно и информативно показывает этот результат

Мое мнение такое: все рутинные действия, частые операции должны выполнятся как можно меньшими телодвижениями, в то же время должна оставаться возможность выполнить что-то менее стандартное в понятной и удобной форме (как пример поиск и расширенный поиск).

Здравствуйте, Twirl, Вы писали:

T>Мое мнение такое: все рутинные действия, частые операции должны выполнятся как можно меньшими телодвижениями, в то же время должна оставаться возможность выполнить что-то менее стандартное в понятной и удобной форме (как пример поиск и расширенный поиск).

Вы теоретизируете Это чисто практический способ, который неожиданно у меня сработал. В том то и дело, что теоретически у вас может быть все выверено — однако на практике пользователи либо не умеют пользоваться правильно программой, либо программа работает не так как вы хотели — и все узкие места сразу всплывут.

Здравствуйте, Sshur, Вы писали:

S>Например, это покажет, выполняется ли классическое требование, чтобы проведение множества одинаковых операций над разными объектами требовало не больше чем на 20% времени больше, чем одной операции над одним объектом. Если интерфейс сделан в виде списка объектов, по каждому из которых надо щелкнуть мышкой и выбрать действие — то общее время сразу будет равно 10 с * количество объектов. А если интерфейс построен таким образом, что надо выбрать операцию, а потом просто отметить все требуемые объекты — то время останется на уровне 10 с. Думаю, понятно, какой бухгалтер прибежит (позвонит) в техподдержку первым А когда система работает так как надо, разница может быть незаметна и не вызовет раздражения.

Если вы сначала выбираете действия, а потом выделяете объекты, то вам придется добавить лишнее действие (подтверждение), которое будет означать, что выбранное действие можно выполнять (все нужные объекты выбраны). Это раз.

Во вторых, такая модель неудобна при выполнении нескольких последовательных действий на одной группой объектов. В особенности если вы делаете undo/redo (например, в графическом редакторе)

Если вы хотите упростить доступ к "типовым" действиям, просто сделайте "панель быстрого доступа" к наиболее чсасто используемым действиям. Вот, например, для сотовых телефонов есть такой интерфейс, когда на экран выдается список телефонов, первыми из которых стоят не как обычно последние набранные, а чаще всего набираемые за какой-то период. Если воспользховаться таким же принципом, то каждому пользователю вашей программы можно генерировать свою панель быстрого доступа, и бухгалтер, который будет выписывать счета, будет иметь свой набор операций, а бухгалтер, приходующий товары — свой.

Здравствуйте, Spidola, Вы писали:


S>Если вы хотите упростить доступ к "типовым" действиям, просто сделайте "панель быстрого доступа" к наиболее чсасто используемым действиям. Вот, например, для сотовых телефонов есть такой интерфейс, когда на экран выдается список телефонов, первыми из которых стоят не как обычно последние набранные, а чаще всего набираемые за какой-то период. Если воспользховаться таким же принципом, то каждому пользователю вашей программы можно генерировать свою панель быстрого доступа, и бухгалтер, который будет выписывать счета, будет иметь свой набор операций, а бухгалтер, приходующий товары — свой.

Я не о том говорил. Пусть будет список типовых действий или любой другой вариант упрощения доступа к наиболее используемым операциям. Если в вашем примере бухгалтер для выписки 10 счетов на 10 одинаковых товаров 10 раз выберет операцию, даже из списка "любимых" — это плохо. И если выписка каждого счета занимает меньше секунды плюс у него уйдет секунд 10 на выбор товара и подтверждение, то он управится за несколько минут, это не так заметно. А если выписка будет занимать минут 5 — то это сразу выплывет. Один раз подождать 5 минут человек сможет, а вот 50 — уже нет. Это все как пример использования такого "стресс тестирования".

Здравствуйте, Sshur, Вы писали:

S>Я не о том говорил. Пусть будет список типовых действий или любой другой вариант упрощения доступа к наиболее используемым операциям. Если в вашем примере бухгалтер для выписки 10 счетов на 10 одинаковых товаров 10 раз выберет операцию, даже из списка "любимых" — это плохо. И если выписка каждого счета занимает меньше секунды плюс у него уйдет секунд 10 на выбор товара и подтверждение, то он управится за несколько минут, это не так заметно. А если выписка будет занимать минут 5 — то это сразу выплывет. Один раз подождать 5 минут человек сможет, а вот 50 — уже нет. Это все как пример использования такого "стресс тестирования".

Я, честно говоря, так и не понял, причем тут "стресс-тестирование"...

Если разговор идет о выписке нескольких однотипных счетов, то имеет место обычная Batch операция, когда открывается окно выписки счета, где указываются товары, а потом предлагается список контрагентов, из которых выбираются нужные, после чего счета выписываются пачкой.

Если же разговор идет о выписке нескольких счетов с разными товарными позициями, то экономии времени от того, что после выписки одного счета сразу возникет окно для выписке следующего счета, весьма сомнительна.

Поведение системы в таком случае должно определяться количеством счетов, которые одновременно выписываются пользователем "обычно".

Вообще неплохо было бы поподробнее описать use-case, поскольку пока непонятна область применения вашей идеи.

Здравствуйте, Spidola, Вы писали:

S>Вообще неплохо было бы поподробнее описать use-case, поскольку пока непонятна область применения вашей идеи.

Насчет use-case не знаю, но идея простая — делаем время реакции системы на любое действие пользователя в интерфейсе достаточно заметным для пользователя, например минуту. Берем самых закаленных пользователей или тестеров и заставляем их работать. Смотрим, на какие операции они будут жаловаться больше всего — и изучаем их на предмет оптимизации юзабилити.

Насчет жизнеспособности не уверен, у меня так само собой получилось из-за тормозов программы, возникших по ошибке. Эффект дало.

Кстати, можно не все операции "тормозить", а самые редкоиспользуемые по мнению разработчиков. Не секрет, что пользователи зачастую используют ПО не таким образом, как то было запланировано разработчиками, по причине незнания либо потому, что предложенный разработчиком способ неудобен. Вот оно и всплывет.

Здравствуйте, Sshur, Вы писали:

S>Здравствуйте, Spidola, Вы писали:

S>>Вообще неплохо было бы поподробнее описать use-case, поскольку пока непонятна область применения вашей идеи.

S>Насчет use-case не знаю, но идея простая — делаем время реакции системы на любое действие пользователя в интерфейсе достаточно заметным для пользователя, например минуту. Берем самых закаленных пользователей или тестеров и заставляем их работать. Смотрим, на какие операции они будут жаловаться больше всего — и изучаем их на предмет оптимизации юзабилити.

Во-первых, если сделать время реакции достаточно большое, то жаловаться пользователи будут на все операции. Во-вторых, "жалобы" пользователя в usability-тестировании рассматриваются в последнюю очередь, поскольку жалдоба — понятие субъективное. одни жалуются, другие нет. Нужно анализировать поведение пользователя (1) и, если хотите, замерять реальное время работы пользователя с каждым оптимизируемым use-case и , на основании замеров, интерпретировать проблему(2). Третье несоответствие — это брать выборку пользователей ("самых закаленных") вместо выборки реальных пользователей, поскольку вы получите результат для "самых закаленных", а не для тех, кто будет реально использовать систему.

S>Насчет жизнеспособности не уверен, у меня так само собой получилось из-за тормозов программы, возникших по ошибке. Эффект дало.

Согласен, что в конкретном вашем случае может быть эффект. Однако как методику, на мой взгляд, использовать нецелесообразно.

S>Кстати, можно не все операции "тормозить", а самые редкоиспользуемые по мнению разработчиков.
А вот тут тоже несколько нюансов )) Редкоиспользуемые операции оптимизировать себе дороже, поскольку выключается принцип 20 на 80 и ваше потраченное время никто не оценит. Что касается мнения разработчиков — то оно здесь тоже не требуется — проще посмотреть лог использования системы и точно определить, какие операции какими пользователями чаще/реже используются.

S> Не секрет, что пользователи зачастую используют ПО не таким образом, как то было запланировано разработчиками, по причине незнания либо потому, что предложенный разработчиком способ неудобен. Вот оно и всплывет.

Здесь вижу попытку сделать замер поведения пользователя. Думаю, что обычный скринкаст (а можно и с видеосъемкой) даст куда как больше информации. Пример такого исследования можнопосмотреть здесь (http://www.usametrics.ru/usability_research.asp)

Здравствуйте, Sshur, Вы писали:

S>При борьбе за производительность системы, родился способ, выяснить качество UI. Надо всего-лишь сделать, чтобы время реакции системы на каждое действие пользователя занимало секунд 10. Тогда, качество UI можно легко оценить по накалу глаз пользователей

Мне кажется, что при времени реакции системы на каждое действие порядка 10 секунд потребуется существенно другой UI. Который, в свою очередь, будет ужасен при времени реакции 0.5 сек.

Поэтому IMHO способ не очень применим.

Здравствуйте, Spidola, Вы писали:

S>Если вы хотите упростить доступ к "типовым" действиям, просто сделайте "панель быстрого доступа" к наиболее чсасто используемым действиям. Вот, например, для сотовых телефонов есть такой интерфейс, когда на экран выдается список телефонов, первыми из которых стоят не как обычно последние набранные, а чаще всего набираемые за какой-то период. Если воспользховаться таким же принципом, то каждому пользователю вашей программы можно генерировать свою панель быстрого доступа, и бухгалтер, который будет выписывать счета, будет иметь свой набор операций, а бухгалтер, приходующий товары — свой.

Этот подход был опробован Microsoft в Windows 2000, Office не помню каком, и Internet Explorer’е тоже не помню каком, под кодовым именем Personalized Menus. Вывод был сделан — «нафиг, нафиг». Потому что пользователи стали жаловаться — «вчера оно было, а [ночью робот собрал статистику использования и] сегодня его нет, верните взад!».

Здравствуйте, Centaur, Вы писали:

C>Здравствуйте, Spidola, Вы писали:

S>>Если вы хотите упростить доступ к "типовым" действиям, просто сделайте "панель быстрого доступа" к наиболее чсасто используемым действиям. Вот, например, для сотовых телефонов есть такой интерфейс, когда на экран выдается список телефонов, первыми из которых стоят не как обычно последние набранные, а чаще всего набираемые за какой-то период. Если воспользховаться таким же принципом, то каждому пользователю вашей программы можно генерировать свою панель быстрого доступа, и бухгалтер, который будет выписывать счета, будет иметь свой набор операций, а бухгалтер, приходующий товары — свой.

C>Этот подход был опробован Microsoft в Windows 2000, Office не помню каком, и Internet Explorer’е тоже не помню каком, под кодовым именем Personalized Menus. Вывод был сделан — «нафиг, нафиг». Потому что пользователи стали жаловаться — «вчера оно было, а [ночью робот собрал статистику использования и] сегодня его нет, верните взад!».

Про телефон я упомянул исключительно с точки зрения примера панеоли как таковой. Принцип её формирования — это отдельный вопрос. В случае с бухгалтерами можно использовать как раз принцип персонализации рабочего стола, принятый в классияечких портальных решениях, а другими словами выводить на кнопки быстрого доступа те операции, которые каждый конкретный бухгалтер чаще всего использует.

Пример из другной области: есть ресторанный софт, который установлен в гостинице. Несколько терминалов в обеденном зале, баре, кафе на веранде и т.п. У каждого официанта, работающего в своем месте, есть панель быстрого заказа, которую отчасти он сам набирает и фиксирует, отчасти набирается сама по статистике.

У Microsoft-а я готов посчитать аналогом панели быстрого доступа весь интерфейс офиса 2007, в котором все часто используемые операции выведены на панели быстрого доступа, а нечасто используемые упрятаны глубоко в интерфейс. Согласен, что в офисе нет статистического перерасчета панели, но, в данном случае, это и не нужно.

Здравствуйте, wildwind, Вы писали:


W>Мне кажется, что при времени реакции системы на каждое действие порядка 10 секунд потребуется существенно другой UI. Который, в свою очередь, будет ужасен при времени реакции 0.5 сек.

W>Поэтому IMHO способ не очень применим.

Не обязательно. Пример уже приводил — представьте, что вам надо удалить 100 файлов, а множественное выделение в вашем любимом файловом менеджере сделать забыли... И каждый файл удаляется секунд по 10. Как скоро вы помянете разработчиков добрым словом?

Здравствуйте, Spidola, Вы писали:

S>> Не секрет, что пользователи зачастую используют ПО не таким образом, как то было запланировано разработчиками, по причине незнания либо потому, что предложенный разработчиком способ неудобен. Вот оно и всплывет.

S>Здесь вижу попытку сделать замер поведения пользователя. Думаю, что обычный скринкаст (а можно и с видеосъемкой) даст куда как больше информации. Пример такого исследования можнопосмотреть здесь (http://www.usametrics.ru/usability_research.asp)

Это скорее немного негуманный способ получить фидбек от пользователей Крайне редко попадаются толковые пользователи, которые сами обращаются в поддержку и обращают внимание на реальные недоработки. Ну, и бывает о какой-то ошибке тоже молчат долго. А тут по сути они не смогут работать с системой — и будут вынуждены обратиться в поддержку.

Ну, а что касается скрин кастов — ну нет у нас достаточного штата разработчиков, чтобы наблюдать в течении долгого времени за пользователями. Вот если бы как-то автоматизировать процесс..

Повторюсь, я не претендую на универсальный способ решения всех проблем. Это получилось само собой и был получен неожиданный результат).

Здравствуйте, Sshur, Вы писали:
S>Не обязательно. Пример уже приводил — представьте, что вам надо удалить 100 файлов, а множественное выделение в вашем любимом файловом менеджере сделать забыли... И каждый файл удаляется секунд по 10. Как скоро вы помянете разработчиков добрым словом?
К сожалению, это совершенно очевидный и шибко частный пример.
Привожу альтернативный пример — вы делаете интерфейс с драг-н-дропом. Поставив вот такие 10-секундные замедления, вы сделаете следующие выводы:
1. Динамическая подсветка дроп таргетов — зло; она чудовищно тормозит процесс при проносе над неверными таргетами
2. Драг-н-дроп — вообще зло. Лучше его не делать, потому что воспользоваться им правильно практически невозможно.

Убрав замедления, вы сделаете совершенно обратные выводы.

Здравствуйте, Sinclair, Вы писали:

S>Привожу альтернативный пример — вы делаете интерфейс с драг-н-дропом. Поставив вот такие 10-секундные замедления, вы сделаете следующие выводы:
S>1. Динамическая подсветка дроп таргетов — зло; она чудовищно тормозит процесс при проносе над неверными таргетами
S>2. Драг-н-дроп — вообще зло. Лучше его не делать, потому что воспользоваться им правильно практически невозможно.

S>Убрав замедления, вы сделаете совершенно обратные выводы.

Нет, придем ровно к тем же выводам — что надо переносить кучу объектов за раз. Может быть, стоило уточнить, куда надо вставлять замедления. Надо замедлять общую реакцию системы на действие пользователя, а не каждое действие, выполняемое системой.

В случае с драг-н-дропом дейсвтия у получается следующая последовательность — пользователь выделил файлы, подождал 10 сек подтверждения, перенес их в нужное место, подождал еще 10 сек и все. Не надо доводить до абсолюта, например, реакцией системы можно считать и появление символов на экране после нажатия на клавиатуре, вот их явно не стоит замедлять. (хотя студия с решарпером у меня так иногда начинает работать, очень стимулирует использовать copy&paste)

Надо наверно разделить реакцию системы на выполнение бизнес-задачи пользователя и на выполнение служебных задач типа отрисовки плавающих меню.

Здравствуйте, Sshur, Вы писали:

S>Повторюсь, я не претендую на универсальный способ решения всех проблем. Это получилось само собой и был получен неожиданный результат).

Главное, что результат получен. Если положительный, то способ имеет право на жизнь )