Foundation.mozilla.org: "Join us" Button Interaction

[taisdesouzalessa]

• For pages in which we have a specific area for "join us" (like the home page) we will have a smooth scrolling interaction.
  Example:
  

• For pages that only have the button in the top nav, here is the suggested interaction:
  V1: http://www.taislessa.com/mozilla/joinus/prototype-joinus-v1/index.html
  V2: http://www.taislessa.com/mozilla/joinus/prototype-joinus-v2/index.html

I feel V2 is stronger (Luke and Sabrina contributed to that option and we all agree it seems a better one). What do you think? @xmatthewx

@gvn do you think this is feasible to implement?

[gvn]

I think it's do-able, but it might not be the smoothest animation since you have to move the entire page, but we can try it out. I'd speed up the animation a bit and put put some easing on it.

[xmatthewx]

I prefer v2 as well.

If animation is sub-optimal, form could come down over the page instead of moving it. That works for v2, but not v1.

[taisdesouzalessa]

Sure, speed up and easing sounds good. Let us know how it goes, @gvn. If it doesn't work, we definitely should go for Matthew's recommendation. I can do a mockup later on on that option, just let me know once you do the tests.

[xmatthewx]

Let's add UI comp for this component @taisdesouzalessa

[taisdesouzalessa]

I am sending the Sketch file to your e-mail @gvn.

Background color, illustration and texture may change.

[taisdesouzalessa]

We decided to eliminate the "smooth scrolling" of the pages that have the "Join Our Ranks" component embedded. The reason being is that smooth scrolling may not be the best solution when this component is close to the footer.

So we are going with the V2 interaction for all the pages. This solution comes with a small issue in one specific scenario: when user is scrolling a page that have the "Join us" component embedded (like the home page) and then they decide to join using the button on the top they would see a duplicate of the form, which can look like a mistake. After trying some solutions I think the best and most simple one is to just change the background color of the top component so it looks more intentional and not like an error of duplicated form.

I am not a huge fan of this dark green, but the color should be darker to show the form is in a layer behind the page. Will discuss with Sabrina options based on the theme color we have for the whole site.

This is a test on how the color works in the scenario described above - click on the top "join us" button to see it in action:
http://www.taislessa.com/mozilla/joinus/prototype-joinus-v3/index.html

Let me know your thoughts @xmatthewx @gvn @sabrinang

[xmatthewx]

I like the design. Darker seems like the right option. I don't mind the green but I will leave that to you and Sabrina.

Question: Why don't we scroll down? Can we just let the browser jump down to an anchor tag? Is that too old fashioned? Is this new-fangled smooth scrolling important enough to warrant the other compromises?

[taisdesouzalessa]

@xmatthewx answering your question: if we scroll down on this page, we should use the same behavior to other pages that also have the embedded component. The problem happens when the component is close to the bottom:

It gets confusing because the top of the component doesn't touch the top of the browser window and @sabrinang and I thought it could disorient users. So we opted for eliminating the smooth scrolling. Let us know your perspective on that.

cc: @sabrinang

[gvn]

I don't think we should vary the behavior of the Join Us button in the header.

Introducing varied behavior for the same UI between pages is jarring and could introduce cognitive accessibility issues. I also think the jump/scroll on mobile could feel weird and disconnected.

[taisdesouzalessa]

Yeah, I am concerned about the smooth scrolling in mobile as well...I didn't know it could be an accessibility issue - good point Gavin.

@xmatthewx we can discuss this issue in our stand tomorrow - for now I am feeling that the solution we have (consistent behavior) is the best way to go so users know what to expect when they click that button - even if the form repeats.

I did the test with the animation as you suggested today and I think it is a great solution for the problem related to the top of the form. However this solution doesn't address the consistency problem across pages. So I am leaning towards keeping it as we have now (even with duplicated form) instead of scrolling. What do you think?

[xmatthewx]

Introducing varied behavior for the same UI between pages is jarring and could introduce cognitive accessibility issues. I also think the jump/scroll on mobile could feel weird and disconnected.

Join us is not an action users will repeat. We need solid UX, not uniform UX for this particular interaction. We have other concerns that outweigh this. For example, seeing two almost identical forms could signal that something is broken, prompting a user to wonder if something is broken.

[xmatthewx]

To move forward, I recommend we pick one of two options:

• A) We build and test @taisdesouzalessa's design, design based on her research and prototypes. Also: we halt this if implementation becomes complicated.
• B) We abandon ship and create a simple modal. We have a modal pattern we're using for primary nav. We should be able to repeat that without too much difficulty. We can do this for all pages, regardless of whether the page has a form on it, since the modal will block the view of it.

@taisdesouzalessa – think on it. Let us know what you recommend.

[taisdesouzalessa]

Hey @xmatthewx and @gvn - after some careful thinking and brainstorming some options with Natalie and Sabrina I recommend we go with the modal option.

I don't want to over complicate this interaction and even though I think the sliding top form is a pretty cool animation I think it needs a more careful consideration - maybe for V2. The majority of the benchmarks are either modals or a separate screen (which I don't think it is a good idea for this case).

The modal helps the user to focus only on the form once they click on the button (eliminate distractions) and also we don't have the problem of duplicated forms that could confuse users. It also works well on mobile. It addresses our main concerns.

We also discussed the possibility to have a narrow version of the form on the bottom of every page, so we try to grab the attention of the users that are really interested on the content (assuming they scrolled to the end of the page). Would love to test this option on release and we see what the users say. We can tweak based on the results.

Here is a prototype for this version:
https://invis.io/ZJ9YTAGEA#/219299053_P-Home_Page_-_Hero_Opt_3

We could tweak the animation of the modal to make it more friendly (we can do some fun subtle animations). Let me know what you think.

cc: @sabrinang

[gvn]

Can we skip the modal and leave it as is on staging?

https://network.mofostaging.net

[taisdesouzalessa]

@xmatthewx let us know about the final decision on this issue - as soon as we have one I'll add it to the prototype.

[gvn]

@xmatthewx Marking blocked until a decision is made.

[taisdesouzalessa]

@xmatthewx - remember you gave an idea of making the screen darker when the user clicks on "Join Us"? - I think your insight may be the solution for the problem we are having here. I finally found a benchmark...yay!

Here it is
https://drive.google.com/a/mozilla.com/file/d/0B3b1KWRwjxtoNVRnNGZENHJLU1U/view?usp=sharing

So a solution would be:
To keep the interaction as is but with some enhancements:

• add a darker layer on top of the whole page (except on the form triggered by the user) - in the example from Apple the dark layer is very subtle, I would recommend a bit darker. This solve the problem of "duplicated" form since the focus is in the bright layer - top layer.
• I really feel the window should close automatically if user starts scrolling. The scroll shows an intent to stop seeing the information.

Let me know what you all think :).

[xmatthewx]

Let's freeze this issue until we have a chance to chat.

One big slice of feedback we've gotten: people want to know what it means to join, what it means to be a member. We're going to need a bit more space to spell this out.

[xmatthewx]

We decided to use a standalone join page (in addition to the inline homepage form). We will keep this module for site alerts (e.g. welcome to member preview, or fundraising). @gvn please file a task to adjust existing module as you see fit. Closing this ticket.

[gvn]

Did that here: https://github.com/mozilla/network/issues/96