Content
View differences
Updated by Parimal Satyal over 1 year ago
**Context**
Currently in our pre-Primer toolbars, we use the "pressed" state of buttons to indicate that something is active/enabled. Some key examples:
* **Watch**: Watch: pressed when watching a work package
* **Filter**: Filter: pressed when the filter panel is displayed
* **Baseline**: Baseline: pressed when the baseline panel is visible
However, this isn't always the case. In other cases, we do not use the pressed state:
* **Watch Watch in Wiki pages**: pages: not pressed when watching; a change of icon and label (Watch/Unwatch)
* **Reminders**: Reminders: Not pressed when a reminder is active; a badge will be shown instead: <mention class="mention" data-id="61314" data-type="work_package" data-text="#61314">#61314</mention>
* **Include projects**: Include projects: Not pressed when the include projects panel is visible
* **Live Live time tracking:** tracking: Not pressed when active; the icon changes and the icon-button becomes a button with a time-elapsed label
* **Sharing work pacakges:** Shared: Not pressed; a badge is shown with the number of 'shares'
* **Starred projects:** Starred projects: A star is either visible or not in the list of projects when enabled; the action is only visible on hover.
* **Locking/unlocking Lock/unlock a wiki page**: page: not pressed since action only available in the More menu; a change of icon and label (Lock/Unlock)
**Approaches**
To summarise, we have four approaches used in OpenProject at the moment to indicate that something is an active in OpenProject: state:
* The addition of a badge
* The pressed state
* A change of icon
* A change of button (from icon to text, for example)
**Decision need**
Primer does not have guidelines on whether a pressed state can be used as an persistent indication of state (as opposed to indicating that the button is being pressed at that moment). communicate information. There are reasons _not_ to mis-use the pressed state to indicate state, notably because there are other components like a toggle or a segmented control that are better suited to this.
However, when space is a premium and adding a toggle (which requires a label) is impractical, the pressed state can be very useful. Also, there are certain cases with 'enabled' state is a lot clearer than a change in icon.
The question then is: **Should we continue using the pressed state in our Primerised design? If so, when should we use it vs other options?**
**Relevance**
These decisions will mostly be relevant to our re-design of our Primerised split screen header and work package details sections:
* ###58599
* ###61516
<br>
<br>
Currently in our pre-Primer toolbars, we use the "pressed" state of buttons to indicate that something is active/enabled. Some key examples:
* **Watch**:
* **Filter**:
* **Baseline**:
However, this isn't always the case. In other cases, we do not use the pressed state:
* **Watch
* **Reminders**:
* **Include projects**:
* **Live
* **Sharing work pacakges:**
* **Starred projects:**
* **Locking/unlocking
**Approaches**
To summarise, we have four approaches used in OpenProject at the moment to indicate that something is
* The addition of a badge
* The pressed state
* A change of icon
* A change of button (from icon to text, for example)
**Decision need**
Primer does not have guidelines on whether a pressed state can be used as an persistent indication of state (as opposed to indicating that the button is being pressed at that moment).
However, when space is a premium and adding a toggle (which requires a label) is impractical, the pressed state can be very useful. Also, there are certain cases with 'enabled' state is a lot clearer than a change in icon.
The question then is: **Should we continue using the pressed state in our Primerised design? If so, when should we use it vs other options?**
**Relevance**
These decisions will mostly be relevant to our re-design of our Primerised split screen header and work package details sections:
* ###58599
* ###61516
<br>
<br>