task/FP-327 - Onboarding welcome messages

[jchuahtacc]

Overview:

Add alert messages to each section
Message text edited by @thbrowntacc

PR Status:

• Ready.
• Work in Progress.
• Hold.

Related Jira tickets:

• FP-327

Summary of Changes:

• Add alert message describing each section to Workbench component
• Welcome messages are permanently dismissable
• Welcome message dismissal state is saved in browser localStorage

Testing Steps:

1. See and dismiss messages in each section
2. Reload the browser to make sure they stay gone
3. Reset your saved message state in Chrome by going to Dev Tools > "Application" Tab > Storage - Local Storage - https://cep.dev in the sidebar -- delete the welcomeMessages key

UI Photos:

Notes:

[codecov]

Codecov Report

Merging #191 into master will increase coverage by 4.74%.
The diff coverage is 0.00%.

@@            Coverage Diff             @@
##           master     #191      +/-   ##
==========================================
+ Coverage   58.33%   63.08%   +4.74%     
==========================================
  Files         251      109     -142     
  Lines        8585     2847    -5738     
  Branches     1269      648     -621     
==========================================
- Hits         5008     1796    -3212     
+ Misses       3358      971    -2387     
+ Partials      219       80     -139     

Flag	Coverage Δ
#javascript	63.08% <0.00%> (-0.23%)	⬇️
#unittests	?

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
client/src/components/Workbench/Workbench.js	0.00% <0.00%> (ø)
server/portal/apps/signals/signals.py
server/portal/libs/agave/serializers.py
server/portal/apps/workbench/views.py
server/portal/libs/agave/models/base.py
...ps/workspace/migrations/0002_auto_20200218_2115.py
server/portal/apps/onboarding/api/webhook.py
.../portal/apps/onboarding/migrations/0001_initial.py
server/portal/apps/users/views.py
server/portal/apps/workbench/api/views.py
... and 133 more

[wesleyboar]

Please use the info color/style. It's the gray one.

[jchuahtacc]

Please use the info color/style. It's the gray one.

I am. Is this wrong?

            <Alert
              isOpen={welcomeMessages.dashboard}
              toggle={() => onDismissWelcome('dashboard')}
              color="info"
              className="welcomeMessage"
            >

[rstijerina]

Please use the info color/style. It's the gray one.

I am. Is this wrong?

            <Alert
              isOpen={welcomeMessages.dashboard}
              toggle={() => onDismissWelcome('dashboard')}
              color="info"
              className="welcomeMessage"
            >

@tacc-wbomar Referring to the _common Message?
Or the bootstrap alert-secondary?

[nathanfranklin]

This is great. 👍

[nathanfranklin]

Local storage is good but do you think people will get annoyed seeing it again when they use a different computer?

[wesleyboar]

@rstijerina @jchuahtacc
Whoops. My bad. Yes, I meant "secondary". So, color="secondary".

P.S. For the UI-curious, Reactstrap should not have chosen color as the property name. Alerts/messages/notifications/whatever types can be distinguished without color.

[wesleyboar]

Local storage is good but do you think people will get annoyed seeing it again when they use a different computer?

I vote "They'll live". This is a temp solution overall.

If feasible, then tying the state to user account is "better", but I don't know how to do (thus critique) that, and I assumed Joon Ye found it quicker to use local storage than step into what might be an active cobweb of user data (again, I dunno).

[jchuahtacc]

Local storage is good but do you think people will get annoyed seeing it again when they use a different computer?

I vote "They'll live". This is a temp solution overall.

If feasible, then tying the state to user account is "better", but I don't know how to do (thus critique) that, and I assumed Joon Ye found it quicker to use local storage than step into what might be an active cobweb of user data (again, I dunno).

Yeah this is temporary. Ideally we'd tie this into the user profile in django and fold these sagas/reducers together, but in the amount of time that i had this was the most attainable.

[rstijerina]

Rad.

Note: Do we also want a welcome message for "Manage Account" and the unauthed tickets view?

[wesleyboar]

Hoowah!

[wesleyboar]

Rad.

Note: Do we also want a welcome message for "Manage Account" and the unauthed tickets view?

I've asked Maytal directly. These messages were her want.

https://tacc-team.slack.com/archives/GQW4Q8HLG/p1598031117004400

[wesleyboar]

Yes, let's add one for (logged out) "Add Ticket" form—if feasible in the time available.

Message Proposal:

This page allows you to submit a help request via an RT Ticket.

Why so short (no info about what happens next)?:

• The form message afterward _tells the user to expect contact.
• The user will get an e-mail (if they didn't lie about e-mail address).
• All website tickets work like this... We are allowed to assume some user knowledge.

[wesleyboar]

And, if Maytal doesn't answer in time (y'all decide what "in time" means), then forgo or add message for Manage Account.

Message Proposal:

This page allows you to A, B, and C.

I don't give much thought to this, because Design didn't want these to begin with.

[rstijerina]

And, if Maytal doesn't answer in time (y'all decide what "in time" means), then forgo or add message for Manage Account.

Message Proposal:

This page allows you to A, B, and C.

I don't give much thought to this, because Design didn't want these to begin with.

For time's sake, let's follow up with these in a separate task.

https://jira.tacc.utexas.edu/browse/FP-652