+
Open MCT Style Guide
+
Colors
+
+
+
Overview
+
In mission operations, color is used to convey meaning. Alerts, warnings and status conditions are by convention communicated with colors in the green, yellow and red families. Colors must also be reserved for use in plots. As a result, Open MCT uses color selectively and sparingly. Follow these guidelines:
+
+ - Don't use red, orange, yellow or green colors in any element that isn't conveying some kind of status information.
+ - Each theme has a key color (typically blue-ish) that should be used to emphasize interactive elements and important UI controls.
+ - Within each theme values are used to push elements back or bring them forward, lowering or raising them in visual importance.
+ In this theme, Espresso, lighter colors are placed on a dark background. The lighter a color is, the more it comes toward the observer and is raised in importance.
+ In this theme, Snow, darker colors are placed on a light background. The darker a color is, the more it comes toward the observer and is raised in importance.
+
+ - For consistency, use a theme's pre-defined status colors.
+
+
+
+
+
{{ colorSet.category }}
+
{{ colorSet.description }}
+
+
+
+
+ | Name | {{color.name}} |
+ | SASS | {{color.constant}} |
+ | Value |
+ {{color.valEspresso}}
+ {{color.valSnow}}
+ |
+
+
+
+
+
+
Open MCT Style Guide
+
Glyphs
+
+
Symbolic glyphs are used extensively in Open MCT to call attention to interactive elements, identify objects, and aid in visual recall. Glyphs are made available in a custom symbols font, and have associated CSS classes for their usage. Using a font in this way (versus using images or sprites) has advantages in that each symbol is in effect a scalable vector that can be sized up or down as needed. Color can also quite easily be applied via CSS.
+
New glyphs can be added if needed. Take care to observe the following guidelines:
+
+ - Symbols should be created at 512 pixels high, and no more than 512 pixels wide. This size is based on a "crisp" 16px approach. Find out more about crisp symbol fonts.
+ - In general, the symbol should occupy most of a square area as possible; avoid symbol aspect ratios that are squat or tall.
+ - For consistency and legibility, symbols are designed as mostly solid shapes. Avoid using thin lines or fine detail that will be lost when the icon is sized down. In general, no stroke should be less than 32 pixels.
+ - Symbols should be legible down to a minimum of 12 x 12 pixels.
+
+
+
+
+
+
+
How to Use Glyphs
+
+
+
The easiest way to use a glyph is to include its CSS class in element. The CSS adds a psuedo :before HTML element to whatever element it's attached to that makes proper use of the symbols font.
+
Alternately, you can use the .ui-symbol class in an object that contains encoded HTML entities. This method is only recommended if you cannot use the aforementioned CSS class approach for some reason.
+
+
+
+
+
+
+
+
+
+
+
+
General User Interface Glyphs
+
Glyphs suitable for denoting general user interface verbs and nouns.
+
+
+
+
+ | Meaning | {{glyph.meaning}} |
+ | Class | .{{glyph.cssClass}} |
+ | CSS Content | \{{glyph.cssContent}} |
+ | HTML Entity | {{glyph.htmlEntity}} |
+
+
+
+
+
+
+
Control Glyphs
+
Glyphs created for use in various controls.
+
+
+
+
+ | Meaning | {{glyph.meaning}} |
+ | Class | .{{glyph.cssClass}} |
+ | CSS Content | \{{glyph.cssContent}} |
+ | HTML Entity | {{glyph.htmlEntity}} |
+
+
+
+
+
+
+
Object Type Glyphs
+
These glyphs are reserved exclusively to denote types of objects in the application. Only use them if you are referring to a pre-existing object type.
+
+
+
+
+ | Meaning | {{glyph.meaning}} |
+ | Class | .{{glyph.cssClass}} |
+ | CSS Content | \{{glyph.cssContent}} |
+ | HTML Entity | {{glyph.htmlEntity}} |
+
+
+
+
+
+
+
Open MCT Style Guide
+
Text Input
+
+
Text inputs and textareas have a consistent look-and-feel across the application. The input's placeholder attribute is styled to appear visually different from an entered value.
+
+
+
+
+
+
Textareas
+
+
+
Use a textarea where the user should enter relatively longer or multi-line text entries.
+
By default, textareas are styled to expand to 100% of the width and height of their container; additionally there are three size styles available that control the height of the element: .lg, .med and .sm.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Open MCT Style Guide
+
Introduction
+
+
Open MCT is a robust, extensible telemetry monitoring and situational awareness system that provides a framework supporting fast and efficient multi-mission deployment. This guide will explore the major concepts and design elements of Open MCT. Its overall goal is to guide you in creating new features and plugins that seamlessly integrate with the base application.
+
+
+
+
Everything Is An Object
+
+
+
First and foremost, Open MCT uses a “object-oriented” approach: everything in the system is an object. Objects come in different types, and some objects can contain other objects of given types. This is similar to how the file management system of all modern computers works: a folder object can contain any other type of object, a presentation file can contain an image. This is conceptually the same in Open MCT.
+
As you develop plugins for Open MCT, consider how a generalized component might be combined with others when designing to create a rich and powerful larger object, rather than adding a single monolithic, non-modular plugin. To solve a particular problem or allow a new feature in Open MCT, you may need to introduce more than just one new object type.
+
+
+
+
+
+
+
+
+
Object Types
+
+
+
In the same way that different types of files might be opened and edited by different applications, objects in Open MCT also have different types. For example, a Display Layout provides a way that other objects that display information can be combined and laid out in a canvas area to create a recallable display that suits the needs of the user that created it. A Telemetry Panel allows a user to collect together Telemetry Points and visualize them as a plot or a table.
+
Object types provide a containment model that guides the user in their choices while creating a new object, and allows view normalization when flipping between different views. When a given object may only contain other objects of certain types, advantages emerge: the result of adding new objects is more predictable, more alternate views can be provided because the similarities between the contained objects is close, and we can provide more helpful and pointed guidance to the user because we know what types of objects they might be working with at a given time.
+
The types of objects that a container can hold should be based on the purpose of the container and the views that it affords. For example, a Folder’s purpose is to allow a user to conceptually organize objects of all other types; a Folder must therefore be able to contain an object of any type.
+
+
+
+
+
+
+
+
+
Object Views
+
+
+
Views are simply different ways to view the content of a given object. For example, telemetry data could be viewed as a plot or a table. A clock can display its time in analog fashion or with digital numbers. In each view, all of the content is present; it’s just represented differently. When providing views for an object, all the content of the object should be present in each view.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Open MCT Style Guide
+
Standards
+
+
+
Absolute Positioning and Z-Indexing
+
Absolute positioning is used in Open MCT in the main envelope interface to handle layout and draggable pane splitters, for elements that must be dynamically created and positioned (like context menus) and for buttons that are placed over other elements, such as a plot's zoom/pan history and reset buttons. When using absolute positioning, follow these guidelines:
+
+ - Don't specify a z-index if you don't have to.
+ - If you must specify a z-index, use the lowest number you that prevents your element from being covered and puts it at the correct level per the table below.
+
+
+
+
+ | Base interface items | Base level elements | 0 - 1 |
+ | Primary pane | Elements in the primary "view area" pane | 2 |
+ | Inspector pane, splitters | Elements in the Inspector, and splitters themselves | 3 |
+ | More base interface stuff | Base level elements | 4 - 9 |
+ | Treeview | Lefthand treeview elements | 30 - 39 |
+ | Help bubbles, rollover hints | Infobubbles, and similar | 50 - 59 |
+ | Context, button and dropdown menus | Context menus, button menus, etc. that must overlay other elements | 70 - 79 |
+ | Overlays | Modal overlay displays | 100 - 109 |
+ | Event messages | Alerts, event dialogs | 1000 |
+
+
+
+