630822 - The default dashboard used to be beta/ but now it is release/

Status: RESOLVED WONTFIX

(Input :: General, defect, P2)

Description

[David Burns :automatedtester]

The url is being directed to this page

Search Unavailable

I'm sorry, there was an error with your search.

Our search engine might be currently unavailable. You may start over on the dashboard and try again later.

If the problem persists, please file a bug, mentioning the URL you were accessing.

Include the following error message in your bug report:

no enabled local indexes to search

Thanks!

Comment 1

[Dave Hunt [:davehunt] [he/him] ⌚BST]

Also, in beta 10 I am being redirected from http://input.stage.mozilla.com/ to http://input.stage.mozilla.com/en-US/release instead of http://input.stage.mozilla.com/en-US/beta so our automated tests are currently failing.

Comment 2

[Fred Wenzel [:wenzel]]

comment 0 is a dupe of bug 630704, so let's make this bug about comment 1.

Looking at the code, this is expected, since the default dashboard is now the release dashboard (you shouldn't see a different dashboard based on *your* browser, that's horrendous UX).

Assigning this to Aakash, who should say which one of the two current dashboards he'd like to be the default.

Comment 3

[Aakash Desai [:aakashd]]

The default dashboard should be the release dashboard if you're on any browser useragent except in the following case:

* Firefox Beta: default should be the beta dashboard

Though this is more work right now than needed as we don't have nightlies, so its up to you Fred as to when you'd like to tackle this.

Comment 4

[Fred Wenzel [:wenzel]]

I'll ask Chowse for input on the UX here. I am not completely convinced yet that a user (say, a QA person) on a Beta would want to see the Beta dashboard and then, when surfing there on a release version, would like to see releases by default. But I might well be wrong!

Let me put this into 3.3 for now, as it involves pulling the UA detection code out of the feedback submission code, make it more general, and use it on the dashboard as well. It's a little bit too extensive a change than I want to do while our other 3.1 features are landing and being QAed.

CCing chowse: Can you comment on the above if you have a minute to think about it? Otherwise I will bug you come 3.3.

Comment 5

[Chris Howse [:chowse]]

(In reply to comment #4)

Ideally, if the user visited http://input.mozilla.com/ with no path, they'd see:

  * On their first visit, the dashboard for their browser version. If the
    version cannot be detected, default to release.

  * On subsequent visits, the last dashboard they visited (perhaps stored
    in a cookie).

That said, the chances that people will visit http://input.mozilla.com/ directly seem slim to me. I imagine most people will get to the dashboard by:

  * A link at the end of the submission flow, which will be a direct link
    to the appropriate dashboard.

  * A bookmark, which would be set post-redirect and hence be a direct link.

  * A link from a blog or message, which (hopefully) will be a direct link 
    for the same reason above.

Unfortunately because it's a redirect, I don't have any metrics on how often people are taken to http://i.m.c/ directly (and if its from a place we can change).

Based on this, I'd say the cookie would be more useful (for recurring visitors), followed by user agent detection (for first-time visitors). However, lack of either would not lead to an overtly bad UX.

Comment 6

[Aakash Desai [:aakashd]]

> That said, the chances that people will visit http://input.mozilla.com/
> directly seem slim to me. I imagine most people will get to the dashboard by:

I think that's true for the dashboard once we get to major release versions, but I'd say its more likely that people who want to view the beta dashboard right now will likely be those who go straight to it (i.e. employees and community memebers within Mozilla).

The cookie approach seems like the smarter approach. Moving this back to unassigned; thanks, Chris.

Comment 7

[Fred Wenzel [:wenzel]]

After discussing this further with Dave and Chowse, the expected win for the added complexity is minute here. Everybody who "professionally" uses Input will have their desired dashboard in their awesomebar in no time, thus jumping over the detection in the first place. Everybody else will likely survive a reasonable default, which I believe "releases" is. Wontfix, for the sake of not adding more hidden complexity to our product.