Closed Bug 596201 Opened 14 years ago Closed 14 years ago

Create Panorama welcome page

Categories

(www.mozilla.org :: General, defect, P1)

Product:
www.mozilla.org
Component:
General
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: mitcho, Unassigned)

References

Details

Attachments

(1 file)

Sketch of the first-run page.
38.32 KB, image/png
Details
The Panorama first-run welcome video/group is disappearing, in lieu of automatically opening a new tab pointed at a Mozilla-hosted Panorama welcome page (bug 596075). This page must be created. For the purposes of bug 596075, we first need a simple dummy page/URL that we can use for working out that bug. Not sure what component/product this bug should be under, but I'll start it here (Firefox/TabCandy). Ultimately, this page will have to go through l10n as well.
Assigning this to Sean Martell as (1) he does awesome amazing work, and (2) he has done much of Mozilla's other work in this area. As background for Sean, this is a page that will appear large in the first-run experience in the place of the current video. The idea is to give an easy video introduction + more to the user. I'm imagining a page very much like <http://www.apple.com/iphone/tips/> but with a giant video filling up all columns at the top (in fact, this video: http://videos-cdn.mozilla.net/firefox4beta/tabcandy_howto.webm).
Assignee: aza → smartell
As a stop-gap until we get a real page from Sean: http://azarask.in/projects/tabcandy/tutorial/
(In reply to comment #2) > As a stop-gap until we get a real page from Sean: > http://azarask.in/projects/tabcandy/tutorial/ Thanks Aza.
Added Slater as we should align this first-run page with the look-n-feel of the new firstrun / what's new pages for FF4.
As background, the general idea behind *all* our websites is that we should be moving in the direction of a more unified look rather than a more disparate one. This applies double for anything to do with the product. So, I want to make sure that this page gets synced up with all the other things we're doing (thanks to Sean for the cc). The good news is that in the next few weeks Sean will be working on a revamped first run/what's new design for the main desktop Firefox. My recommendation is that he do that first, then base the Panorama page on that work. It can evolve from the basic pages as needed, but still should be clear that it's on the same site. To that end, I'd suggest changing this to a mozilla.com website bug rather than a Firefox product one. How does that sound? Also, what's the desired timing here?
Hi Slater, Unifed look feels right. It makes sense (and was my desire) to have the page conform to the rest of the product pages. I'd like a first-round done in time for beta 8 so that we can iterate. The first-round really just needs to have the video and not much more. Do you know how to change this to a mozilla.com bug? I'd still like to take inspiration from that how-to page from Apple, instead of the widgety feel for which we sometimes go.
(In reply to comment #5) > Also, what's the desired timing here? Aza or Beltzner would be the right person to answer that question. For the time being I'm going to get started on bug 596075 simply using Aza's stopgap URL. We probably want to have at least a temporary Mozilla-hosted URL instead, however, by the time 596075 becomes part of a beta (beta 8?)... perhaps even before landing bug 596075 for nightlies.
(In reply to comment #6) > Hi Slater, > > Unifed look feels right. It makes sense (and was my desire) to have the page > conform to the rest of the product pages. I'd like a first-round done in time > for beta 8 so that we can iterate. The first-round really just needs to have > the video and not much more. Do you have a general sense of when beta 8 will be? I'm guessing Sean can have the basic first run page done around the end of this month, although I would certainly need to confirm that with him first! Then figure some time after that to design the Panorama version, then code & QA it, etc. > Do you know how to change this to a mozilla.com bug? Unfortunately I don't. I changed the product to websites (instead of Firefox), but it's still listed under TabCandy as a component. > I'd still like to take inspiration from that how-to page from Apple, instead of > the widgety feel for which we sometimes go. Sounds like a plan to me.
Assignee: smartell → nobody
Component: TabCandy → www.mozilla.com
Product: Firefox → Websites
QA Contact: tabcandy → www-mozilla-com
Target Milestone: --- → 4.0
Version: Trunk → unspecified
Actually, it looks like I was able to move this over to the mozilla.com component, so we should be all set in terms of bugzilla organization. Sean, let's continue discussing this.
John et al, Bug 596075 has passed ui-review and is now in review, but we shouldn't really land it without a stable URL for the welcome page. Could a URL (just with a dummy page) be determined soon?
Hey guys. For the URL, it depends a little bit on how you plan on using the page. We basically have two models for in-product page URLs. Pages that aren't updated with each version: http://www.mozilla.com/en-US/firefox/phishing-protection/ http://www.mozilla.com/en-US/firefox/central/ Pages that are more version-specific: http://www.mozilla.com/en-US/firefox/3.6/firstrun/ Based on what I know, I'd recommend something like the former...perhaps: http://www.mozilla.com/en-US/firefox/panorama/ The only difference is that your page is a panorama first run page rather than a general info page like the two examples listed. What do you think?
John, That makes sense, although I do wonder if we may want to update the page with some releases of Firefox. In Firefox 4.5(?) we may end up adding a new feature, for instance. I wonder if the right approach is to use http://www.mozilla.com/en-US/firefox/panorama/ and have Javascript or a server-side script detect the Firefox version number and redirect if and when we need it?
Yeah, I thought that might be the case. I really think we could go either way here...if we can serve up version-specific content like you suggested then I'd suggest keeping the version number out of the URL (because, unlike the regular first run page, you won't need a new one for every Firefox release). Also, on a scheduling note, the design for the regular first run page is due to webdev on 10/13. I don't manage Sean's schedule, but I'm guessing he won't have time to do any significant work on this before then. Does that work?
At the very least, we can start with a static url and then update it in the future to be version specific. Sean mentioned that he can get us a rudimentary version of the first-run page done this week by slapping some divs together. 10/13 is probably too late.
Can we rely on accept-lang to resolve the locale instead of hardcoding it? That'd be just http://www.mozilla.com/firefox/panorama/. Also, we're going to rip out more and more UA information from http headers, I wouldn't rely on either js or apache being able to tell apart 4.1 from 4 by the time we ship 4.1. Folks are just paranoid about that finger-printing thing these days.
If we can make the language and browser detection stuff mentioned in the above comments work, then I'd say that http://www.mozilla.com/firefox/panorama/ is definitely the way to go.
FYI: Bug 596075 has been reviewed and could land, except that we're unsure if we should land it before the URL is fixed and a simple page is put up. The patch that was reviewed uses http://www.mozilla.com/%LOCALE%/firefox/panorama/ (%LOCALE% replaced, of course) but if l10n and webdev think we can forgo the %LOCALE%, I can easily change it and we can land a minimally modified patch.
I'd guess that both l10n and webdev are consumers of what the platform will be. I'd expect that accept-lang will stay, but user agent version detection will get at least harder. So I'd suggest to not put the locale into the URL, but the appversion. No suggestion on who could give you a less fuzzy answer on the platform side, sorry.
Given the plethora of existing "mozilla.com/ab-CD/foo" pages, I don't see any reason why _this_ bug should be blocked up by doing accept-lang handling. File a separate bug for that, and then we can switch over all the Fx4 URLs to "mozilla.com/foo". This bug is about adding a required new page, not redesigning the mozilla.com URL structure. The version detection is also a red-herring. I don't expect there will be any reason to change the Panorama welcome page for security releases (4.0.1, 4.0.2, ect). If we want to have a new page for the next major Firefox release, we can just change the URL for that release. [And, in any case, the UA for Fx4 will still be including the full version number for the release.]
dolske, locale detection works already. Just click on the link in comment 15.
(In reply to comment #20) > dolske, locale detection works already. Just click on the link in comment 15. Ah, I thought it wasn't implemented yet. So, should we spin off a bug to update the other in-product URLs to remove the locale-in-URL formatting? Or does this need implemented per-page?
Assignee: nobody → smartell
Priority: -- → P1
It's probably per-site, I don't know how much of that code is shared infrastructure within webdev/it. I'm not sure if all in-product pages want to not include the locale, either. Like, software update is the trivial counter-example. But a review of the urls we have in the product surely sounds like a good idea.
Aza, do you have more up-to-date direction for Sean on what the content should be here? Once we get those details he can probably knock this out pretty easily.
A bare-bones mockup of the first-run page for Sean to work with as inspiration.
Page created and can be viewed here: http://mozilla.seanmartell.com/tabcandy/welcome/ Aza: please review/comment and let me know if you have the content for the page. Thanks!
(In reply to comment #26) > Page created and can be viewed here: > http://mozilla.seanmartell.com/tabcandy/welcome/ > > Aza: please review/comment and let me know if you have the content for the > page. > > Thanks! Aza, please review this, so we can get it in!
Blocks: 598154
Sean, this is looking great. Here's some placeholder copy: See Your Tabs Sometimes you need to take a step back to see the big picture. Panorama shows you a small version of all your tabs, so you can find what you are looking for instantly. Organize them Drag your tabs where you want them. Your tabs, your way. Put two on top of each other to make a group. Or just click and drag in empty space. What's in a name? You name your folders and files, why can't you label a set of tabs? Put all of your vacation research tabs together and call it "Vacation", or everything from the office together and call it "Work". It helps keep your browser organized your way. By key or by swipe Tap command+e to enter or exit Panorama in an instant. Or, if you like, use a satisfying three-finger swipe. Search Sometimes you know exactly for what you are looking. Just start typing and Panorama will find it for you in an instant. Hit return and you are there.
Also, f+
bugspam (moving b9 to b10)
Blocks: 608028
bugspam (removing b9)
No longer blocks: 598154
We really need this fixed, or every time someone loads Panorama for the first time they'll see a big 404. This needs to block, but unfortunately bugzilla doesn't have blocking for this component. How do we make sure this gets done?
Per comment #26 it looks like we have the design. Is the copy in comment #28 solid enough we can use? If yes, we can start building this...Steven, can you work this into the 1.1 release schedule? (note: we now are on a bi-monthly release schedule for mozilla.com...1.1 is slated for Jan 25.) Sean, can you pass the PSD for this page along to Steven?
Assignee: smartell → steven
Target Milestone: 4.0 → 1.1
I built it already: http://mozilla.seanmartell.com/tabcandy/welcome/ (comment 26) Looks like aza's video has been moved though.
(In reply to comment #35) > Looks like aza's video has been moved though. We (someone) should probably redo the video, though. It mentions the old shortcut key, has the older CSS, etc...
The process on this page has been a little unusual. Normally we'd have someone like Sean design it, then someone like Steven build it and from there it would get QA'd and put into production. In this case, we have a live prototype of the design on Sean's server, but it needs updated copy and other elements, like the video. It also needs to be moved into the mozilla.com branch and, I assume, reviewed before it goes into QA, etc. As a next step, it'd be great if the Panorama owner of this page could supply final versions of the copy, video and any other elements needed as soon as possible...then we can get it onto mozilla.com as quickly as possible.
Assignee: steven → nobody
A copy of Sean's page has been setup in mozilla.com trunk (r80662): http://www-trunk.stage.mozilla.com/en-US/firefox/panorama/ I'm inclined to include a version # in the URL for any in-product pages as this is what we've done for all firstrun/whatsnew pages so far. The video is there, but it's in the hawt-new WebM format, so if you aren't using Fx4, you won't see it.
(In reply to comment #38) > http://www-trunk.stage.mozilla.com/en-US/firefox/panorama/ Thanks Steven. I'm getting a 404 for that URL, fwiw. Panorama team, let us know about final content.
The video is a really effective way of teaching users about the functionality, but do we have a plan for localization? Also, there's the usual problem of users on two of the three platforms being upset that they weren't featured, no matter who we choose (or we could record three screen casts).
We, aka pascalc, are quite proficient in generating subtitles for videos.
(In reply to comment #39) > Thanks Steven. I'm getting a 404 for that URL, fwiw. Missed a file in the commit. Thanks. Fixed in r80707.
Depends on: 616079
The wording in comment 28 looks fine to me, except: > By key or by swipe > > Tap command+e to enter or exit Panorama in an instant. Or, if you like, use a > satisfying three-finger swipe. As far as I know, the swipe has already been removed. The key combo is under debate; it may change. Actually, once you've gotten this far, I figure you probably know how to get there, so maybe remove this section entirely? On the other hand, there's discussion about removing the Panorama button from the window by default, so perhaps we could add some instruction in here for how to add that button if you want it? At any rate, let's go with what we've got (minus that section) for now. As for the video being out of date, that's bug 616079, assigned to Grace. For that matter, Grace may have some thoughts on this page as well? (In reply to comment #38) > The video is there, but it's in the hawt-new WebM format, so if you aren't > using Fx4, you won't see it. As far as the Panorama team is concerned, we only need to see it in the context of Panorama (it appears when you first use the feature), so FX4 only is fine.
(In reply to comment #43) > As for the video being out of date, that's bug 616079, assigned to Grace. For > that matter, Grace may have some thoughts on this page as well? Grace, any updates on this video and when it'll be ready?
Steven, on https://www-trunk.stage.mozilla.com/en-US/firefox/panorama/ I see "/cdn" in the top left corner.
(In reply to comment #45) > Steven, on https://www-trunk.stage.mozilla.com/en-US/firefox/panorama/ I see > "/cdn" in the top left corner. Ah, left in some debug code. Fixed in r80728.
If someone is redoing the video... could we add a quick section like "go back to your tab by clicking on a thumbnail, clicking on the Panorama button again, or pressing the 'close window' button." ? Perhaps this could help with the "I accidentally entered Panorama and don't know how to get out" feedback.
(In reply to comment #47) > If someone is redoing the video... could we add a quick section like "go back > to your tab by clicking on a thumbnail, clicking on the Panorama button again, > or pressing the 'close window' button." ? > > Perhaps this could help with the "I accidentally entered Panorama and don't > know how to get out" feedback. Though once you have made it to the video, you've already figured out how to get out of Panorama and into a tab...
I hate to say it, but I'm still a little confused about what needs to be done to bring this one to completion. Panorama team, what still needs to happen on this page?
(In reply to comment #49) > I hate to say it, but I'm still a little confused about what needs to be done > to bring this one to completion. Panorama team, what still needs to happen on > this page? I assume the page at https://www-trunk.stage.mozilla.com/en-US/firefox/panorama/ will become available at http://www.mozilla.com/firefox/panorama/ once it's pushed, yes? If that's the case, it looks good to me, with these changes: * The lorem ipsum needs to be replaced with the text from comment 28. * Remove the "By key or by swipe" section Hopefully there will be updates to the video, but let's not hold this page up for them... we can drop the new video in when it's ready. Sound fair?
To those implementing the webpage: please make sure that the video on the finished page has autoplay=false, in order to avoid the unfortunate situation in bug 625423. Thank you! :)
Blocks: 625423
Note this bug now blocks the hardblocker bug 625423. At some point recently http://www.mozilla.com/firefox/panorama/ was changed from a 404 to redirecting to the welcome video directly, which I believe is the primary cause of bug 625423. Is it possible to get that URL to 404 again until the final version is made live? Mike, Ian, thoughts?
I can do that quickly if you want.
I don't think we can or should count on updates to the video - including translation, which I don't think is being done - which means that I don't think we should include the video, which means that the firstrun page as designed here wouldn't really be all that useful. As I said in bug 625423 comment 23, I think we should just drop the first-run experience for this release. We don't have good l10n support (that I know of) for the video and page content, and I think it's a nice to have, not an actual blocker.
Oh, we should do the 404 for now, though, too, yes. No point in hosting the video if we're not going to use it, anyway.
Committed r81161 on stage. (don't look at the commit message, I wrongly used a bad "svn-commit.tmp)
r81161 pushed to production r81163 | jlong@mozilla.com | 2011-01-18 17:22:02 -0500 (Tue, 18 Jan 2011) | 1 line
Per comment #54, should we resolve this bug? Sounds like the page may not be needed as originally spec'd.
Blocks: 626926
No longer blocks: 625423
Blocks: 626527
I've removed the Panorama page from trunk (r81192) and am closing this bug on the assumption that this page is dead. Re-open if it is needed.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → WONTFIX
Component: www.mozilla.org/firefox → www.mozilla.org
Component: www.mozilla.org → General
Product: Websites → www.mozilla.org
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: