It should be easier to find EE specific page and EE features pages

@amara do you feel it's a problem too?

@regisF do we have any data to validate this is a problem?

I agree that site navigation is not ideal across the board. Focusing on EE, there is also nothing in the header or on the homepage that let's you know we have an enterprise product.

That said, from the header you can get to the EE page in two clicks: click Products then Learn more in the pricing table then when on the EE page you can click the feature landing page links.

I suggest we establish a baseline then we can test headers or homepage variants to see if we can improve the number of people to get to the standalone EE page.

@amara yes, Google Analytics.

0.25% of the traffic in February for https://about.gitlab.com/gitlab-ee/

The dedicated feature pages (for instance, for Time tracking) is lower than 0.08%.

It's safe to say that no one looks at those pages.

Thanks! I was hoping we had more info on how many clicks its taking people to get to the EE page. My only issue with traffic as the sole indicator is that almost all of our pages outside of navigation have less than 1% of our traffic.

That said, if we want to actively push people into an EE flow, I suggest the following:

A/B test a new nav that has products as a drop down where people can go to relevant landing pages
A/B test the homepage to call out our enterprise product

Let me know if you had other suggestions in mind.

@amara these are good ideas. I just thought of 1) personally, and 2) is excellent.

Thanks for this discussion.

Next step would be: it's up to you to prioritize this change amongst the list of the other changes you would like to do.

You should be able to test 1 with no involvement from me.

We can test that and see if it makes a difference. I would prefer to keep the homepage product agnostic so #1 (closed) is a better place to start. In addition to just being better about linking the EE standalone page across the site. For example, do we link to this page from our blog posts, namely the release post? If not, this would be a good thing to correct.

@amara

if we want to actively push people into an EE flow

Isn't it what we want to achieve? Or is it not the primary goal of the website (genuine question)?

@regisF I would love to push EE more heavily! I should clarify that by "actively push people to EE" I mean that our site flow leads people to EE and then a user has to downgrade from there into our other products. I don't think that we have made this decision yet though.

@regisF should we have a quick convo on what we want to test with the Nav?

https://gitlab.com/gitlab-com/marketing/issues/878

Suggested new nav:

Make the nav a drop down on click. Like https://www.atlassian.com/

Download (Dropdown to download EE or CE (this will require an update to the download page)
Features
Products (Dropdown to EE, CE, .com, GitLab Hosted, Pricing, Product Direction)
Community
Explore
Docs
Resources (Blog, Customer Stories, Events, Additional Resources)
Contact

@erica any suggestions on how best to organize the resource tab that we'll create for the new dropdown nav? See above for my current suggestion.

@regisF can you confirm that this idea of a dropdown on click is possible?

@amara I believe it's possible. I don't see how we can do it differently. We have to take care of making a graceful solution on mobile as well, to make sure it also works fine there.

Good to hear, @regisF! Let's wait for @erica to comment on how best to manage the resources tab and then we can get started on this.

Will you need design support or is this something front end can implement as just a dropdown on click? It does not have to be the full menu like the Atlassian example I shared.

@amara @regisF I think we should include events in that drop down as well. Is the plan to make the dropdown as robust as the Atlassian example? Or, will it be a simpler list-style drop down?

Resources (direct link to about.gitlab.com/resources)

Blog (about.gitlab.com/blog)
Events (about.gitlab.com/events)
Customer stories (about.gitlab.com/resources/customer-stories) - doesn't exist yet
Guides (about.gitlab.com/resources/guides) - doesn't exist yet.

Because the customer stories and guides links don't exist yet (and I'm not sure when exactly the will) should we just list a "Resources Library" as a third option that also goes directly to about.gitlab.com/resources?

Also, what is the time frame for this? The resources page isn't ready to be customer-facing just yet but if I know the scope of this than perhaps I can work with luke to get it to a state that it will be ready on time?

@amara typically for this, I believe we need design first.

@erica Events seems more like community thing than a "resource."

The resource page isnt pretty but its functional and thats a start! I believe Tim was okay with include it in the Nav as is and he said after we see what people engage with then we can design the page.

What's the ETA on adding a customer stories section to the resource page? We still need to design this before we can launch so there is some time. There is already this page fed by posts that use the customer stories category. But it would be better to have these on the resources pages where site visitors can also find other helpful material.

mentioned in issue marketing#910

@regisF I've created a design issue for this and assigned it to @luke. He will share an ETA on design in that issue, linked above.

@amara the reason I'd like the events page to be listed under resources is because I think it's a good place to list upcoming webcasts, whereas on-demand ones can live on the resources page. Is it a problem to have it linked in 2 places? Or, will the community tab also have a drop down listing it? I just wonder if it's completely intuitive to someone who is checking us out for our enterprise products/solutions to navigate to the community section.

ETA on getting customer stories onto the resources page is EOD tomorrow. However, again, they will just be listed but perhaps instead of linking to the about.gitlab.com/resources/customer-stories we can link to a header like about.gitlab.com/resources/#customer-stories. I'm going to talk with Jose today because I think we can repurpose the design from the events page for now to at least make it so you can search by topic or content type. Because we already have the template for that we might be able to get that up pretty quickly.

Is the plan to take down the current customer stories page once everything is migrated?

@erica Thanks for explaining! We can list it in Resources then. There will not be a drop down for community as of right now since I haven't heard concerns about traffic flow to those pages.

As for the customer stories link, I think about.gitlab.com/resources/#customer-stories version is best since we use anchored headings across the rest of the site.

Finally, about migrating the old customer stories, I don't think we need to. The categories pages RARELy get visited bc they are impossible to find. We don't surface our blog categories anywhere on the site. If we decide to change that then we can consider where customer stories should live but for now the resources page is the best option.

I added the baseline metrics to the issue description so we have a standard of comparison after we roll out the new nev.

The challenge with this is that we don't know how people flow through our site. We are guessing the nav is key (and it likely is) but we still may need to consider changes to the homepage and more updates to the Nav to boost site traffic to the EE page. This will be a good first test though.

mixpanel or kissmetrics will help give us visibility into the common paths visitors take on our site and the common funnels a trial or contact us or a purchase take on our site.

@ChadMalchow I agree. I'll follow up with the lead gen team to see what tools we are using today for site metrics.

@luke can you please work share the design files from your mock up in this issue so @regisF can assign it to a frontend developer?

@amara @regisF I added the design mockup to the issue description. Once we have a frontend developer assigned, I'll sync with them on how I envisioned the hover, click states, etc. working.

@luke thanks!

@jschatz1 can we have someone to work on this new menu for about.gitlab.com? Thanks!

@amara we'll also need in the issue description the content of the new menu, clearly outlined, so it's easier for devs to know what to put in it.

@regisF @samrose3 do you have time for this?

@regisF the issue description is updated.

I'm going to link to the EE trial page vs. the EE download page.

assigned to @samrose3

removed assignee

That's odd!! I guess me updating the issue description removed your assignee @samrose3 I'll reassign to you now.

assigned to @samrose3

changed milestone to %9.1

@samrose3 here's what I'm envisioning for the interaction / reveal of the dropdown menus (happy to jump on a call if you need more clarification):

**1.** static state

**2.** hover state for all nav items (which is currently the clicked state on the live site).

**3.** on click — (a) the purple bar "grows" from the center to the full width of the dropdown menu (220px) and (b) the dropdown menu drops / animates down from the purple bar.

**4.** hover / click state of dropdown menu item

~~**5.** active / clicked state for the nav item once navigated to a page within that bucket (i.e. Products)

~~

Reading back through this flow the last step, number five, might not be entirely necessary. ~~But I like that it gives context as to which section of the site you are on.~~ Any thoughts on this @amara @regisF?

I'm not sure we need 5 since I imagine that if you are looking at the Nav again you are looking to go somewhere else on the site so your current position isn't really that important.

Thanks for pushing me over the fence @amara — updated my comment to disregard step 5.

@luke thank you! This is perfect, I'll give you a shout if I have any questions

@samrose3 you can checkout this nifty little preview to help get accurate colors, font sizes, spacing, etc.

created branch 1123-it-should-be-easier-to-find-ee-specific-page-and-ee-features-pages

mentioned in merge request !5450 (merged)

closed via merge request !5450 (merged)

mentioned in commit 4f30994a

reopened

Reopening this issue.

There is no visual indicator that a certain nav menu item is a dropdown. This is a confusing experience for a user. Can we add a visual indicator, something like a small downward pointing arrow?

See the Slack thread here: https://gitlab.slack.com/archives/C0259241C/p1490980297227093

@luke and @samrose3 The simple solution is to add an arrow like this one on

Download
Products
Resources

created branch 1123-it-should-be-easier-to-find-ee-specific-page-and-ee-features-pages

Also, @luke @amara

can we investigate the possibility to have the menu appearing on hover? I'm really worried about the experience/discoverability. Can we test this somehow @sarahod ?
can we put the blog outside a submenu somehow? I know we won't have much space, but is there something we could change somehow?

Thanks a lot.

Btw I love the fact that we push EE much more now with this new header, good job team.

For reference, only about 1.45% of our total traffic to the site ever hits about.gitlab.com/blog/. It's between 400 and 1,800 users a day. I don't know that it's 100% vital to have Blog as its own item on the navigation bar if there's not a lot of space. If we can make it work in a good way, then sure, let's do it!

@regisF the question on hover states is best answered by the UX team. I'd be happy with a hover as it makes it even more obvious than having to click.

As for the blog, my thought is that we should actually try to shrink the Nav even more to define a flow through the site. But I did not move forward with that as this is meant to be a test to see if we can drive more traffic to EE. Also, having the blog under resources hopefully will increase discovery of our gated materials so we have more opportunities to learn about the audience that visits our site.

Seems a bit packed. Anything we could remove, move, reword?

I am also in favor of shrinking the nav, as @mitchellwright stated above with stats on /blog I would assume most users arrive there by clicking on a particular blog post we promote.

@samrose3 hmm...could we try a super small fa-angle-down?

mentioned in issue #1252 (closed)

~~Seems a bit packed. Anything we could remove, move, reword?~~

~~@samrose3 see https://gitlab.com/gitlab-com/www-gitlab-com/issues/1252~~

mentioned in merge request !5523 (merged)

closed via merge request !5523 (merged)

mentioned in commit virtuacreative/www-gitlab-com@2bada048

I don't really understand the thinking that brought this change.

Are we measuring the impact, what is the goal?

Other problems:

For one, I'd highly recommend against using dropdowns. Especially since there is a delay in opening them, find the page your need becomes an exercise. Dropdowns are never nice on mobile.
Products -> CE leads to the download page. That is very confusing to a new user.
There is no clear top-level comparison of products. We now rely on the user clicking through all these pages until they find pricing
Pricing is not top level, even though it's top of funnel. Are we measuring the impact of this?
There are now 2 links to download CE (products -> CE and download -> CE)
Why not make a single download page where you have CE and EE next to each other?
Community is a top-level link, but links to pages also found under resources
Explore is super strange for an outside visitor: You're dropped in an external application. What would a user expect when they click 'Explore'? I don't think they'd expect to be viewing some random repositories.
Why is Contact top level, yet Blog (a very important resource for our release posts) isn't? The fact that it receives less visitors doesn't devalue its importance.

This change has been designed with a mindset of someone that knows what is on the site, but that is not what the website is for. You have to account for the searching user, the one that just goes over the site. Now they are required to scour through links, instead of being given a limited set of obvious choices, from which they'll learn and funnel to the right place.

Top level for docs is good.

You could have it much simpler, without dropdown

Download: Download page offers you to try EE
Products: Top level page showing what the different products are roughly, leading to explore each
Pricing
Blog
Docs (icon for external link)
Sign in / Sign up

At the moment, it takes too many steps for users to discover the page that describes EE . It's worse to find specific EE feature page (like time tracking).

You can even have an item there "Enterprise Edition" that leads directly to the EE page. If that's the goal, why didn't we try that and iterate on that?

I see some comparisons to Atlassians site, that has a dropdown, but it's a world of difference:

They describe the products. It acts like a separate page. Our visitors have no idea what the products are and the click targets are small. A naive visitor won't have an idea what the difference is between GitLab Hosted and .com.

This is a UX heavy discussion and at several times the UX team is referenced, but I see no activity of them here, yet many decisions were made without their consultation.

Another simple example: the contrast in the dropdowns is extremely low. We have many people with bad eyesight using or considering using GitLab (including myself). This made our website less usable for them.

The plan forward should involve input from the UX team and should focus on measurable results. Together that could bring us improvement, but this seems like a major step back.

reopened

@JobV thanks for the feedback.

The goal was to test if a dropdown would improve discovery of the EE webpage. Adding a dropdown was viewed as the smallest iteration. You can see in the issue description what the current pageviews were over a 2 month period. I suggested we run a test to see if we can improve traffic to our EE webpage and the EE download page. Since this was just merged it's too soon to say what the result has been.
The Nav that you suggested was very similar to what we had before and the EE downloads page got very little traffic because the first read on the page is to "Download Community Edition" with a very small mention of EE in the links on the page. Separating Downloads into two links was an attempt to make the ability to download CE or EE clear.
You make some good points about UX and I agree that should become a formal part of the website improvement process
Some of the points you raised were not a result of this edit (i.e. Community, Explore, and Contact have been top level nav items for several months.) We can discuss changing that but it should be in a separate issue as changing the entire Nav was not the goal of this particular issue.
On the blog, most traffic to the blog is driven by direct links to our blog posts vs. some coming to our homepage and then navigating to our blog. (this is evidenced by Mitchell's point that from the homepage the blog was clicked on less than 2% of the time.) Moving the blog under resources should not have any impact on the release posts and our hope is that we can improve traffic to the resources and events pages so that we can start to get information on site visitors.

@JobV I personally believe it is too soon to call it a major step back. We need to measure the impact against our stated goal of improving discovery and then iterate. I suggest we do following:

Add contrast to the existing dropdown menus
Start work on the second iteration of the dropdown that adds more explanation (I would've liked to wait and see what the impact on traffic is before doing this but we do not believe that our product names offer enough explicit differentiation then we should add descriptions soon to ensure that discovery is not hindered by users not understanding what the product pages are)
Open another issue to discuss what should be in the Nav

@amara thanks, the next steps make sense.

I think on the first-line improvements, we should also remove the delay between click and opening the dropdown. It's a cool effect, but it's not a useful one.

A two-month period for testing seems too long to me, considering the high amount of pageviews we get. I'd say a week at max. We should not just measure views, but also look at how long people stay on a page. We might get more visits because the link to a page is more obvious, but if all those people immediately switch pages because it's not the resources they're looking for, the change was for the worse.

Some of the points you raised were not a result of this edit (i.e. Community, Explore, and Contact have been top level nav items for several months.) We can discuss changing that but it should be in a separate issue as changing the entire Nav was not the goal of this particular issue.

In this case I'm glad my attention was brought to the nav ;-)

@samrose3 can you make the changes we've discussed as short term wins? (decrease / remove animation and increase constrast).

I agree two months is too long. It's more so about getting a reasonable sample size which we could get in 1 week. Let's see! And yes, we will look at time on site and bounce rate as well.

Let's look at the data after a week. If it is not significantly better I propose we'll revert the change due to the problems @job outlined.

removed assignee

I agree with many of the issues and suggestions @JobV outlined https://gitlab.com/gitlab-com/www-gitlab-com/issues/1123#note_26966222. I understand the purpose of this issue and that it differs from a total restructure of the navigation but simplifying the navigation and UI would greatly help users not get lost, as well as funnel them to certain areas we want to promote. Please feel free to tag a member of the ux team to help with information architecture of the about site in the future issues that have been discussed here.

Also leverage @sarahod who can chime in about a reasonable sample size and help determine a suitable length for future studies like this.

Also leverage @sarahod who can chime in about a reasonable sample size and help determine a suitable length for future studies like this.

You gotta get that power (Beta)!

@regisF @amara Some feedback from a friend:

@amara @regisF who is taking ownership of this? I don't see the updated contrast, for instance.

@JobV I'll take it.

@amara It's been a week exactly that we shipped this new menu. It's time to see if we've improved the discovery of the EE webpages. Could you check, perhaps with @mitchellwright, if we've reached this goal? Can you post here the results? This has the highest priority.

Also, we should check if we generated more EE trials with this new menu. I'm unsure about who could help us here to find out. @mitchellwright perhaps? Thanks!

If the impact is not significant, we'll have to revert the changes. If not, we'll start from there with improvements.

@regisF @amara I think we should revert it anyway. The products page, one that is important to clarifying the difference between our products is impossible to find now.

I remembered that I had access to Google Analytics actually.

So here are the changes on the traffic on the different pages in the last 30 days (Mar 11- Apr11). Note that the new menu went live Apr 4.

https://about.gitlab.com/free-trial/ Much better.

https://about.gitlab.com/gitlab-ee/ Doubled traffic compared to week-1 and week-3, but not that much vs week-2

https://about.gitlab.com/products/ Significantly reduced

https://about.gitlab.com/downloads/ Not better

https://about.gitlab.com/features/ Exactly like the week before, lower than week-2 and week-3

https://about.gitlab.com/gitlab-com

I'd be curious to know now, if driving more traffic to the free trial page converted to more leads. That'd be interesting to know.

To sum up, having the new menu has:

Positive impact

No or negative impact:

What remains unknown is the number of leads.

I think we can achieve more traffic to the first two pages above, without this new menu.

@amara you mentioned bounce rate and time on site as well. I don't know how to see them over time in GA. Can you check and summarize? Or @mitchellwright ?

just a note: it feels weird having blog not being a top item.. but if numbers prove me wrong, than dont mention it ;)

usecase: go to gitlab homepage => go to blog (now have to really look for it.. .. there is no cue about it being in "Resources" .. feels unintuitive

It appears we haven't make the situation better with the new menu. We should look at other ways to drive traffic to the EE pages.

@iamphill @samrose3 can one of you please revert the changes? Thanks!

@regisF I can revet it back

assigned to @samrose3

created branch 1123-it-should-be-easier-to-find-ee-specific-page-and-ee-features-pages

mentioned in merge request !5651 (merged)

closed via merge request !5651 (merged)

removed assignee

Thanks @samrose3 and @iamphill for the revert.

It should be easier to find EE specific page and EE features pages

Description

Proposal for a New Nav

Design Mockup

Baseline Metrics

Designs

Child items ...

Activity

Admin message

Admin message

It should be easier to find EE specific page and EE features pages

Description

Proposal for a New Nav

Design Mockup

Baseline Metrics

Activity