Взаимодействие пользователей с прикладным программным обеспечением, входящим в состав системы должно осуществляться посредством визуального графического интерфейса (ОШ). Интерфейс системы должен быть понятным и удобным, не должен быть перегружен графическими элементами и должен обеспечивать быстрое отображение экранных форм. Навигационные элементы должны быть выполнены в удобной для пользователя форме. Ввод-вывод данных системы, прием управляющих команд и отображение результатов их исполнения должны выполняться в интерактивном режиме. Интерфейс должен соответствовать современным эргономическим требованиям и обеспечивать удобный доступ к основным функциям и операциям системы.
Интерфейс должен быть рассчитан на преимущественное использование манипулятора типа «мышь», то есть управление системой должно осуществляться с помощью набора экранных меню, кнопок, значков и т. п. элементов. Клавиатурный режим ввода должен используется главным образом при заполнении и / или редактировании текстовых и числовых полей экранных форм.
Программирование-2017. 03. Интерактивное взаимодействие с программой
Система должна обеспечивать корректную обработку аварийных ситуаций, вызванных неверными действиями пользователей, неверным форматом или недопустимыми значениями входных данных. В указанных случаях система должна выдавать пользователю соответствующие сообщения, после чего возвращаться в рабочее состояние, предшествовавшее неверной (недопустимой) команде или некорректному вводу данных.
Экранные формы должны проектироваться с учетом требований унификации:
— все экранные формы пользовательского интерфейса должны быть выполнены в едином графическом дизайне, с одинаковым расположением основных элементов управления и навигации;
Система должна соответствовать требованиям эргономики и профессиональной медицины при условии комплектования высококачественным оборудованием (ПЭВМ, монитор и прочее оборудование), имеющим необходимые сертификаты соответствия и безопасности Росстандарта.
Требования к защите информации от несанкционированного доступа
ИС должна обеспечивать защиту от несанкционированного доступа (НСД) на уровне не ниже установленного требованиями, предъявляемыми к категории 1Д по классификации действующего руководящего документа Гостехкомиссии России «Автоматизированные системы. Защита от несанкционированного доступа к информации. Классификация автоматизированных систем» 1992 г.
Компоненты подсистемы защиты от НСД должны обеспечивать:
Уровень защищённости от несанкционированного доступа средств вычислительной техники, обрабатывающих конфиденциальную информацию, должен соответствовать требованиям к классу защищённости 6 согласно требованиям действующего руководящего документа Гостехкомиссии России «Средства вычислительной техники. Защита от несанкционированного доступа к информации. Показатели защищенности от несанкционированного доступа к информации».
Защищённая часть системы должна использовать «слепые» пароли (при наборе пароля его символы не показываются на экране либо заменяются одним типом символов; количество символов не соответствует длине пароля).
Основы интерфейса взаимодействия пользователя с системой Unix на уровне командной строки
Защищённая часть системы должна использовать многоуровневую систему защиты. Защищённая часть системы должна быть отделена от незащищённой части системы межсетевым экраном.
Требования по сохранности информации
Программное обеспечение АИС» ACDR» должно восстанавливать свое функционирование при корректном перезапуске аппаратных средств. Должна быть предусмотрена возможность организации автоматического и (или) ручного резервного копирования данных системы средствами системного и базового программного обеспечения (ОС, СУБД), входящего в состав программно технического комплекса Заказчика. Приведенные выше требования не распространяются на компоненты системы, разработанные третьими сторонами и действительны только при соблюдении правил эксплуатации этих компонентов, включая своевременную установку обновлений, рекомендованных производителями покупного программного обеспечения.
Требования по патентной чистоте.
Установка системы в целом, как и установка отдельных частей системы не должна предъявлять дополнительных требований к покупке лицензий на программное обеспечение сторонних производителей, кроме программного обеспечения.
Требование к функциям
Подсистема обработки звонков должна реализовать следующие функции:
— функция поиска нужного звонка;
— функция прослушивания звонка;
Подсистема хранения данных должна реализовать следующие функции:
— функция хранения данных;
— функция экспорта данных;
— функция импорта данных;
Подсистема построения граффиков должна реализовать следующие функции:
— функция расчета затрат на телефонную связь;
— функция мониторинга занятости технических специалистов;
Требования к видам обеспечения
Требования к математическому обеспечению системы.
Требования к математическому обеспечению системыне предъявляются.
Требования для информационного обеспечения системы
Состав, структура и способы организации данных в системе должны быть определены на этапе технического проектирования. Уровень хранения данных в системе должен быть построен на основе современных реляционных или объектно-реляционных СУБД. Для обеспечения целостности данных должны использоваться встроенные механизмы СУБД. Средства СУБД, а также средства используемых операционных систем должны обеспечивать документирование и протоколирование обрабатываемой в системе информации.
Доступ к данным должен быть предоставлен только авторизованным пользователям. Структура базы данных должна быть организована рациональным способом, исключающим единовременную полную выгрузку информации, содержащейся в базе данных системы.
В состав системы должна входить специализированная подсистема резервного копирования и восстановления данных.
При проектировании и развертывании системы необходимо рассмотреть возможность использования накопленной информации из уже функционирующих информационных систем.
Лингвистическое требование
Все прикладное программное обеспечение системы для организации взаимодействия с пользователем должно использовать русский либо английский язык.
Требования к программному обеспечению системы
При проектировании и разработке системы необходимо максимально эффективным образом использовать ранее закупленное программное обеспечение, как серверное, так и для рабочих станций.
Используемое при разработке программное обеспечение и библиотеки программных кодов должны иметь широкое распространение, быть общедоступными и использоваться в промышленных масштабах.
Требования к техническому обеспечению системы. Техническое обеспечение системы должно максимально и наиболее эффективным образом использовать существующие в органах федерального агентства технические средства.
В состав комплекса должны следующие технические средства:
Требования к техническим характеристикам серверов БД и веб-сервера:
— Процессор — Intel Хеоп 3 ГГц;
— Объем оперативной памяти — 2 Гб;
— Дисковая подсистема — 300 Гб;
— Сетевой адаптер — 100 Мбит.
Требования к техническим характеристикам ПК сотрудника отдела приема и обработки заказов:
— Процессор — Процессор Intel® Core™ i7-2670QM (2.8 ГГц, 3Мб, LGA1155);
— Объем оперативной памяти — 2 Гб;
— Дисковая подсистема — 500 Гб;
— Сетевой адаптер — 100 Мбит.
Требования к метрологическому обеспечению.
Требования к метрологическому обеспечению не предъявляются.
2.5 Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие
Для функционирования АИС» ACDR» необходимо:
— Определить подразделение и ответственных должностных лиц, ответственных за внедрение и проведение опытной эксплуатации АИС» ACDR»;
— Обеспечить присутствие пользователей на обучении работе с системой, проводимом Исполнителем;
— Обеспечить соответствие помещений и рабочих мест пользователей системы в соответствии с требованиями, изложенными в настоящем ЧТЗ;
— Обеспечить выполнение требований, предъявляемых к программно-техническим средствам, на которых должно быть развернуто программное обеспечение АИС» ACDR»;
— Провести опытную эксплуатацию АИС» ACDR».
Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие, включая перечень основных мероприятий и их исполнителей должны быть уточнены на стадии подготовки рабочей документации и по результатам опытной эксплуатации.
Источник: infopedia.su
Разработка взаимодействия с пользователем мобильных устройств — ключевые принципы
Наиболее важное, о чём надо помнить, разрабатывая мобильное приложение, это то, что оно должно быть как полезным, так и интуитивно понятным. Если приложение не приносит пользы, то оно не имеет практической ценности для пользователя, и нет мотивации использовать его. Если приложение полезное, но обучение работе с ним требует много времени и усилий, то люди откажутся от него.
Хорошая разработка пользовательского интерфейса решает обе эти проблемы проектирования:
- Чтобы быть полезным, мобильное приложение должно быть полностью ориентировано на пользователя. Тот устанавливает ваше приложение потому, что ему надо решить насущную для него проблему. Таким образом, приложение имеет чётко определённое «понимание цели». Думайте о том, что именно ваши пользователи будут пытаться выполнить, сосредоточивайтесь на их ключевых целях, и удаляйте все препятствия с ведущего к ним пути.
- Пользовательский интерфейс обязан быть предельно ясным. Чтобы эффективно использовать разработанный вами интерфейс, должна быть обеспечена возможность легко понимать, для чего он и как его использовать. В нём просто не должно быть ни малейшего места для какой-либо путаницы.
1. Не допускайте перегруженности
Внимание пользователя является ценным ресурсом и должно быть распределено соответствующим образом. Загромождение интерфейса перегружает вашего пользователя информацией: каждые добавленная кнопка, изображение и текстовая строка усложняют картинку на экране.
Перегруженность является недостатком в приложении для настольного компьютера или на сайте, но на мобильном устройстве она имеет ещё более серьёзные последствия. Изображение получено от ftrain
Есть знаменитое высказывание писателя Антуана де Сент-Экзюпери: «Совершенство достигается не тогда, когда уже ничего нельзя добавить, а когда уже ничего нельзя убрать». В интерфейсе мобильного приложения важно избавиться от всего, что не является абсолютно необходимым; снижение загруженности улучшает понимание.
Простое эмпирическое правило: должно быть только одно основное действие в каждом окне. Каждое окно, разработанное вами для приложения, должно поддерживать только одно-единственное действие, представляющее ценность для пользователя. Это облегчает обучение, использование и добавление, или встраивание при необходимости. Иметь сто продуманных по заполненности окон лучше, чем иметь одно забитое до предела.
Возьмите для примера Uber. Uber знает, что целью пользователя данного приложения является заказ такси. Поэтому приложение не нагружает пользователя другой информацией: оно автоматически на основании спутниковых данных определяет местонахождение вызывающего аппарата, и пользователь должен выбрать лишь конечную точку маршрута.
Одним из главных правил обеспечения хорошего взаимодействия с пользователем является снижение количества усилий пользователя на его пути к требуемому результату.
2. Обеспечьте интуитивно понятную навигацию
Помощь пользователю в навигации должна быть приоритетной для каждого приложения. Хорошая навигация должна ощущаться как невидимая рука, направляющая пользователя по его пути. В конце концов, даже самая крутая фишка или самый привлекательный контент являются бесполезными, если люди не могут найти их. Принципы хорошей навигации в приложении для мобильного устройства:
- Навигация должна быть ясной. Необходимо использовать надлежащие символы (правильные зрительные образы), чтобы для навигации не требовались какие-либо пояснения, и следует обеспечить, чтобы каждый элемент навигации (такой как, например, иконка) приводил к надлежащему месту назначения.
- Навигация в приложении для мобильного устройства должна быть последовательной во всём приложении. Не допускайте расположения элементов управления навигацией на разных страницах в разных местах или, вообще, их отсутствия. Это будет значительно затруднять действия пользователя.
- Навигация должна обеспечивать пользователя информацией о его текущем нахождении в приложении. Отсутствие такой индикации является, вероятно, одной из наиболее распространённых ошибок, которые встречаются во многих меню приложений. «Где я?» — один из основных вопросов, ответ на который требуется пользователям при навигации.
3. Обеспечьте продуманное взаимодействие
Нельзя думать о разработке навигации в приложении для мобильного устройства изолированно. Создание продуманного взаимодействия между мобильными, настольными и планшетными устройствами имеет большое значение для ваших пользователей.
Apple Music
Возьмите для примера Apple Music. Вы можете поместить плей-лист на ваш Mac, и он немедленно станет доступным на вашем iPhone. Apple осознаёт, что, в то время как структура мобильного приложения имеет чрезвычайно большое значение, продуманное взаимодействие между iPhone, Mac и IPad также важно для пользователей.
4. Разрабатывайте сенсорные элементы управления такими, чтобы они были удобными для пальцев
Пользователям легче обращаться с крупными сенсорными элементами управления, чем с малыми. При разработке интерфейсов мобильных устройств лучше делать элементы управления достаточно большими, чтобы по ним было проще попадать.
Размеры элемента управления должны быть 7-10 мм, так чтобы палец мог точно накрыть его. Такой элемент позволяет пользователю удобно расположить палец внутри него. Края элемента будут видны из-под пальца. Это обеспечивает пользователю ясную обратную связь, показывающую, что контакт с элементом управления обеспечен.
Элементы управления пользовательским интерфейсом должны быть достаточно большими, чтобы чётко регистрировать касание кончика пальца, не создавая помех пользователю ненадлежащей реакцией и малыми размерами. Изображение получено от Apple.
Необходимо обеспечить также достаточное расстояние между сенсорными элементами.
5. Тексты должны быть удобочитаемыми
Экраны смартфонов невелики по сравнению с настольными компьютерами, поэтому одной из проблем разработки их приложений является размещение требуемой информации на небольшом интерфейсе. Возникает соблазн предельно всё сжать, чтобы обеспечить максимальное количество информации. Но не надо поддаваться на этот соблазн.
Эмпирическое правило для мобильных устройств: текст должен иметь размер, по крайней мере, 11 точек, чтобы он был читаемым на типичном расстоянии просмотра без увеличения.
Изображение получено от Apple.
Необходимо улучшать удобочитаемость, увеличивая высоту строк или интервал между знаками. Хороший, превышающий среднее значение пробел может сделать некоторые из трудночитаемых интерфейсов привлекательными и простыми.
Хороший пользовательский интерфейс выглядит просторно. Изображение получено от Apple.
6. Делайте элементы интерфейса хорошо видимыми
Используйте цвет и контраст, чтобы помочь пользователям видеть и понимать ваш контент. Выбирайте первичные, вторичные и акцентные цвета для вашего приложения такими, чтобы они поддерживали удобство использования. Обеспечивайте достаточный цветовой контраст между элементами, чтобы ваше приложение могли видеть и использовать также пользователи с ослабленным зрением.
Обеспечьте контраст между цветом шрифта и фона так, чтобы текст был удобочитаемым. W3C рекомендует следующие значения контраста для основного текста и текста изображения:
- Малый текст должен иметь контраст, как минимум, 4,5:1 относительно фона.
- Большой текст (начиная с 14 точек для полужирного и 18 точек для обычного) должен иметь контраст, как минимум, 3:1 относительно фона.
Текст, не отвечающий рекомендациям по цветовому контрасту, трудно читать. Изображение получено от Apple.
Чрезвычайно важно иметь достаточный контраст на мобильном устройстве: при нахождении на открытом воздухе контраст может быть низким из-за внешней освещённости.
Нейтральный серый цвет данной страницы выглядит хорошо внутри помещения, однако при нахождении на открытом воздухе впечатление иное. Изображение получено в ходе тестирования.
Пиктограммы или иные критические элементы должны также использовать рекомендованные выше значения контраста.
Пиктограммы, не отвечающие рекомендациям по цветовому контрасту, трудно различать на фоне. Изображение получено из инструкций по Material Design.
7. Разрабатывайте элементы управления, исходя из положения руки
Стивен Хубер в своём исследовании по использованию мобильных устройств показал, что 49% людей полагается только на большой палец, чтобы проводить какие-то операции на своих телефонах. На рисунке ниже области, показанные на экранах мобильных телефонов, цветом ориентировочно информируют, какие участки экрана пользователь может достать большим пальцем, чтобы взаимодействовать с ними.
Удобные зоны для управления смартфоном одним пальцем. Изображение получено от uxmatters.
Зелёные области пользователь может достать легко; жёлтые области требуют некоторого напряжения, а чтобы достать красные участки пользователь должен изменить положение устройства в руке. Положения руки и захват следует учитывать при размещении элементов управления мобильного устройства:
- Важно расположить меню верхнего уровня, часто используемые элементы управления и элементы типовых действий в зелёной зоне экрана, поскольку их тогда можно удобно достать одним пальцем.
Типовые действия тамблера. Изображение получено от Capptivate.
- Критические действия (такие как, например, удаление или стирание) следует располагать в труднодоступной красной зоне, чтобы затруднить их случайный запуск.
8. Минимизируйте необходимость ввода с клавиатуры
Ввод с клавиатуры на мобильном устройстве является медленным процессом, в котором легко возникают ошибки. Поэтому лучше всегда пытаться минимизировать количество ввода с клавиатуры, необходимое для использования мобильного приложения:
- Формы должны быть предельно короткими и простыми и содержать только абсолютно необходимые поля.
Нет людей, которые любили бы заполнять формы. И чем более длинной или сложной кажется форма, то тем меньше вероятность, что пользователь войдёт в неё и начнёт заполнять бланки. Изображение получено от Lukew.
- Используйте автозаполнение и персонализированные данные там, где это приемлемо, чтобы от пользователя требовалось ввести только какой-то минимум информации.
Поле с автозаполнением для страны
9. Тестируйте вашу разработку
Чрезвычайно часто мобильное приложение выглядит великолепно на большом экране настольного компьютера, но оказывается просто в разы хуже при тестировании на реальном мобильном устройстве. Даже, кажется, тщательнейшим образом проработанный продукт взаимодействия с пользователем, в конечном счёте, будет содержать некоторый дефект, который проявится в условиях реального использования. Поэтому чрезвычайно важно протестировать ваше приложение с реальными пользователями на множестве мобильных устройств. Вы должны просить реальных пользователей выполнять их регулярные задачи; только после этого можно будет понять, насколько, действительно, хорошо функционирует ваша разработка. Рассматривайте ваше приложение как постоянно развивающийся объект, используя данные из аналитики и отзывов пользователей, чтобы постоянно улучшать взаимодействие.
Заключение
Так же как с любыми другими элементами разработок, указанные выше советы являются лишь отправной точкой для размышлений. Соединяйте и согласовывайте эти идеи со своими, чтобы получить наилучшие результаты. Всегда помните, что любой проект предназначен, прежде всего, не для разработчиков, а для пользователей.
- пользовательский интерфейс
- мобильные приложения
- мобильные устройства
- принципы разработки
- Анализ и проектирование систем
- Графические оболочки
- Разработка мобильных приложений
- Тестирование мобильных приложений
Источник: habr.com
Структура Приложения и алгоритмы взаимодействия Пользователя с Приложением
Участникам необходимо разработать приложение для демонстрации кейсовых заданий и воспроизводства виртуальных туров при помощи системы Android.
Участники работают в командах по 3-5 человека в период с 21.00 16 сентября до 8.00 17 сентября. Победителем признается команда набравшая наибольшее количество баллов по результатам презентации разработки (решения оцениваются экспертами на основании 5 критериев — Приложение).
Разработка должна отвечать требованиям и характеристикам представленным ниже.
Требования и характеристики VR/AR приложения для демонстрации интерактивных кейсов
Цели и задачи приложения
Целью разработки приложения является изучение промышленного объекта (завода, оборудования и пр.), находящегося в пространстве – его схемы устройства, составных частей и процессов, связанных с ними.
— осуществлять выбор промышленного кейса, объекты которого должны отслеживаться при помощи приложения;
— улавливать через фотокамеру метки — составные части заранее заданных объектов (в печатной форме кейса);
— выводить по меткам информацию в виде всплывающих окон.
Портрет целевой аудитории
Студенты, молодые специалисты 18-35 лет.
Основные понятия, используемые в техническом задании
Пользователь – человек, использующий данное приложение для выполнения связанных с ним задач.
Система Android – мобильная операционная система, разработанная компанией Google на основе ядра Linux. Устанавливается на смартфонах, планшетных компьютерах, электронных книгах, цифровых проигрывателях, наручных часах, игровых приставках, нетбуках, смартбуках, очках Google, телевизорах и других устройствах.
Структура Приложения и алгоритмы взаимодействия Пользователя с Приложением
Стартовый экран приложения (Вид 1) – статичные картинки с подписями. При клике на картинку загружается одна из баз данных об объектах. Каждая база данных включает в себя набор меток, при которых срабатывает активация 3D-модели, набор составных частей 3D-модели и их названия с привязкой к конкретным частям появившейся модели, а также описания каждой части.
Вид 1. Стартовый экран приложения
Далее открывается фотокамера (Вид 2). При обнаружении заранее определенного объекта появляются пояснения к составным частям модели в виде иконок (как на рис. 1).
В случае с динозавром на рис. 2 составные части – это голова, тело, хвост, лапы, которые отмечены иконками с текстом как на рис. 3. При клике на каждую иконку открывается доп. всплывающее окно с картинками и/или текстом, поясняющее каждую составную часть. В примере с динозавром при клике на голову появляется описание глаз, длина клыков, размер черепа и т.д.
Вид 2. Экран фотокамеры при наведении на объект
Рис. 1 пояснения к составным частям модели
Также на страницах, кроме главной, присутствует кнопка меню, скрывающая выплывающее окно. Через ссылку «Выбор кейса» можно вернуться на Вид 1 с выбором кейсов. Выход из всплывающего окна осуществляется при потере камерой из вида данного объекта, либо по клику на кнопке «Закрыть».
В приложении необходимо предусмотреть возможность расширения за счет внедрения дополнительных баз данных (с другими метками, моделями, текстом) и последующего выбора одной из них. (рис 2.) Изначально доступен только ОДИН кейс (одна база данных).
Вид 3. Стандартное меню
При клике на ссылку «Описание» справа открывается окно (Вид 4) с описанием конкретного кейса, включающее изображения и текст. Для каждого кейса – свои изображения и текст.
Вид 4. Активный пункт «Описание» в меню
Помимо того, необходимо предусмотреть последующее расширение — возможность для пользователя пройти квест по заданным меткам. Например, в тексте встречается 5 меток с уникальной информацией (работа с метками строится точно так же через камеру и всплывающие окна), когда пользователь находит все 5 меток, появляется поздравление, и в меню рядом с кейсом появляется отметка о прохождении квеста.
Еще одной возможностью приложения должен быть просмотр карты территории предприятия (рис 3.), при клике на метку открывается дополнительная информация об особенностях оборудования данного цеха (рис 4.)
Рис 2. карта предприятия с активными метками
Рис 3. Детальный просмотр оборудования с текстом и медиаматериалами
Язык локализации
Приложение будет локализовано на русском языке.
Источник: poisk-ru.ru