# **02. Navigation**
###### tags: `Done`, `Functions`, `Behaviours`, `Transitions`

**Purpose:**
* Understand which components facilitate navigation throughout the 3.Finance **App**.
* Understand the relationships between, and expected behaviours of these components.

Content:

> Definitions
> References
> Navigation:
>> Components
>> Behaviours
>> Transitions

## Definitions

* **Drawers** are like panels that enter the screen from the left or right to facilitate a function. Drawers contain actionable functions like navigation or means to perform transactions that will change the state of a card or space. More about drawers will be explained in other documents.
* **Cards** are again like panels, but in this instance, they reveal themselves from the bottom of the screen and do not contain any actionable data. Cards are for high level informative information; presenting a state of a widget, position or application. More about cards will be explained in other documents.
* **Money Apps** are external protocols that have been integrated into the 3.Finance web app.

## References
> There are a number of prototype video's illustrating how navigation is expected to work and the behavioural interactions desired. Please reach out to Gravity on 3.Finance's discord for access to these videos.

## Navigation
To navigate the 3.Finance app, the following 'Components' are used:

### The Left Drawer (Navigation Drawer)

Figure 1.

Anchored to the left edge of the screen will be a glass panel also referred to as the '**Navigation drawer**'. It is referred to as a drawer because from time to time it will retract/hide from view; allowing for UI real estate to be used efficiently and efficiently.

The primary function of this drawer is to give access to the **PRIMARY Navigation** menu.
Primary navigation is displayed vertically in the format of a timeline and provides access to each of the 4 main spaces within the 3.Finance app: Dashboard, Deposits, Emissions & Money Apps.

>*When the screen width permits; above the highest snap point (to be defined by and confirmed with design team) this drawer may be permitted to remain in view at all times. When this permission is exercised the 'Cheveron' and 'Hide' button will be hidden from view. **Not for MVP as Design still needs to confirm this.***

More information on Drawers can be found in document '03'.

### Cards

Figure 2.

The main body of each space consists of cards.
There are two types of cards:
1. **Widgets** - these display data feeds from connected money apps and come in 4 sizes: Large, Tall, Wide and Small. (As seen in figure 1)

> * **Amendment Dec' 2nd 2022:**
> * Widgets will no longer be customisable for MVP.
> * Thus they will come in once size for now: Large.

2. **Rows** - these are rectangular and stretch multiple columns within the '**Design Grid**'. (As seen in figure 2) They display high level information about a working position (when viewed in the Deposits space), a collected reward (when viewed in the Emissions space), or the state of a money app (when viewed in the Money Apps space).

All cards have multiple states depending on user interaction or function. These states are:

* A '**Default**' state - visible when a user has not engage with a specific card.
* A '**Rollover**' state - visible when ever a user hovers over, but has not engaged with a specific card.
* A '**Selected**' state - visible when a user has directly engaged with a specific card.
* A '**Highlighted**' state - visible when a function a user has engaged with is expected to impact the state or value displayed on the highlighted card.

**Notes:**
The highlighted state is currently only used in the 'Deposits' and 'Emissions' spaces.
More information on Cards can be found in document '03'.

### The Right Drawer (Action Drawer)

Figure 3

Anchored to the right edge of the screen will be a glass panel also referred to as the '**Actions Drawer**'. (As seen in figure 3)

The primary function of this drawer is to facilitate actionable functions to progress the state of the card and portfolio. The secondary function of this drawer is to provide more in-depbth information about the content of the card selected.

This drawer will only be revealed to the user on request by the user. The user may call this drawer by selecting a card within the main body of the page.

The state of the selected card will effect the state of the Action drawer as follows:
- If the user is in the walkthrough state; the action drawer will display a 'Connect Wallet' prompt.
- If the user is connected and has selected the card for the first time OR has no balance relating to that card, the panel will display the '**Details tab**' by default.
- If the user is connected and has a balance relating to that card, the panel will display the '**Actions tab**' by default.

**Note:**
The Action Drawer has special relationships with both the Navigation Drawer and those Cards visible on the page. These are defined under '**Behaviours**' below.

More information on Drawers can be found in '[03 Cards & Drawers](https://hackmd.io/@3Fi-4-DeFi/3Fi-Cards-n-Drawers)'.

## Behaviours
The following points itemise are expected interaction behaviours between the aforementiond components.

### Common Behaviours
These are interaction behaviours expected in all 'Spaces'.
Spaces being: Dashboard, Deposits, Emissions & Money Apps.

>**Navigation Drawer**

1. As a user, I can navigate between spaces by:
* Selecting the title of each space or
* Select + hold + drag the '**Dot**' corresponding to the space I wish to navigate too. (Drag an inactive space towards an active space, ie. Drag an electric green dot towards the white dot) Doing so will trigger a transition between spaces. (See '**Transitions**' below)
2. As a user, when I select '**Hide**' adjacent to the '**Space Description**' (*In walkthrough state*) OR '**Summary**' (*In connected state*), I expect the Navigation Drawer to reduce its width to 1 colum + gutters as per the design grid. This state is referred to as the '**Minimised State**'
3. If in the minimised state, as a user, when I select '**Show**', I expect the Navigation Drawer to expand its width to its maximum width as defined by the design grid. This state is referred to as the '**Maximised state**'.
4. If in the minimised or maximised states, as a user, if I selct the '**< Cheveron**', I expect the Navigation drawer to collapse to the width of the first gutter as per the design grid. This state is refererd to as the '**Collapsed State**'.
5. If in the collapsed state, as a user, I can navigate between spaces by:
* Select + hold + drag the '**Dot**' corresponding to the space I wish to navigate too. (Drag an inactive space towards an active space, ie. Drag an electric green dot towards the white dot) Doing so will trigger a transition between spaces. (See '**Transitions**' below)
6. If in the collapsed state, as a user, when I select the '**> Cheveron**', I expect the Navigation drawer to transition to its maximised state.

>**Action Drawer**

7. As a user, when I select a card, I expect the Action Drawer to be revealed by sliding into view from the right edge of the screen. When in full view, this is referred to as the '**Visible State**'.
8. With the action drawer in its visible state, as a user, if I select a different card, I expect the action drawer to remain open and for the drawers content to update. **Note:**
* As a user, I also expect all tabs (selected) internal to the drawer to remain in the same state while their content is updated.
9. With the action drawer in its visible state, as a user, if I reselect a selected card OR I select the '**X (Close)**' button within the drawer, I expect the drawer to hide: moving from left to right until it is no lonver in view. (When no longer in view, this is referred to as the '**Hidden State**')
* At the same time as the above occurs, I expect the Navigation drawer to transition to its maximised state.
11. If in the visible state, as a user, if I select the '**> Cheveron**' in the Navigation drawer, I expect the navigation drawer to transition to its maximised state as the Action drawer transitions to its hidden state.
12. If in the hidden state and the Navigation drawer is in its minimised state, as a user, if I select a card, I expect the Action drawer to transition to its visible state and the Navigation drawer to transition to its collapsed state.

* **Note:** (Transitions between the Navigation and Action drawers are expected to be in sync)

### Uncommon Behaviours
These may be interaction behaviours specific to a component(s) or a specific space.

>**Action Drawers**
>*Continued*

Applicable when a card in Deposits, Emissions or Money Apps is selected and the user navigates to the Dashboard using the Navigation drawer:

12. With the Action drawer in its visible state and the Navigation drawer in its collapsed state, as a user, if I navigate to the dashboard, I expect the action drawer to remain open and the first card (widget) on the dashboard to be auto-selected. **Note:**
* As a user, I expect all tabs internal to the drawer to remain selected as the drawers content is updated unless the internal tabs do not match.
* If internal tabs do not match, I expect the Action drawer to transition to its hidden state and I do not expect the first card (widget) on the dashboard to be auto-selected.

**Additional note:** Dashboard action drawers only have one primary tab: **Actions**. All other spaces have two internal primary tabs: **Actions** & **Details**. Thus: if at any time a user is looking at '*Details*' of a card and navigates to the Dashboard; this is when the above would occur.

>**Cards**

Applicable to cards in the Deposits, Emissions and Money Apps spaces:

14. Navigation drawer = Maximised state + Action drawer = Hidden state, Card widths = 8 columns as per design grid.
15. Navigation drawer = Collapsed state + Action drawer = Visible state, Card widths = 8 columns as per design grid.
16. Navigation drawer = Collapsed state + Action drawer = Hidden state, Card widths = 10 columns as per design grid.
17. Navigation drawer = Minimised state + Action drawer = Hidden state, Card widths = 10 columns as per design grid.

## Transitions
The following points reference expected timing and effects on components as their behaviours trigger transitions.

>Transitions within spaces

1. All transitions should be timed to **300ms**, **900ms** or **1800ms**
2. As a rule of thumb;
* If the animation is a **micro interaction** (eg. An icon transforming, text fading in/out or a rollover interaction), **use 300ms**.
* If the animation is a **local interaction** (eg. A drawer moving in and out), **use 900ms**.
* If the animation is a **macro interaction** (eg. Navigating between spaces), **use 1800ms**.
* **Note:** Please ensure animation times are editable as there may be a need to customise the timings for certain transitions.
3. Micro interactions do not require an ease in, but an ease out would is preferred.
4. Local interactions require an ease in and an ease out.
* The ease in + ease out should make up 1/3 to 1/2 of the total allotted time for the animation to occur.
* As a rule of thumb, I typically advise alloting 1/2 the time to ease in + out.
5. Macro interactions require an ease in and an ease out.
* The ease in + ease out should make up 1/3 to 1/2 of the total allotted time for the animation to occur.
* As a rule of thumb, I typically advise alloting 1/3 the time to ease in + out.
6. Any fading in or out of copy or components as part of a micro interaction nested in a local and/or macro interaction should be sync'd to the ease in and out of the local and/or macro interaction. (Some adjusting of timings may be required here)

>Transitions between spaces

7. All transitions between spaces are considered macro transitions.
8. When a user transitions between neighbouring spaces, we recommend using the advised 1800ms transition times.
9. When a user transitions between spaces that are 1 or 2 neighbours apart, we recommend inserting a mask that blurs the background to enable a smoother transition.
10. When a user navigates between spaces, the following is expected:
* If the Navigation Drawer is in its maximised state (which means the Action drawer will be in its hidden state), the only transitions to occur will be:
* That internal to the navigation drawer and,
* The cards visible in the page and,
* The background asset.
* If the Navigation Drawer is in its minimised state (which means the Action drawer will be in its hidden state), the only transitions to occur will be:
* That internal to the navigation drawer and,
* The cards visible in the page and,
* The background asset.
* If the Navigation Drawer is in its collapsed state (which may mean the Action drawer is in its visible state), the maximum number of transactions to occur will be:
* That internal to the navigation drawer and,
* That internal to the action drawer and, (If in visible state)
* The cards visible in the page and,
* The background asset.

>With the above know, here are a few more behaviours:

11. **With respect to Cards and the Background**; when a user navigates between spaces, the following behaviours are expected:
* If the user is navigating to a space '**Lower**' in the navigation time line, then:
* Cards are expected to transition upwards and out of view.
* An ease in is expected as they begin the transition.
* As they begin to transition, we recommend staggering the ease in so that the space between each card increases as the transition unfolds.
* As they transition, they are expected to fade out.
* When all cards have faded from view the reverse is expected to occur for those cards belonging to the next space.
* Backgrounds are expected to transition in the same manner as is seen on the Landing Page.
* See document '12' for details on these transition expectations.

END