Несколько возможностей приходят на ум, чья пригодность зависит от задачи пользователя (не всегда):
Задача: Получить общий краткий обзор того, как все изменилось в окне. Здесь пользователю нужно сравнить старые значения вместе с новыми, но необязательно проверять каждое поле.
Дизайн: Предоставьте кнопку панели инструментов и/или клавишу ускорителя, которая меняет новые значения на старую. Если это можно сделать мгновенно (< 500 мс), кажущаяся анимация, естественно, привлечет глаз пользователя к местам, где были сделаны самые большие изменения. Это особенно эффективно, если содержимое графическое (например, значения ползунка, графики или редактирование изображения)
Задача: Перекрестно проверять каждое изменение каждого поля, чтобы убедиться, что новые значения верны. В этом случае знание старых значений является не более чем второстепенной задачей (т. Е. Только время от времени будет заботиться о том, каким было поле).
Дизайн: Продемонстрируйте отмеченные поля (см. Последний абзац) и покажите старое значение в виде всплывающей подсказки с помощью мыши.
Вышеупомянутые конструкции имеют то преимущество, что вы можете использовать «нормальное» окно, предназначенное для целей без аудита, сокращая количество пользователей, которые должны изучать пользователи.
Задача: Подробную оценку того, как изменилось каждое поле, включая, возможно, длинную историю нескольких изменений для каждого поля, за которым следует иногда корректировка значения на основе истории.
Дизайн: При выборе пункта меню окно расширяется вертикально, чтобы показать старые значения в списке только для чтения под каждым новым значением. Для длинных историй для такого списка может потребоваться полоса прокрутки. Для большинства буквенно-цифровых значений легче сканировать по вертикали, чтобы увидеть, как вещи изменяются по характеру, чем для сканирования по горизонтали. Вы должны разрешить пользователю редактировать значения в этом режиме, а также выбрать значение в списке истории, чтобы вернуть это поле. Сохранение нажимает на старые значения редактируемых полей в списке. Подсказки могут использоваться для предоставления дополнительной информации (например, когда каждое значение в истории было введено и кем).
Дизайн: Для «тяжелых» полей, например большого текстового окна, рассмотрим режим отображения, в котором используются зачеркивания и выделения, чтобы отображать изменения в поле, например, выполненные MS Word в трековых изменениях.
Эти два проекта по-прежнему используют «нормальное» окно, которое сводит к минимуму обучение, но изменяет размер и макет окна, требуя несколько более обучения и переориентации, чем первые два проекта.
Задача: Найти, когда и кто изменил определенные поля. Здесь пользователь уже знает или подозревает, какие поля были изменены и каковы новые значения, но теперь хочет знать, как они получили этот путь.
Дизайн: Если пользователям обычно требуется проверить только одно поле, откроется пункт меню для текущего поля, в котором в настоящее время сосредоточено небольшое окно с сеткой, в которой перечислены истории значений, которые изменили их, когда они изменились их и любую другую аудиторскую информацию (например, кто ее одобрил и когда). Если история имеет тенденцию быть длинной, выполните сортировку и/или фильтрацию. Вы можете предоставить командную кнопку, которая устанавливает текущее значение поля в значение, выбранное из сетки истории. Обратите внимание, что это отличается от списка с помощью всплывающих подсказок тем, что пользователь в основном заинтересован в выяснении, кто и когда поле изменилось, а не в том, что должно быть полем - проще просканировать по меткам времени, но сложнее вернуть стоимость.
Дизайн: Если пользователь, скорее всего, нужно проверить и сравнить несколько полей в окне, обеспечивают закрываемую историю панель, а не окно. Когда пользователь вводит вкладки в поля в окне, панель мгновенно обновляется с историей каждого поля, в комплекте с отметками времени и именами пользователей. Пункт меню может вернуть поле к значению, выбранному на панели. Это подходит для группы пользователей, для которой аудит является довольно регулярной задачей, а не редким случаем.
Эти две конструкции минимально нарушают «нормальное» окно, но требуют от пользователя изучения совершенно нового окна или панели.
Задача: Реконструировать эволюцию объектов данных посредством нескольких обновлений нескольких полей. В этом случае корректирующие значения не являются частью задачи.
Проект: Предоставьте общее окно аудита для любого произвольного списка полей или объектов, позволяя пользователю запрашивать/фильтровать по полям, значениям полей (например, отвечать, «когда это когда-либо X?») окна, таблицы базы данных и, конечно же, временную шкалу. В дополнение к поддержке специального запроса вы можете разрешить пользователю открывать окно аудита для всех полей, отображаемых в их текущем окне. Вы также можете предоставить простой способ заполнить эту таблицу полями, которые пользователь должен регулярно проверять или полями, которые определяет автоматизация, должны быть проверены. Окно аудита показывает сортируемую сетку, в которой перечислены временные метки, объект данных (или таблица), поле, старое значение и новое значение, а также имя пользователя. При сортировке по метке времени (возможно, она должна быть по умолчанию) пользователь может определить, как изменения повлияли друг на друга по полю (например, User A изменил X на 2, что, вероятно, привело пользователя B к изменению Y до 4). Возможно, вы захотите предоставить варианты графического отображения, чтобы помочь пользователю увидеть корреляции в изменениях. Это самый мощный инструмент аудита, который я давал, но он также требует самой подготовки и навыков для использования.
Для всех проектов, это действительно хорошая идея для недавно измененных полей цвета, чтобы помочь пользователям определить то, что они, вероятно, ищут (то есть, что-то другое, чем в последний раз, когда они смотрели). Возможно, вы даже захотите иметь три или четыре градации недавнего времени. Я бы выбрал яркий цвет, чтобы предложить «новизну», но я бы избегал красного цвета, что подразумевало что-то неправильное (не обязательно) или требуемое поле. Как насчет солнечного желтого «ореола» вокруг поля? Что-то вроде границы позволит избежать проблем с читабельностью поля. Что касается причин доступности и лучшей самодокументации, я бы также включил избыточную метку, такую как значок с меткой (возможно, «блеск») или просто слово «новое» рядом с полем.