Разработка пользовательского интерфейса ведется параллельно разработке программного продукта в целом и в основном предшествует его внедрению. Процесс разработки эргономичного ПИ разбивается на следующие этапы:
1. Анализ производственной деятельности
анализ производственной деятельности пользователя, определение и спецификация его бизнес-функций. Формулировка требований к работе пользователя;
построение пользовательской модели данных (ERD), формирование рабочих мест.
2. Проектирование ПИ
выбор показателей оценки пользовательского интерфейса;
разработка обобщенного сценария взаимодействия пользователя с системой (функциональной модели) и его предварительная оценка пользователями и Заказчиком (бумажный прототип ПИ);
корректировка и детализация сценария взаимодействия, выбор и дополнение стандарта (руководства) для построения прототипа;
разработка макетов и прототипов ПИ и их оценка в деловой игре, выбор окончательного варианта.
При проектировании пользовательского интерфейса приведенная выше последовательность не является строго обязательной. Проектировщик может представить диалог в экранных формах.[1]
Этапы разработки и анализ интерфейса приложения
Наиболее распространенной ошибкой разработчика является именно отсутствие четкой проработки выполняемых действий. Без этого дальнейшая реализация оказывается несогласованной и может оказаться не соответствующей квалификационным требованиям, а на практике требованиям пользователя.
3. Реализация ПИ
реализация ПИ в коде, создание тестовой версии (визуализация);
разработка средств поддержки пользователя (пользовательские словари, подсказки, сообщения, помощь и пр.) и их встраивание в программный код.
тестирование тестовой версии ПИ по набору ранее определенных показателей;
подготовка пользовательской документации и разработка программы обучения.
Принципы проектирования эргономичного пользовательского интерфейса
Пользовательский интерфейс приложений базы данных является одним из важнейших компонентов системы. Интерфейс должен быть удобным и обеспечивать все функциональные возможности, предусмотренные в спецификациях требований пользователей.
При проектировании пользовательского интерфейса рекомендуется использовать следующие основные элементы и их характеристики:
ясные и понятные инструкции;
логически обоснованные группировки и последовательности полей;
визуально привлекаемый вид окна или поля отчета;
легко узнаваемые имена полей;
согласованную терминологию и сокращения;
согласованное использование цветов;
визуальное выделение пространства и границ полей ввода данных;
удобные средства перемещения курсора;
средства исправления отдельных ошибочных символов и целых полей;
средства вывода сообщений об ошибках при вводе недопустимых значений;
особое выделение необязательных для ввода полей;
средства вывода пояснительных сообщений с описанием полей;
средства вывода сообщения об окончании заполнения формы.
Этапы дизайна мобильного приложения
Цель создания эргономичного интерфейса состоит в том, чтобы отобразить информацию настолько эффективно насколько это возможно для человеческого восприятия и структурировать отображение на дисплее таким образом, чтобы привлечь внимание к наиболее важным единицам информации. Основная же цель состоит в том, чтобы минимизировать общую информацию на экране и представить только то, что является необходимым для пользователя.
Размещение информации на экране
Количество информации, отображаемой на экране, называется экранной плотностью. Исследования показали, что, чем меньше экранная плотность, тем отображаемая информация наиболее доступна и понятна для пользователя и наоборот, если экранная плотность большая, это может вызвать затруднения в усвоении информации и ее ясном понимании. Однако опытные пользователи могут предпочитать интерфейсы с большой экранной плотностью. Информация на экране может быть сгруппирована и упорядочена в значимые части. Это может быть достигнуто с использованием кадров (фреймов), методов типа цветового кодирования, рамок, негативного изображения или других методов для привлечения внимания.
Непротиворечивость и стандартизация
Данные на экране следует располагать таким образом, чтобы пользователь знал, где найти и где ожидать вывода необходимой информации.
информация, на которую следует немедленно обратить внимание, должна всегда отображаться в видном месте, чтобы захватить внимание пользователя (например, предупреждающие сообщения и сообщения об ошибках);
информация, которая необходима не очень часто (например, средства справки) не должна отображаться, но должна быть доступна, когда потребуется;
менее срочная или менее необходимая информация не должна постоянно находиться перед пользователем, но должна быть доступна, когда понадобится;
отчеты и ссылки должны быть сгруппированы.
Тексты и диалоги
Некоторые принципы, которыми необходимо руководствоваться при создании текстовых диалогов и отображений:
· текст в нижнем регистре читается приблизительно на 13% быстрее, чем текст, который напечатан полностью в верхнем регистре;
· символы верхнего регистра наиболее эффективны для информации, которая должна привлечь внимание;
· выровненный по правому краю текст труднее читать, чем равномерно распределенный текст с не выровненным правым полем;
· оптимальный интервал между строками равен или немного больше, чем высота символов.
Понравилась статья? Добавь ее в закладку (CTRL+D) и не забудь поделиться с друзьями:
Источник: studopedia.ru
10.2. Этапы разработки пользовательского интерфейса
Разработка пользовательского интерфейса включает те же основные этапы, что и разработка программного обеспечения:
• постановка задачи – определение типа интерфейса и общих требований к нему;
• анализ требований и определение спецификаций – определение сценариев использования и пользовательской модели интерфейса;
• проектирование – проектирование диалогов и их реализация в виде процессов ввода-вывода;
• реализация – программирование и тестирование интерфейсных процессов.
При проектировании пользовательских интерфейсов необходимо учитывать психофизические особенности человека, связанные с восприятием, запоминанием и обработкой информации.
Существуют три совершенно различные модели пользовательского интерфейса: модель программиста, модель пользователя и программная модель.
10.3. Критерии оценки интерфейса пользователем
Многочисленные опросы и обследования, проводимые ведущими фирмами по разработке программного обеспечения, показали, что основными критериями оценки интерфейсов пользователем являются:
• простота освоения и запоминания операций системы – конкретно оценивают время освоения и продолжительность сохранения информации в памяти;
• скорость достижения результатов при использовании системы – определяется количеством вводимых или выбираемых мышью команд и настроек;
• субъективная удовлетворенность при эксплуатации системы (удобство работы, утомляемость и т. д.).
Графические пользовательские интерфейсы поддерживаются операционными системами Windows, Apple Macintosh, OS/2 и т. д. В рамках указанных операционных систем для таких интерфейсов разработаны наборы стандартных компонентов взаимодействия с пользователем. Эти наборы не идентичны, как и основные приемы работы с интерфейсами различных операционных систем. Пользовательские интерфейсы большинства современных программ строятся по технологии WIMP: W – Windows (окна), I – Icons (пиктограммы), М – Mouse (мышь), Р – Pop-up (всплывающие или выпадающие меню). Основными элементами графических интерфейсов, таким образом, являются: окна, пиктограммы, компоненты ввода–вывода и мышь, которую используют в качестве указующего устройства и устройства прямого манипулирования объектами на экране.
11. Порядок работы эвм при выполнении программ. Трансляторы, интерпритаторы, компиляторы
Программа – это последовательность инструкций, предназначенных для выполнения компьютером. В настоящее время программы оформляются в виде текста, который записывается в файлы. Этот текст является результатом деятельности программиста и, несмотря на специфику формального языка, остаётся программой для программиста. Процесс создания программы предполагает несколько этапов.
За этапом разработки проекта программы и алгоритма следует этап программирования. На этом этапе пишется программа. Файл с исходным текстом программы (его также называют исходным модулем) обрабатывается транслятором, который осуществляет перевод программы с языка программирования в понятную машине последовательность кодов. Транслятор (англ.
translator – переводчик) – это программа–переводчик. Она преобразует программу, написанную на одном из языков высокого уровня, в программу, состоящую из машинных команд. Трансляторы реализуются в виде компиляторов или интерпретаторов. С точки зрения выполнения работы компилятор и интерпретатор существенно различаются. Компилятор (англ.
compiler – составитель, собиратель) читает всю программу целиком, делает ее перевод и создает законченный вариант программы на машинном языке, который затем и выполняется. Интерпретатор (англ. interpreter – истолкователь, устный переводчик) переводит и выполняет программу строка за строкой.
После того, как программа откомпилирована, ни сама исходная программа, ни компилятор более не нужны. В то же время программа, обрабатываемая интерпретатором, должна заново переводиться на машинный язык при каждом очередном запуске программы. Откомпилированные программы работают быстрее, но интерпретируемые проще исправлять и изменять.
Каждый конкретный язык ориентирован либо на компиляцию, либо на интерпретацию – в зависимости от того, для каких целей он создавался. Например, Паскаль обычно используется для решения довольно сложных задач, в которых важна скорость работы программ. Поэтому данный язык обычно реализуется с помощью компилятора.
С другой стороны, Бейсик создавался как язык для начинающих программистов, для которых построчное выполнение программы имеет неоспоримые преимущества. Иногда для одного языка имеется и компилятор, и интерпретатор.
В этом случае для разработки и тестирования программы можно воспользоваться интерпретатором, а затем откомпилировать отлаженную программу, чтобы повысить скорость ее выполнения. Рассмотрим процесс компиляции более подробно и полно. Он разделяется на несколько этапов.
На первом этапе исходный текст (он обычно хранится в виде текстового файла) подвергается лексической обработке. Программа разделяется на предложения, предложение делится на элементарные составляющие (лексемы). Каждая лексема распознаётся (имя, ключевое слово, литерал, символ операции или разделитель) и преобразуется в соответствующее двоичное представление.
Этот этап работы транслятора называют лексическим анализом. Затем наступает этап синтаксического анализа. На этом этапе из лексем собираются выражения, а из выражений – операторы. Невозможность построить разрешенную конструкцию является признаком синтаксической ошибки в тексте исходной программы. После синтаксического анализа наступает этап поэтапной генерации кода.
На этом этапе происходит замена операторов языка высокого уровня инструкциями ассемблера, а затем последовательностями машинных команд. Но пока в результате получается файл не готовый к исполнению. Результат преобразования исходного текста программы записывается в виде двоичного файла (его называют объектным модулем) с расширением «.obj».
Объектный модуль можно выполнять лишь после специальной дополнительной обработки (компоновки), которая осуществляется специальной программой–компоновщиком. Что же нужно скомпоновать, т. е. соединить в единое целое? Дело в том, что проектировщики трансляторов предусмотрели, что в большинстве случаев программы создаются из отдельных фрагментов (модулей).
Если программа сложная, то деление ее на части упрощает работу над ней. Можно каждую часть отлаживать отдельно, а отладить короткую программу всегда легче, чем большую, можно разработку отдельных частей предоставить вести отдельным программистам и за счет этого добиться существенного сокращения сроков работы над всей программой и т. д. Можно конечно компоновать отлаженные части программы в текстовом виде, но это не всегда эффективно и возможно.
Например, если Вы используете в качестве модулей библиотеку стандартных программ, то эти программы поставляются в виде объектных файлов, а не текстовых. Во всех описанных пока случаях Вы должны явно указать транслятору (программе–компоновщику) какие файлы надо скомпоновать.
Но кроме этого компоновщик также добавляет к компонуемой программе коды так называемых библиотечных функций. Во–первых, это коды стандартных программ вычисления математических функций (sin, tg, exp), которые реализованы с использованием числовых методов.
Во–вторых, это коды функций отвечающих за выполнение конкретных действий, например, вывод информации на экран дисплея и т. п. Эти компоновки транслятор выполняет автоматически. Но этим перечень задач, которые решаются на этапе компоновки не ограничивается. Программа строится из инструкций и операторов.
В свою очередь, операторы включают выражения, которые состоят из операций и операндов. По крайней мере, части операндов в выражениях должны соответствовать отдельные «участки» оперативной памяти, предназначаемые, например, для сохранения результатов вычислений. В ходе трансляции устанавливается соответствие между операндами и адресами областей памяти вычислительной машины.
Задача компоновщика состоит в согласовании адресов во всех фрагментах кода (объектных файлов), из которых собирается готовая к выполнению программа. Компоновщик отвечает за то, чтобы конкретному операнду выражения соответствовала определённая область (ячейка) памяти.
Программа-компоновщик устанавливает все связи между отдельными компонуемыми модулями, поэтому ее часто называют редактором связей или линкировщиком (от англ. link – связь). Преобразованная компоновщиком программа называется загрузочным или выполнимым модулем. Файлы, содержащие загрузочные модули, называют загрузочными или выполнимыми файлами. Часто они имеют расширение (формат) «.ехе». Таблица Этапы сборки программы
| Действия | Исполнитель | Результат |
| Ввод исходного текста программы на языке программирования | Программист | Исходный модуль (файл с кодом программы) |
| Компиляция | Компилятор (программа языковой обработки) | Объектный модуль (программа в машинных кодах) |
| Сборка готовой программы из нескольких файлов, библиотек | Линкер (сборщик) | Исполняемый файл (загрузочный модуль) |
| Выполнение программы | Операционная система (выполнение) + Пользователь (загрузка исходных данных, управление) | Результаты расчета |
Полученный после компиляции машинный код – это готовый исполняемый файл, он выполняется только в той операционной системе, под которую был скомпилирован. Некоторые современные среды разработки, например, Free Pascal, являются кроссплатформенными – разные версии среды устанавливаются под разные операционные системы и позволяют создавать под них программы.
Источник: studfile.net
Этапы разработки интерфейса программы
Открыть меню
Основываясь на личном опыте и опыте своей компании, Роман написал статью о процессе разработки пользовательского интерфейса. Изначально она была размещена на Medium, на английском языке. Перевод этой статьи публикуется нами на Хабре.
Создание концепции
Самый первый этап — это когда идея уже есть, а разработчик имеет все необходимые инструменты для ее реализации. Но с чего нужно начинать? Мы начинаем с изучения ниши, целевой аудитории и кейсов продукта. Это неплохо помогает понять будущих клиентов сервиса и создать пользовательский интерфейс, который оптимален для каждого из них.
На этом этапе могут быть затронуты и такие аспекты, как размеры и расположение кнопок и форм, шрифты и многие другие аспекты структуры интерфейса. Давайте сравним финтех-приложение и сервис такси-компании.
Финтех-приложение. Много иконок, они не слишком крупные, но работать с ними удобно. Обилие разнообразных функций
Приложение одного из такси-сервисов. Кнопок не так много, и они большие, чтобы сложно было промахнуться
В первом случае должно быть много полей, списков, графиков и переходов. Во втором случае мы видим большие элементы управления, которые просто использовать во время поездки, — и такие вещи лучше понимать уже на этом этапе.
Брейнсторминг и эскизы
Как только концепция проекта ясна, двигаемся к следующему этапу — брейнстормингу. Он нужен, чтобы превратить идею интерфейса в реальность. Мы в Django Stars берем ручку и лист бумаги — это быстрее, чем использование таких продвинутых инструментов, как Balsamiq Mockups, Sketch, Photoshop и InVision.
Диаграмма переходов
Создание эскиза дает нам структуру интерфейса. Но как пользователь должен взаимодействовать с ним? Здесь поможет User Flow Diagram. Она проиллюстрирует логику продукта, показав всевозможные способы взаимодействия с интерфейсом, дорожную карту этих взаимодействий и состояние интерфейса на каждом этапе.
Утверждение структуры и диаграммы переходов
Как только мы закончили с эскизами интерфейса и диаграммой переходов, необходимо, чтобы клиент их утвердил. Структура и переходы — основа всей дальнейшей работы с интерфейсом, поэтому мы не двигаемся дальше без получения подтверждения. На этом этапе гораздо проще внести какие-то изменения в будущий интерфейс, а значит, сэкономить и время, и деньги заказчика.
В качестве примера можно взять интернет-магазин или систему управления продажами. Меняя структуру такого проекта после внедрения дизайна, можно попасть в ситуацию, когда ломается цветовая схема сайта, поскольку элементы интерфейса и некоторые другие его части были изменены. В этом случае вам, вероятнее всего, придется отказаться от изменений. Либо всю работу нужно будет переделывать с нуля.
Выбор стиля интерфейса
Когда клиент все утверждает — можно двигаться дальше. Что будем делать? Выберем стиль интерфейса. Есть множество вариантов: от минимализма и Metro до material design и скевоморфизма. На этом этапе мы просим клиентов прислать несколько ссылок на примеры стиля интерфейса, который им нравится, а также спрашиваем об их планах на ближайшее будущее продукта.
Мы уделяем внимание текущим трендам, масштабированию интерфейса, определяем время, которое необходимо на разработку и внедрение дизайна.
Подтверждение стиля
На этом этапе мы рассказываем клиенту о том, как видим все сами, а также объясняем, почему приняли то или иное решение. Он может не соглашаться с некоторыми моментами в самом начале, поскольку пока не получил полной информации об интерфейсе — у него не сформировалось представление и еще нет понимания возможных проблем. Цель — завершить обсуждение принятием варианта, который удовлетворяет и нас, и клиента.
Курс создан силами Skillbox и Agima. 4-месячная программа обо всех инструментах, без которых невозможна разработка мобильных продуктов.
Прототипирование, дизайн и их демонстрация
Как только все эти этапы завершены, мы готовы к тому, чтобы разрабатывать и показывать заказчику полную версию дизайна. Демонстрация может выглядеть по-разному. Основываясь на собственном опыте, мы рекомендуем придерживаться следующего.
Самая быстрая форма реализации ваших идей. Это низкоуровневая демонстрация дизайна. Однако такой способ позволяет показать структуру и описание взаимодействия пользователей с разрабатываемым продуктом. Выполняется в форме блочного интерфейса в оттенках серого.
Макетная демонстрация позволяет продемонстрировать проект дизайна, приближенный к реальности. Здесь все элементы и контент статичны, но воспринимается такая форма нагляднее предыдущей. И создать презентационную модель можно достаточно быстро.
Это уже детализированный прототип финального продукта. Он эмулирует взаимодействие пользователя с интерфейсом. Например, позволяет кликать по элементам управления, использовать формы и проверять другие моменты, включая анимацию. Тем не менее создание такого прототипа — процесс, который требует большого количества времени.
Так. Пришло время ребуса, вы попали именно в то место, где можно найти скидку. Учитывайте, что английский здесь может мешаться с русским, и главное — не забывайте, что мы будем тщательно следить за комментариями и удалять из них подсказки и ответы! Промослово, зашифрованное в ребусе, следует назвать, когда с вами свяжется наш менеджер после того, как вы отправите заявку на курс.
Скидки за разгаданные ребусы суммируются между собой (с учетом этой статьи есть четыре ребуса), но не со скидками на сайте. Слишком медлить не стоит — промо работает до 30 августа 2018 года.
А это уже видеозапись взаимодействия пользователя с приложением. Создание демонстрационной модели такого типа требует максимального количества времени, ведь необходимо не только сделать прототип, но еще и записать на видео работу с ним. Тем не менее это очень наглядная модель.
Утверждение дизайна
Есть люди, которые четко представляют себе, как должен выглядеть дизайн, и есть те, кто лишь предполагает. Как бы там ни было, у каждого свое видение. На этом этапе клиент видит результат и обсуждает с нами важные моменты, а мы вносим необходимые коррективы.
В качестве вывода
Поэтапная разработка интерфейса позволяет быстро добраться до конечной цели. Все это экономит время, причем в процессе разработки можно без проблем вносить изменения. Также такой способ работы значительно снижает вероятность появления неожиданных правок от клиентов.
Источник: full-arts.ru