UI Design Principles
Breakpoints
A breakpoint is the media query values that will mark the transition to a new class of devices. The design will use 2 breakpoints to create 3 types of device; mobile, tablet, and desktop. These breakpoints will be;
-
720px - Transition from phone to tablet
-
1024px - Transition from tablet to desktop
Limited support will be given for devices under 320px width.
Mobile first approach
Designing with the mobile layout first will help separate the essential elements from the secondary ones. Once the mobile design questions are answered, designing for other devices will be easier. The mobile-first approach is also a content-first approach. The heart of the site is content — that’s what the users are there for!
|
Build the mobile wireframe first, then use that as the model for larger breakpoints.
|
Base layout
The Layout Shifter, the name coined by Luke Wroblewski in his article Multi-Device Layout Patterns, will form the bases of the design.
"This pattern does the most to adapt across different screen sizes. That is, different layouts are used on large, medium, and small screens."
Primary Menu
The application title and primary menu is rendered in the PrimaryMenu section. On mobile devices and tablets the PrimaryMenu will be rendered as a HamburgerMenu in the PageHeader, resulting in a pop-up menu when pressed.
On desktop devices the menu will be rendered on the left.
Page Header
The page header will display the active page name. This will make users aware of the screen/function in view.
The page header will host the HamburgerMenu on the left for mobile and tablet devices.
Main Control
Some pages will render a main control to render any primary actions for the page, or provide summary data. This section will follow the page title.
About this screen band
Some screens explain themselves in-flow, so that an operator does not need external documentation to finish the task. On those screens an "About this screen" band holds a short purpose paragraph and a few bulleted operational details. The copy is stage-aware: a staged flow shows the copy for the current stage.
- Placement
-
The band is full width and sits above the screen’s content. It sits below the page header (the command row) and below any stage bar or section tabs. It is never placed beside the content as a side rail.
- Behaviour
-
-
The band is expanded the first time an operator opens a screen. On every later visit it starts collapsed, until the operator expands it again.
-
The state is remembered per screen in
localStorage; a staged flow remembers it per stage. -
If storage is unavailable, the band opens expanded.
-
Collapsed, the band is one row: the eyebrow "About this screen", the stage or screen title, and a Show / Hide control.
-
Expanding the band pushes the content down. It does not overlay the content.
-
- Chrome budget
-
The band counts as content, not chrome, whether collapsed or expanded. It does not count towards the limit on chrome rows above the content set in C01.
- Implementation
-
One shared component implements the band in admin-portal:
ap-import-about-panel. The import page shell places it above the import screens' content. Other screens that carry the band, such as stock return and order detail, place the same component above their content. - Dialogs
-
The band is a screen pattern. A dialog that explains itself keeps its own "About this dialog" panel inside the dialog, and this section does not apply to it.
Command pages
A section groups several screens over the same data under one tab strip, below the breadcrumb (see C01 — Section tabs at tenant scope). Numbers & Tags is one: its tabs are Stock status, Numbers, UNFIT and Activity.
A command page is a child page that runs one task. It is opened from an action in the section’s command row, and it has its own leave-page guard where it holds unsaved work. A command page is defined by this role, not by its route: a detail page can share the same parent in the route tree.
The pattern applies across the portal. Today it covers the command pages of Numbers & Tags: Stock take, Return, Flag unfit, Onboard and Manufacture. Command pages at instance scope, such as the participant import under an event, are not yet covered; whether they hide the instance tab strip is an open decision.
- Tab strip
-
A command page hides the section tab strip. It does not highlight one of the tabs. The command takes the whole page, and a row of tabs would invite the operator to leave in the middle of a session.
- Breadcrumb
-
The breadcrumb stays "section › command", for example
Southern Suburbs Schools › Numbers & Tags › Return. The section crumb is a link and leads back to the section. - Leaving
-
A command page that holds unsaved work has a leave-page guard. The guard handles every way out: the section crumb, the sidebar and browser Back. The tab strip is not needed as a way out.
- Detail pages are different
-
A detail page opened from a tab, such as one batch under Activity, keeps the tab strip with its tab highlighted. It shows more of what the tab already shows. It does not run a task.