Style Guide

For off-the-shelf applications developed on 1C:Enterprise 8.2 Platform

Index
Main Provisions ........................................................................................................................... 1 Command Interface (CI) .............................................................................................................. 1 Sections Panel (SP)...................................................................................................................... 2 Main Window Navigation Panel (NP) ........................................................................................ 3 Actions Panel (AP) ...................................................................................................................... 5 Desktop ........................................................................................................................................ 7 Workplace.................................................................................................................................... 8 Reports ......................................................................................................................................... 9 Designing List Forms ................................................................................................................ 10 Messages to User ....................................................................................................................... 13 Start-Up Windows ..................................................................................................................... 15 Forms ......................................................................................................................................... 15 Items Design .............................................................................................................................. 16 Attributes ................................................................................................................................... 18 Font and Color ........................................................................................................................... 18 Requirements for Pictures ......................................................................................................... 19 Forms Composition ................................................................................................................... 19 Texts .......................................................................................................................................... 19 Hot Keys .................................................................................................................................... 20

Main Provisions

Typical screen resolution is considered being 1024768 px. All sizes in this guide are matched to this resolution, including the Windows 7 Aero. Operating environment:

o The 1C:Enterprise main window is maximized to the full screen. o The operation systems task bar is visible. Development of the application should be performed under the default resolution of 96 DPI. It is recommended not to change defaults of the platform too often during the development, unless otherwise stated herein or in other standards.
For example, it is recommended to use the platform default settings for the context menu, but it is allowed to make changes in specific cases.

Command Interface (CI)

The CI provides users a navigation to the application. CI consists of Sections, Navigation and Actions panels. Each panel has its own purpose but all panels together are presenting the commands space which are the users functions. Note that all of the three navigation elements are associated with the context and have following purposes:

Increasing the operators daily performance; Shortening the application studying time for a newbie. Quality of the application mainly depends on:

Usability of the interface design; How much user friendly and intuitive it is.

Well-designed CI criteria:

Operating performance; Time of studying; Subjective user satisfaction.

Sections Panel (SP)

Sections panel is contents of the application. Sections should reflect business activities or area of work according to the users opinion. It is recommended to design the section content avoiding the scroll bar appearance in typical combination of user roles. To match the above the Sections panel should contain not more than 8-10 sections.

Aspects which Should be Considered during Design

Sections panel is a "face" of the program and is very important during the studying, so the sections structure should be designed thoughtfully. It is assumed that the user will use one specific section when performing tasks within a specific activity. I.e. the section is the stable operating mode. Related to one activity or same area of work tasks should be performed within a single section. Number of switching between sections should be minimized. Section interface should be designed to contain all commands and functions necessary to work. Also frequently used or important commands should be sorted to be on top of the Navigation or Actions panel. Also consider the accessibility of sections (subsystems) for different roles during design. The scroll bar in the panel is allowed for the administrative interface. By default, sections are arranged in the alphabetical order. It is recommended to define the order according to priority of sections: starting from most frequently used and important till minor and rarely used. The administrative, development and service functions sections should always be placed last. It is not recommended to create a "Service" section. That is due to the similar Service menu and Service group in Actions panel. As an alternative, following captions could be used: "Service features", "Additional features", "Miscellaneous", "Service functions", and so on.

Section Naming

Total name length should not exceed approximately of 50 characters, including spaces (about 150 point with resolution of 96 DPI). It should be kept in mind during selection of the name (synonym) that Sections panel could display not more than two lines of the name. And there is an automatic word wrapping, but no hyphenations, i.e. the words will not be split. It is recommended to use the following words combinations to make section names look nice: o One or two medium-length words; "Finances", "Salary and Payroll"

One medium-length and one short word;

"Time Accounting"

One short and one long word; "Service and Administration"

Two short words and one long word. "Goods, Services, Manufacturing"

Do not use long words if it is possible. For example, "supermastergroup-dropping equipment" or "documentation management".

Names should be selected of approximately same length to provide an uniform and aligned presentation. Sections should be named with the specific, non ambiguous, easy-to-remember names. It is allowed to use only abbreviations which are commonly used and corresponding to the target audience, such as the "VAT" or "HR".

It is recommended to avoid abbreviations whenever its practicable. See also: Texts

Choosing Images for Sections Panel

A picture with dimensions of 4848 px should be set for every section in the Sections panel. Pictures should be of PNG format with an alpha-channel. Pictures should be differ in shape and prevailing colors. It is required to provide better mnemonics. Also they should be drawn in one style, with the same perspective, alignment, lighting angle and so on. It should be verified that Sections panel looks aligned and balanced in the Pictures only representation mode.

See also: Requirements for Images

Tooltips for Interface Subsystems

Tooltips are not required for the Sections panel due to the purpose of the section should be unambiguously understandable from its name. The Section name should be intuitive to allow the user to identify if the section contains the information the user is looking for.

Tooltips could additionally expand the sections content, for example, by listing its functions. Help is not required for the Sections panel sections.

Main Window Navigation Panel (NP)

The Navigation panel is the section contents. The main panels feature is its visibility and a possibility to quickly switch to the required list or workplace. Default panel size is 243589 px. Number of regular commands is 31 (without grouping, without important items highlighting, without scroll bars).

Command Naming

Command names should fit the Navigation panel considering its default width (234 pt) when it is possible. o Important commands approximately 40 characters (since they are displayed bold). o Regular commands approximately 48 characters. It is preferable to start command names with different words, as it will simplify searching for it. It should be considered that the Navigation panel width could be narrowed by the user, so commands should have distinct names with two first characters, to remain understandable in that case.

Important Command Group

The Important command group is not required. This command group should include commands for switching to the most important workplaces, lists and document forms in the context of this section. It is recommended to highlight not more than 5 commands as important. If there would be more highlighted commands the Navigation panel will look heavy, and commands highlighting will be less effective.

Command Groups

If there are lots of commands in the regular group, they should be grouped by their meaning. For that purpose, the content of the subsystem should be revised and divided on smaller subsystems with 4 to 9 commands per group. An estimation of the humans short-term memory capacity (72) could be used as a criterion for defining the command quantity.

Command content should be designed to avoid the scroll bar appearance in the navigation panel. It is recommended to hide rarely used commands user could turn them on if required.

Try to avoid a creation of navigation panel groups consisting of the single command only, when it is possible. Note that roles are applied when the command interface is rendered, which could lead to appearing degenerated groups (i.e. group consisting of a single command only) for some users.

It is not recommended to make the depth of nested command groups greater than 2. With this in mind, it should be noted that the default command text width on second level would be smaller - 46 characters.

It should be considered on design stage that all groups are expanded by default. Group names in the Navigation panel should not repeat system groups, for example, "Create", "Reports", "Service", "See Also".

See Also Group

This group is not required. Commands should not be included into the "See also" group for "just in case". The See Also group is designed to provide horizontal links between subsystems. It should include important and useful for a user commands which are not related to this section directly but could be needed in some cases.

Command Order

By default, commands are displayed in alphabetical order. It is recommended to change the order to place frequently used and important commands on top.

Which Commands to Include in the Navigation Panel

The Navigation panel should include items which are necessary in context of the section: commands for switching work places, lists, special data processors. Special data processors are data processors similar to standard data processors, for example, the "Event Log", but not the "Delete marked objects".

It is necessary to place commands for opening the primary data lists. Primary documents/data lists have their own value (Purchase Orders, Expenditure Invoices). Business processes are starting at primary documents. Therefore list forms for primary data should be optimized for corresponding user tasks, for example, for searching or selecting of not processed requests.

It is recommended for documents: o To put journal commands and list commands to the Navigation panel; o To make Go to List commands hidden by default. If the object is logically secondary and dependent on the other object, it could be excluded from the command interface at all (for example, the child information register). If there is the independent information register, and it is important to the user, this register should be placed to the Navigation panel.

Regular reports opening commands should NOT be placed to the Navigation panel. Due to that typical reports should be opened in the separate window with its own interface.

If the report actually is the workplace for performing various functions, a special navigation command for opening this report should be created and placed to the Navigation panel.

Actions Panel (AP)

Actions panel is the place where users could find the most frequently used commands in context of current section. They also are used as a kind of introduction which displays functions of this section. User tasks, such as goods selling, working with the internal documents and so on should drive the design of commands set. Most frequently used and important commands could be chosen and placed to the Actions panel. The purpose of the Actions panel is providing the ability to quickly create new objects, perform typical processing and build most popular reports without switching to other interface in the Navigation panel.

When the Actions Panel is not Required

Frequently used command could not be defined, or there are very few frequently used commands. All frequently used commands are the context-dependent. For example, it is not recommended to place folders creation commands to the Actions panel as almost all of them are context-dependent.

The design recommends performing actions through special forms (workplaces). For example, before creating the Purchase Order one should be able to see the orders structure for entire the company.

Actions Panel Sizes

During the Actions panel commands composition it is necessary to consider the following:

By default, not more than 15 of the medium-length commands could be placed in a visible area of the Actions panel. The medium-size commands are commands with synonym length of 10-25 characters.

Maximum capacity of the Actions panel by height is 30 commands. If there are more commands, the Other Group Commands "Actions" button will appear.

Commands Naming

Standard commands name (Create New Item, Open Report or Data Processor) is generated from the synonym or presentation of the corresponding metadata object. Note that when giving synonyms and presentations to the metadata objects one should make clear their purpose from the commands name, including the group name it belongs to (Create, Report, Service). User commands name should also conform to this recommendation. It is not recommended to use too short (less than 5 characters) and too long (more than 30 characters) command names and synonyms (or presentations) of the metadata objects. It is recommended to start command names, synonyms, and presentations of metadata objects with different words. This will allow various commands to look different in the Actions panel.

See also: Texts

Command Groups in the Actions Panel

In case where Actions panel command could not be assigned to any of standard groups ("Create", "Reports", "Service"), it is possible to create custom groups. It is recommended to minimize number of custom groups.

Tooltips in the Actions Panel

Tooltips and help for commands in the Actions panel are not required but recommended.

See also: Texts

Report Commands

If there are only few reports, the commands for opening them should be placed to the Actions panel. With this, the overall filling of the Actions panel should be kept in mind to avoid making it bulky. If there are lots of reports, or user need a special interface for working with the reports, a special workplace should be developed for that. That workplace could contain, for example:

o o o

List of reports with options Predefined settings Preview

It is recommended to place the workplace opening command:

To the Navigation panel if the workplace should be opened in the main window; To the "Service" group of the Actions panel if the workplace should be opened in a separate window.

Desktop
A desktop is the careful users personal assistant. Each a work day starts with interaction with it. The desktop should guide the user by answering to users questions like following:

What should I do today? Whats happened new? What should I pay an attention for? What is the state of the data important for me?

What Should be Placed on the Desktop

When defining the composition of roles available on the desktop, the configuration roles set should be considered. One or more of the desktop forms could correspond to each role. As, in general, users belong to different roles, the desktop will consist of a combination of these roles forms. It is important to consider the following questions when designing the desktop:

The Desktop is the first thing visible to the application user, therefore it should be designed very carefully. It is allowed to turn off the AutoFill check box for the desktops command bar and its manual filling. Desktop forms should be considered as the micro-desktops. On the one side, it should not be overloaded, but on the other side it should provide the user with wide features. For example, the task list could support drag-and-drop technology, so to create new task for a colleague the user could drag the Order document to the tasks list.

Desktop content will be generated automatically in accordance with the user roles. Usually, one user has several roles. For example, the sales manager performs sales, tracks his own time, executes internal orders and instructions, performs the market analysis, searches for new opportunities.

What Should be Considered During Development

Desktop is a mandatory section that could not be disabled. Desktop forms should be designed for significantly smaller size than regular forms. It is not recommended to place the lists with horizontal scroll bars on desktop forms. It is not recommended to use the All Actions menu for desktop forms. Do not place help commands to desktop forms if it is possible. It is recommended to place a minimal command set to desktop forms command bars. It is not recommended to place the Find and the Cancel Search commands at the lists command bars. Desktop forms should be created in addition to the default set, making them invisible by default to allow users to configure the desktop in accordance with its own needs. It is recommended to place the Refresh command in command bars of dynamic lists. The desktop forms composition should be designed in a way to have 3 to 6 forms appearing on the users desktop, depending on users roles. Otherwise, the desktop will look like an empty or an overloaded. Lists on the desktop by default should make visible at least 3.5 rows of data.

Desktop Navigation Panels

It is not recommended to make the desktop navigation panel with the small number of links (for example, less than 3) since it will looks empty but will occupy the space at the left side.

Desktop Actions Panel

Actions panel should be placed on the desktop only in the case if it is possible to define frequently used non-context dependent commands: o Commands which would be used frequently; o Commands which do not require switching to the other section. With this, it should be avoided to the Actions panel becoming confusing due to the diversity of commands from different sections.

Workplace
Workplace is a form, designed for performance of one specific business operation or a group of linked business operations. Consequently, the workplace should conform two basic requirements:

Provide the required set of the commands (new data creation, analysis of changed data, and other context-dependent actions); Provide user with the up-to-date information required for the correct and quick performance of business operations.

Other Requirements to the Workplace

Workplace should be an intuitive for the user that knows his job but is not familiar with the application. Workplace should be designed in the way it to be clear which kind of specialist and what tasks to perform it is provided for. A set of tools required for the specialists work should be placed on the workplace. Important information should be highlighted with the color to emphasize the users attention. Verify that the workplace does not look overloaded visually. Workplace should contain a sufficient minimum of the information required to the user to qualitative perform tasks.

Most important information should be located at the top. Tools should be placed in the specific order according to tasks performing order. Optimal tasks performance should be provided: without necessity to switching to the other interfaces. Switching to other workplaces should be provided if necessary. Workplaces names should be given in accordance with the scope of the tasks which are to be solved there. Examples: "Administration", "Payroll", and "Components Registration".

It is not recommended to use the "workplace" in workplace names. It is not recommended to place built-in help on the workplace. Built-in help is a help placed on a form either as detailed comments to fields, or as the separate field containing help for the form.

Where the Command of Switching to the Workplace Should be Located

At the Important group of the Navigation panel, if tasks are frequently used. This command will be displayed bold.

At the See Also block of the Navigation panel if the workplace has a secondary purpose in context of the specific subsystem, and is not frequently used.

Reports
Design

Report will looks well if the user would understand the following parts of its appearance: o To whom it may be useful (the position, the user role); o Which questions may be answered using this report and how could it be done. It is recommended to group the reports associated with one data source (query) to one report with several variants. An example of the data source could be a set of documents and information registers designed for users with the same set of access rights (for example, the Profit and Loss Statement report).

Reports should either not contain the data marked for deletion, or that data should be highlighted in the report (for example, using a foreground or a background color). If the report option is a workplace and is frequently used, this option should be designed as a separate report to facilitate its using. It is recommended for reports in which the data is represented in a form of list, to include a first column with the row number. It is recommended to set the Title in the report properties. Each report should have a recognizable and understandable title. If there are several parts in the report (for example, the bar chart and the list), it is recommended to set a title for each part. Main report title is not necessary in this case. If there are several parts in the report (for example, the bar chart and the list), it is recommended to provide a possibility to turn off these parts in the quick settings. Most frequently used values should be used as the reports defaults. For example, the This Month period for the Profit and Loss report.

Set the sorting method is a way to display most important for the user items on top. Use bold for highlighting the important or summarized information. If it is supposed to print the report, it should be optimized for A4 paper size. Use the conditional appearance of the report and use the uniform colors. For example, a red color could be used to highlight expired tasks.

See also: Recommended colors

Quick and Default Settings

Quick settings should contain frequently used settings. It is not recommended to add too many items to quick settings (not more than 5 items). If settings are not frequently used, it is recommended to set regular editing mode. Try to avoid setting the name which could be unclear or ambiguous. For example, it is recommended to replace the "Date of Payment (< or =)" with the "Pay not Later Than".

Report Names

Purpose of the report should be clear from its synonym. It is not allowed to use the "Main" name for the report variants, since it would not be clear to the newbie. It is recommended to use descriptive names, for example, a Profit and Loss Statement report will have following variants: By Partner, By Responsible, By Reason.

Try to avoid a "report" word in the synonym.

See also: Texts

Designing List Forms

Columns set and order should be defined basing on the logical meaning and importance. Select and group columns in several rows to avoid the horizontal scroll bar appearing. Note that the multi-level lists are harder to understand.

Set fixed column width where it is possible. For example, the "Number" and the "Amount" fields in the document lists.

It is allowed to add columns to dynamic lists tables and making them invisible by default during the design to allow users to configure lists according to their own needs. This rule is not applicable for tabular sections. It is recommended to make the column an active if it will probably be used for a searching. For example, for table with items list it would be a "Item".

It is not recommended to use the row selection mode Single.

If there is only One Column in the List

It is not recommended to use a header for the table. If there is no header, the empty list will look like a multi-line entry field. It should be noted not to confuse a user. It is not recommended to apply horizontal borders or interlacing rows highlighting.

Sizes

Lists height by default could be chosen using the typical lines number. The practical experience should be used for that. It is not necessary to make the same lists height, for example, in the various documents. They should be recognizable, but it is not required to exactly match the geometry. Row height in the managed list with standard font is 19 pt. If it is required to know the column width with known number of characters, use the following formula: Column width = Number of characters /1,25

Minimal column sizes for the tables of the managed form

Column Bank Bank account BIC Currency Year Number of characters (with spaces) 20 20 9 3 4 Width 16 16 7 3 4

Date (with time) Contract ZIP-code Individual TIN Corporate TIN IFTS code Comment Contractor TRR Month Nomenclature Number CCD number PSRN ARCPS Description Organization Responsible Division

19 24 6 12 10 4 20 20 9 8 20 11 30 13 11 20 20 15 20

13 19 5 10 8 4 16 16 7 7 16 9 23 10 9 16 16 12 16

Quick Filters in Lists How to Use

If the list is frequently used and typical search queries are observed. For example, by name, by contractor, for period, and so on.

Data quantity makes it difficult to search for the data visually. Select and search operations are frequently used when working with the list.

Quick Choice Fields Design Recommendations

Input fields and checkboxes are recommended to be placed before the list, to the left or right, according to the design and meaning. It is allowed to place selection to the bottom of list if it is a useful, but is not frequently used. For example, the Show Completed Tasks in the My Tasks list.

Quick choice fields at the top should be located over the lists command bar.

A Clear button should be added for fields with non-mandatory selection, or one Clear button should be provided for clearing of all quick choice fields. If the quick choice field stretches significantly, the fixed sizes could be used if it is possible to set the suitable size.

When to Use Two- and Multi-Level Lists

This allows to see the important data without of scrolling. List has many columns, greater than 10. If the user should frequently uses the horizontal scrollbar for viewing the data. Note that visual searching of the data in multi-level lists is more difficult than that is in single-level lists.

Choosing Row Height

Single, if there are short values in cells and the list looks compactly and not overloaded. Double, if there are long values in the cells and it is important to see entire it.

Command Placement in the All Actions Group

It is recommended to use the platforms default values. It is allowed for some lists to configure the command bar individually. It is recommended to place several (not more than 10) of frequently used commands, while the other commands should be placed to the All Actions group.

Context Menu

It is recommended to use the platforms default values. In special cases, it is allowed to configure the context menu for commands expected by the user. o First actions which are frequently used in the current context. o Second service and miscellaneous actions. Do not overload the context menu: o If there are lots of commands, divide them into groups by 5-9 commands. o Total number of commands and delimiters should fit the screen without of scrolling.

List Titles

If there is one list in the form, it does not require the title. Same rule is applied when there are two lists linked with the common context. For example, contractor groups tree and list of the contractors in the group. The purpose of those lists is the intuitively clear and, as a general rule do not require the additional explanations. If there are several lists on the form, their purpose should be clear from the form context, column names and the form title. If the above is impossible, these lists should be provided with titles o If the list has a command bar, then the title should be implemented as a group with standard border (line) o If the list has no command bar, then the standard heading should be used and placed in top position.

Columns with Checkboxes

Try to avoid long headers, since the column is looking ugly and takes a lot of space: checkbox will be aligned to the left side and column will appear empty. Try to replace these column names with understandable pictures as good hints or use abbreviations when it is possible. Note that large number of pictures slows down the form loading.

When Grouping in Lists Should be Used

There is an assurance in that the grouping would facilitate the visual search of the required data. If there are several groupings are provided, it could be carried out using the quick selection fields. Note that groupings could make the work significantly slower.

See also: Quick Choice in Lists

Messages to User

Abbreviations are not allowed in messages texts. If text consists of several lines, it is recommended to split it to separate lines finishing with the logical pause or punctuation marks.

Correct:

It is not recommended to change the tax rate value, if it is used in catalogs or documents.

Incorrect:

It is not recommended to change the tax rate value, if it is used in catalogs or documents.

The following principle should be used: there should not be any interactions with the user (like as warnings, requests etc.) in procedures and functions running inside the transaction.

Error messages in a form

Error message window should automatically align the text and wrap words (without hyphenation) with maintaining of its proportions. User should understand the following information from the message text: o What is happened? o What is the reason of error? o What should he (or she) do to continue? Message should be clear and to the point, as much as it is possible. "The Description field is empty" - it should be enough to tell the user that it is necessary to fill this field. If the field is filled, but it is filled incorrectly, the message should be more detailed. For example, "Not enough <some> goods in the warehouse", "Selling with the wholesale prices is disabled for <some> contractor".

The error message should be linked to the field which caused an error or allows to fix it, if it is possible. If the error message could not be linked to a specific field, the message text should contain the information on actions required to resolve the problem. The message text should be polite and not contain accusations or being of exhortative nature.

Notification

Notifications are used when the data object is a source of notification. If the notification source is not a data object, but for example, is a processing form, the link processing to the user's history should be ensured Notifications should be used to inform the user about events happened without of interrupting the main work process, i.e. it is not necessary for a user to respond to the notification, it is displayed for information purpose only. Notification informs on completion of the requested operation (writing of the catalog list item or document posting).

Notifications should contain hyperlinks to the corresponding objects. Note that notifications are displayed in the information panel, so it should not be used for the logging of long operations. Text and description of the notification should be designed is the way to fit the notification window of default size: o Text 46 characters; o Description about 120 characters (with the breaking onto three lines).

Status

Status should be used to inform about the progress of long operations (longer than 10 seconds) to avoid the user's feeling that an application hangs up. One notification should be displayed before the execution ("Calculating. Please wait"), within the process of the execution (whenever it is possible), and on the completion ("Calculation completed"). Status should be used for long operations consisted of several smaller operations. So, when transferring files from the hard disk to the information base, the status could be displayed for every transferred file. For example: Status("Copying of files...", Percent, "Processing file " + FileName, PictureInfo).

Warning

It is recommended to use warnings only in cases when the user works should be interrupted to provide the user with some information. Information on the performance of the long operation should be displayed in the processing form directly, not as the separate warning.

It is recommended to display warnings before execution of following operations: o Actions which results could not be undone; o Actions which are potentially dangerous for the user's data; o Massive processing in the informational base; o Long operations. Logically completed explanations on the follow-up activities and it consequences should be included to the warning text.

Question

It is recommended to use questions only when it is needed to wait the user to make decision, for example, if to continue of the started operation. Default answer to the question should be most safe answer for the user data. Question should be composed in the way to avoid "Yes" to be the default answer in critical situations.

Other Messages

It is not recommended to use messages, notifications or status to display a information upon completion of some operation. A special form should be provided for this purpose, this form with the report or log of work performed, either during the execution of the operation, or after its completion.

Start-Up Windows

If the start-up window content is not required for user to read, the "Show at program start" checkbox should be provided, being checked by default. It is recommended to place the checkbox under the window content.

Forms

A possibility to effective work without the mouse should be provided by design.

Command Bar

The most left button in the command bar should be selected by default.

Sizes

It is recommended to set a size of the form and/or its elements in special cases only, for example, for decorations. Otherwise, the platform default values are recommended. For tabbed forms it is recommended to set the width in the way to make the all tabs visible at a time. It is recommended to change the form columns width only when columns contain a simple set of well-scaled fields and groups, for example, two list fields in the left and right columns. It is recommended to use the auto width of the columns for the form's objects (set by default).

Fields Order

It is recommended to assign the SkipOnInput property for buttons. It is recommended to assign the DefaultItem property to the field which is generally used to start the data input.

Field Groups in Forms When it Should be Used

To group the logically linked data. For facilitation of the form appearance by the way of data blocks highlighting.

Number of Items in Group

It is not recommended to create groups containing one item only. It is recommended to place 5-9 elements per group.

Designing Group Headers

The title could be used for an explanation or clarification, if the item's names do not clearly show its purpose. It is not recommended to use titles if there is one group only and it is located on the panel's page. Title of the page will be a title of the group in this case.

Checkboxes

Text should be placed to the right from checkboxes if it is possible. First letter of the checkbox label and option button should be capitalized. Checkbox labels and option buttons should be made as a positive (without negations). Text of the label should be clear and short. Text of the checkbox is defining only one (checked) option, the second option remains not evident and not formulated therefore, the text of the checkbox should be set in the way to make user clearly understanding the second option.

Navigation Panel of the Miscellaneous Window

If some additional information, which is not stored in the object: linked lists, reports and so on shall be displayed in the object's form (document, catalog list), this information should be displayed using commands placed to the navigation panel of the Miscellaneous window instead of placing this information to the form itself (even to separate tabs). It is recommended to provide users with uniform solution, otherwise, part of the information will be received from the navigation panel, while other part will be received from tabs. Additional navigation items slow down the form opening.

For frequently used and important forms, it is recommended to set the command visibility in the Navigation panel manually, selecting commands for navigation to the important data only. It is recommended to place not more than 10 commands in the Navigation panel. It is not recommended to place in the panel commands for moving to other forms for editing object properties. It is not allowed to open item's form from the Navigation panel of the other item's form.

Modal or Independent Form? Modal Form

Form is processed inside itself, without of requirement to switch to other forms. There are few items on the form, lets say, less than 5.

Independent Form

If other forms opening could be required when working with this form. If it could be required for the user to compare two or more objects. There are more than 9 items on the form.

Choice Forms

It is recommended not to create choice forms but to use the platform generated by default. If it is required in accordance with application logic to provide specific set of commands or columns it the choice form, following recommendations should be observed: o It is recommended to place a minimal necessary command set for choosing, adding of the new item, and the searching/filtering data on the form's command bar. o At the frequently used choice forms with large data sets it is recommended to place the quick selection/search fields. o Columns composition should be optimized for quick visual search

See also: Quick Choice Forms in Lists

Items Design

Same items of various forms must have the uniform design, same labels and position on the form and in groups.

Button or Hyperlink? Button

o o o o
Is suitable for single stand-alone command (processing, calculation). Generally is used to launch some process and perform actions on modifications in the information base. Changes that could not be undone (for example, tables clearing) should always be designed as the buttons. Button name should contain a verb answering to the "What to do?" question, for example, "Search", "Calculate", "Write", "Fill", "Select". Verbal nouns could be used instead of verbs. Buttons should be located near objects which they influence on.

Hyperlink
o o
Is used for switching to other forms which display linked data (other objects); Hyperlink name should clearly explain the information that will be opened in a new window, for example, the "Item Prices", or the "Passport Details".

Command representation as a Picture or Picture and Text

If there is only one command in the command bar, it must have a picture. It is recommended to assign pictures to frequently used commands.

Picture

If the command is frequently used (edit, delete, copy, print) and picture is explicit, as well as command purpose is clear.

Picture and Text

If these are non-typical or special commands. If not sure that the command picture is explicit.

Design of Frequently Used Buttons

It is recommended to use Picture and Text representation for buttons with frequently used actions. Picture which is used for the button also could be used in the row of tabular section for additional identification of the data type, which the given command is applicable to.

Placing Buttons not Oriented to Perform of Main Tasks

Menu items which are oriented to perform special-purpose commands or for special user groups should be placed in submenus.

Designing Document Totals

Totals could be placed in the footer of list columns. If there are lots of columns and the column with total is hard to be found, it would be better to design totals as separate fields of Label type. If there are several totals, it would be better to place them one over another to show the difference in values.

Pick Up Command

It is recommended to use the command in a form of an infinitive Pick Up. If there is an assurance that a user will effectively work with the Pick Up command instead of using the Add command, Pick Up command should be located at the first place. Otherwise on the second or any other place. An F8 accelerator should be used for the Pick Up command.

Cancel Command

The Cancel command should cancel of changes made in the form and close it. The Cancel button should not be the default form item. If there are no actions available except of the form closing, Close should be the default button.

Field Labels

It is recommended to show units after fields. Incorrect

Correct

Units of measurement should be placed in the columns titles rather than in every cell. Special cases:

o o

Percent a "%" symbol should be displayed in the every cell, if this is made entire the application (VAT rate, order fulfillment progress and so on) It is recommended not to display a currency: If there is reference in total fields; If the currency is evident from the context.

Attributes

It is recommended to leave on forms standard fields such as Description, Number and Date (for documents and tasks). If there is a Choice Form assumed for the attribute, but there is only one item in the list, this item should be substituted by default. Examples: one VAT rate value (18%), one contract for the contractor, one order.

When creating the form on base of something, all inherited attributes should be filled. Units of measure should be indicated for tables columns and input fields containing numeric data (length, weight, height, velocity, distance, size and so on) o For tables columns at the column heading; o For input fields in the label, from the left side of the field.

Font and Color

It is not recommended to use the absolute fonts and colors values. Corresponding style elements should be created instead.

It is not recommended to use underlining for the form items which are not hyperlinks. It is not recommended to use capital letter in the texts (except of first letter in the sentence and for titles).

Recommended colors

Color of the incorrect value o Web FireBrick Color of the information label o Web SteelBlue It is not recommended to combine green and the red colors of the same saturation on one form.

Requirements for Pictures

Well recognizable images implemented in the uniform style. Adjacent icons should have different contours to increase mnemonics. All used icons should have the same view angles, perspective and lighting. Objects are pictured in modern form (for example, a computer). Icons should differ by contours and primary colors. Situations when icons differ by the color only should be avoided. Format the PNG images with the 8-bit alpha-channel. If it is possible to make this without the loss of the quality, it is recommended to use the image with the 1-bit alpha-channel since this will decrease the size of the application.

It is required to manually review all pictures in the application, both in common pictures, as well as in forms. As for the rest, pictures should conform with the Creating Images for Typical Configurations on the 1C:Enterprise 8.2 Platform Guide

Forms Composition

Order of fields on the form should conform to the business logic. It is recommended to use right-top corner of the form for non-mandatory, insignificant fields and fields filled automatically. If items on the form look chaotic, set the fixed size as far as it possible. Field labels should be placed from the left or from the top of the field.

Texts
Common Requirements

Try to avoid technological terms and abbreviations, use the users language. Keep the uniformity of terms used in the application. Use short sentences, since reading from the screen makes users tired quickly. If the text is large, briefly explain the main idea first, other ideas should be written then with decreasing of their importance order. Split the text into small paragraphs. Check all labels, signatures and messages for the grammar and spelling to be correct. Input field and label must be displayed in one font (face, size, weight), but not with the same color. Only the straight quotes could be used in the interface texts. It is allowed to use the nonstraghit in the help.

Titles and Headings

It is recommended to avoid titles and headings that could be ambiguous for the user.

It is not recommended to use titles and headings with length more than 60 characters. A Parent term should be used to show relations between individuals, but not for the information base objects hierarchy. Following terms could be used instead, for example: o Products Folder o Main Department o Is in Group o Belongs to Category o and so on. If it is assumed in the applicaton to display the items quantity at the pages or groups titles (for example, the "Goods (10)"), this method should be used for all objects of the application.

How to Use Ellipsis

Ellipsis should be used if the command or the hyperlink name presents the action ("Change Form", "Delegate Task" in an infinitive or verbal noun form), and on click it opens the additional form (place) to perform these actions. Ellipsis should be adjoined to the last word without of space, for example "Print" but not "Print ". If the command name describes the process that will be launched, the ellipsis are not required. "Form Changes", "Tasks Distribution" and so on.

Tailing Spaces in Objects Presentations and Managed Form Item Titles

It is not allowed to use tailing spaces (space, unbreakable space, tabulation) in texts of item titles of managed form and in presentations of the application objects (presentation and extended presentation of the object, list, or record). Objects presentations and item titles of managed forms are used for rendering the managed Command Interface, and tailing (as well as leading) space characters could distort the appearance of the form, Actions panel, Navigation panel, or Sections panel.

Limitation on Using Similar Texts for Form Items

It is recommended to avoid using form items with the same text. For example, two "All Actions" submenu, in the tabular section, and in the form itself. This causes confusion in the user work, makes difficult to read and write the help, as well as could lead to problems with explanation by the user of interaction with an application to other users or specialists.

Hot Keys

It is recommended to define hot keys for most frequently used commands. It is recommended to define hot keys for frequently used context independent forms. For example, the Full Text Search form, Daily Timetable Report form.