Как специалисты по эргономике формулируют задачу по оценке качества интерфейса?

Цитата:

"Во многих исследованиях по оценке деятельности операторов задаётся простой вопрос: какая интерфейсная система лучше – A или B? Это пример плохо сформулированной задачи, и результаты последующих усовершенствований почти наверняка будут разочаровывающими., т.е. они будут не очень информативными по сравнению с затратами на их получение. Поскольку интерфейсы используются для сообщения данных оператору в целях оказания помощи при выполнении рабочих заданий, то, как минимум, вопрос об оценке должен задаваться в такой форме:

Проектирование игр: функциональный подход

Сегодня выкладываю свою презентацию с КРИ 2008. Она освещает вопросы проектирования видео игр, разумеется, не с гейм-дизайнерской, а с технической точки зрения. В презентации изложены ответы на такие вопросы:

1. К каким проблемам приводят слишком большие иерархии классов?
2. Чем можно заменить такие иерархии?
3. Что брать в качестве основы декомпозиции на подсистемы - функции или объекты?
4. Как проектировать AI-водителя для гоночной игры? (Описание примера.)
5. Чем "грешит" паттерн "Цепочка обязанностей"?

В чём различие между объектно-ориентированным и системным подходами? Часть 1

Объектно-ориентированный подход – это подход к разработке программ. Он был изобретён Кристеном Нюгордом и Оле-Йоханом Далем при разработке языка Симула-67. Впоследствии многие его концепции были развиты Аланом Кеем и Дэном Ингалссом при работе над языком Smalltalk.

Объектно-ориентированный подход предполагает, что любую программу можно представить в виде набора взаимодействующих объектов. Сначала предполагалось, что объекты будут взаимодействовать посредством обмена сообщениями. Однако в большинстве существующих языков программирования объекты взаимодействуют при помощи вызова функций.

Для описания объектов в языках программирования существуют классы. Фактически, класс – это модуль, для которого можно создать экземпляр (или несколько экземпляров). Как и всякий модуль, класс имеет свои интерфейс (открытую часть) и реализацию (закрытую часть). Экземпляр класса является объектом.

Объектно-ориентированный подход считают развитием структурного подхода к программированию. Основное отличие заключается в том, что объектно-ориентированный подход позволяет объединить данные и методы, обрабатывающие эти данные, в единой сущности – объекте.

Системный подход – это подход к:

Usability GPS-навигатора

30 июня 2008 года на форуме RSDN.RU автором была размещена такая задача...

ЗАДАЧА

Уважаемые Коллеги!

Хотелось бы знать, как можно решить подобную задачу (см. описание ниже). Свои решения имеются. Но хочется, чтобы посмотрели на задачу люди со стороны. Чтобы не навязывать свои решения, я опишу их чуть позже.

Задача: Навигационная система для КПК (с поддержкой GPS и GSM) должна включать модуль "поиск друзей". Функциональность этого модуля достаточно проста: любой пользователь системы может послать своему другу запрос (через СМС) о его местоположении. Получив такой запрос, пользователь может либо подтвердить его (т.е. навигационная система отсылает другу текущие координаты), либо отклонить (запрос остаётся без ответа).

Обязательное условие: Отсылка координат по запросу всегда должна утверждаться пользователем. Т.е. система сама без ведома пользователя не должна никому отсылать его координаты.

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

Другое обязательное условие: Ничто не должно отвлекать внимание пользователя, пока он управляет автомобилем.

Что такое "идеальный код"?

Из обсуждения на форуме RSDN.RU (привожу свои доводы):

Судя по приведенному примеру, Вы предполагаете, что программный код – это набор символов. Но это неправильно! Это все равно, что предполагать, будто дом – набор кирпичей или строительных блоков.

Так же, как письменная речь не сводится к набору букв, так и программный код – нечто большее, чем набор символов. Код имеет иерархическую структуру, и на каждом уровне этой иерархии в качестве элементов выступают разные абстракции:

0. Символы.

1. Слова (операторы, переменные, константы, типы данных).

2. Функции и функциональные блоки.

3. Типы данных, определяемые пользователем.

4. Иерархии, группы связанных классов.

5. Библиотеки.

6. И т.д. – наверняка что-то пропустил.

Соответственно, когда я пишу, что хороший код – это компактный код, я отнюдь не имею в виду минимальное количество символов. Ибо хорошо понимаю, что код – это нечто большее, чем просто набор символов, и вижу различные системные уровни.