A standardized graphical user interface for XperienCentral ensures a better user experience because all functionality within the application looks and behaves more or less the same, making it more predictable and therefore more usable.

In This Topic

XperienCentral Users

Designing usable functionality starts with knowing the (future) users of it. Most XperienCentral users are not programming experts. Developers should take this into account when developing new functionality. The typical users of XperienCentral can be divided into six groups: casual users, editors, application managers, administrators, developers and website visitors. Each group performs its own different tasks within the application and outside, using specific skills and knowledge. In the real world these different roles are not so strictly divided; a single person can perform multiple roles simultaneously or tasks can be divided between multiple roles. These six profiles are intended to help developers get a general impression of the different users of the application.

Casual user

Main task: Content entry

Knowledge: Minimal

Skills: Entering content and researching

The most important group of users is the casual users, not only because this group is the largest, but also because entering and editing content is the main task that is performed within XperienCentral. Most functionality within the application focuses on entering or editing content (text, images or any other media), which are the main tasks of the casual user. They are used to browsing the internet gathering information on their subjects.

Editor

Main task: Managing and editing content

Knowledge: Communication, commercial, marketing

Skills: Managing people and information

The editor is the person that manages all content that is entered by casual users and others. He or she decides what is published, when it is published and in what form. The editor is the person with knowledge of the target audience and is responsible for the form and content of the frontend, usually a website. Editors use XperienCentral to manage, edit and publish content which means that they typically use a lot more functionality within XperienCentral than the casual user.

Application Manager

Main task: Setting up and configuring XperienCentral applications

Knowledge: XperienCentral, software (general), technology and engineering

Skills: Technical

The application manager is responsible for setting up and configuring XperienCentral according to the needs and wishes of the client. He or she has a broad knowledge of the XperienCentral framework and application in addition to his or her general knowledge of software technology. The application manager gets clients up and running with their XperienCentral installation. Typically he or she is an employee of or an implementation partner of GX Software.

Administrator

Main task: Maintenance of an XperienCentral application

Knowledge: Software (in general), information technology (in general)

Skills: Technical

The administrator facilitates other users in using the XperienCentral application for performing their specific tasks. Typically the administrator is not concerned with content but instead with the system as a whole and its users. He or she is an expert in computer systems and able to understand the abstract technological structure of XperienCentral.

Developer

Main task: Develop new functionalities for XperienCentral

Knowledge: Software development

Skills: An expert in software engineering and web development

The developer is primarily a user of the XperienCentral framework instead of the application. His or her task is to add new functionality to the application, where needed,within the existing framework. A developer has advanced knowledge about web technologies and software engineering.

Website Visitor

Main task: unknown

Knowledge: unknown

Skills: unknown

The most basic end user of XperienCentral is the visitor to the website that is managed by the application. This may seem like an unimportant user because he or she will not use or see anything of the XperienCentral application, however the visitor has some of the most important demands of all users such as feature richness, speed and reliability of the system.

Back to top

Background of the XperienCentral GUI

An important concept of the XperienCentral graphical user interface is the separation of content and design. Editors, who are primarily focused on managing content should not be concerned about the design and layout of the web page where the content will be published. The GUI of the Editor in the Workspace focuses on content; just as in Microsoft Word, text is the most important content type and can be embellished by all kinds of elements (images, tables, lists, polls, etc.). In the Editor, all content presented to the user is optimized for editing,

The GUI of the Workspace contains a formatting toolbar when a content item is being edited, two sidebars that can be customized by adding available widgets, and drop-down menus. Using the Site Structure widget, a user can navigate through the entire page structure of the website and using Search and/or Advanced Search, they can find and navigate to articles, images, downloads, and the rest of the content types.

A large part of the XperienCentral GUI is not directly visible but accessible via the Configuration menu which gives users access to all the available functionality, arranged according to category (Application Tools, User Interaction, and so forth). Panels offer access to all the functionality and could be regarded as applications inside the XperienCentral application. All user all panels should look like they are an integral part of the application.

Adding new functionality to XperienCentral using plugins doesn’t mean that a developer has to re-invent the graphical user interface every time a panel or content element is added to the application. A set of standard GUI elements is already available for the developer to use for new functional GUIs. This makes the development of new functionality easier and it also ensures a consistent look and feel within XperienCentral, which is important for the users of the application.

Back to top

GUI Elements

All standard GUI elements are centrally styled using CSS which means that developers don’t have to add CSS classes themselves as long as they use the standard GUI elements and (in some cases) apply the right CSS classes to them or their containing HTML element. The following overview lists the standard GUI elements along with a short description of the element. The numbers map to the previous two images, which show examples of the standard GUI elements. Some of the GUI elements are to be used in panels only - this is indicated in the list by an asterisk.

It is possible that a new plugin functionality requires a GUI element that is not in the list below. In that case, the GUI element should be designed to fit in this range.

GUI Element	Description
1 - Title*	Describes the function of the panel.
2 - Horizontal tabs (first level)*	Default first level navigation. Tabs are ordered logically from left to right, e.g. a sequence of steps in a workflow.
3 - Vertical tabs	Indicates whether this permission category appears in the channel configuration panel of the Workspace. If it is visible, the plugin as a whole can be enabled/disabled per channel.
4 - Horizontal tabs (second level)*	Second level navigation.
5 - Field sets*	Used for grouping input elements. Field sets preferably use a title (legend) to label their content.
6 - Label	Descriptive label for input elements.
7 - Text field	Used for user input of short string values.
8 - Date field	User input for dates. Consists of a text field with a button that invokes a date picker.
9 - File field	User input for files. Displays a text field with a button that invokes the systems file dialog.
10 - Text area	Used for user input of long string values.
11 - Drop-down list	Used for user input of a single selection from a list of options, for example the position of an item in a list.
12 - Checkbox	Used for user input of a boolean value.
13 - Radio buttons	Used for user input of a single selection from a small number of options.
14 - Regular buttons	Used for miscellaneous actions, for example creating a new instance of an object.
15 - Data grid	Used for listing multiple instances, possibly multi-column and sortable.
16 - Bottom bar buttons	Used for the main controls of the panel, for example [OK], [Close], and so forth. These buttons always appear in the bottom right-hand portion of the panel and are larger than the regular buttons.

* The GUI element should not be used in a content element

Back to top

Layout

The CSS will ensure the proper layout of the input elements within forms or grids, like the contents of a tab pane or the input elements within a custom content element. A grid based layout helps the user to ‘read’ the GUI. If all input elements were just randomly scattered across the panel or content element the focus of the user would just bounce from element to element trying to find some logical structure or hierarchy.

Layout of the input elements is done in HTML by the use of tables. By assigning the ‘widgetgrid’ class to the table the input elements are in, specifying column widths and giving all table cells the proper classes (according to their content) will ensure a proper layout. The class needs to be assigned to the TD element containing the GUI element, not to the input element itself. This is because the input elements inside a TD element with a class are horizontally scaled to fit their container. That means that the input elements automatically resize to the width of their parent TD. This can lead to unexpected and undesirable results when the width of the TD (or the width of the whole column or table) is not specified.

<table class="widgetgrid" width="100%">
   <col width="20%" />
   <col width="40%" />
   <col width="40%" />
   <tr>
      <td class="label">Label 1:</td>
      <td class="textfield"><input type="text" name="texfield01" /></td>
      <td class="text">(Some help text)</td>
   </tr>
   <tr>
      <td class="label">Label 2:</td>
      <td class="textfield"><input type="text" name="texfield02" /></td>
      <td /> 
   </tr>
</table>

An exception to this automatic scaling is the file input field in Mozilla browsers. To horizontally scale this input element in Firefox, the parameter size should be added, for example size="40".

Back to top

CSS Classes

There are several CSS classes a developer can use to define the layout of input elements. Applying the wrong class to a certain input element (or its container), or omitting the use of classes can lead to unexpected results. For a consistent look and feel throughout the application, it is recommended that you do not use inline layout tags, like <b>, <i> or <font>. Using inline CSS markup is also discouraged.

TD Class Name	Description
`class="label"`	Labels of input fields (align right, default)
`class="label_left"`	Labels of input fields (align left)
`class="heading"`	Headings (align left)
`class="text"`	Plain texts
`class="textfield"`	Text type INPUT elements
`class="datefield"`	Date type INPUT elements (contents do not scale to fit)
`class="textarea"`	TEXTAREA elements (contents scale vertically as well as horizontally, so a height should be set on a <TD> element)
`class="pulldown"`	SELECT elements
`class="listbox"`	SELECT elements with size > 1
`class="checkbox"`	Checkbox type INPUT elements
`class="radio"`	Radio type INPUT elements
`class="button"`	Button type INPUT elements
`class="file"`	File type INPUT elements (Mozilla browsers need a "size" parameter to control the width of this INPUT element)
`class="layout"`	Nested table element for cell-specific layout
`class="presentation"`	For presentation of data (creates a boxed area)
`class="hr"`	Horizontal rules
`class="splitterrow"`	Empty cell used for creating space between two separate rows

Back to top

Layout Examples

In this part a few basic examples of different layouts will be outlined and explained. These examples can be used for developing new plugin panels or content elements. They are meant to describe the layout of input elements by tables. The table grids are merely a schematic representation of the actual grid design. Text labels are used in the grids to hint the contents of table cells. When no text label is present the cell should be considered empty. In the code example the HTML markup for the input elements themselves is omitted because the focus is on grid layout, not on content.

Basic Layout

The following basic layout:

Label 1	Text field 1
Label 2	Checkbox 1
	Checkbox 2
Label 3	Drop-down list 1
Label 4	Radio button 1	Radio button 2

Is rendered using the following HTML markup:

<table class="widgetgrid" width="100%">
    <col width="20%" />
    <col width="40%" />
    <col width="40%" />
    <tr>
        <td class="label">Label 1</td>
        <td class="textfield">Textfield 1</td>
        <td />
    </tr>
    <tr>
        <td class="label">Label 2</td>
        <td class="checkbox">Checkbox 1</td>
        <td /> 
    </tr>
    <tr>
        <td />
        <td class="checkbox">Checkbox 2</td>
        <td /> 
    </tr>
    <tr>
        <td class="label">Label 3</td>
        <td class="checkbox">Drop-down list 1</td>
        <td /> 
    </tr>
    <tr>
        <td class="label">Label 4</td>
        <td class="radio">Radiobutton 1</td>
        <td class="radio">Radiobutton 2</td>
    </tr>
</table>

The example above is a very basic table layout without any spanning or nesting. The first column contains all the labels for the input elements, the second column contains the input elements themselves and the third column is empty for all but the last row. In this case, the empty cells in the third column prevent the text field and the drop-down list from displaying too large. The width and height of these input elements are determined by their container, that is, the table cell. Notice how the <COL> tags determine the width of the columns. Using these <col> tags is a lot easier than adding a width parameter to every single cell.

Layout Using Column Spanning

The following basic layout:

Label 1	Text field 1
Label 2	Text area 1



Label 3	Radio button 1	Radio button 2

Is rendered using the following HTML markup:

<table class="widgetgrid" width="100%">
    <col width="20%" />
    <col width="40%" />
    <col width="40%" />
    <tr>
        <td class="label">Label 1</td>
        <td class="textfield">Textfield 1</td>
        <td />
    </tr>
    <tr>
        <td class="label">Label 2</td>
        <td class="textarea" colspan="2" height="80">Textarea 1</td>
    </tr>
    <tr>
        <td class="label">Label 3</td>
        <td class="radio">Radiobutton 1</td>
        <td class="radio">Radiobutton 2</td>
    </tr>
</table>

In this example column spanning is used to make a text area step out of the regular grid layout and span across two columns by adding the colspan property to the containing <td> tag. Notice that as a result in the row with the colspan there are only two <td> elements instead of three. Also notice the height parameter of the <td> element containing the text area - this is because the text area needs to be higher than a regular row and vertically scales to 100% of its container.

Layout Using Row Spanning

Label 1	Text field 1
Label 2	Text area 1	Checkbox 1
		Checkbox 2
		Checkbox 3
Label 3	Radio button 1	Radio button 2

Is rendered using the following HTML markup:

<table class="widgetgrid" width="100%">
    <col width="20%" />
    <col width="60%" />
    <col width="20%" />
    <tr>
        <td class="label">Label 1</td>
        <td class="textfield">Textfield 1</td>
        <td />
    </tr>
    <tr>
        <td class="label">Label 2</td>
        <td class="textarea" rowspan="3">Textarea 1</td>
        <td class="checkbox">Checkbox 1</td>
    </tr>
    <tr>
        <td /> 
        <td class="checkbox">Checkbox 2</td>
    </tr>
    <tr>
        <td /> 
        <td class="checkbox">Checkbox 3</td>
    </tr>
    <tr>
        <td class="label">Label 3</td>
        <td class="radio">Radiobutton 1</td>
        <td class="radio">Radiobutton 2</td>
    </tr>
</table>

Row spanning is less common than column spanning because in most cases it’s possible to achieve the layout within one ordinary row. In cases like the one in this example, row spanning is needed because the row separation is still needed in another column. Notice that after the rowspan property in the successive rows the spanned <td> element is omitted, resulting in <tr> elements with only two <td> elements in them (representing first and third column).

Layout Using Table Nesting

Label 1

Text field 1

Label 2

Header 1	Header 2	Header 3
Value 1a	Value 2a	Value 3a
Value 1b	Value 2b	Value 3b

Label 3

Drop-down list 1

Is rendered using the following HTML markup:

<table class="widgetgrid" width="100%">
    <col width="20%" />
    <col width="60%" />
    <col width="20%" />
    <tr>
        <td class="label">Label 1</td>
        <td class="textfield">Textfield 1</td>
        <td />
    </tr>
    <tr>
        <td class="label">Label 2</td>
        <td class="presentation" colspan="2">
<table class="widgetgrid" width="100%">
    <col width="40%" />
    <col width="30%" />
    <col width="30%" />
    <tr>
        <td class="heading">Header 1</td>
        <td class="heading">Header 2</td>
        <td class="heading">Header 3</td>
    </tr>
    <tr>
        <td class="text">Value 1a</td>
        <td class="text">Value 2a</td>
        <td class="text">Value 3a</td>
    </tr>
    <tr>
        <td class="text">Value 1b</td>
        <td class="text">Value 2b</td>
        <td class="text">Value 3b</td>
    </tr>
</table>
        </td>
    </tr>
    <tr>
        <td /> 
        <td class="checkbox">Checkbox 2</td>
    </tr>
    <tr>
        <td /> 
        <td class="checkbox">Checkbox 3</td>
    </tr>
    <tr>
        <td class="label">Label 3</td>
        <td class="radio">Radiobutton 1</td>
        <td class="radio">Radiobutton 2</td>
    </tr>
</table>

Table nesting allows complicated and dynamic layouts, but it also makes the HTML structure more complicated. If possible, table nesting should be avoided and column or row spanning should be used instead. For various reasons, that will sometimes not be possible. A typical example of the use of nested tables is when the result of some query with an unknown number of results is shown in a tabular layout inside the main grid layout.

Back to top

GUI Guidelines

To ensure a good user experience within the application, XperienCentral developers should design the graphical user interface of new functionality according to the guidelines outlined in this part. Note that they are referred to a guidelines as opposed to rules. This is because it simply isn’t possible to create a set of rules that, when strictly followed, will guarantee a good user experience in every situation.

Basic Guidelines

Decisions concerning the GUI should always be made with the end user in mind. The following are guidelines you should consider when creating new GUIs within XperienCentral. After a few basic guidelines, the use of the most important GUI elements is described in more detail.

Less is More

The focus of the GUI should be kept clear by avoiding the use of unnecessary elements like lines, text or headings. The user shouldn’t be confronted with too much visual information at the same time. It’s better to split up the information (or action) into multiple smaller chunks (or steps), for instance by using tabs or a wizard flow. Text (labels, descriptions, etc.) should be kept brief because the user is not likely to take the time to read vast amounts of text. Another reason for limiting the amount of data and controls shown in a content element is space usage. When content elements become too large in size, the user loses the overview of the page as a whole while editing.

Consistency

Developers should be consistent in choices concerning both data presentation and interaction. There shouldn’t be different ways to present the same type of information and the user shouldn’t be offered different controls or procedures for entering the same type of data. Unless there’s a really good reason to do so, deviation from the standard should be avoided. Interaction patterns in XperienCentral should be identified and reused. A strict layout will help the user know what to do and how to do it, in other words, the user interface should be predictable. For example, if the GUI makes it possible for the user to add a new product in a web shop using an [Add product] button, the same kind of button should be used to let the user add other items.

Hide the Backend

The user usually doesn’t know, and in most cases doesn’t want to know, about the technical implications that his actions will have in the backend of the application. To the regular user, it is irrelevant how the application accomplishes its tasks. Their only concern is that it will do what needs to be done, preferably without too much hassle, therefore the backend should be hidden as much as possible from the user without taking control out of their hands. This also means avoiding technical terminology in the GUI, for example, labels like "Create new instance" for adding a new product to the products database even though this is technically what is being done. Be straightforward and succinct.

Back to top

Tabs and Wizards: Splitting up Tasks

Tabs are typically used in panels that contain a lot of information and/or controls. Tabs are not commonly used in content elements. By splitting things up into logical parts and assigning these to the different tabs, the user will be able to find the information or controls he needs more easily. It is important that this division creates a structure that the user can understand and that it is logical and practical for him or her to be able to performing tasks. Vertical tabs are typically used when the first level tabs represent different objects instead of different aspects of the same object. Choosing the right text labels (and icons, in the case of vertical tabs) for the tabs is obviously crucial. The left-right or top-down order of the tabs can also help the user in understanding the logic of the functionality. For instance, the tabs can be ordered as successive steps in a certain workflow or as drill-down levels with an increasing level of detail. Multiple levels of tabs are sometimes helpful, but it could also make the structure of information and controls complicated and or convoluted and therefore more difficult to use. Try to limit the number of tabs to a reasonable amount. A general rule of thumb is to limit the number of tabs to a maximum of 7 (per level). The following is an example of a panel containing a logical tab structure:

Another way of splitting information input into logical steps is by using a wizard flow. In a wizard, the user is confronted with only one or a few input elements at a time, which makes it easier to use. There are no tabs and preferably no other kind of grouping of input elements within the steps, because each step handles only one setting or choice. This choice could be presented using any input element or group of input elements available. It’s possible to use various alternate paths in a wizard, for example, "When user selects option X, go to step 2 - when user selects option Y, go to step 5").

A wizard panel typically has 3 main buttons (from left to right):

Back - navigates to the previous panel (disabled in the first step).
Next - navigates to the following step (changes to Finish in the last step).
Cancel - closes the panel without saving.

A wizard is great for complicated settings or configurations that the user doesn’t encounter very often or upon initial setup. It’s less suitable for functionality the user often needs because it slows the advanced user down - tabs are more suitable in such circumstances.

Back to top

Field Sets, Horizontal Rules and Whitespace

While tabs and wizards are used to split information into manageable chunks, field sets group separate elements, like labels and controls in order to render the functional structure of a GUI. Field sets typically have a title (called "legend") that summarizes the functional role of the elements or the action to be performed in that group. As with tabs, try to limit the number of field sets per panel or content element to a reasonable amount. Using too many field sets has the same result as using no field sets at all. The same goes for the nesting of field sets which should be avoided. Field sets are not commonly used in content elements because the space in a content element is limited and the extra lines of the field set create more visual noise. The following is an example of a fieldset in a panel:

<fieldset>
    <legend>fieldset 1</legend>
    <table class="widgetgrid" width="100%">
        <col width="20%" />
    <col width="20%" />
        <col width="20%" />
        <col width="40%" />
        <tr>
            <td class="label">Label 1:</td>
            <td class="textfield" colspan="2">
                <input type="text" name="textfield01" /></td>
            <td />
        </tr>
    <tr>
            <td class="label">Label 2:</td>
            <td class="radio">
                <input type="radio" name="radiogroup1" id="option1" />
                <label for="option1">Option 1</label>
            </td>
            <td class="radio">
                <input type="radio" name="radiogroup1" id="option2" />
                <label for="option2">Option 2</label>
            </td>
            <td class="radio">
                <input type="radio" name="radiogroup1" id="option3" />
                <label for="option3">Option 3</label>
            </td>
        </tr>
    </table>
</fieldset>

Horizontal Rules

Horizontal rules (an <hr> element inside a <td> with class="hr") and whitespaces (an empty <td> element with class="splitterrow") can also be used to divide information into logical parts:

<table class="widgetgrid" width="100%">
    <col width="20%" />
<col width="40%" />
    <col width="40%" />
    <tr>
        <td class="label">Title:</td>
        <td class="textfield"><input type="text" name="textfield01" /></td>
        <td />
    </tr>
<tr>
        <td class="label">Subtitle:</td>
        <td class="textfield"><input type="text" name="textfield02" /></td>
        <td />
    </tr>
    <tr>
        <td class="splitterrow" colspan="3" />
    </tr>
    <tr>
        <td class="label">Description:</td>
        <td class="textfield" colspan="2"><input type="text" name="textfield03" /></td>
    </tr>
</table>

Back to top

Tagging Elements: Labels and Headings

Labels describe the kind of value an input element expects. By default an input element label (a text field, drop-down list, text area, etc.) is displayed left of the field with a right alignment. In some cases it is better to use another type of label, for example a left aligned top label if a text area is used that needs 100% of the horizontal space. A label is always followed by a colon those for checkboxes and radio buttons. Keep labels as short as possible and always clear.

The following is an example of a default label:

<table class="widgetgrid" width="100%">
    <col width="20%" />
<col width="80%" />
    <tr>
        <td class="label">Title:</td>
        <td class="textfield"><input type="text" name="textfield01" /></td>
    </tr>
</table>

The following is an example of a non-default label:

<table class="widgetgrid" width="100%">
    <col width="20%" />
<col width="80%" />
    <tr>
        <td class="label_left" colspan="2">Title:</td>
    </tr>
    <tr>
        <td class="textarea" colspan="2" height="80">
            <textarea name="textfield01">Lorum ipsum</textarea>
        </td>
    </tr>
</table>

Headings are less often used in both panels as content elements because labeling a group of input elements is most likely done by the legend of the field set the input elements are in. Headings should only be used if it is really necessary to explicitly label a group of input elements and only if the use of a fieldset is impossible.

The following is an HTML example of a heading:

<table class="widgetgrid" width="100%">
    <col width="50%" />
<col width="50%" />
    <tr>
        <td class="heading" colspan="2">Group 1</td>
    </tr>
    <tr>
        <td class="presentation">
<table class="widgetgrid" width="100%">
    <col width="20%" />
<col width="80%" />
    <tr>
        <td class="label">Title:</td>
        <td class="textfield"><input type="text" name="textfield01" /></td>
    </tr>
<tr>
        <td class="label">Subtitle:</td>
        <td class="textfield"><input type="text" name="textfield02" /></td>
    </tr>
</table>
        </td>
        <td />
    </tr>
    <tr>
        <td class="heading" colspan="2">Group 2</td>
    </tr>
    <tr>
        <td class="presentation">
<table class="widgetgrid" width="100%">
    <col width="20%" />
<col width="80%" />
    <tr>
        <td class="label">Title:</td>
        <td class="textfield"><input type="text" name="textfield03" /></td>
    </tr>
<tr>
        <td class="label">Subtitle:</td>
        <td class="textfield"><input type="text" name="textfield04" /></td>
    </tr>
</table>
        </td>
        <td />
    </tr>
</table>

Back to top

Choices: Checkboxes, Radio Buttons and Drop-down Lists

Checkboxes and radio buttons are used in cases where the user has to choose from a small set of options. If the options the user has to choose from exceed 7, consider using a drop-down list instead.The big advantage of checkboxes and radio buttons over drop-down lists is that all options are always visible for the user. A disadvantage is that they typically need a lot more space than a drop-down list.

Checkboxes are used for setting boolean values (true/false), for example. on/off. Radio buttons do the same, but in a set of radio buttons only one can be true at the same time, for example. coffee/tea. The use of two radio buttons for true boolean values, like on/of or yes/no should be avoided because the same can be accomplished by using only one checkbox.

The following HTML creates a group of checkboxes:

<table class="widgetgrid" width="100%">
    <col width="20%" />
    <col width="40%" />
    <col width="40%" />
    <tr>
        <td class="label">Title:</td>
        <td class="checkbox">
            <input type="checkbox" name="checkbox01" id="checkbox01" />
            <label for="checkbox01">Option 1</label>
        </td>
        <td />
    </tr>
    <tr>
        <td />
        <td class="checkbox">
            <input type="checkbox" name="checkbox02" id="checkbox02" />
        <label for="checkbox02">Option 2</label>
        </td>
        <td />
    </tr>
    <tr>
        <td />
        <td class="checkbox">
            <input type="checkbox" name="checkbox03" id="checkbox03" />
        <label for="checkbox03">Option 3</label>
        </td>
        <td />
    </tr>
</table>

Checkboxes and Radio Buttons

Both checkboxes and radio buttons have a descriptive label. This label is placed at the right of the input element. In HTML, both the input element and its label are placed within the same <td> element. When checkboxes in a column all have the same label, the label can also be shown once as a header above the checkboxes. In the layout of sets of checkboxes or radio buttons, the input elements, together with their labels, are usually placed in a (vertically oriented) list. If there are only 2 to 3 options and not a lot of vertical space available, you can also place them next to each other.

The following HTML creates a set of horizontally aligned radio buttons:

<table class="widgetgrid" width="100%">
    <col width="20%" />
<col width="20%" />
<col width="20%" />
    <col width="20%" />
<col width="20%" />
    <tr>
        <td class="label">RadioGroup01:</td>
        <td class="radio">
            <input type="radio" name="radiogroup01" id="radio01" />
            <label for="radio01">Option 1</label>
        </td>
        <td class="radio">
            <input type="radio" name="radiogroup01" id="radio02" />
            <label for="radio02">Option 2</label>
        </td>
        <td class="radio">
            <input type="radio" name="radiogroup01" id="radio03" />
            <label for="radio03">Option 3</label>
        </td>
    </tr>
</table>

Drop-down Lists

Drop-down lists can be used in various ways. Typically they are used to offer a large range of choices. The range may include the option "none" if case user input isn’t required. Oftentimes when "none" is an option, it is set to the default option. If user input is required because "none" is not an accepted value, the initial value should be the first option in the list. If the chance of the user forgetting to select an option needs to be ruled out, a dummy option like "Select" can be used. If you choose for the latter, a validation should be performed that checks whether the user has actually selected an acceptable value before processing the data. All of these drop-down lists have a separate label to the left.

No separate labels should be used when drop-down lists are used to select and trigger actions. The initial dummy value indicates the action that is expected from the user. This type of drop-down lists are used in adding items to a list ("Select item to add") or selecting an object to edit. In the second case it’s also possible to omit the dummy label value and have the first object (or the last edited object) initially selected.

The following HTML creates a drop-down list:

<table class="widgetgrid" width="100%">
    <col width="20%" />
<col width="40%" />
<col width=”40%” />
    <tr>
        <td class=”label”>Label 1:</td>
        <td class=”textfield”><input type=”text” name=”textfield01” /></td>
        <td />
    </tr>
    <tr>
        <td class=”label”>Label 2:</td>
        <td class=”pulldown”>
            <select name=”select01”>
                <option>Option 1</option>
                <option>Option 2</option>
                <option>Option 3</option>
                <option>Option 4</option>
                <option>Option 5</option>
            </select>
        </td>
        <td />
    </tr>
</table>

Back to top

Multi-line Text Input: Text Areas

Most textual input can be entered using a regular text field, but sometimes strings can be long and need more space. In those cases, use a text area. A text area is not only scaled to fit horizontally, but also vertically. This means not only the width of the <td> (or column) should be set, but also its height. A default height of approximately 3 lines should be used and you can also use more lines if required.

The following HTML creates a text area:

<table class=”widgetgrid” width=”100%”>
    <col width=”20%” />
<col width=”80%” />
    <tr>
        <td class=”label”>Title:</td>
        <td class=”textarea” height=”80”>
            <textarea name=”textarea01”>Lorum ipsum</textarea>
        </td>
    </tr>
</table>

Back to top

Date Input: Date Fields

Providing a user friendly way to input a date can be done by using the date field. The date field is a regular text field with a button next to it that opens a calendar widget which the user can use to select a date. By using the widget, the user doesn’t need to worry about entering the date in the correct format because this is done automatically. Users can still manually enter the date into the text field if they want to. The text field with its button is not scaled in any direction within the table.

The following HTML creates a date field:

<table class=”widgetgrid” width=”100%”>
    <col width=”15%” />
    <col width=”5%” />
    <col width=”40%” />
    <col width=”5%” />
    <col width=”10%” />
    <col width=”25%” />
    <tr>
        <td class="label">Label05:</td>
        <td class="radio">
            <input type=”radio” name=”radiogroup1” id=”radio1” />
            <label for=”radio1”>From</label>
        </td>
        <td class="datefield">
            <input type="text" size="10" />
            <a href="#"><img border="0" src="btn_date2_up.gif"/></a>
        </td>
        <td class="radio">
            <input type=”radio” name=”radiogroup1” id=”radio2” />
            <label for=”radio2”>Last</label>
        </td>
        <td class="textfield">
            <input type="text" name=”textfield01” />
        </td>
        <td class=”text”>entries</td>
    </tr>
    <tr>
        <td />
        <td class="label">to</td>
        <td class="datefield">
            <input type="text" size="10" />
            <a href="#"><img border="0" src="btn_date2_up.gif"/></a>
        </td>
        <td />
        <td />
        <td />
    </tr>
</table>

Back to top

Initiating Action: Buttons

Every regular panel in XperienCentral typically has 2 buttons: [Apply] and [Close]. These are at the bottom right of the panel and apply to all changes made inside the panel. Sometimes complementary buttons are needed for other tasks than to apply all changes made or to close the panel. For instance for creating a new item in a list or deleting a product from the database. These buttons do not appear in the bottom right of the panel but inline, in the context where the action is performed. The label of a button is on the button itself; it does not need another label to describe its action. Because the label determines the width of the button it shouldn’t be too long.

The following HTML creates an inline button:

<table class=”widgetgrid” width=”100%”>
    <col width=”20%” />
<col width=”40%” />
<col width=”40%” />
    <tr>
        <td class=”label”>Label 1:</td>
        <td class=”pulldown”>
            <select name=”select01”>
                <option>Option 1</option>
                <option>Option 2</option>
                <option>Option 3</option>
                <option>Option 4</option>
                <option>Option 5</option>
            </select>
        </td>
        <td class=”button”><input type=”button” value=”Button label 1” /></td>
    </tr>
</table>

Back to top

Uploading Files: File Fields

A file field is used to upload files from the user's local file system to the server. Like text fields, these fields are scaled horizontally to fit the widgetgrid table. The size parameter is overridden in Internet Explorer by the CSS style.

The following HTML creates a file field:

<table class=”widgetgrid” width=”100%”>
    <col width=”20%” />
<col width=”40%” />
<col width=”40%” />
    <tr>
        <td class=”label”>Label 1:</td>
        <td class=”file”>
            <input type=”file” name=”filefield01” size=”40” />
        </td>
        <td />
    </tr>
</table>

Back to top

Presenting Data: Tables and Grids

Multiple items, like search results, are commonly presented in some sort of a nested table. These tables are basically regular tables, but have alternating row colors and sortable columns. Because these grids are mostly used for showing search results, the <div> element containing the grid are assigned the class searchresults. Regular tables are more basic and present less visual noise and are better suited for use in content elements. Tables can have a <td> element with the class presentation which will display the table in a boxed area.

The following HTML creates a search results table, which can be embedded in a table:

<fieldset>
<legend>fieldset01</legend>
<div class=”searchresults”>
        <table width=”100%”>
            <col width=”20%” />
            <col width=”40%” />
            <col width=”40%” />
            <tr>
                <th>header01</th>
                <th>header02</th>
                <th>header03</th>
            </tr>
            <tr class=”even”>
                <td>Value01</td>
                <td>Value02</td>
                <td>Value03</td>
            </tr>
            <tr class=”odd”>
                <td>Value04</td>
                <td>Value05</td>
                <td>Value06</td>
            </tr>
            <tr class=”even”>
                <td>Value07</td>
                <td>Value08</td>
                <td>Value09</td>
            </tr>
        </table>
    </div>
</fieldset>

The following HTML creates a presentation table in a content element:

<table class=”widgetgrid” width=”100%”>
    <col width=”20%” />
    <col width=”80%” />
    <tr>
        <td class=”label”>Products:</td>
        <td class=”presentation”>
            <table class=”widgetgrid” width=”100%”>
                <col width=”20%” />
                <col width=”35%” />
                <col width=”45%” />
                <tr>
                    <td class=”heading”>header01</td>
                    <td class=”heading”>header02</td>
                    <td class=”heading”>header03</td>
                </tr>
                <tr>
                    <td class=”text”>value01</td>
                    <td class=”text”>value02</td>
                    <td class=”text”>value03</td>
                </tr>
                <tr>
                    <td class=”text”>value04</td>
                    <td class=”text”>value05</td>
                    <td class=”text”>value06</td>
                </tr>
                <tr>
                    <td class=”text”>value07</td>
                    <td class=”text”>value08</td>
                    <td class=”text”>value09</td>
                </tr>
            </table>
        </td>
    </tr>
</table>

Lists should not contain too many items because that will make it hard to locate the item(s) the user needs. When a list could be potentially very long, it’s better to add some sort of pagination or search/filter functionality.

Back to top

Tag Library

Developers can use the wmedit tag library to create standard GUI elements like the ones described in the previously in this topic. Using these standard widgets has the advantage that you don't have to code all GUI logic yourself and the standard GUI elements within XperienCentral are all implemented in the same way. The tags markup follows the XML standards. The following is an overview of all available tags in the wmedit tag library. For each tag an example is given which shows its markup. Note that in some examples not all parameters are set.

attributes

Exposes a string of HTML attributes from the given map of attributes.

Attributes	The dynamic attributes specified will be added to the string if they do not already exist in the map. This tag exposes a variable with the name specified in the `var` attribute.
Example	`<wmedit:attributes var="attrString" attributeMap="${attributes}" name="${status.expression}"></wmedit:attributes>`

button

Displays a button.

Attributes

Does not accept dynamic attributes.

Parameters

type:String - The type of action which should be invoked when the button is pressed.

APPLY - Submit the form.

OK - Submit the form and close the panel.

CLOSE - Close the panel.

NEXT - Submit the panel with palelgototabid parameter="next".

PREVIOUS - Submit the panel with panelgototabid parameter="previous".

SUBMIT - Submit the panel and invoke the optional parameter panelaction.

key:String - The text that displays within the button (required).

panelaction:String - An extra JavaScript funtion which will be invoked upon submission.

Example

<wmedit:button type="NEXT" key=”Next step” panelgototabid=”next” panelaction=”validateForm()” />

datePicker

Displays an input field and binds it to the attribute of a command or bean.

Attributes	Accepts dynamic attributes.
Parameter	`path:String` - The name of the field to bind to (required).
Example	`<wmedit:datePicker path="personBirthdate" />`

fileUpload

Displays an input field to upload a file and binds it to the attribute of a command or bean.

Attributes	Accepts dynamic attributes.
Parameter	`path:String` - The name of the field to bind to (required).
Example	`<wmedit:fileUpload path="personPicture" />`

input

Displays an input field (default type="text") and binds it to the attribute of a command or bean. If name and/or value attributes are specified, they will be used instead of a status.expression and/or status.value, respectively. A type attribute may also be used to override the input tag type (the default is text).

Attributes

Accepts dynamic attributes.

Parameters

path:String - The name of the field to bind to (required).

name:String - Use this attribute to override the input name.

value:String - Use this attribute to override the input value.

type:String - use this attribute to override the input type (for example, hidden).

Example

<wmedit:input path="personPassword" name=”personPwd” type=”password” />

onOffCheckbox

Displays a checkbox and binds it to the attribute of a command or bean. When the checkbox is checked, the value of the attribute will be set to true, otherwise it will be set to false.

Attributes	Accepts dynamic attributes.
Parameters	`path:String` - The name of the field to bind to (required).
Example	`<wmedit:onOffCheckbox path="submitToSpam" />`

onOffToggle

Displays an on/off toggle switch and binds it to the attribute of a command or bean. When the toggle is on, the value of the attribute will be set to true, otherwise it will be set to false.

Attributes	Accepts dynamic attributes.
Parameters	`path:String` - The name of the field to bind to (required).
Example	`<wmedit:onOffToggle path="submitToSpam" />`

openPanel

Opens a new panel with the ID of the panel as identifier

Attributes

None.

Parameters

id:String - The id of the panel which has to be opened.

title:String - The title of the popup.

width:Integer - The width of the popup, defaults to 640.

height:Integer - The height of the popup, defaults to 480.

resizable:Boolean - Specifies whether the popup is resizable.

Example

<wmedit:openPanel id="1" title=”Person” width=200 height=300 resizable=true />

radioButton

Displays a number of radio buttons and binds them to the attribute of a command or bean. The radio button containing the current value of the attribute will be checked Accepts dynamic attributes.

Attributes

None.

Parameters

path:String - The name of the field to bind to (required).

items:Array - Array of objects that can be assigned to the bound attribute (required).

item:String - Current value of the bound attribute (required).

itemValue:String - Attribute of the items class to override the value of the radio button.

itemLabel:String - Attribute of the items class to override the label of the radio button.

Example

<wmedit:radioButton path="personGender" items="${genderOptions}" item="${thisElement.personGender}" />

select

Displays an input field (default type="text") and binds it to the attribute of a command or bean. If name and/or value attributes are specified, they will be used instead of status.expression and/or status.value, respectively. A type attribute may also be used to override the input tag type (the default is text).

Attributes

Accepts dynamic attributes.

Parameters

path:String - The name of the field to bind to (required).

name:String - Use this attribute to override the input name.

value:String - Use this attribute to override the input value.

type:String - Use this attribute to override the input type (i.e. hidden).

Example

<wmedit:select path="personCity" name”City” />

selectItem

Displays a select drop-down list for selecting an item from a list and binds it to the attribute of a command or bean. The selection is based on the UUID, so the objects in the list have to have a getUUID() method.

Attributes

Accepts dynamic attributes.

Parameters

path:String - The name of the field to bind to (required).

items:Object - The object list to show (required).

item:Object - The current selected item (required).

itemValue:String - Fieldname for the list object key, option key (required).

itemLabel:String - Fieldname for the list object description, option text (required).

Example

<wmedit:selectItem onchange="" path="personSelectedFavoriteCity" items="${cities}" item="${thisElement.personFavoriteCity}" itemValue="UUID" itemLabel="personName" />

selectTermsBox

Displays a term selector for selecting a term from the Media Repository and bind it to the attribute of a command or bean

Attributes	Accepts dynamic attributes.
Parameters	`path:String` - The name of the field to bind to (required).
Example	`<wmedit:selectTermBox path="personTems" />`

staticContentBlock

Display static content block with collapse and hide functionality.

Attributes

Accepts dynamic attributes.

Parameters

name:String - The name to display in the header of this block.

id:String - The block identifier.

Example

<wmedit:staticContentBlock name="Person details" id=”personDetails”>Content</wmedit:staticContentBlock>

textArea

Displays a text area and binds it to the attribute of a command or bean.

Attributes	Accepts dynamic attributes.
Parameters	`path:String` - The name fo the field to bind to (required)
Example	`<wmedit:textarea path="personInformation" />`

yesNoRadioButton

Displays a yes and a no radio button and binds them to the attribute of a command or bean. When the yes radio button is checked, the value of the attribute will be set to true, otherwise it will be set to false.

Attributes	Accepts dynamic attributes.
Parameters	`path:String` - The name fo the field to bind to (required)
Example	`<wmedit:yesNoRadioButton path="personAccept" />`

Back to top

Interaction Patterns

In XperienCentral there are several recurring interaction patterns that make the application more consistent and more predictable for the user. As stated before in the guidelines, it is impossible to create a set of patterns that suit the needs of all developers in all situations. For the basic interactions like adding, editing and removing instances, the following patterns outline the interaction concepts.

Creating a New instance

A common action performed in a content element maintenance panel is creating a new instance of something. This can be an instance of anything, like a product group or a product in a web shop. To enable the user to create new instances, you should use one of these options:

A [New] button next to the selection drop-down list
A, [Add new] button with textfield(s) at the bottom of a list of existing instances

In all cases, the new instance will be automatically selected for editing after creation so that the user doesn't have to select the instance first in order to set its parameters.

Selecting an Instance

Before the user can edit an instance in a content element maintenance panel he or she has to select it or create a new instance (that will automatically be selected after creation). To enable the user to choose from the existing instances, a drop-down list should be used. After selecting the instance, the panel will load and display the settings of the chosen instance, after which the user can edit them.

Deleting an Instance

Deleting an instance should be implemented using a [Delete] button. The user should first select an instance before he or she can delete it. The button should be placed in the parameter section so that it will only be available when an instance is selected next to the first input element which is likely to be a name or title field and right-aligned in order to visually disconnect it from the first input element. If the delete action can’t be undone, a warning message such as “Are you sure you want to delete instance X?” should be displayed in order to protect the user from mistakenly deleting instances. An alternative way to delete (multiple) instances is to use a list of instances and add a "Delete" checkbox at the end of every row. When checked, the instance will be deleted when the [Apply] button is clicked.

Apply Changes and Close

To apply changes made in a panel, the user clicks the [Apply] button. To close a panel, the user clicks [Close]. The [Apply] button is always the left-most of the buttons in the bottom bar of the panel. The [Close]’ button is always the furthest right button.

Back to top

Browser not supported