Sparked by this: https://twitter.com/neave/status/415533230579019777/photo/1 I think Aral is right when he says that we could do better here. I don't know how frequently this happens, but it certainly does every now and again. One downside is that it could be annoying when using throwaway profiles. Thus, it should be very easy to click away, or just hide itself after a short-ish timeout if the user doesn't interact with it. (Though I don't know what that interaction should look like.)

Just a note here, it is relatively hard to open devtools by mistake for a non techie person. The shortcuts for individual tools are complex (two modifiers plus one key). Even the quick shortcut (f12) is not easily discoverable. Opening the tools via the menu buttons is also not a single click thing. It needs atleast 3 (or 2 in australis) clicks, but in the process of those clicks, the user is pretty much clear on what the click is going to do. That being said, a short help page would be beneficial in case the user opens the tools for the first time using the most easiest way i.e. F12 . I think if the user opened "Console" using "Ctrl + Shift + K" shortcut, then he pretty much wants/knows it.

(In reply to Girish Sharma [:Optimizer] from comment #1) > Just a note here, it is relatively hard to open devtools by mistake for a > non techie person. I agree. The "Inspect Element" context menu entry might be slightly more likely to be used by accident. > That being said, a short help page would be beneficial in case the user > opens the tools for the first time using the most easiest way i.e. F12 . I > think if the user opened "Console" using "Ctrl + Shift + K" shortcut, then > he pretty much wants/knows it. A help page explaining what the devtools are would be pretty nice in any case. Maybe even something like the australis walkthrough that's planned to be shown on first start of the new version. This guide could contain the option to permanently disable the devtools, too.

(In reply to Till Schneidereit [:till] from comment #2) > (In reply to Girish Sharma [:Optimizer] from comment #1) > > Just a note here, it is relatively hard to open devtools by mistake for a > > non techie person. > > I agree. The "Inspect Element" context menu entry might be slightly more > likely to be used by accident. Ah, I forgot about that way to open the "Inspector". > > That being said, a short help page would be beneficial in case the user > > opens the tools for the first time using the most easiest way i.e. F12 . I > > think if the user opened "Console" using "Ctrl + Shift + K" shortcut, then > > he pretty much wants/knows it. > > A help page explaining what the devtools are would be pretty nice in any > case. Maybe even something like the australis walkthrough that's planned to > be shown on first start of the new version. Australis is a very major overhaul of the whole of the browser UI. This change affects *everyone* using Firefox. The importance of a walkthrough is much more there. Devtools on the other hand is not a change of any kind. > This guide could contain the option to permanently disable the devtools, too. lets not bring this discussion here please :)

(In reply to Girish Sharma [:Optimizer] from comment #3) > Australis is a very major overhaul of the whole of the browser UI. This > change affects *everyone* using Firefox. The importance of a walkthrough is > much more there. Devtools on the other hand is not a change of any kind. Neither are they self-explanatory at all, though. Ideally, they will be a new feature to explore for many people who're starting out with web development. That, we should make as easy as possible. (And yes, I think explaining the devtools is almost infinitely more useful than making it possible to disable them.)

I'm not sure about one-shot "now you get it" solutions. If the welcome message is passive enough to not annoy web developers, is it going to be memorable enough to solve this problem on the second click for non-web-developers (or even on the first)? Perhaps there are other solutions to consider like having the web console default to not showing so many error messages when things are actually working OK?

From Jeff on Bug 957261: > cc'ing Darrin whose expertise would be critical for getting this done. Darrin - what do you think?

Copying relevant bits of my comment from bug 957261: I think the tools should include some sort of first run experience, in particular now that we've taken over F12. I don't have a particular agenda for what it should look like, but some concerns I have are: * non-dev users should have a simple explanation of what the tools are, with a 'would you like to know more...' hook, possibly to MDN. * developers opening the tools on a fresh profile should be able to get rid of the interruption easily and get on with their work * if we include this we have the opportunity to ask developers permission to provide anonymous usage data to help us improve the devtools

Instead of a complex first run experience, you could also do something simple: Add a button, in a different color, labeled "What is this?". When clicked, popup a very simple box saying "This is a tool for Firefox programmers that shows information about the inner working of the Firefox software while processing web sites. Click [thing] to hide it."

A "first run experience" is going to be triggered every time a person creates a new profile. Developers are somewhat more likely to do this than other humans. I know I'm always peeved when I create a new profile and have to click through "Know your rights", the GCLI "I Get It" popup and the about:config "Get Me Out Of Here" warning. (not to mention participate in telemetry, test pilot and other data gathering services we bundle) Every time we introduce a new one of these, we're creating friction between our browser and the people trying to get stuff done.

> Every time we introduce a new one of these, we're creating friction between our browser and the people trying to get stuff done. Web browsers are primarily for the end users, not developers. Developers' needs should always come second to users' needs. This is why we have this problem in the first place. And surely this 'multiple profile' thing is a problem that can be fixed. It's poor programming if it can't be fixed. The splash screen should cover the entire dev tools area on first run (for every profile) with text to explain what happened, and a big button to enable, exactly the same way Firefox handles the about:config page: http://www.shicho.net/lamp/wp-content/uploads/2010/05/about-config.png

Largely, I agree with Paul: especially with the devtools now opening on F12, we shouldn't ignore the concerns of end users here. > And surely this 'multiple profile' thing is a problem that can be fixed. > It's poor programming if it can't be fixed. It's not really about programming so much as about knowing when not to show the first run thing. I could imagine a MOZ_DEVTOOLS_NOFIRSTRUN env var that devs could just export in their shell's init file. > > The splash screen should cover the entire dev tools area on first run (for > every profile) with text to explain what happened, and a big button to > enable, exactly the same way Firefox handles the about:config page: > http://www.shicho.net/lamp/wp-content/uploads/2010/05/about-config.png This part, I don't necessarily agree with: what exactly the first run experience should look like isn't immediately obvious to me, but I do think that about:config is a very different case: we want to protect users from blindly following guides that tell them to do dangerous stuff. How well any splash screen can accomplish that is a different question, but it's at the very least a good argument for having a somewhat-inconvenient stumbling block in the process. The dev tools, OTOH, should guard against cases like the one that triggered this bug, where users accidentally open the devtools and don't know what they're about. It can thus be much more lightweight, I think.

Worth remembering: We have plans to separate the web console from the logs. The web console will be the first thing that shows on first use, so the 'scary messages' problem will be solved without need for a 'first-run-experience'. Hence I think the need for a first-run-experience needs to be weighed against the friction for developers, and not against the original bug report. Personally I have some doubts that it's the best thing to work on right now.

(In reply to Joe Walker [:jwalker] from comment #13) > Personally I have some doubts that it's the best thing to work on right now. I want to agree but my immediate next thought is: "when will it be the best time?" Devtools are a hot topic nowadays, and given the amount of things that need improvements and work (console rewrite, memory tools, per-frame timeline, devtool API for addons, e10s is pushing for a bunch of minor tasks too, keeping up with competition, etc.), I wonder if the right time will come before the next 3-4 years :-/ Maybe it can be a good project for an intern? Maybe an intern would be expected to work on other matters ;-)

(In reply to David Bruant from comment #14) > (In reply to Joe Walker [:jwalker] from comment #13) > > Personally I have some doubts that it's the best thing to work on right now. > I want to agree but my immediate next thought is: "when will it be the best > time?" Surely after the new console lands?

(In reply to Panos Astithas [:past] from comment #15) > (In reply to David Bruant from comment #14) > > (In reply to Joe Walker [:jwalker] from comment #13) > > > Personally I have some doubts that it's the best thing to work on right now. > > I want to agree but my immediate next thought is: "when will it be the best > > time?" > > Surely after the new console lands? oh ok. I had originally misunderstood Joe's message. My mistake, sorry about that.

(In reply to David Bruant from comment #14) > (In reply to Joe Walker [:jwalker] from comment #13) > > Personally I have some doubts that it's the best thing to work on right now. > I want to agree but my immediate next thought is: "when will it be the best > time?" > Devtools are a hot topic nowadays, and given the amount of things that need > improvements and work (console rewrite, memory tools, per-frame timeline, > devtool API for addons, e10s is pushing for a bunch of minor tasks too, > keeping up with competition, etc.), I wonder if the right time will come > before the next 3-4 years :-/ > Maybe it can be a good project for an intern? Maybe an intern would be > expected to work on other matters ;-) I'm generally bullish on having something, but I think thought needs to be put into it: * it should either go away on its own * it should prevent a developer from getting work done, eg, not modal * we could even constrain it to contexts like: only a single, Default profile on the system and/or Beta or Release build. The win is that we don't confuse people, but that we do provide a path from curious exploration of the browser to some really good docs explaining whet the heck the tools are.

It was mentioned over in bug 971597 that a first-run dialog like this might prevent end users from shooting themselves in the foot.

(In reply to Rob Campbell [:rc] (:robcee) from comment #10) > Every time we introduce a new one of these, we're creating friction between > our browser and the people trying to get stuff done. What would you think about limiting this first-run experience to the release channel?

(In reply to Jeff Griffiths (:canuckistani) from comment #19) > (In reply to Rob Campbell [:rc] (:robcee) from comment #10) > > Every time we introduce a new one of these, we're creating friction between > > our browser and the people trying to get stuff done. > > What would you think about limiting this first-run experience to the release > channel? +1

fine with me.

(In reply to Jeff Griffiths (:canuckistani) from comment #19) > (In reply to Rob Campbell [:rc] (:robcee) from comment #10) > > Every time we introduce a new one of these, we're creating friction between > > our browser and the people trying to get stuff done. > > What would you think about limiting this first-run experience to the release > channel? Plus maybe only show it for the main profile, so users running with secondary or temporary profiles don't get bothered by it at all?

(In reply to Jeff Griffiths (:canuckistani) from comment #19) > (In reply to Rob Campbell [:rc] (:robcee) from comment #10) > > Every time we introduce a new one of these, we're creating friction between > > our browser and the people trying to get stuff done. > > What would you think about limiting this first-run experience to the release > channel? I think that might help, but we should remember that Mozilla doesn't like to divide the world into users and developers. Part of the mission is to reduce that divide. My biggest concern about this bug is that we have 20 half reasons to do it, and 10 half reasons not to do it, but nothing decisive, and no clear "when you add it all up there is a net gain" argument. Maybe what it needs is a mock-up so we can see clearly what the trade-offs are.

Just wanted to throw my hat into the ring here. I work on UI/UX for Webmaker and we're planning a meeting later today with Madhava and Darrin to discuss how we might tackle this issue. Webmaker has an obvious interest in helping new users grok dev tools, and we have some ideas to make this more visual, starting with the things users can see on a page – colors, fonts, images. While perhaps slightly out of the scope of this bug, it is all part of a similar challenge to lower the barrier to entry and expand the base of users who are web literate. Will followup here after the meeting...

(In reply to Cassie McDaniel [:cassiemc] from comment #24) > Just wanted to throw my hat into the ring here. Ah, pleased you're here, I was about to ask Paula who should help. Thanks.

Following up post-call. Darrin and I are going to collaborate on some UX here – our starting point will be considering the experience of the Australis tour. We'll look forward to feedback when we have something concrete to share. In the meantime feel free to keep the conversation going, it's been helpful to read everyone's thoughts.

(In reply to Cassie McDaniel [:cassiemc] from comment #26) > Following up post-call. Darrin and I are going to collaborate on some UX > here – our starting point will be considering the experience of the > Australis tour. We'll look forward to feedback when we have something > concrete to share. In the meantime feel free to keep the conversation going, > it's been helpful to read everyone's thoughts. This sounds great. I'm really pleased with the Australis tour generally, and I'm eager to see options that don't veer to extreme options.

I understand that Firebug had one of these and people complained. I'd be interested to know what Honza thinks of the idea.

(In reply to Joe Walker [:jwalker] from comment #29) > I understand that Firebug had one of these and people complained. I'd be > interested to know what Honza thinks of the idea. Firebug didn't have a tour like the one that has been done for Australis. But in general, we have always got negative feedback if users had to deal with anything that prevents them to use the tool right away (even if for the first time only). * After some time, when we wanted to notify users we created a friendly good looking log in the Console + "I got it" button. This worked pretty well (no negative feedback), it doesn't block the user and since the Console is the default it's quite visible. * I agree that having the Console panel empty (when opened for the first time) would look a lot less scary and perhaps the original reason for this bug wouldn't suddenly be that strong. * Note that, I really like the Australis tour and I am sure having it for developer tools would be just great. I would be careful about force users to see it automatically, and consider rather notifying them (e.g. again through a good looking Console log or any other non invasive tactic), that the tour exists and they can go ahead and learn. * In any case, I like the idea of having these things only on the release channel. Honza

Note also that Firebug specifically targets developers, whereas part of what we're trying to solve here is non-developers accidentally opening the devtools and not understanding what's going on at all. That seems very unlikely for someone who explicitly installed Firebug.

(In reply to Girish Sharma [:Optimizer] from comment #1) > Just a note here, it is relatively hard to open devtools by mistake for a > non techie person. Last I checked, it is exposed in the main menu quite prominently!

(In reply to :Ehsan Akhgari (lagging on bugmail, needinfo? me!) from comment #32) > (In reply to Girish Sharma [:Optimizer] from comment #1) > > Just a note here, it is relatively hard to open devtools by mistake for a > > non techie person. > > Last I checked, it is exposed in the main menu quite prominently! Also cats, books and shirt sleeves are surprisingly good at hitting cmd+alt+k or just F12. We have enough shortcuts now that you've got a good chance of getting devtools just by mashing the keyboard.