Patterns

Patterns are large, self-contained parts of the layout, that fulfill a singular purpose.

Application Menu

The application menu is rendered as a vertical sidebar on the left border of the viewport. It is fully responsive, and breaks down to a phone-sized fullscreen menu that is toggled via a hamburger icon located on the page heading and as a floater on the bottom center of the viewport. The application menu contains L1 and L2 menu nodes, and provides access to the entire suite of installed applications. That requires a consistent menu population within all applications of any given suite. User menu to be decided.


Application Menu PIM

Application Menu OPC

Search / Search Bar

Search bars are rendered as a single input Simple Search or as a Multiple Field Search. A Simple Search can be combined with an Extended Search, which is a collapsible Multiple Field Search. Search bars can be augmented with several javascript driven controls, i.e. autocomplete or keyword tagging. It is important not to restyle search bars, as their appearance and layout is required to be uniformous everywhere.

Simple Search

The Simple Search utilizes a XXX component, and expands into an extended search in an X-column grid. Extended Searches require a .form-submit at the bottom which reproduces the function of the main search button Can be extended with autocomplete, erase input field, group and compatibility restrictions, tags. Requires a search button, which always contains a magnifying glass icon and may contain the string Search.

Extended Search

..

Inline Search

The Inline Search utilizes a XXX component. Can be extended with autocomplete, erase input field, group and compatibility restrictions, tags. Requires a search button, which always only contains a magnifying glass icon.

Multi Field Search

The Multi Field Search is the standard search pattern for all CRUD search result pages. It is always located right below the view header, and comes without its own heading. That makes sense because it is a control that directly relates to the topic of the page header. Multi Field Searches give access to a set of business objects that can be edited in the scope of the parent function. They are rendered as a column grid of form fields, with a form-submit at the bottom. The search Results of a Multi Field Search are always rendered as the next pattern, without intermediate layout elements.


Form Heading

Search Don'ts:

  • Don't scale searchbar up or down
  • Don't prevent responsive behaviour
  • Don't switch button classes
  • Don't use non-standard icons/labels for buttons

Search Results

Result lists are rendered as tabular data, with a special case in OPC, showing product lists. Search result lists are an integral part of the OCUI User Experience, allowing access to the business objects that require handling. Result lists require a corrensponding search bar preceding the list in the same layout, but are NOT a child node of the search bar. Result lists are constructed from tables, populated by business objects, filter and sorting tools, pagination and mass operations. They can also contain a form-submit, if the primary goal of the view is to process part of the search result list. Filters and Categories Filtering, sorting and category drill in functionality can be used in conjunction with the search bar, allowing the user to narrow results to a good result size with consecutive searches and filtering. This functionality is called Drill-in-Search.

CRUD Editor / Business Object Editor

...

Form Section

is documented

Nested Forms

Nested forms require a constraining parent. A prime example is a form based editor that renders a result list populated with on-view editable nodes, which allows for an expanding nested form that allows Search-and-Entry functionality for complex data types.

Page Header / BO Heading

Each Page/View has a <h1> heading, which may be extended by form elements, labels, callouts, static text or pictures. There are notable exceptions to that rule, listed below. If you want to build a view without a header, please consult a UX Designer.

Exceptions: These Views Don't Require a Page Header

    OPC
  • Search
    opc/search
  • Free Text Order
    opc/productDetails/show?productKey=Freetext_Freetext
  • Customer Service CMS Page
    opc/cms/opcSupport/service
  • Contact CMS Page
    opc/cms/opcSupport/contact
  • External Shops
    opc/externalShops/index
  • Shopping Cart
    opc/shoppingCart

Page Header

Page Header

Page Header Object Identifier

Status Page Header Object Identifier

Ordered Page Header OFSR000001

Created on
10/05/2016 4:29:05 AM
Attribute
Value
Attribute
Value
Attribute
Value
Attribute
Value

Page Header Object Identifier

This is what it's about

This is some sort of information about what's happening or what's to be done here.

Status Page Header Object Identifier

Attribute
Value

This is what it's about

This is some sort of information about what's happening or what's to be done here.

Status Page Header Object Identifier

Attribute
Value

This is what it's about

This is some sort of information about what's happening or what's to be done here.

Status Page Header Object Identifier

Value

Value

Value

Value

Value

Value

Value

Value

Value

Value

Value

Value

This is what it's about

This is some sort of information about what's happening or what's to be done here.

Page Header Object Identifier

Page Header Object Identifier

Apple iPad3 128GB Wifi/3G

5658741
Confirmed

Apple iPad3 128GB Wifi/3G

5658741
Confirmed

Footer

The footer contains the OpusCapita logo, a shorthand copyright notice and a two-line version info. Each view, except Popups and Modals requires a footer. The footer is located at the bottom of the viewport if the layout is shorter than the viewport. If the layout exceeds the height of the viewport, the footer is found at the bottom of the scrollable content area.

Mapping Editor

..

Dashboard

..

Full Width / Fullscreen Wrapper

..