Skip to content
This repository has been archived by the owner on Apr 16, 2021. It is now read-only.

Global Nav & Role Switcher #2

Closed
colbycheeze opened this issue Aug 26, 2016 · 0 comments
Closed

Global Nav & Role Switcher #2

colbycheeze opened this issue Aug 26, 2016 · 0 comments
Labels
Milestone

Comments

@colbycheeze
Copy link
Contributor

colbycheeze commented Aug 26, 2016

As a user, I can switch roles and create new managers in a global header.

@kingtraceyj commented on Tue Aug 02 2016

Complete UX and Visual for Global navigation & role switching

  • Logo
  • Persistent Git Hub link
  • Role Switcher
  • Clear/Restart Session
  • Explore how to find session link

Story #12


@Austinauth commented on Tue Aug 09 2016

After working with Tracey on multiple variations of how the Global Header, Role Switcher, & Demo Settings might manifest together, we were able to come up with a solution we believe works for the Logistic Wizard demo.

Note: Wires are low fidelity, visual fidelity will be improved in future iterations.

Global Header - Default

v4-global nav

Notes

  1. As originally proposed the Global Header expands horizontally across the viewport. The Global header is home to items that are persistent across the demo, regardless of state.
  2. Logo/Logotype occupies the top left side of the Global Header
  3. The right side of the Global Header includes 3 items:
    • The Role/Persona Switcher (User icon)
    • A persistent link to the GitHub Source Code (Github Icon)
    • A persistent option to invoke the Demo Settings

Global Header - Role Switcher

v4-global nav expanded

Notes

  1. By clicking the the user icon, the user is able to: see the current selected persona, switch roles to a retail manager and add a new retail manager (maximum of 5). In the future, user notifications might manifest here as well.
  2. Notice in this proposed version of the Global Header we have separated Role Switching & Demo Settings. We separated these two items because the action of switching roles is not exclusive to someone giving the demo. If we were to remove demo settings entirely, role switching would still be necessary.
  3. The Github source code link and the Demo Settings are grouped together because they require the user to exit the context of the demo. Clicking the Github icon takes the user to the Github source code & clicking demo settings invokes a menu containing certain scenario triggers (weather, etc...)

Open Questions

  • @jakepeyser In order for us to design the Demo Settings panel we need a concrete script that calls out specific scenario triggers (weather, notifications, etc...).
  • Will the Supply Chain Manager have a location as well?
  • Do should we surface the actual names of the Supply Chain Manager & Retail Managers?

@colbycheeze commented on Tue Aug 09 2016

Yea I like holding context of role in the app bar. It could be easy to show the user of the app which role they are in (SCM, or RSM) by changing the color of the app bar similar to google inbox, IE:

Inbox:
image

Done:
image


@jakepeyser commented on Tue Aug 09 2016

Love it, I think that works perfectly.

In order for us to design the Demo Settings panel we need a concrete script that calls out specific scenario triggers (weather, notifications, etc...)

The scripts will be located here, it is next on my list of non-dev work items. This also begs the question on if it needs to be a "settings" menu or can just be another dropdown button to trigger specific events.

Will the Supply Chain Manager have a location as well?

No, their role is global for the sake of the demo

Should we surface the actual names of the Supply Chain Manager & Retail Managers?

Let's do it like you designed for now (role w/ location subtext). If we feel it's necessary, we can build in display of real names later. Right now they are like name: Retail Store Manager (fTC72mfeR8), email: ruth.fTC72mfeR8@acme.com, which is not very user friendly.


@Austinauth commented on Wed Aug 10 2016

@jakepeyser

The scripts will be located here, it is next on my list of non-dev work items. This also begs the question on if it needs to be a "settings" menu or can just be another dropdown button to trigger specific events.

I think you're right. As long as the scenario triggers/settings aren't super complicated, they should probably be in a dropdown in the same vein as the Role Switcher.


@kingtraceyj commented on Fri Aug 12 2016

global nav and role switcher comps

@LRRoberts0122 do you need redlines or do you want to start with this and then we can adjust later?

global navigation lw

Type:
In the header I'm using Libre Franklin - .875em/14px Bold #FFFFFF

Here's a quick type reference:
lw type


@LRRoberts0122 commented on Fri Aug 12 2016

@kingtraceyj No need for red lines. =) Will start working on the updates! =)

Also @colbycheeze I can update the typography thing in Storybook if you want? Or did you want to keep that the same? Or???


@colbycheeze commented on Fri Aug 12 2016

Looks like you have 6 heading types @kingtraceyj so may as well have H1 be the 4rem size and then if most titles use h3 (which then would be the 2.5 rem type), that's likely fine.


@kingtraceyj commented on Fri Aug 12 2016

sure. that sounds good. i probably won't use them but lets do it!


@colbycheeze commented on Fri Aug 12 2016

Also when it comes to "red lines" what you can do is reference the type size or style you have defined (define more if you have others which are reusable)

IE: button, subheading, thin, light which is how we will apply styles to things (as opposed to giving us the specific font weights and sizes every time)

So for now we have a few defined which we can update to use w/e reusable styles you are planning to have

em, .em { font-style: italic; }
strong, .strong { font-weight: 600; }
small, .small { font-size: 75% }
.light { font-weight: 300; }
.thin { font-weight: 200; }

So based on this typography I'd add something like

.subheading {
  font-size: $base-font-size * 0.75rem;
  letter-spacing: 0.5rem;
}

@LRRoberts0122 commented on Mon Aug 15 2016

Okay, so I've been having an issue incorporating fonts for some reason. They work externally, but I think something with React or whatever is causing conflicts. I'm not 100% sure, so I'm just working around the typography issue for now, and I'll get back to it at some point. =) But I just wanted to let you guys know! @kingtraceyj


@kingtraceyj commented on Wed Aug 17 2016

@LRRoberts0122
Header hover state: #B7DEE4

image


@kingtraceyj commented on Thu Aug 18 2016

@LRRoberts0122
Here's the updated hover for the role switcher. I made it a little more clear on whats selected than before with adding in a background color.

image

@Scribblets Scribblets self-assigned this Aug 29, 2016
@colbycheeze colbycheeze added this to the 9/8 - Sprint milestone Aug 29, 2016
colbycheeze added a commit that referenced this issue Sep 10, 2016
Addresses story #2 and task #5

The dashboard page currently doesn't call the getAdminData. I'll hook that up next to a real lifecycle or action.

Here is what everything looks like:
![screen recording 2016-09-08 at 04 48 pm](https://cloud.githubusercontent.com/assets/8884298/18371523/8d6ef1f0-75fa-11e6-812d-cfc0ad53b272.gif)

## Other changes in this PR
 - Tests now inject the tap event plugin, so that MUI components dont spit out errors
 - Test config removes extra quotes from stringified json strings.

### Demo Data Flow
 - demo module now handles fetching data associated with a demo session and logs in to the supplychainmanager automatically
 - Dashboard component no longer manages data fetching on route loading, instead it is handled properly within the route itself.
 - CreateDemo saga now simply creates a demo and changes the route (In a future task, I want to have it manage adding one retail manager automatically so that demos always begin with that role as a default)

### Mock API / stronger saga tests
 - Sagas tests now make use of state changes from actually calling the reducer, which requires proper data passed in....meaning I needed a way to mock the API calls. I made a mock file that gives back faker data in the shape we currently expect from the API.

What this allows, is for saga tests to properly fail if things change in the way data is passed around and modified (whereas before, we just generated made up objects and so it worked in test, but not in the running app)

The Saga tests look a bit more confusing, but are WAY more solid now. Writing and testing complex async actions has never been fun, but this makes them accurate and stable, which is the real win.
@l2fprod l2fprod closed this as completed Sep 20, 2016
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

3 participants