mirror of
https://github.com/opf/openproject.git
synced 2026-06-13 19:20:00 +00:00
Added page for 'Email Updates Mode' and more
Also updated the 'Forms' and 'How to use' pages
This commit is contained in:
committed by
Mir Bhatia
parent
c96720334b
commit
78e31fd3fe
@@ -9,15 +9,21 @@ You will find defined styles, components and patterns in the relevant sections.
|
||||
|
||||
### Components
|
||||
|
||||
On the left side you see the component previews. In "Open project", all re-usable components are listed that are specific to OpenProject (e.g the user avatar). The section "Primer" contains the components of the Primer repository. Within that, we distinguish between the status of a component: "Alpha", "Beta", "OpenProject". The latter is used for all generic components that we added to the repository (e.g. the PageHeader).
|
||||
On the left side you see a list of available components. You can click on them for more details such as anatomy, code examples, options and implementation details.
|
||||
|
||||
**Please note that these the documentation on this LookBook contains components and patterns that are unique to or have been modified for OpenProject, and previews for all Primer available components. However, we do not duplicate documentation for base Primer components; if you want more details on components that do not have specific pages in our LookBook, please refer to the [GitHub Primer documentation](https://primer.style/product/components/) instead**.
|
||||
|
||||
If you are looking for a specific object you know by name, you can also use the search bar under *Previews* to go directly to that component.
|
||||
|
||||
### Patterns
|
||||
|
||||
In the lower left, there is a section called "Patterns". In here, we will document all kind of decisions that we take with regards to Primer and/or the components. This includes parts where we explicitly do not follow the primer way, as well as specific UX patterns that we decided for.
|
||||
In the lower left, there is a section called "Patterns". In here, we will document specific decisions and patterns concerning how we approach the use of certain components, or how certain things (like dialogs or flash banners) work in OpenProject.
|
||||
|
||||
This includes behaviour and patters that explicitly do not follow the Primer approach, as well as specific UX patterns that are unique to OpenProject.
|
||||
|
||||
### Icons
|
||||
|
||||
When it comes to icons, please use the Octicons provided by Primer. You can find a list of all icons [here](./styles/icons). There is also a preview example on how to use the Octicons in `Primer/Beta`.
|
||||
Please use the Octicons provided by Primer. You can find a list of all icons [here](./styles/icons). There is also a preview example on how to use the Octicons in `Primer/Beta`.
|
||||
|
||||
## Approach
|
||||
|
||||
|
||||
@@ -0,0 +1,41 @@
|
||||
The Email Updates Mode selector is used to let users enable or disable automatic email updates when significant events take place. It serves as both a mode indicator and, if the user has the necessary permissions, control to change the mode.
|
||||
|
||||
## Overview
|
||||
|
||||
[Code example here]
|
||||
|
||||
## Anatomy
|
||||
|
||||
The component is simple: it consists of a static header, a text that indicates mode (and what that status means) and, in some cases, a button to change the mode.
|
||||
|
||||
The current mode is always indicated in bold.
|
||||
|
||||
The action to change the mode (often 'Enable' or 'Disable') is a button with scheme `link`, with a leading icon. If a suitable leading icon is not available, it can also be used without an icon. This action is not present in some views; for example, if the user does not have the necessary permissions to change the mode, then the action is simply not displayed (or replaced by text telling users where they can go to change the mode).
|
||||
|
||||
## Best practices
|
||||
|
||||
**Do**
|
||||
|
||||
- Only use the component on the right side panel.
|
||||
- Use simple, non-jargon language when describing what the current mode is doing.
|
||||
|
||||
|
||||
**Don't**
|
||||
|
||||
- Do not use this component when a checkbox or a toggle is more relevant. However, because toggle switches are activated immediately and the request sent asynchronously before a form submit (regardless of whether the request is successful or not), they might not always be the right component to use. This is the case for email updates.
|
||||
|
||||
## Used in
|
||||
|
||||
The component is used in:
|
||||
|
||||
* Meetings to indicate (and, when the user has the necessary permissions, control) the automatic sending of updated calendar invites by email to all participants when there are significant changes to meeting details, such as date, time or location.
|
||||
* File storage health check email updates to admins
|
||||
|
||||
|
||||
## Technical notes
|
||||
|
||||
[Add info if necessary, else remove section]
|
||||
|
||||
### Code structure
|
||||
|
||||
[Add info if necessary, else remove section]
|
||||
@@ -1,4 +1,4 @@
|
||||
A form is a series of components that require user input that will then be submitted. Forms are notably common in settings pages but are also present elsewhere like in individual modals (edit project attribute section, edit meeting details) and the filter panel.
|
||||
A form is a series of components that require user input that will then be submitted. Forms are notably common in settings pages but are also present elsewhere like in individual modals (edit project attribute section, edit meeting details), the filter panel and in multi-step configuration screens (such as admin file storage or authentication setup pages).
|
||||
|
||||
## Overview
|
||||
|
||||
|
||||
Reference in New Issue
Block a user