Как сделать максимально юзабельное редактирование данных в веб-интерфейсе?
Имеются документы/объекты которые пользователь может и просматривать, и изменять.
Например, собственный профиль.
Рассматриваю три способа реализации этих действий: формой, инлайн, фокусный.
Исходное состояние: данные объекта/документа отображаются где-то в блоке / панели / на отдельной странице.
Формой.
u1. включение режима редактирования (кнопка "изменить")
i1. отображение заполненной формы в томже блоке или отдельным диалогом
u2. ввод/изменение данных
i2. валидация данных/подсветка
u3.1 сохранение изменение кнопкой "сохранить"
i3.1 валидация данных на сервере/подсветка, или сохранение и возврат в режим просмотра
u3.2 отмена изменений кнопкой "отмена"
i3.2 возврат в режим просмотра
Достоинства:
- привычная схема
- явное обозначение режима действий
Недостатки:
- неестественность и бюрократичность переключения в режимы "просмотр" и "редактирование"
- дополнительные кнопки "изменить", "сохранить", "отменить" формирующие лишний блок
- сильно разная вёрстка у документа в режимах просмотра и редактирования
- сохранение данных, котрые не изменялись
Инлайн
u1. выбор поля, двойным или одинарным кликом
i1. поле становится редактируемым
u2. ввод/изменение данных
i2. валидация данных/подсветка
u3.1 сохранение данных нажатием ентер
i3.1 валидация данных на сервере/подсветка, или сохранение
u3.2 отмена изменений нажатием escape
i3.2 возврат исходного значения поля
Достоинства:
- привычная схема для текстовых редакторов
- неизменная вёрстка
- отсутствие переключений режимов
- отсутствие дополнительных кнопок и необходимости к ним тянуться
- естественность сохранения и отмены
- возможность изменения одного поля
Недостатки:
- неочевидность действий для изменения поля
- невозможность навесить на поля просматривательных функции (переход по ссылкам, открытие блоков с подробностями, выделение текста, итп)
- невозможность валидации связанных полей
Фокусный
u1. выбор поля или блока полей наведением на него курсора
i1. появление рядом с выбранным иконки "изменить" (например значок "карандаш")
u2. включение редактирования нажатием на карандаш
i2. фокусировка на выбранном поле, затемнение всего остального, трансформация элемента в поле ввода, дорисовывание рядом с полем иконок "сохранить", "отмена", "удалить"
u3. ввод/изменение данных
i3. валидация данных/подсветка
u4.1 сохранение данных нажатием ентер или кнопкой
i4.1 валидация данных на сервере/подсветка, или сохранение
u4.2 отмена изменений нажатием escape или кнопкой
i4.2 возврат исходного значения поля, отмена фокуса
Достоинства:
- отсутствие переключений режимов
- отсутствие дополнительных кнопок и необходимости к ним тянуться
- наличие дополнительных кнопок для обозначения возможных действий
- естественность сохранения и отмены
- возможность изменения одного поля
- явное обозначение режима действий
Недостатки:
- не очевидность действий для изменения
- прыгающая вёрстка из за дополнительных элементов
- невозможность валидации связанных полей
Этот способ я считаю пока оптимальным и собираюсь реализовать в проекте.
От прыгающей вёрстки можно избавиться, помещая дополнительные элементы над остальным контентом, и оставив пустое место в вёрстке. Связанные поля можно скомпоновать в один целиком редактируемый блок.
Неочевидность действий для изменения частично компенсируется появлением значка при наведении, которое само по себе вроде бы достаточно ествственное движение при желании что-то сделать.
Usability неразрывна связана с 3-мя вещами, лежащими в её определении:
— задача
— пользователь
— контекст
@DmitriyEntelis абсолютно справедливо указал на то, что без понимания того, для решения какой задачи необходимо редактирование данных и в каком контексте, невозможно вообще оценить степень эффективности, трудоёмкости и удовлетворённости (а это и есть usability).
Вот вы так написали, как будто есть волшебная формула, в которую можно подставить эти три переменных, зааджастить тремя критериями и получить рекомендации простым численным дифференцированием.
А между тем по "usability guidelines" гуглится начиная от 10 до 247 "основных принципов".
@qmax именно про это я и говорю — нет универсального решения на все случаи, подходящее под любые задачи и любой контекст.
Есть конкретные сценарии, а формулы волшебной нет. В зависимости от пользователя, задачи и контекста можно хоть 100, хоть 200 критериев написать. Но если нет сценария — нет и хорошего решения.
Вопрос очень абстрактный и зависит например от того какие данные планируется редактировать.
Если речь идет про что то важной (банковские реквизиты, etc) - я бы настаивал на отдельной форме, пользователь не должен менять их просто так.
Если речь идет о чем то менее важном - мне кажется нормальным (и де-факто применяемым на куче сайтов) некий гибридный подход из последних двух пунктов.
По ховеру надо как то подсвечивать поле призывая по нему кликнуть.
По клику открывать редактирование в +- границах поля.
Обязательно показывать кнопку отмены изменений.
По клику на любое другое место/нажатию enter - сохранять данные.
