Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add notification bar component. (Fixes #383) #431

Merged
merged 8 commits into from
Aug 8, 2019

Conversation

amychurchwell
Copy link
Contributor

Description

Adds the notification bar component used on /thanks and /whatsnew

  • I have documented this change in the design system.
  • I have recorded this change in CHANGELOG.md.

Issue

#383
mozilla/bedrock#7468

Testing

https://demo2--mozilla-protocol.netlify.com/patterns/molecules/notification-bar.html

  • Supports different styles:

    • Success
    • Warning
    • Error
    • Click
  • Dismiss is optional.

@amychurchwell
Copy link
Contributor Author

Should we support a standard set cookie for components that utilize a dismiss function like this in protocol? I'm not sure if this should be baked in on a per-component basis or a reusable token(?) of some kind.

@alexgibson
Copy link
Member

alexgibson commented Jul 18, 2019

My personal take here is that Protocol shouldn’t use or require setting any form of cookies in its code (that’s probably a bigger discussion that we’ve yet to have). Providing a callback when the notification is dismissed should be enough so that consumers (i.e bedrock) can then use cookies if required. It can also be useful for things like GA, which can differ from site to site.

It might be nice to have a JavaScript API that enables showing the notification itself too, vs a script that does it automatically on load? Also, tests!

@craigcook
Copy link
Member

A few drive-by opinions, not a review because I know it's WIP.

It probably shouldn't be an h1. The original one on the whatsnew page was because it's arguably the most important content on that particular page, but as a general-purpose notification the example should be a plain old p, or maybe a div or aside with a p for the content.

We should move the close button to the left in RTL.

And this is more of a discussion for the designers, but I'm not sure the "click" variant should even exist. It appears in the brand guide but I think it was just an example of "use blue for actions," it wasn't a fully thought-through component. If there's an action to be taken it shouldn't take the form of a big pseudo-button with its own little dismiss button inside it. We should get some more opinions on that.

I also think we might need a neutral notification for messages that aren't warnings, errors, or successes, just general notices. Maybe with a light gray background, or white with a blue or purple border?

@amychurchwell
Copy link
Contributor Author

@stephaniehobson If you have a moment tomorrow, would you mind taking a look at this? I've refactored the JS a bit but I'm struggling with the unit test portion (or perhaps the JS needs to be refactored more?) 😔

@amychurchwell
Copy link
Contributor Author

@alexgibson would you mind taking a look at this tomorrow? (only if you have the time, is not a p1)
The JS isn't quite right and writing unit tests has been a little blocked.

Copy link
Member

@alexgibson alexgibson left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I took a look at the tests and left a few comment / suggestions.

Happy to review this more fully when you think it's ready. Looking great!

tests/unit/protocol-notification-bar.js Outdated Show resolved Hide resolved
src/assets/js/protocol/protocol-notification-bar.js Outdated Show resolved Hide resolved
@amychurchwell
Copy link
Contributor Author

@alexgibson thanks for the feedback, Alex! I tidied things up and everything seems to be working as it should. I only have two unit tests for opening & closing a notification, I wasn't sure what else to include?
Also, in it's current form, does this component feel ready to use on whatsnew pages? (I'm not quite sure if the way I've written the init of this component requires the use of a "trigger", whereas on wnp the bar is static.)

@amychurchwell amychurchwell added Needs:Review 👋 Ready for Developer Review and removed WIP 🚧 Work In Progress labels Jul 31, 2019
Copy link
Member

@alexgibson alexgibson left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A few comments / suggestions, and might need a small refactor to work on the browsers bedrock needs to support. But overall I think this is looking teriffic, nice work!

package-lock.json Show resolved Hide resolved
src/assets/js/protocol/protocol-notification-bar.js Outdated Show resolved Hide resolved
src/assets/js/protocol/protocol-notification-bar.js Outdated Show resolved Hide resolved
src/assets/js/protocol/protocol-notification-bar.js Outdated Show resolved Hide resolved
src/assets/js/protocol/protocol-notification-bar.js Outdated Show resolved Hide resolved
src/assets/js/protocol/protocol-notification-bar.js Outdated Show resolved Hide resolved
src/assets/js/protocol/protocol-notification-bar.js Outdated Show resolved Hide resolved
@alexgibson
Copy link
Member

Styling on smaller viewports needs a little work:

image

@alexgibson
Copy link
Member

alexgibson commented Aug 1, 2019

Also, in it's current form, does this component feel ready to use on whatsnew pages? (I'm not quite sure if the way I've written the init of this component requires the use of a "trigger", whereas on wnp the bar is static.)

I think the way you've written it feels right, but we should also consider that on some pages we may not require the use of JavaScript at all. For example, this bar is already on /firefox/download/thanks/ (minus the close button). As long as we have the option to include it statically on pages without needing JavaScript, then what you're added here is a nice progressive enhancement, should we ever need it 👍

@alexgibson
Copy link
Member

Oh, the bar on /download/thanks/ also includes a link:

image

I'm guessing this should also be factored into the component design?

Copy link
Member

@alexgibson alexgibson left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Took a second pass, looking good! The styles for small screens (i.e. mobile) could use a few tweaks, but the content is resizing well for all other breakpoints 👍

src/assets/js/protocol/protocol-notification-bar.js Outdated Show resolved Hide resolved
// add title to notification
notification.appendChild(notificationTitle);
}else{
console.log('Notification banner requires title parameter.'); // eslint-disable-line no-console
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think we should leave console.log() in as production code, since it can cause errors in older browsers unless dev tools are open.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

agreed! will fix that up tomorrow.

tests/unit/protocol-notification-bar.js Show resolved Hide resolved
tests/unit/protocol-notification-bar.js Show resolved Hide resolved
src/assets/sass/protocol/components/_notification-bar.scss Outdated Show resolved Hide resolved
@amychurchwell amychurchwell added WIP 🚧 Work In Progress and removed Needs:Review 👋 Ready for Developer Review labels Aug 6, 2019
@alexgibson
Copy link
Member

One other thought: we should consider a11y when a notification is programatically opened using JS. What should happen: should focus move to the notification title when it is displayed? Should that be required, or optional? Do we need any additional ARIA information?

@amychurchwell
Copy link
Contributor Author

Tests are passing locally, I'm not sure why travis is failing. Also, I'm not entirely sure what additional ARIA information may be useful here. @alexgibson

Copy link
Member

@alexgibson alexgibson left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One suggested change on why the tests are failing, but otherwise looks great.

I'd suggest we file separate issues for followups on this component:

  • Improve a11y when a notification opens.
  • Allow a notification to contain a link (such as the one on /download/thanks/)

Does that sound about right?

expect(notification).toBeTruthy();
});

it('closes as expected', function() {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here you've created an ordered dependency on the "open" test needing to run before the "close" test, which will lead to intermittent failures. Tests run in a random order and not sequentially (hence why this passes sometimes and not at other times, like in CI).

I'd suggest treating each test as it's own distinct piece of logic. Before each test runs you should create the notification, and after each test finishes you should remove the notification. That way, tests should pass regardless of the order they are run.

Copy link
Member

@alexgibson alexgibson left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One last suggestion on tidying up after the tests, but it's a nit. This looks great, nice work!


'use strict';

beforeEach(function () {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: Suggest adding an afterEach below here to remove the button after each test also?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah! Yes! Good catch!

@amychurchwell amychurchwell removed the WIP 🚧 Work In Progress label Aug 8, 2019
@amychurchwell amychurchwell merged commit 817f3c3 into mozilla:master Aug 8, 2019
@amychurchwell amychurchwell deleted the notification-banner branch August 8, 2019 17:06
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants