Contents

Why is it important to have a Style Guide

A Style guide helps to make consistent design decisions. A reference to agree on before doing try-and-error discussions that can be costly and frustrating. In the end it may not really matter if the colour of the alert modal is red or orange. And it may not matter if the OK and Cancel button is left and right. Or the opposite.

But what matters is that once you decide for one of those patterns you do it consistently! Not come up with alternating patterns or have various different versions of a UI/UX of similar functionality.

Further material and examples on what a typical Style Guide (and StoryBooks) would contain and solve:

Definitions and getting feedback

Following is a list of component, principles, ideas. It may not be complete and it may evolve over time. You may add your problem, discuss, get feedback. The main place to discuss is the Mailing list. But you can also comment here in line, although if the feedback is very broad it may help to use the mailing list to discuss upfront.

Ultimately the goal is to agree on something. In order to make that more easy below should articulate to Do's and Don'ts. Agreement it reached by merit. Everyone has some voice in the process.

General principles

Following a more general principles. Rather than concrete components.

In general OpenMeetings relies on Apache Wicket, Bootstrap and jquery.

Hiding vs Disabling elements 

This is a draft proposal and subject to discussion

Do enable and disable UI, Buttons and elements in case it only depends on the context of how you use it

Examples:

  • In the whiteboard, assuming you have permissions to edit the whiteboard, all whiteboard tools including the document navigation should be disabled if there is currently nothing to select, enabled when there is something (not hidden and visible true/false)
  • In the file explorer, the download button, if you have permissions to access the File tree, the buttons to download something should be disabled not invisible

Do hide elements, UI, Buttons in case you do not have permissions currently to use it

Examples:

  • If you don't have permissions to use the whiteboard tools, the whiteboard tools shouldn't be visible
  • If you don't have permissions to share your screen or enable your audio/video the buttons to share your audio/video should be hidden, not disabled

Primary vs Secondary call to actions buttons

This is a draft proposal and subject to discussion

Do have primary button of action left, secondary button of actions right

Examples:

  • In a confirmation dialog the OK (Primary) button should be left, the Cancel (Secondary) button right

Components

Bootstrap Style and components

OpenMeetings relies on Bootstrap, so the Bootstrap general guide should be our guideline: https://getbootstrap.com/docs/4.4/components/

Whiteboard toolbar menu

This is a draft proposal and subject to discussion

Proposed design

Whiteboard-menu-bar

Proposed behaviour

  • Visible true if you have permissions for whiteboard (or inherited permissions)
  • Disable elements when for example no document in whiteboard for page elements



  • No labels