Проектирование программного интерфейса для различных размеров экрана

Question

В настоящее время у нас есть экраны, такие как 1920x1200 и 1680x1050 в популярном использовании, а некоторые даже используют разрешение 2560x1600, в то время как некоторые более старые системы все еще полагаются на разрешение 800x600. Я пишу программное обеспечение, которое хорошо выглядит на 1680x1050, но слишком маленькое на 1920x1200 и слишком большое на 1024x768. У вас есть предложения по разработке приложений для разных размеров экрана?

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

Я знаю, что этот вопрос больше касается проектирования/компоновки, чем программирования, но я уверен, что это более или менее часть жизни программистов, поэтому я сделал этот пост здесь.

Answer 1

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

Проектирование (если оно не разрабатывается) для нескольких размеров окон довольно просто, когда данные выложены в виде списка/табличного или графического формата (последние включают карты, диаграммы и большинство приложений WYSIWYG). Панель, отображающая таблицу или рисунок, должна изменяться по мере изменения размера окна. Как правило, вы включаете горизонтальные и вертикальные полосы прокрутки по мере необходимости, чтобы пользователь мог панорамировать данные в пределах любого размера панели, который есть на данный момент. Изменение размера панели с изменениями окна обычно подразумевает, что все данные доступны полосами прокрутки. Это не работает, чтобы разбить данные на страницы (например, как разбить результаты поиска Google).

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

Для данных, выложенных как форма, с полями и надписями для одной записи, бегущей по панели, действительно нет хорошего способа обработки нескольких размеров окна, и вам нужно выбрать размер окна для проектирования , Для удобства использования вы должны проектировать так, чтобы при стандартном размере текста все поля были видны без прокрутки, когда размер окна соответствует наименьшему разрешению экрана, с которым вы, вероятно, столкнетесь. Используйте вкладки или другие аналогичные элементы управления для соответствия всем необходимым полям в этом пространстве. Как правило, это подразумевает размер 1024x768, предполагающий, что ваши пользователи могут использовать ваше приложение на ноутбуке. Это может быть приемлемым, чтобы иметь макет формы, который требует некоторой вертикальной прокрутки при меньших разрешениях (как это обычно бывает в веб-приложениях), но пользователям не нужно прокручивать по горизонтали для типичных случаев. Таким образом, в вашем случае вы можете создать дизайн для 1024x1050, если большинство ваших пользователей используют настольные компьютеры и только изредка используют ноутбуки. Проверьте, что пользователи понимают, что им нужно прокручивать, когда используете низкое разрешение, прежде чем приступать к этому. Если вы ожидаете, что пользователи будут регулярно использовать это окно при просмотре других окон (например, это скорее похоже на диалог свойств), это может установить дополнительные ограничения на размер окна.

С макетом формы размер текста или пробелы между полями не должен изменяться при изменении размера окна (хотя разрешение на явное увеличение размера текста является хорошей идеей). Изменение размера, превышающее заданный размер, должно просто добавлять пустые поля вправо и снизу. Другими словами, на самом деле не так много смысла в изменении размера для макета формы. Это нормально. По крайней мере, некоторые из ваших пользователей будут использовать неиспользуемое пространство экрана для чего-то еще (например, другого окна или приложения). Реальные пользователи с большими экранами могут открывать два экземпляра одного окна рядом друг с другом и каждый экземпляр отображает другую вкладку, чтобы они могли отслеживать как можно больше одновременно.

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

Answer 2

В общем, вы разрабатываете для самого низкого разрешения экрана, которое вы ожидаете встретить.

Вы правы в том, что существует множество разумных разрешений экрана.

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