Closed Bug 396738 Opened 17 years ago Closed 16 years ago

Implement front page (DES-3)

Categories

(addons.mozilla.org Graveyard :: Public Pages, defect)

defect
Not set
normal

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: baz, Assigned: morgamic)

References

()

Details

As specified in the AMO v3.2 PRD (Update:RequirementsV32) and the mockups (http://wiki.mozilla.org/Update:Remora_UI_Review/Mockups/Home_Page/2007-09-12_revisions/)
Crossposting my comment from Basil's blog to this bug:

Wow, thanks for making AMO absolutely useless for non-Firefox applications like Thunderbird, SeaMonkey or Sunbird.

The frontpage mockup gives the user absolutely no indication that this page is about anything else than Firefox addons. And since AMO is the only addon page that is whitelisted by default in all applications based on Gecko 1.9, that will a major headache for users of non-Firefox applications.

You know, there are also very popular extensions for non-Firefox applications as well. Lightning alone got nearly 1.2 million downloads since its creation 2 years ago, 820000 of those downloads coming via AMO.

If you want to create a Firefox-only AMO page, then please state this clearly, so that nobody gets delusions about AMO being a place for the Mozilla Project as a whole. I also recommend renaming AMO to AFC (addons.firefox.com) as this hits nearer to the mark than the current name.
The current plan (not reflected in the mockups) is to have text links in the footer that leads to the other supported applications. My intention with the "demotion" was actually to reduce dependencies between the applications hosted on AMO. Based on the traffic access patterns, we DON'T see that much app switching...

My thought was to have completely separate instances (seamonkey.addons.mozilla.org or whatever) so that each app & community supporting that app would have the flexibility to do what they like, e.g. set their own list of recommended add-ons, in the future (if we have support for AMO skins) that each app decide on its own look-and-feel, etc. What I believe needs to happen is to change the doorway to the site, e.g. why can't we register DNS CNAMEs and direct users to the "SeaMonkey" add-ons area instead of having them navigate and switch between apps.

AMO is a Mozilla project that should be shared across all Mozilla apps and I have every intention to make sure that's the case. What I'm trying to do is give autonomy, flexibility while balancing a simplified user experience.

Let me know your thoughts
"addons.mozilla.org" is a magic name for purposes of the whitelist, as long as we have that control in place.  Does addons.mozilla.org/$lang/seamonkey/ not work today, and permit per-app recommended lists already?
Some Q&A about the design, copied here for reference. 

1) The recommended add-ons are all from the "appearance" category (which should be "Themes & Appearance, but that's not really my question here); how are these generated?  Shouldn't they be a blend of featured categories?

Yes -- they should be a blend of categories.  That they're all "appearance" is just an artifact of the mockup.


2) "68 reviews" is a hyperlink, right?

Yes -- to the reviews section of the page about that add-on.


There are also some explanatory notes here:

http://wiki.mozilla.org/Update:Remora_UI_Review/Mockups/Home_Page/2007-09-12_revisions/
Assignee: nobody → morgamic
Front page is implemented, unless anybody has any major objections.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Madhava can correct me here but I think that there needs to be a few changes to categories.

1) I think it's probably confusing since there were so many mocks floating around - but the requirements intended to have the following list, http://wiki.mozilla.org/Update:RequirementsV32#Category_Revision

Interface Customizations -> Themes & Appearance

I have an open bug - bug 396742 which is awaiting this change as well.

So, we need to make sure that the front page and the search drop down list reflect this list.

2) I would also suggest that we move "Other" to the end of the list as listed per the requirements

3) Missing are "Tabs", "Toolbars" (I've added those to the production AMO since they were missing) and "Languages & Dictionaries" which I'm hesitant to add myself since it's a hybrid types page wasn't sure if that would be treated the same as "Themes & Appearance" which is also a hybrid types page.

Re-opening the bug to get these three issues fixed.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Minor edit: please format the download count string in each of the boxes with commas such as xxx,xxx,xxx. It'll make the number more readable.
(In reply to comment #7)
> Minor edit: please format the download count string in each of the boxes with
> commas such as xxx,xxx,xxx. It'll make the number more readable.
> 

More readable in en-US; possibly inaccurate in other locales. Does gettext take care of number_format() stuff?
(In reply to comment #8)
> (In reply to comment #7)
> > Minor edit: please format the download count string in each of the boxes with
> > commas such as xxx,xxx,xxx. It'll make the number more readable.
> 
> More readable in en-US; possibly inaccurate in other locales. Does gettext take
> care of number_format() stuff?

Not automatically; but you can seed it with options you get from localeconv() which in turn obtains its data from gettext.
The download #'s are formatted w/ xxx,xxx -- not a showstopper there.  Aside from that, I think the comments from comment #6 all concern categories, which can be handled in bug 396741 so I'd like to resolve this.  I didn't fix the categories as they don't block this being completed -- the template does what it's supposed to.
Status: REOPENED → RESOLVED
Closed: 17 years ago16 years ago
Resolution: --- → FIXED
The front page is in, and plenty of spin-off bugs have been and will be continued to be filed; calling this Verified FIXED.
Status: RESOLVED → VERIFIED
Product: addons.mozilla.org → addons.mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.