Руководство по стилю. Для типовых конфигураций на платформе 1С:Предприятие 8.2 "Управляемое приложение"

назад


Руководство по стилю. Для типовых конфигураций на платформе 1С:Предприятие 8.2 Общие рекомендации

  • Типовым разрешением экрана считается 1024х768 pt. Все размеры в руководстве приведены с учетом этих значений и распространяются, в том числе на Windows Vista Aero. Условия эксплуатации:
    • Основное окно 1С:Предприятия растянуто на весь экран.
    • Видна панель задач операционной системы.
  • Разработку (конфигурирование) нужно вести в стандартном разрешении - 96 DPI.
  • При разработке управляемого интерфейса не рекомендуется вносить массовые изменения, нарушающие умолчание платформы, если иное не указано в этом руководстве по стилю или других стандартах. Например, для контекстных меню лучше использовать умолчание платформы, но в отдельных специфических случаях допускается внесение изменений.

Командный интерфейс (КИ)
КИ – средство навигации пользователей по функциональности конфигурации. КИ создается панелью разделов, панелью навигации и панелью действий. Каждая из панелей имеет свое назначение, но все вместе они создают пространство команд – возможностей для пользователя.

При проектировании КИ следует учитывать, что все три навигационных элемента связаны контекстом и предназначены:

  • для повышения эффективности выполнения повседневной работы;
  • для быстрого освоения программы.
Качество конфигурации во многом зависит:

  • от того насколько удачно это пространство будет организовано;
  • насколько оно будет соответствовать представлениям пользователя о назначении этой конфигурации.
Критериями хорошо спроектированного КИ являются:

  • скорость работы;
  • скорость обучения;
  • субъективная удовлетворенность пользователя.
 


Панель разделов (ПР)
Панель разделов – оглавление конфигурации.

Разделы должны соответствовать реальным областям деятельности или участкам работ так, как их понимают пользователи.

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

 


Что следует учитывать при проектировании
  • Панель разделов является "лицом" программы и имеет большое значение на этапе освоения, поэтому состав и порядок разделов следует проектировать с особой тщательностью.
  • Предполагается, что при выполнении задач связанных с определенной деятельностью пользователь будет проводить большую часть времени в каком-то одном разделе. Т.е. раздел является устойчивым режимом работы. Задачи, относящиеся к одной деятельности или к одному участку работ, должны решаться в рамках одного раздела – переключения между разделами должны быть минимизированы.
  • Интерфейс раздела нужно проектировать так, чтобы он содержал в себе все необходимые для работы команды и функции. При этом частотные или важные команды следует "вытаскивать наверх" – в начало панели навигации и панели действий.
  • При проектировании панели учитывайте и используйте доступность разделов (подсистем) по ролям.
  • Для интерфейса администратора допустимо наличие полосы прокрутки в панели.
  • По умолчанию разделы располагаются в алфавитном порядке. Рекомендуется определять порядок в зависимости от приоритета каждого раздела: от наиболее частотного и значимого до второстепенного и не часто используемого.
  • Последним всегда должен быть раздел для администрирования, настройки и выполнения сервисных действий.
  • Не рекомендуется делать раздел с названием "Сервис". Т.к. он будет перекликаться с меню "Сервис" и группой "Сервис" в ПД. Альтернативой могут быть такие названия как "Сервисные возможности", "Дополнительные возможности", "Прочее", "Сервисные функции", "Служебные функции" и т.д.

Названия разделов
  • Общая длина названия не должна превышать примерно 50 знаков с учетом пробелов (примерно 150 точек при 96 DPI).
  • При выборе названия (синонима) нужно учитывать, что панель разделов отображает максимум две строки названия с автоматическим переносом строк, но без переноса слов, т.е. слова не разрываются.
  • Для того чтобы название раздела смотрелось симпатично, рекомендуется использовать такие комбинации слов:
    • одно-два средних слова; "Финансы", "Зарплата и персонал"
    • одно среднее и одно короткое; "Учет времени"
    • одно длинное и одно короткое; "Сервис и администрирование"
    • два коротких и одно длинное. "Работы, услуги, производство"
  • По возможности не используйте длинные слова. Например, "гидролесомелиорация" или "делопроизводство".
  • Выбирайте названия примерно одного размера по ширине так, чтобы они смотрелись единообразно и ровно.
  • Давайте разделам конкретные (не двусмысленные) запоминающиеся названия.
  • Используйте в названиях только общеупотребительные и соответствующие целевой аудитории сокращения и аббревиатуры, например, "НДС" или "МСФО". Но если это возможно, лучше обходиться без сокращений.
См. также: Тексты


Картинки разделов в ПР
  • Для каждого раздела в ПН назначьте картинку размером 48х48 pt. Формат PNG с переменным альфаканалом.
  • Картинки следует делать разными по начертанию и по ведущим цветам. Это нужно для лучшей запоминаемости. Но при этом они должны быть нарисованы в одном стиле, с одинаковым углом поворота, выравниванием, направлением света и т.д.
  • Следует проверять, чтобы в режиме отображения "только картинки" ПР выглядела ровно и гармонично.
См. также: Требования к изображениям


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

Панель навигации основного окна (ПН)
Панель навигации представляет собой оглавление раздела.

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

Размеры панели по умолчанию – 243х589 pt.

Количество обычных команд – 31 (без группировки, выделения важных, без полосы прокрутки).


Названия команд
  • По возможности, названия команд должны помещаться в ПН с учетом ее стандартной ширины ПН (234 pt).
    • Важные команды – примерно 30 символов (т.к. они отображаются жирным шрифтом).
    • Обычные команды – примерно 38 символов.
  • Лучше, если названия команд начинаются с разных слов, так их удобнее искать с взглядом. Следует учитывать, что ширина ПН может быть уменьшена пользователем поэтому команды должны отличаться друг от друга уже в первых символах, но в тоже время должны быть понятны.

Группа команд "Важное"
  • Наличие группы команд "Важное" не является обязательным.
  • Относите в группу команды для перехода к таким рабочим местам, спискам и журналам документов, которые наиболее важны для пользователя в контексте данного раздела.
  • Выделяйте не более 5 важных команд.
При большем количестве команд ПН выглядит громоздко и выделение команд жирным шрифтом действует не так эффективно.

 


Группировка команд
  • Если команд в группе "Обычное" получается много, группируйте их по смыслу. Для этого следует пересмотреть содержимое подсистемы и разбить его на подсистемы так, чтобы в группе было от 4 до 9 команд. Критерием количества команд может служить оценка емкости кратковременной памяти человека – 7± 2.
  • Состав команд следует проектировать так, чтобы по умолчанию в панели навигации не было полосы прокрутки. Скрывайте нечастотные команды – пользователь, если потребуется, сам их себе включит.
  • По возможности избегайте появления в панели навигации групп, состоящих всего из одной команды. Помните, что при построении командного интерфейса учитываются роли и это может привести к тому, что для каких-то пользователей группа станет "вырожденной", т.е. состоящей всего из одной команды.
  • Не рекомендуется делать глубину вложенности групп команд более 2. При этом помните, что по умолчанию на втором уровне ширина текста команды будет меньше - 36 символов.
  • При разработке учитывайте, что по умолчанию все группы раскрыты.
  • Названия групп в ПН не должны пересекаться с системными группами, например, "Создать", "Отчеты", "Сервис", "См. также".

Группа "См. также"
  • Наличие группы не является обязательным.
  • В группу "См. также" не следует помещать команды по принципу "на всякий случай" или "вдруг пригодится".
  • Группа "См.также" предназначена для того, чтобы обеспечить горизонтальные связи между подсистемами – в нее следует относить важные, полезные для пользователя команды, которые напрямую не относятся к текущему разделу, но могут быть востребованы в некоторых случаях.

Порядок команд
  • По умолчанию команды располагаются в алфавитном порядке. Рекомендуется менять порядок так, чтобы частотные или первостепенные команды располагались сверху.

Какие команды следует помещать в панель навигации
  • В ПН следует помещать то, без чего нельзя обойтись в контексте текущего раздела: команды для перехода к рабочим местам, спискам, специальным обработкам. Под специальными понимаются обработки похожие на обычные списки, например, "Журнал регистрации", но не "Удаление помеченных объектов".
  • Обязательно размещайте команды перехода к спискам "первичных" данных. Списки первичных документов/данных, имеющих самостоятельную ценность (заказы покупателей, расходные накладные). Первичные – такие документы, с которых начинаются бизнес-процессы.
    Формы списков первичных данных при этом следует оптимизировать под соответствующие задачи пользователей, например поиск, или отбор необработанных заявок.
  • Для документов рекомендуется:
    • помещать в панель навигации и команды журналов и команды списков;
    • команды перехода к спискам делать по умолчанию невидимыми.
  • Если объект по логике второстепенен, подчинен другому объекту, то его можно вообще не выносить в командный интерфейс – например, подчиненный регистр сведений.

    Если же есть независимый регистр сведений, и он является важным для пользователя, то его следует поместить в панель навигации.
  • НЕ размещайте в панели навигации команды открытия обычных отчетов. Это связано с тем, что типовые отчеты должны открываться во вспомогательном окне со своим интерфейсом.
  • Если отчет по сути является рабочим местом для выполнения тех или иных функций, то нужно сделать специальную навигационную команду открытия этого отчета и разместить ее в ПН.

Панель действий (ПД)
Панель действий – место, где пользователи всегда смогут найти самые востребованные команды в контексте текущего раздела.

Она также служит своеобразным введением, "рассказывает" о том, что в этом разделе можно сделать.

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

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

 


Когда ПД не нужна
  • Если нельзя выделить частотные команды или их очень мало.
  • Когда все частотные команды контекстные. Например, команды создания групп не рекомендуется выносить в ПД, т.к. они почти всегда контекстны.
  • Если выполнение действий рекомендовано разработчиком через специальные формы (рабочие места). Например, перед созданием заказа поставщику нужно видеть общую картину заказов по организации.
 


Размеры ПД
При проектировании состава команд ПД, необходимо учитывать следующее:

  • По умолчанию в видимой области ПД помещается не более 15-ти средних команд. Под средней подразумевается команда, название которой состоит из 15-20 символов.
  • Максимальная емкость ПД по высоте - 30 команд. Если команд больше, то появляется кнопка открытия полного списка команд.

Названия команд
  • Текст стандартных команд (создание нового объекта, открытие отчета или обработки) формируется из синонима или представления соответствующего объекта метаданных. Это следует учитывать при присвоении имен и представлений объектам метаданных так, чтобы из текста команды было однозначно понятно ее назначение с учетом группы, в которую она входит (создать, отчет, сервис).
  • Тексты пользовательских команд тоже должны соответствовать этой рекомендации.
  • Не рекомендуется использовать очень короткие (менее 5 символов) и очень длинные (более 30) названия команд и синонимы (или представления) объектов метаданных.
  • Лучше, если названия команд, синонимы или представления объектов метаданных начинаются с разных слов. Тогда соответствующие команды будут хорошо различаться в панели действий.
См. также: Тексты


Группы команд в ПД
  • Если команду ПД нельзя отнести к одной из стандартных групп ("Создать", "Отчеты", "Сервис"), то можно создавать свои группы. Рекомендуется минимизировать количество таких групп.
 


Подсказки в ПД
  • Подсказка и справка для команд в ПД не является обязательной, но рекомендуется.
См. также: Тексты


Команды отчетов
  • Если отчетов немного, то следует помещать команды для их открытия в панель действий. При этом нужно учитывать общее наполнение ПД, чтобы она не получилась громоздкой.
  • Если отчетов много или если для управления ими пользователю нужен особый интерфейс, следует разработать специальное рабочее место по работе с отчетами. Такое рабочее место может содержать, например:
    • Список отчетов и вариантов
    • Готовые настройки
    • Предварительный просмотр
Команду вызова рабочего места рекомендуется поместить:

  • в панель навигации – если рабочее место должно открываться в главном окне;
  • в группу "Сервис" панели действий - если рабочее место должно открываться в отдельном окне.

Рабочий стол
Рабочий стол – личный заботливый помощник пользователя. Каждый рабочий день начинается с "общения" с ним.

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

  • Что нужно сделать сегодня?
  • Что появилось нового?
  • На что следует обратить внимание?
  • Каково состояние важных для меня сведений?

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

При проектировании рабочего стола важно учитывать:

  • Рабочий стол – первое, что увидит пользователь при запуске программы, поэтому его следует разрабатывать особенно тщательно. К формам рабочего стола нужно относиться, как к микро рабочим местам. С одной стороны они не должны быть перегружены, но с другой, предоставлять богатые возможности. Например, список задач может поддерживать drag-and-drop, чтобы при перетаскивании в него заказа покупателя система сразу предлагала создать новую задачу для коллеги со ссылкой на этот заказ.
  • Содержимое рабочего стола формируется автоматически в соответствии с ролями. Как правило, пользователь выполняет несколько ролей. Например, менеджер по продажам – занимается продажами, ведет личный учет времени, исполняет общефирменные поручения и приказы, выполняет анализ рынка, ведет исследования для развития своего направления.
 


Что нужно учитывать при разработке
  • Рабочий стол является обязательным разделом и не может быть отключен.
  • Проектируйте формы рабочего стола под существенно меньший размер чем обычные формы.
  • Не рекомендуется размещать на формах рабочего стола списки с горизонтальной полосой прокрутки.
  • Не рекомендуется использовать в формах рабочего стола меню "Все действия".
  • По возможности, не вставляйте команду вызова справки в формы рабочего стола.
  • В командных панелях форм рабочего стола рекомендуется делать минимально необходимый набор команд.
  • В командной панели списков не рекомендуется делать команды поиска и отмены поиска.
  • Формы для рабочего стола следует проектировать "с запасом" - делая их по умолчанию не видимыми, чтобы пользователи имели возможность настроить рабочий стол под себя.
  • В командных панелях динамических списков рекомендуется размещать команду обновления.
  • Состав форм рабочего стола следует проектировать таким образом, чтобы рабочий стол реального пользователя, с учетом ролей, содержал по умолчанию от 3-хдо 6-ти форм. Иначе рабочий стол будет смотреться вырожденным или перегруженным.
  • Высота списка должна быть не менее 3,5 строк.
 


Панель навигации на рабочем столе
  • Не рекомендуется делать на рабочем столе ПН, содержащую небольшое количество ссылок (например, менее 3-х) т.к. в этом случае ПН будет выглядеть пустой, но при этом занимать место слева.
 


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

Рабочее место
Рабочее место – это форма для выполнения какой-то одной бизнес-операции или группы взаимосвязанных бизнес-операций.

Следовательно, рабочее место должно удовлетворять двум основным требованиям:

  • предоставлять необходимый набор команд (создание новых данных, анализ имеющихся, выполнение других контекстных действий);
  • обеспечивать пользователя актуальной информацией, необходимой для правильного и быстрого выполнения бизнес-операций.

Другие требования к рабочему месту
  • Рабочее место должно быть интуитивно понятно сотруднику, который знает свою работу, но не знаком с программой.
  • Своим оформлением рабочее место должно "говорить", для какого специалиста и для решения, каких задач оно предназначено.
  • Предусмотрите на рабочем месте необходимый состав инструментов для работы специалиста.
  • Акцентируйте внимание пользователя на важной информации с помощью цвета.
  • Проследите, чтобы визуально рабочее место не казалось перегруженным. Рабочее место должно содержать достаточный минимум сведений, необходимых для качественного выполнения пользователем своих задач.
  • Самые важные сведения располагайте сверху.
  • Размещайте инструменты в логической последовательности решения задач.
  • Продумайте оптимальное выполнение действий: без необходимости переключения в другие интерфейсы.
  • Предусмотрите, в случае необходимости, переход к косвенным задачам (рабочим местам).
  • Названия рабочим местам следует давать по смыслу решаемых ими задач. Примеры: "Администрирование", "Расчет заработной платы", "Регистрация корреспонденции".
  • В названиях рабочих мест не рекомендуется использовать словосочетание "рабочее место".
  • Не рекомендуется размещать внедренную справку на рабочем месте. Внедренная справка – справка в форме, оформленная в виде подробных комментариев к полям, либо в виде отдельного поля, содержащего справку к форме.

Где размещать команду перехода к рабочему месту
  • В группе "Важное" панели навигации, если решаемые задачи частотны. При этом команда будет отображаться жирным шрифтом.
  • В блоке "См. также" панели навигации, если в контексте конкретной подсистемы рабочее место имеет второстепенное, вспомогательное значение и используется не часто.

Отчеты
 


Оформление
  • Отчет будет хорошим, если глядя на него, пользователю будет понятно:
    • для кого он предназначен (должность, роль пользователя);
    • на какие вопросы и каким образом можно получить ответы с помощью этого отчета.
  • Отчеты, связанные с одним источником данных (запросом), рекомендуется группировать в один отчет с несколькими вариантами. Примером источников данных может являться совокупность документов и регистров сведений, которые предназначены для пользователей с одинаковым уровнем прав (например, отчет "Выручка и себестоимость продаж").
  • Если вариант отчета является рабочим местом или используется очень часто, такой вариант лучше оформлять отдельным отчетом, чтобы упростить его использование пользователями.
  • В тех отчетах, где данные будут представлены в виде списка, рекомендуется первой делать колонку с порядковым номером.
  • В свойствах отчета рекомендуется устанавливать "Заголовок". Каждый отчет должен иметь узнаваемый и понятный заголовок.
  • Если в отчете несколько элементов (например, гистограмма и список), то для каждого рекомендуется устанавливать заголовок. Общий заголовок отчета в этом случае не обязателен.
  • Если в отчете несколько элементов (например, гистограмма и список), то в быстрых настройках рекомендуется предусматривать возможность их отключения.
  • Устанавливайте по умолчанию в настройки отчета наиболее вероятные значения. Например, период "Этот месяц" для отчета "Выручка и себестоимость продаж".
  • Устанавливайте по умолчанию направление сортировки так, чтобы наверху отображались самые важные для пользователей данные.
  • Используйте жирный шрифт для выделения важной, итоговой информации.
  • Если предполагается печать отчета, оптимизируйте макет под формат А4.
  • Применяйте условное оформление для отчетов, используйте единообразное цветовое кодирование. Например, красным можно подсвечивать просроченные задачи.
См. также: Рекомендуемые цвета

 


Быстрые и обычные настройки
  • В быстрые настройки следует вносить только частотные настройки.
  • Не рекомендуется делать много быстрых настроек (не более 5).
  • Для настроек, которые являются нечастотными лучше устанавливать режим редактирования "Обычный".
  • Избегайте использования наименований настроек, которые могут быть истолкованы пользователями неоднозначно или быть для них непонятными. Например, "Дата оплаты (< или =)" лучше заменить – "Оплатить не позже".
 


Названия отчетов
  • Назначение отчета должно быть интуитивно понятно из его названия.
  • Запрещается использование названия "Основной" для варианта отчета, т.к. для новичков не понятно, что кроется за этим определением. Лучше давать осмысленные названия, например, для отчета "Анализ причин проигрыша сделок" варианты: "По партнеру", "По ответственному", "По причине".
  • Избегайте слово "отчет" в синониме.
См. также: Тексты


Оформление форм списков
  • Состав и порядок колонок должен определяется логическим смыслом и важностью.
  • Отбирайте и группируйте колонки в несколько этажей так, чтобы можно было обойтись без горизонтальной полосы прокрутки. При этом нужно учитывать, что в многоэтажных списках труднее воспринимать информацию при беглом чтении.
  • Фиксируйте колонки там, где это уместно. Например, "№" и "Номенклатура" в списках документов.
  • При конфигурировании можно вставлять в таблицы динамических списков колонки "с запасом", делая их по умолчанию невидимыми, чтобы пользователь со временем мог оптимально настроить список по себя. Эту рекомендацию не следует применять для табличных частей.
  • Рекомендуется по умолчанию делать активной колонкой такую, поиск по которой будет наиболее вероятным. Например, для табличной части списка товаров это будет колонка "Товар".
 


Если колонка в списке одна
  • Не рекомендуется делать шапку.
  • Если заголовка нет, то визуально пустой список ничем не будет отличаться от многострочного поля ввода. Это нужно учитывать, чтобы не ввести пользователя в заблуждение.
  • Не рекомендуется горизонтальная разлиновка и чередование строк.
 


Размеры
  • Высота списков по умолчанию может быть подобрана с учетом типового количества строк. При этом нужно исходить из практики. Например, для списка товаров в УНФ это не более5-10 штук.

    Для списка документов заказов покупателя 3-5 строк мало, более 20 уже много т.к. такое количество все равно не охватить одним взглядом.
  • Не обязательно стремиться к одинаковой высоте списков, например, в различных документах. Они должны быть узнаваемыми, но точного соблюдения геометрии не требуется.
  • Высота строки управляемого списка при обычном шрифте – 19 pt.
  • Если нужно понять какой ширины должна быть колонка или поле и известно типовое количество символов в значении, используйте формулу: Ширина колонки = Количество символов/1,25

Минимальные размеры колонок для таблиц управляемой формы
Колонка

Количество символов (с пробелами)

Ширина

Банк

20

16

Банковский счет

20

16

БИК

9

7

Валюта

3

3

Год

4

4

Дата (со временем)

19

13

Договор

24

19

Индекс

6

5

ИНН физ. лица

12

10

ИНН юр.лица

10

8

Код ИФНС

4

4

Комментарий

20

16

Контрагент

20

16

КПП

9

7

Месяц

8

7

Номенклатура

20

16

Номер

11

9

Номер ГТД

30

23

ОГРН

13

10

ОКАТО

11

9

Описание

20

16

Организация

20

16

Ответственный

15

12

Подразделение

20

16




Быстрые отборы в списках

Когда использовать
  • Если список используется часто и просматриваются типовые поисковые "запросы". Например, по контрагенту, за период и т.д., по наименованию.
  • Визуальный поиск данных затруднен из-за их количества.
  • При работе со списком частотной является операция выбора/поиска.
 


Как оформлять быстрые отборы
  • Поля ввода или флажки рекомендуется размещать перед списком сверху, слева или справа, в зависимости от состава отборов и их смысла. Допускается размещать внизу списка, если отбор полезный, но не частотный. Например, "Показывать выполненные задачи" в списке "Мои задачи".
  • Быстрbr /ые отборы сверху следует располагать над командной панелью списка.
  • У полей необязательных отборов должна быть кнопка очистки или должна быть одна кнопка очистки всех полей быстрого отбора.

Когда использовать двух и более этажные списки
  • Когда данные важно просматривать без прокрутки.
  • Если в списке много колонок, например, более 10.
  • Если для просмотра данных пользователям часто придется использовать горизонтальную полосу прокрутки.
  • При проектировании учитывайте, что в многоэтажных списках визуальный поиск данных сложнее, чем в одноэтажных.

Какую высоту строки использовать
  • Одинарную, если значения в ячейках короткие и список выглядит компактно и не перегружено.
  • Двойную, если значения в ячейках длинные и важно их видеть полностью.
 


Размещение команд в группе "Все действия"
  • Рекомендуется использовать умолчание платформы.
  • Для отдельных списков допускается индивидуальная настройка командной панели. При этом непосредственно в командной панели формы лучше располагать небольшое количество наиболее частотных команд (не более 10), а остальные размещать во "Все действия".

Контекстные меню
  • Рекомендуется использовать умолчание платформы.
  • В отдельных случаях можно настраивать контекстное меню так, чтобы оно содержало ожидаемые пользователями команды.
    • В первую очередь - частотные в данном контексте действия.
    • Во вторую – сервисные и вспомогательные.
  • Не перегружайте контекстное меню:
    • Если команд много, делите их на группы по 5-9 команд.
    • Суммарное количество команд с учетом разделителей должно помещаться на экране без прокрутки.

Заголовки списков
  • Если на форме один список, то для него не требуется заголовок. То же самое относится к случаю, когда на форме два списка, связанных общим контекстом, например, дерево групп контрагентов и список контрагентов в группе. Назначение таких списков интуитивно понятно и как правило не требует дополнительного пояснения.
  • Если на форме несколько списков, то их назначение должно быть интуитивно понятно из общего контекста формы, наименования колонок или из заголовка формы.
  • Если это невозможно, то следует оформлять такие списки заголовками
    • Если список имеет командную панель то в виде группы со стандартной рамкой (линия)
    • Если список не имеет командной панели, то следует использовать стандартный заголовок в положении "Верх".

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

Когда использовать группировку в списке
  • Если есть уверенность в том, что эта группировка будет способствовать визуальному поиску нужных данных.
  • Если группировок просматривается несколько, то их можно вынести как настройку в область быстрого отбора.
  • Следует помнить, что группировки могут сильно затормозить работу.
См. также: <A href="#_Быстрые_отборы_в_1">Быстрые отборы в списках


Сообщения пользователю
 


Сообщения об ошибках в форме


  • Окно сообщения об ошибке автоматически форматирует текст и переносит строки (не слова), сохраняя при этом свои пропорции.
  • Из текста сообщения пользователю должно быть понятно:
    • Что сейчас произошло?
    • Почему это произошло?
    • Какие действия ему следует выполнить дальше?
  • Сообщение должно быть как можно более кратким и понятным. "Поле "Наименование" не заполнено" - этого достаточно для того, чтобы сообщить пользователю о том, что нужно заполнить поле. Если же поле заполнено, но неправильно, то сообщение должно быть более подробным.

    Например, "Такого количества товара нет на складе", "Контрагенту запрещена продажа по оптовым ценам".
  • Сообщение об ошибке по возможности должно быть привязано к полю, которое породило ошибку или позволяет исправить ее. Если сообщение нельзя привязать к тому или иному полю, то в тексте сообщения следует явно указать, что пользователю нужно сделать для того, чтобы устранить проблему.
  • Текст сообщения не должен содержать обвинений или носить нравоучительный характер.

Оповещение


  • Оповещение используется тогда, когда источником оповещения является объект данных. Если источником оповещения является не объект данных, а например, форма обработки, то при использовании оповещения необходимо обеспечить попадание ссылки на обработку в Историю работы пользователя.
  • Используйте оповещения для информирования пользователя о произошедших событиях без прерывания основной работы т.е. пользователю не обязательно реагировать на оповещение, оно выдается для информации. Оповещение сообщает о том, что запрошенная операция (запись элемента справочника или проведение документа) выполнена.
  • Оповещения рекомендуется делать с гиперссылками на соответствующие объекты.
  • Следует учитывать, что оповещения попадают в панель информации и поэтому их не следует применять для протоколирования хода выполнения длительной операции.
  • Текст и пояснение оповещения рекомендуется составлять так, чтобы они целиком помещались в окне оповещения с размерами "по умолчанию":
    • Текст – 36 знаков;
    • Пояснение – около 100 знаков (с учетом переноса на три строки).
 


Состояние
  • Используйте состояние для информирования о выполнении длительных процессов (занимающих более 10 секунд), чтобы у пользователей не сложилось впечатление о том, что программа "зависла". Выводите одно состояние перед началом выполнения ("Выполняется расчет. Пожалуйста подождите…"), в процессе выполнения (если есть возможность) и при завершении ("Расчет выполнен").
  • Используйте состояние для длительных операций, состоящих из некоторого числа более мелких операций. Так, при переносе файлов с жесткого диска в информационную базу можно выводить состояние для каждого переносимого файла. Например: Состояние("Копирование файлов...", Процент, "Обрабатывается файл " + ИмяФайла, КартинкаИнформация).

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


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


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

Окна на старте
  • Если содержание окна на старте не обязательно для ознакомления пользователям, то необходимо предусмотреть по умолчанию возведенный флаг "Показывать при открытии программы". Флаг рекомендуется располагать под содержанием окна.

Формы
 


Командная панель
  • В командной панели формы кнопка по умолчанию должна быть самой левой.
 


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

Порядок полей
  • Кнопкам рекомендуется устанавливать свойство "ПропускатьПриВводе".
  • Для поля, с которого обычно начинается ввод, рекомендуется установить свойство "АктивизироватьПоУмолчанию".
 


Группы полей в форме

Когда применять
  • Для объединения логически связанных данных.
  • Для облегчения визуального восприятия формы за счет выделения блоков данных.
 


Количество элементов в группе
  • Не рекомендуется делать группы, содержащие один реквизит.
  • Рекомендуется размещать в группах 5-9 элементов.

Оформление заголовка группы
  • Заголовок может использоваться в качестве расшифровки или пояснения, если из названий реквизитов не достаточно понятно их назначение.
  • Не рекомендуется использование заголовка, если группа одна и расположена на странице панели. В этом случае заголовком группы является заголовок самой страницы.

Флажки
  • По возможности, располагайте текст справа от флажков.
  • Первая буква подписи флажка и переключателя должна быть заглавной.
  • Подписи у флажков и переключателей следует делать позитивными (не содержащими отрицания).
  • Текст подписи должен быть понятным и кратким.
  • Текст флажка определяет только один вариант, второй остается неявным и не сформулированным – подбирайте текст флажка так, чтобы у пользователей не возникало сомнений в том каким будет второй вариант.

Панель навигации вспомогательной формы
  • Для частотных и важных форм рекомендуется вручную настраивать видимость команд в ПН, отбирая только команды перехода к важным для пользователя сведениям.
  • Рекомендуется размещать в ПН не более 10 команд.
  • Не следует размещать в панели команды перехода к другим формам для редактирования реквизитов объекта. Открывать форму элемента из панели навигации окна другой формы элемента недопустимо.

Выбор: блокирующая форма или независимая
 


Блокирующая
  • Работа с формой выполняется "за один заход", без необходимости переключения в другие формы.
  • На форме небольшое количество элементов, например, менее 5.
 


Независимая
  • Если при работе с формой может потребоваться открытие других самостоятельных форм.
  • Если пользователям может потребоваться сравнение двух и более объектов.
  • На форме много элементов, больше 9.
 


Формы выбора
  • Рекомендуется не создавать формы выбора, а использовать генерируемые платформой по умолчанию.
  • Если, в соответствии с прикладной логикой, в форме выбора нужно предусмотреть особенный состав команд или колонок, то можно создать форму выбора, следуя рекомендациям
    • В командной панели формы рекомендуется размещать минимально необходимый набор команд для выбора, создания нового и поиска/отбора.
    • В часто используемых формах выбора из больших наборов данных рекомендуется делать область быстрого отбора/поиска.
    • Состав колонок следует оптимизировать для быстрого визуального поиска данных
См. также: [Быстрые отборы в списках

 


Оформление элементов
  • Следует оформлять единообразно общие для разных форм реквизиты, их подписи, размеры и положение на форме и их группы.
 


Выбор: кнопка или гиперссылка
 


Кнопки
  • Кнопка хорошо подходит для обозначения одиночной, самостоятельной операции (обработка, расчет) и используется, как правило, для запуска некоторого процесса, выполнения действия.
  • Название у кнопок должно содержать глагол, отвечающий на вопрос "Что сделать?" "Найти", "Рассчитать", "Записать". Вместо глаголов можно использовать отглагольные существительные.
  • Кнопки следует размещать в непосредственной близости от объектов, на которые они оказывают воздействие.
 


Гиперссылки
  • Используются для перехода к другой форме, которая отображает
    • связанные данные (другие объекты)
    • дополнительные данные этого же объекта в режиме "только просмотр"
  • Из названия гиперссылки должно быть понятно, что именно откроется в новом окне, например, "цены номенклатуры", "паспортные данные".
 


Выбор: команда отображается картинкой или текстом и картинкой
  • Если в командной панели только одна команда, то она обязательно должна иметь картинку.
  • Рекомендуется назначить картинки таким командам, которые будут использоваться часто.
 


Только картинка
  • Если команда частотная (редактировать, удалить, скопировать, печать) и метафоры картинок интуитивно понятны, а назначение команд очевидно.
 


Текст и картинка
  • Если это нетипичные или незнакомые пользователям команды.
  • Если нет уверенности, что метафоры команд понятны.
 


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

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


Команда "Отмена"
  • Команда "Отмена" должна использоваться для реальной отмены установленных настроек и приводить к закрытию формы.
  • "Отмена" не должна быть кнопкой по умолчанию. Если никакие действия кроме закрытия формы недоступны, кнопкой по умолчанию должна быть кнопка "Закрыть".
 


Подписи к полям
  • Единицы измерения лучше указывать после полей. Не правильно



    Правильно
  • В списках единицы измерения следует указывать в заголовках колонок, а не в каждой ячейке. Частные случаи:
    • Процент – символ "%" следует выводить в каждой ячейке, если в конфигурации это принято повсеместно (Ставка НДС, Процент выполнения заказа и пр.)
    • Валюту лучше не указывать:
      • если о ней есть упоминание в итоговых показателях;
      • если из контекста работы понятно, о какой валюте идет речь.
 


Реквизиты
  • Рекомендуется всегда оставлять на форме стандартные поля, такие как наименование, номер и дата (для документов и задач).
  • Если для реквизита предусмотрен выбор из списка, а в списке имеется только один вариант, его следует подставлять по умолчанию. Примеры: одно значение ставки НДС (18%), один договор по контрагенту, заказ.
  • При создании на основании необходимо заполнять все наследуемые реквизиты.
  • Указывайте единицы измерения для колонок таблиц и полей ввода, содержащих количественные характеристики (длина, вес, рост, скорость, расстояние, размер и пр.)
    • Для колонок таблицы – в заголовке колонки
    • Для полей ввода - в надписи справа от поля

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

Рекомендуемые цвета
  • Цвет ошибочного значения
    • Web - Кирпичный
  • Цвет информационной надписи
    • Web - Синий со стальным оттенком (SteelBlue)
  • Не рекомендуется сочетать зеленые и красные цвета одинаковой насыщенности на одной форме.

Требования к изображениям
  • Хорошо узнаваемые метафоры, выдержанные в едином стиле.
  • Разные очертания у близких в ряду иконок, чтобы повысить их запоминаемость.
  • Соблюдены одинаковые углы, перспектива, тень во всех используемых иконках.
  • Объекты изображены в современном виде (например, компьютер).
  • Иконки разные по начертанию и по ведущим цветам.
  • Исключите ситуации, когда различить иконки можно только по их цвету.
  • Формат - картинки PNG с 8-битным альфаканалом. Если есть возможность без потери качества сделать картинку с 1-битным альфа-каналом, то лучше делать именно так для уменьшения размера конфигурации.
  • Требуется "ручной" пересмотр всех картинок в конфигурации, как в общих картинках, так и в картинках в формах.
  • Не следует использовать в конфигурациях альфа-канал у картинок, чей размер превышает 40000 точек (например, картинка 200х200 точек). Для таких картинок не поддерживается корректное отображение в веб-клиенте, который работает в веб-браузере Microsoft Internet Explorer 6.0. Это правило не относится к картинкам-коллекциям, размер элементов которых меньше указанного ограничения.
  • Если в конфигурации делается поле HTML документа, которое будет показывать какие-либо картинки, то эти картинки нужно делать в формате PNG с 1-битным, а не 8-битным альфа-каналом, т.е. в формате png-8, либо в формате png-24 без альфа-канала. Для правильного отображения цветов в браузере рекомендуется удалять из заголовка файла PNG информацию о палитре и гамма-коррекции.
  • В остальном изображения должны соответствовать "Руководству по созданию изображений для типовых конфигураций на платформе 1С:Предприятие 8.2"
 


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

Тексты
 


Общие рекомендации
  • Избегайте технологических терминов и аббревиатур, используйте язык пользователей.
  • Следите за единообразием понятий, которые используются в программе.
  • Используйте короткие предложения т.к. чтение с экрана монитора достаточно быстро утомляет.
  • Если текст объемный, сначала укажите главную мысль, затем другие в соответствии с уменьшением их важности.
  • Разбивайте текст на небольшие абзацы.
  • Проверяйте все надписи, подписи и сообщения на правописание и грамматику.
  • Поле ввода и подпись к нему должны отображаться одинаковым шрифтом (начертание, размер, жирность), но не цветом.
  • В интерфейсных текстах используйте только прямые кавычки. В справке допускается использовать французские кавычки "елочки".
 


Названия и заголовки
  • Рекомендуется избегать названий и заголовков, которые могут быть неоднозначно поняты пользователями.
  • Не рекомендуется использование названий и заголовков длиной более 60 символов.
  • Термином "родитель" обозначайте родственные отношения между физическими лицами, но не для обозначения иерархии объектов информационной базы. Вместо это можно использовать прикладные термины, например:
    • группа товаров
    • головное подразделение
    • в<I>ходит в группу
    • входит в категорию
    • находится в группе и т.д.
  • Если в конфигурации принято выводить количество элементов (например, "Товары(10)") в заголовках страниц или групп, то этот прием должен применяться везде, во всех объектах конфигурации.
 


Когда использовать троеточия
  • Используйте троеточия, если название команды или ссылки отражает действие ("Изменить форму", "Распределить задачи" – в форме инфинитива или отглагольного существительного), а при нажатии осуществляется переход к дополнительной форме (месту) для выполнения этих действий.
  • Троеточие должно примыкать к последнему слову без пробела, например "Печать…", а не "Печать …".
  • Если название команды описывает процесс, который будет запущен, то троеточия не нужны. Изменение формы", "Распределение задач" и пр.

Горячие клавиши
  • Рекомендуется установить сочетание клавиш для наиболее частотных команд.
  • Рекомендуется установить сочетание клавиш для вызова часто используемых неконтекстных форм. Например, форма полнотекстового поиска, форма ежедневного отчета о рабочем времени.