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

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

5 голосов
/ 14 июня 2009

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

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

  • Свободный текст
  • Числа (цифры)
  • Значение перечисления (например, один из «Высокий», «Средний» и «Низкий»)
  • Другие (например, дата, продолжительность)

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

Цифровые цифры

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

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

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

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

Например?

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


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


Редактировать в ответ на один из ответов ниже.

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

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

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

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

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

Ответы [ 6 ]

4 голосов
/ 17 июня 2009

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

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

Относительно числового ввода:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2 голосов
/ 18 июня 2009

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 есть небольшая кривая обучения, но она в значительной степени делает все: проверку, ограничение ввода, привязку данных и т. Д.

1 голос
/ 24 декабря 2009

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

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

Удачи

1 голос
/ 19 июня 2009

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

Цифровые цифры:

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

Значения перечисления:

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

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

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

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

0 голосов
/ 19 июня 2009

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

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

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...