1031547 - Create a notification style that can be applied to all templates across MDN

Status: RESOLVED FIXED

(developer.mozilla.org Graveyard :: Design, defect)

Description

[Holly Habstritt Gaal [:Habber]]

Attachment: 19June2014_MDN_signin.pdf

We don't currently have a single notification style that can be applied across all pages on MDN. This style should be displayed inline and be versatile so it can work across templates. (e.g. MDN Homepage, all docs level pages) 

2 sample use cases for this notification style are as follows:

1. User wishes to sign in with Github. They attempt to do so with an unverified email address (we only accept a verified email address). Upon returning to MDN, we need to notify the user that they must verify this email address before authentication can happen and sign-in is authorized on MDN. Notification needs to contain Message + link to send user back to Github to verify.

2. User wishes to sign in with Github. Authentication is successful, but Github email does not match any existing MDN profile. We therefore assume this is a new user, but want to give them the chance to merge with an existing MDN profile. This situation will happen if a user's MDN account email does not match their Github email. Notification style needs to contain Message + option to link to MDN account + option to dismiss notification.
For example: http://cl.ly/image/422I1H05130r
 
See also: attached PDF for background on how the Github sign-in flow depends on this notification style.

Comment 1

[Stephanie Hobson [:shobson]]

Do we want this notification style to also handle the page saving notifications (when a user chooses to "save and keep editing")?

Things to consider:
- notification may need option to be dismissed by user
- notification may need option to self dismiss after a period of time.

Comment 2

[Eric Shepherd [:sheppy]]

These may also need to be able to offer a couple of buttons. For instance, on receiving an in-site message, you may need "Read message" (if the message is too big for the box) and "Reply" buttons, for example.

Comment 3

[Stephanie Hobson [:shobson]]

- planned: OAuth also needs notification styles
- planned: edit profile
- planned: site messaging
- planned: received badges? - include an image

Comment 4

[Stephanie Hobson [:shobson]]

Put together an outline of what this might look like: https://docs.google.com/a/mozilla.com/document/d/1Jz5zu4UHWiui2_tB45V5YN49vesrZKB7a1FKIzMdiZM/edit#

:davidwalsh and :openjck promised me feedback and then we'll refine again.

Comment 5

[David Walsh :davidwalsh]

I love it!  I already have ideas for how to code this up!  :D

Comment 6

[John Karahalis [:openjck]]

This is great! I can tell you really thought this through, Stephanie.

Another dismiss option comes to mind: not dismissable on the current page. The notification would appear on screen until the user navigates away from the current page, and it would not appear if they return to that page (unless the notification is triggered again). It sounds like this is the style of notification we want to use for the GitHub/Persona association feature.

As for notifications that should never go away, on any page, might it make sense to keep soapbox? For notifications that persist from page to page, I think soapbox would be much less distracting than a notification that obscures part of the screen.

Again, nice work! I suspect feedback will keep coming in as we implement the notifications. If it does, we can make adjustments as we go.

Comment 7

[Stephanie Hobson [:shobson]]

I think I was assuming that any notification that cannot be dismissed on the current page would be treated as "not dismissible" and the server would either write them onto the page or not when the user navigated  to the page. Are you envisioning a situation where the user opens a page in another window and does something that should result in the notification being dismissed on the first page?

Yes, I think site wide notifications should stay at the top and not obscure content (the region I identified as 1 in the document) but I think it would also be nice to be able to dismiss soapbox which is why I wanted to tie soapbox into this system.

Comment 8

[John Karahalis [:openjck]]

(In reply to Stephanie Hobson [:shobson] from comment #7)
> I think I was assuming that any notification that cannot be dismissed on the
> current page would be treated as "not dismissible" and the server would
> either write them onto the page or not when the user navigated  to the page.
> Are you envisioning a situation where the user opens a page in another
> window and does something that should result in the notification being
> dismissed on the first page?

Great! That's functionally equivalent to what my idea of singe-page not-dismissable notifications. I think I was just confused.

> Yes, I think site wide notifications should stay at the top and not obscure
> content (the region I identified as 1 in the document) but I think it would
> also be nice to be able to dismiss soapbox which is why I wanted to tie
> soapbox into this system.

Also my confusion. Yeah! If you mean that soapbox should have the same style, but be dismissable and be supported by this notification system, then we agree completely!

Comment 9

[Jannis Leidel [:jezdez]]

I added this blocking as it turns out the email address management interface and other views of allauth use standard Django messages to show success and errors. See https://docs.djangoproject.com/en/1.4/ref/contrib/messages/#displaying-messages for how to show them.