Ввод данных в сетку

Question

Вопрос пользовательского интерфейса: есть ли какой-то консенсус по поводу лучшего (определяемого как "тот, который конечным пользователям нравится больше всего") или наименее плохого способа осуществления ввода данных в сетку?

У меня есть сетка, с множеством строк. Столбцы сетки содержат различные типы свойств, которые пользователь может вводить / редактировать. "Типы" свойств включают в себя:

• Свободный текст
• Числа (цифры)
• Перечисляемое значение (например, "High", "Medium" и "Low")
• Другие (например, дата, продолжительность)

Тип "свободный текст" не сложно спроектировать (поэтому я не буду спрашивать об этом), но как насчет следующих двух типов?

Числовые цифры

• Если вы используете клавиатуру для ввода числа, разрешите ли вы ввод произвольного текста, а затем запустите метод проверки на размытие? Или контролировать каждое нажатие клавиши, чтобы ввод данных ограничивался только цифрами?
• Как вы говорите пользователю (в сетке, а не в форме), что синтаксис данных в некотором столбце ограничен только числовым? Что вы делаете, если пользователь нажимает неправильную (не числовую) клавишу?
• Элемент управления "spin" или "spinner" является стандартным элементом управления Windows; уместно ли пытаться использовать его и в сетке на основе HTML?

Перечислите значения

Я полагаю, что для ввода или редактирования значения enum с помощью мыши нужно щелкнуть маленькое контекстное меню при щелчке мыши.

• Альтернативой является использование <select> управление вводом (т. е. поле со списком). Я полагаю, однако, что наличие целого столбца со списком не так просто для чтения, как наличие столбца с текстовым значением (потому что поля со списком добавляют дополнительные нетекстовые чернила)? Что вы думаете об обычном отображении простого текста, но о замене этого текста на поле со списком, когда поле получает фокус ввода (а затем удаление поля со списком при размытии)?
• Вы бы также открыли то же самое меню в фокусе, когда фокус изменяется в результате нажатия клавиши клавиатуры (т.е. клавиши [Tab]), а не мыши (т.е. щелчка)? Другими словами, должны ли вкладки в поле вызывать всплывающее меню? Кстати, всплывающие меню на основе CSS, которые я видел, реагируют на мышь, но не на клавиатуру (например, на клавиши со стрелками [Вверх] и [Вниз]). Знаете ли вы о какой-либо реализации ввода данных, подобной Intellisense, которая может работать в браузере?

Например?

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

---

Изменить: следуя другому вопросу с тегом [data-entry] (" Кто-нибудь использовал Sigma Grid (редактируемая сетка данных на основе Javascript)?"), Я смотрю на пример Sigma Grid. Он хорошо работает в IMO (хорошая поддержка клавиатуры и блоков выбора времени); но его поддержка числовых полей может быть несовершенной, например, если я нажимаю "a" в числовой ячейке, то иногда появляется окно с предупреждением о том, что я не прав (где, возможно, подсказка будет менее навязчивой), и / или иногда он оставляет клетку пустой (пустой), стирая "а" и ничего не оставляя на месте.

---

Отредактируйте в ответ на один из ответов ниже.

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

Я хочу, чтобы один и тот же дисплей (т. Е. Таблица / сетка) хорошо работал для отображения существующих свойств, создания новых свойств и редактирования существующих свойств. Я ожидаю десятки элементов (т.е. десятки строк данных), каждый из которых содержит всего несколько столбцов (например, один столбец описания текста / элемента, плюс 1 или более столбцов для 1 или более связанных свойств элемента).

Некоторые из данных / свойств могут быть субъективными и относительными (например, два свойства для каждого элемента являются "приоритетом" или "сложностью" каждого элемента, что особенно важно только по сравнению с другими элементами), что является причиной, почему я хочу отображать все данные вместе на одном экране: так, чтобы конечный пользователь мог сравнить их.

Мое приложение предназначено для относительно опытных (не начинающих) пользователей компьютеров, но не для специалистов по вводу данных: например, пользователи являются разработчиками программного обеспечения, менеджерами проектов, менеджерами продуктов, специалистами по обеспечению качества и т. Д., А также в некоторой степени их клиентами; он работает в интрасети (не в общедоступном Интернете), тем не менее, удобство использования и простота и / или интуитивность в изучении важны.

Кроме того, я не понимаю, почему удовлетворение пользователей клавиатуры полностью отличается от пользователей клавиатуры и мыши: я думал, что одно решение может / должно поддерживать либо и / или оба.

Answer 1

ИМХО, большой вопрос, который вам нужно задать, - это основная цель вашей страницы и относительная сложность ваших пользователей. Имеете ли вы дело с клавишами Tab+10, машинистами, щелкающими мышью + охота-пек, и тем, и другим?

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

Что касается числового ввода:

• Если вы планируете предоставить процедуру преобразования, вам не нужно ограничиваться цифрами.
• В случае, когда пользователь вводит недопустимый ввод (обратите внимание, что некоторые цифры, а не только текст могут быть недействительными... например, отрицательный возраст), вам лучше показать ошибку в строке и немедленно.
• Избегайте вращений, особенно если вы имеете дело с числами с десятичными знаками. Спиннеры отвлекают внимание от ввода данных и обеспечивают минимальное значение, если вы не имеете дело с конечным набором дискретных чисел. Если это так, то Combo/Select может быть лучше (я опишу почему в следующем посте).

Относительно значений перечисления:

• Избегайте всплывающих окон / контекстных меню, таких как чума. Они требуют от пользователя использовать мышь и отвлекать внимание от текущей задачи, буквально, когда вы создаете новое окно. Комбинирование / выбор дает пользователям некоторую степень опережающего ввода и позволяет выбирать клавиатуру с помощью стрелок.
• Поднятый вами вопрос о поле со списком (стрелка сброса затрудняет чтение текста) - это то, что вы можете облегчить с помощью решения для фокусировки, которое вы предоставляете, однако в целом вы можете сделать свою сетку более читабельной в целом с большим количеством отступов между строками и столбцами.,

Дополнительные комментарии:

• Свободный текст даты с преобразованиями, если это возможно. Если вы не планируете обучать своих пользователей или не решите использовать какую-нибудь драконовскую систему маскировки (и не менее раздражающую шлепок при неудаче проверки), им следует разрешать вводить даты так, как они хотят. Будьте осторожны, если вы имеете дело с иностранцами, они вводят месяцы и дни по-разному. SOP в США в мм / дд / гггг, тогда как многие страны предпочитают дд / мм / гггг.
• Если у вас есть большое количество полей, вы можете разделить ввод данных на несколько строк. Плоская сетка из> 10 столбцов довольно трудно понять в одном представлении. Недостатком этого является увеличенная вертикальная прокрутка, поэтому вам придется балансировать между важностью использования контекста данных (например, строк выше и строк ниже) при интерпретации текущей строки редактирования данных с одной стороны, и получения всех информация одного ряда (многострочная или H-прокрутка) в другом.

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

РЕДАКТИРОВАТЬ: Ответы на комментарии

Кроме того, я не понимаю, почему удовлетворение пользователей клавиатуры полностью отличается от пользователей клавиатуры и мыши: я думал, что одно решение может / должно поддерживать либо и / или оба.

Это не совсем другое. Думайте об этом как о разнице между "оптимизацией" и "поддержкой" большинства ваших пользователей. Несколько примеров: редакторы кода оптимизированы для пользователей клавиатуры. Между горячими клавишами, сочетаниями клавиш и навигацией с помощью клавиатуры пользователю редко требуется использовать мышь. Большинство игр RTS работают с использованием одной руки на мышь, другой на клавиатуре. Обычно они поддерживают исключительно использование мыши, но она не оптимизирована для этого. С другой стороны, ITunes - это почти исключительно мышь (как и большинство пользовательских интерфейсов, в которых доминирует перетаскивание), и использование только клавиатуры практически невозможно.

Вы разрешаете вход и отображаете ошибку; или запретить запись и отобразить ошибку? Что вы имеете в виду, показывая его "встроенным", когда это сетка (ячейка, где-то внутри таблицы)?

Я не уверен, на какой платформе вы строите, но да, я имею в виду где-то внутри таблицы, предпочтительно в строке данных, о которой вы говорите. В ASP.NET GridView позволяет использовать TemplateFields, которые позволяют вам встроить несколько элементов управления в одну и ту же "ячейку". В мире богатых клиентов большинство сторонних компонентов обеспечивают поддержку похожих вещей OOTB (например, IDataErrorInfo), которые выдают ошибки в контексте.

Если альтернативой является размещение всех ошибок над или под вашей сеткой, пользователям будет сложно определить, какая из десятков строк данных содержит ошибку. В качестве примера неоптимальной обработки этого, попробуйте добавить 10 товаров в корзину Amazon, затем измените все суммы на 2, кроме 1 товара, который вы измените на -1. Нажмите обновление и посмотрите, сможете ли вы легко перейти к строке с ошибками.

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

Ну, Intellisense или автозаполнение - это своего рода всплывающее окно, но им можно управлять с помощью (не отвлекающего внимания) клавиатуры.

Если вы можете поддерживать всплывающие окна так же чисто, как Intellisense в Visual Studio, я бы сказал, пойти на это. Мой опыт работы с всплывающими окнами, не связанный с VS, заключается в том, что большинство из них пытаются и терпят неудачу (некоторые, что довольно ужасно, требуя от меня поднять мышь и переориентироваться на правильное место). Еще одна вещь, о которой следует помнить с Intellisense, заключается в том, что он обладает блестящей обработкой конца оператора (я имею в виду взаимодействие с набранными вами словами + предвкушение + орфография / прощание букв + обработка табуляции / ввода). Так как я предполагаю, что вы используете вкладку для навигации между полями (обратите внимание, что в VS нет полей), вам нужно будет найти другой способ сообщить приложению, что "я закончил, переходите на авто -complete/Intellisense, что я только что набрал "

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

Если вы беспокоитесь о кадре ComboBox, я полностью согласен - измените цвет рамки на что-то с более низким контрастом. Любое решение, которое вы принимаете, чтобы минимизировать элемент управления "хром", когда оно не сфокусировано, очевидно, сделает его более текстовым и (возможно?) Более читабельным.

В любом случае, удачи с вашим дизайном.

Answer 2

ExtJS

Редактируемая сетка: http://extjs.com/deploy/ext-3.0-rc2/examples/grid/edit-grid.html

Сетка редактора строк: http://extjs.com/deploy/ext-3.0-rc2/examples/grid/row-editor.html

Я еще не использовал версии 3.0x, но 2.0 довольно круто. Для среды Ext есть небольшая кривая обучения, но она в значительной степени делает все: проверка, ограничение ввода, привязка данных и т. Д.

Answer 3

Вот беспорядочный список наблюдений от работы с формами входа в течение многих лет.

Числовые цифры:

• Не ограничивайте длину поля - это действительно раздражает, если вы добавили разделительный символ (или один слишком много) только для того, чтобы понять, что теперь вы не можете заполнить поле. Затем вам нужно вернуться назад, удалить "оскорбительного" персонажа, пройти до конца и продолжить заполнение. Хорошая система должна обрезать и удалять любые символы без данных при выходе из поля. Если значение по-прежнему не подходит, немедленно сообщите об этом пользователю.
• Чтобы избежать нецифровых чисел, просто игнорируйте ключи, которые будут заполнять нечисловую строку. Остерегайтесь разделителей тысяч / десятичных знаков, пробелов и управляющих символов (CTRL-x). Вы должны иметь возможность вставлять значения практически из любого доступного формата, включая символы валют (необходимо удалить).
• Спин-контроли еще не повсеместны, поэтому их следует использовать только для экспертных интерфейсов. Они также разделяют многие ловушки полос прокрутки: достаточно ли места для размещения стрелок конечной точки, если шкала шкалы соответствует шкале, если шкала линейна, какова минимальная / максимальная длина полосы, которая легко щелкать и дает адекватную точность, может ли он быть увеличен точно и быстро даже с помощью клавиатуры?
• После того, как пользователь выходит из поля, значение должно быть округлено до максимально допустимых цифр и предпочтительно отформатировано в соответствии с настройками ОС для удобочитаемости.

Перечислим значения:

• Изменение виджета поля при вводе в заблуждение для новых пользователей, поэтому его следует использовать только для экспертных интерфейсов.
• Подобные Google Suggest интерфейсы полезны, когда список большой, но знакомый пользователю, поскольку навигация по длинному списку может быть уменьшена до более управляемой части за несколько кликов. Возможно, должен быть доступен раскрывающийся селектор на тот случай, если пользователь действительно хочет увидеть все существующие опции. Если поле не позволяет вводить новые записи и содержимое поля не соответствует ни одному из параметров, оно должно попытаться найти наиболее близкое соответствие, когда пользователь уходит от него. Например, полезно вводить только первый символ, если вы знаете, что параметры "Высокий", "Средний" и "Низкий", и система сделает все остальное.
• Когда поле приобретает фокус, с помощью мыши или клавиатуры, оно должно немедленно показать доступные опции, если они не очень многочисленны. Это хороший совет для пользователей. Одна ловушка, если она слишком настойчива, затеняет другие части экрана, когда пользователь пытается уйти.

Answer 4

Посмотрите на http://www.peterblum.com/

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

Удачи

Answer 5

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

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

Для вкладок я бы позволил им вкладывать в другое поле выбора. Для некоторых людей это будет быстрее вводить много данных.

Answer 6

В jQuery есть несколько классных плагинов, которые помогают в распространенных идиомах ввода данных.

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

У Исаака в evolt также есть хорошая статья об используемых формах