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



8 years ago
8 years ago


(Reporter: automatedtester, Unassigned)






8 years ago
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

Also, in beta 10 I am being redirected from to instead of so our automated tests are currently failing.
Severity: normal → major
Priority: -- → P1
Target Milestone: --- → 3.1
OS: Mac OS X → All
Hardware: x86 → All
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.
Assignee: nobody → mozaakash
Severity: major → trivial
Summary: redirecting to Search unavailable → The default dashboard used to be beta/ but now it is release/
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.
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.
Assignee: mozaakash → nobody
Priority: P1 → P2
Target Milestone: 3.1 → 3.3
Assignee: nobody → chowse
Target Milestone: 3.3 → 3.4
(In reply to comment #4)

Ideally, if the user visited 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 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.
> That said, the chances that people will visit
> 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.
Assignee: chowse → nobody
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.
Last Resolved: 8 years ago
Resolution: --- → WONTFIX
Component: Input → General
Product: Webtools → Input
You need to log in before you can comment on or make changes to this bug.