1.Полосы прокрутки и их альтернатива.

Проблема полос прокрутки заключается в том что для маленьких документов они не очень нужны, поскольку пользователям, держащим руки на клавиатуре, гораздо легче переместиться к нужному фрагменту с помощью клавиш со стрелками. Напротив, в больших документах малое перемещение ползунка приводит к существенному сдвигу области просмотра, так что после перемещения нужно еще и подправляться либо клавиатурой, либо стрелками на полосе прокрутки. Более того: во многих случаях невозможно реализовать динамическое изменение области просмотра во время перемещения ползунка, а значит, перемещаться по большим документам приходится в несколько шагов. И еще раз более того: предположим, что это динамическое изменение всё-таки есть. Тогда пользователю нужно: сначала перевести взгляд на ползунок, затем курсор на ползунок, затем взгляд на документ и только потом, перемещая мышь вверх или вниз, следить за областью просмотра, на тему «не пора ли отпустить курсор».

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

2.В чем заключается принцип спиральности в справочной системе?

Поскольку пользователи обращаются к справочной системе при возникновении проблем, можно смело сказать, что использование справочной системы всегда воспринимается негативно. Таким образом, следует всемерно сокращать объем справочной системы, чтобы тем самым сократить длительность неудовольствия. Но при сокращении объема справочной системы возрастает риск того, что пользователи не найдут в ней ответы на свои вопросы.

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

3.Версии построения прототипа.

Первая версия. Бумажная

Необходимо нарисовать на бумаге все экраны и диалоговые окна. Нужно только убедиться, что все интерфейсные элементы выглядят единообразно и сколько-нибудь похоже на реальные. На нём можно тестировать восприятие системы пользователем и её основную логику. На этом этапе прототип может пережить множество исправлений и, соответственно, много версий.

Вторая версия. Презентация

Для этого точно так же рисуется интерфейс, но уже не на бумаге, а в какой-либо презентационной программе (MS PowerPoint, н-р). При этом каждый слайд получает отдельный экран, а результат нажатия кнопок имитируется переходами между ними. С этой версией прототипа можно тестировать значительно более сложное взаимодействие человека с системой, чем с бумажной.

Третья версия

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

Четвертая версия

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