ShariX Open Docs

С этим руководством(Руководство по созданию безопасного графического интерфейса) следует обязательно всем ознакомиться, т.к. Вы будете работать согласно нему! В нём описано про GUI.

1. В первую очередь тот кто делал (например, вёрстку по макету из редактора figma), должен сам проверить свою работу с помощью чек-листа, либо же передать эту работу соответствующему лицу.
2. Если пункт чек-листа соответствует, то ставим галочку, если пункт не соответствует то ставим крестик и описываем чего нет, какова проблема (например: «а почему этот пункт Вы отметили крестиком, а не галочкой?»).
3. После полной проверки с Вашей стороны, следует показать выполненную работу, если же Вы проверили не полностью, всё равно Вам необходимо показать, что сделали, такого лучше не допускать, но всё равно работа будет проверяться.

1. Проверить на соответствие кнопки Active, Disabled, Hover и действий пользователя: кнопка не должна быть в спокойном состоянии, если она находиться в эффекте(состоянии нажатия) Hover.
2. Про кнопки Active, Disabled: кнопка, которая подразумеваться активной, и должна являться активной, то есть должно происходить какой-то действие, что ей присвоено(например, переход на другую страницу).
3. Если кнопка неактивна, значит она как минимум имеет отличающийся цвет от цвета активной кнопки и она не приводит ни к какому действию.

Обязательно следует проверять например шрифт, в редакторе Figma условно Open Sans отображается одним образом при начертании Regular, а в готовом экране при начертании Regular, он может стать Medium или каким-нибудь другим.

При возникновении проблем с проверкой, описывайте подробно проблему(можете также приводить пример кода, всё это должно происходить в текстовом документе с заполненным чек-листом галочками и/или крестиками), чтобы Вас могли корректно понять.

Если есть какие-то вопросы по поводу чек-листа или Вы хотите что-то добавить в чек-лист, то Вы можете оставить свои комментарии в руководстве и возможно они будут учтены и добавлены в чек-лист.

Вы можете обращаться к отделу вёрстки.

В руководстве в скором времени появиться процесс нэйминга, он будет применяться как при создании дизайна, так и при создании приложений.

1. Проверить на соответствие ТЗ.
2. Проверить приложение на наличие элементов, способных выдать повышенный уровень доступа.
3. Проверить на соответствие состояния кнопок (active/disabled/hover) и действий пользователя.
4. Расположение, размер, цвет, ширина, длина элементов; возможность ввода букв или цифр.
5. Реализуется ли функционал приложения с помощью графических элементов.
6. Размещение всех сообщений об ошибках, уведомленией (а также шрифт, цвет, размер, расположение и орфография и пунктуация в тексте).
7. Читабелен ли использованный шрифт.
8. Переходит ли курсор из текстового в поинтер при наведении на активные элементы, выделяются ли выбранные элементы.
9. Выравнивание текста и форм.
10. Качество изображений.
11. Проверить расположение и отображение всех элементов при различных разрешениях экрана, а также при изменении размера окна браузера для сайтов (проверить, появляется ли скролл).
12. Проверить текст на орфографические, пунктуационные ошибки.
13. Появляются ли тултипы (если есть необходимость).
14. Верный ли тип данных используется. Нужно убедиться, что для определенных типов данных, таких как валюта и даты и т.д., можно вводить только допустимые значения.
15. Указана ли ширина поля. Если определенное текстовое поле предназначено для определенного количества символов, укажите в пользовательском интерфейсе, что введенные данные не должны превышать границу по количеству символов. (Например, поле, которое позволяет использовать 50 символов в базе данных приложения, не должно позволять пользователям вводить более 50 символов в интерфейсе).
16. Правильно ли работают элементы навигации.
17. Все ли необходимые индикаторы прогресса присутствуют.
18. Проверить на корректность работы все индикаторы прогресса.
19. Подсказки ввода. В выпадающем меню с сотнями элементов при вводе первой буквы должны остаться только те элементы, которые начинаются с этой буквы, таким образом можно уберечь пользователей от просмотра лишней и потенциально опасной информации.
20. Скролл таблиц. Когда данные из таблицы перетекают на следующую страницу, функция прокрутки должна позволять пользователям прокручивать данные, но не трогать все заголовки.
21. Ведение журнала ошибок. Когда в системе возникает фатальная ошибка, нужно убедиться, что приложение записывает сведения об ошибке в специальный файл журнала для последующего просмотра.
22. Пункты меню и режим. Убедитесь, что приложение отображает только те пункты меню, которые доступны в определенном режиме.
23. Комбинации клавиш. Проверьте комбинации клавиш, правильно ли они работают, независимо от браузера, платформы или устройства.
24. Кнопки подтверждения действий. Убедитесь, что пользовательский интерфейс имеет работающую кнопку подтверждения каждый раз, когда пользователь хочет сохранить или удалить элемент.