MozillaWiki - User contributions [en]

Websites/Mozilla.org/Archive/Design Implementation/RSS

2009-05-15T12:18:54Z

FeyP: /* Implementation */ some gerneral ideas

== What we want to do ==

[https://bugzilla.mozilla.org/show_bug.cgi?id=493099 Bug 493099: Hook up news feeds on new www.mozilla.org home page].

We want a feed parser that

* pulls latest feed info from feeds.mozilla.com for front page
* pulls latest feed info from news.rdf (for now) for front page
* optionally: creates mash ups of multiple feeds on sub-pages (e.g. ''Our causes'' > ''Education'')

== How to do it ==

Mozilla.org has a lot of visitors, so we probably want to '''cache feed items''' for some time to a) be nice to the feed provider and b) get better performance.

We probably want a '''database-based cache''' over a file-based cache, because it gives faster results.

'''TTL''' of the cached items can be relatively high (higher on the sub-pages than on the front page), because we offer the feeds to open up an additional window into the community and not to be a direct, always-up-to-date information resource.

== Implementation ==

Overall ideas:
* Use a cron-job to generate static html with the news items
* Pull in the items from a db-based cache, refresh the cache occasionally

There are several different options (subject to evaluation).

=== Write a parser from scratch ===
* + maybe better performance
* + would hopefully be exactly what we want
* - more development time
* - not as well tested as other solutions

=== Zend Framework ===
* New BSD license
* very modular and flexible
* PHP5 only (read: makes use of new OOP features, which is good)
* well maintained, active development
* DB abstraction layer, cache handling
* some known issues, API a bit counter-intuitive in places
* probably not as heavily tested as other solutions (because relatively new)
* generally long turnaround time (bug filed to fix released)

=== PEAR ===
* XML_Feed_Parser
** LGPL license
** No maintainer
* XML_RSS
** PHP license
** No active development (last release 06)
=== SimplePie ===
* BSD license
* CURL extension required (need to check with reed, if it is enabled)
* Caching out of the box (flat file only right now, but could be overloaded with own DB-class)
* Meshing of multiple feeds out of the box
* Problems with some feeds, but workarounds exist
* Nice API
* Goodies such as feed auto-discovery (feels a lot like Firefox ;)
* Performance seems to be good with caching, but no idea, if it scales up nicely.

=== Magpie RSS ===
* GPL license
* No active development (last release 05)

=== PHP Universal Feed Parser ===
* GPL license
* seems to be a one-man effort
* uses OOP methodology

=== Other ===

Websites/Mozilla.org/Archive/Design Implementation/RSS

2009-05-15T11:44:25Z

FeyP: /* Implementation */ some more libraries

== What we want to do ==

[https://bugzilla.mozilla.org/show_bug.cgi?id=493099 Bug 493099: Hook up news feeds on new www.mozilla.org home page].

We want a feed parser that

* pulls latest feed info from feeds.mozilla.com for front page
* pulls latest feed info from news.rdf (for now) for front page
* optionally: creates mash ups of multiple feeds on sub-pages (e.g. ''Our causes'' > ''Education'')

== How to do it ==

Mozilla.org has a lot of visitors, so we probably want to '''cache feed items''' for some time to a) be nice to the feed provider and b) get better performance.

We probably want a '''database-based cache''' over a file-based cache, because it gives faster results.

'''TTL''' of the cached items can be relatively high (higher on the sub-pages than on the front page), because we offer the feeds to open up an additional window into the community and not to be a direct, always-up-to-date information resource.

== Implementation ==

There are several different options (subject to evaluation):

=== Write a parser from scratch ===
* + maybe better performance
* + would hopefully be exactly what we want
* - more development time
* - not as well tested as other solutions

=== Zend Framework ===
* New BSD license
* very modular and flexible
* PHP5 only (read: makes use of new OOP features, which is good)
* well maintained, active development
* DB abstraction layer, cache handling
* some known issues, API a bit counter-intuitive in places
* probably not as heavily tested as other solutions (because relatively new)
* generally long turnaround time (bug filed to fix released)

=== PEAR ===
* XML_Feed_Parser
** LGPL license
** No maintainer
* XML_RSS
** PHP license
** No active development (last release 06)
=== SimplePie ===
* BSD license
* CURL extension required (need to check with reed, if it is enabled)
* Caching out of the box (flat file only right now, but could be overloaded with own DB-class)
* Meshing of multiple feeds out of the box
* Problems with some feeds, but workarounds exist
* Nice API
* Goodies such as feed auto-discovery (feels a lot like Firefox ;)
* Performance seems to be good with caching, but no idea, if it scales up nicely.

=== Magpie RSS ===
* GPL license
* No active development (last release 05)

=== PHP Universal Feed Parser ===
* GPL license
* seems to be a one-man effort
* uses OOP methodology

=== Other ===

Websites/Mozilla.org/Archive/Design Implementation/RSS

2009-05-14T23:24:11Z

FeyP: /* What we want to do */

== What we want to do ==

[https://bugzilla.mozilla.org/show_bug.cgi?id=493099 Bug 493099: Hook up news feeds on new www.mozilla.org home page].

We want a feed parser that

* pulls latest feed info from feeds.mozilla.com for front page
* pulls latest feed info from news.rdf (for now) for front page
* optionally: creates mash ups of multiple feeds on sub-pages (e.g. ''Our causes'' > ''Education'')

== How to do it ==

Mozilla.org has a lot of visitors, so we probably want to '''cache feed items''' for some time to a) be nice to the feed provider and b) get better performance.

We probably want a '''database-based cache''' over a file-based cache, because it gives faster results.

'''TTL''' of the cached items can be relatively high (higher on the sub-pages than on the front page), because we offer the feeds to open up an additional window into the community and not to be a direct, always-up-to-date information resource.

== Implementation ==

There are several different options (subject to evaluation):

=== Write a parser from scratch ===
* + maybe better performance
* + would hopefully be exactly what we want
* - more development time
* - not as well tested as other solutions

=== Zend Framework ===
* New BSD license
* very modular and flexible
* PHP5 only (read: makes use of new OOP features, which is good)
* well maintained, active development
* DB abstraction layer, cache handling
* some known issues, API a bit counter-intuitive in places
* probably not as heavily tested as other solutions (because relatively new)
* generally long turnaround time (bug filed to fix released)

=== PEAR ===
* XML_Feed_Parser
** LGPL license
** No maintainer
* XML_RSS
** PHP license
** No active development (last version from 06)
=== SimplePie ===
* BSD license
* CURL extension required (need to check with reed, if it is enabled)
* Caching out of the box (flat file only right now, but could be overloaded with own DB-class)
* Meshing of multiple feeds out of the box
* Problems with some feeds, but workarounds exist
* Nice API
* Goodies such as feed auto-discovery (feels a lot like Firefox ;)
* Performance seems to be good with caching, but no idea, if it scales up nicely.

=== Other ===

Websites/Mozilla.org/Archive/Design Implementation/RSS

2009-05-14T21:55:00Z

FeyP: /* SimplePie */

== What we want to do ==

We want a feed parser that

* pulls latest feed info from feeds.mozilla.com for front page
* pulls latest feed info from news.rdf (for now) for front page
* optionally: creates mash ups of multiple feeds on sub-pages (e.g. ''Our causes'' > ''Education'')

== How to do it ==

Mozilla.org has a lot of visitors, so we probably want to '''cache feed items''' for some time to a) be nice to the feed provider and b) get better performance.

We probably want a '''database-based cache''' over a file-based cache, because it gives faster results.

'''TTL''' of the cached items can be relatively high (higher on the sub-pages than on the front page), because we offer the feeds to open up an additional window into the community and not to be a direct, always-up-to-date information resource.

== Implementation ==

There are several different options (subject to evaluation):

=== Write a parser from scratch ===
* + maybe better performance
* + would hopefully be exactly what we want
* - more development time
* - not as well tested as other solutions

=== Zend Framework ===
* New BSD license
* very modular and flexible
* PHP5 only (read: makes use of new OOP features, which is good)
* well maintained, active development
* DB abstraction layer, cache handling
* some known issues, API a bit counter-intuitive in places
* probably not as heavily tested as other solutions (because relatively new)
* generally long turnaround time (bug filed to fix released)

=== PEAR ===
* XML_Feed_Parser
** LGPL license
** No maintainer
* XML_RSS
** PHP license
** No active development (last version from 06)
=== SimplePie ===
* BSD license
* CURL extension required (need to check with reed, if it is enabled)
* Caching out of the box (flat file only right now, but could be overloaded with own DB-class)
* Meshing of multiple feeds out of the box
* Problems with some feeds, but workarounds exist
* Nice API
* Goodies such as feed auto-discovery (feels a lot like Firefox ;)
* Performance seems to be good with caching, but no idea, if it scales up nicely.

=== Other ===

Websites/Mozilla.org/Archive/Design Implementation/RSS

2009-05-14T21:53:32Z

FeyP: /* SimplePie */

== What we want to do ==

We want a feed parser that

* pulls latest feed info from feeds.mozilla.com for front page
* pulls latest feed info from news.rdf (for now) for front page
* optionally: creates mash ups of multiple feeds on sub-pages (e.g. ''Our causes'' > ''Education'')

== How to do it ==

Mozilla.org has a lot of visitors, so we probably want to '''cache feed items''' for some time to a) be nice to the feed provider and b) get better performance.

We probably want a '''database-based cache''' over a file-based cache, because it gives faster results.

'''TTL''' of the cached items can be relatively high (higher on the sub-pages than on the front page), because we offer the feeds to open up an additional window into the community and not to be a direct, always-up-to-date information resource.

== Implementation ==

There are several different options (subject to evaluation):

=== Write a parser from scratch ===
* + maybe better performance
* + would hopefully be exactly what we want
* - more development time
* - not as well tested as other solutions

=== Zend Framework ===
* New BSD license
* very modular and flexible
* PHP5 only (read: makes use of new OOP features, which is good)
* well maintained, active development
* DB abstraction layer, cache handling
* some known issues, API a bit counter-intuitive in places
* probably not as heavily tested as other solutions (because relatively new)
* generally long turnaround time (bug filed to fix released)

=== PEAR ===
* XML_Feed_Parser
** LGPL license
** No maintainer
* XML_RSS
** PHP license
** No active development (last version from 06)
=== SimplePie ===
* BSD license
* CURL extension is a requirement (need to check with reed, if we have it)
* Caching out of the box (flat file only right now, but could be overloaded with own DB-class)
* Meshing of multiple feeds out of the box
* Problems with some feeds, but workarounds exist
* Nice API
* Goodies such as feed auto-discovery (feels a lot like Firefox ;)
* Performance seems to be good with caching, but no idea, if it scales up nicely.

=== Other ===

Websites/Mozilla.org/Archive/Design Implementation/RSS

2009-05-14T21:47:29Z

FeyP: /* SimplePie */

== What we want to do ==

We want a feed parser that

* pulls latest feed info from feeds.mozilla.com for front page
* pulls latest feed info from news.rdf (for now) for front page
* optionally: creates mash ups of multiple feeds on sub-pages (e.g. ''Our causes'' > ''Education'')

== How to do it ==

Mozilla.org has a lot of visitors, so we probably want to '''cache feed items''' for some time to a) be nice to the feed provider and b) get better performance.

We probably want a '''database-based cache''' over a file-based cache, because it gives faster results.

'''TTL''' of the cached items can be relatively high (higher on the sub-pages than on the front page), because we offer the feeds to open up an additional window into the community and not to be a direct, always-up-to-date information resource.

== Implementation ==

There are several different options (subject to evaluation):

=== Write a parser from scratch ===
* + maybe better performance
* + would hopefully be exactly what we want
* - more development time
* - not as well tested as other solutions

=== Zend Framework ===
* New BSD license
* very modular and flexible
* PHP5 only (read: makes use of new OOP features, which is good)
* well maintained, active development
* DB abstraction layer, cache handling
* some known issues, API a bit counter-intuitive in places
* probably not as heavily tested as other solutions (because relatively new)
* generally long turnaround time (bug filed to fix released)

=== PEAR ===
* XML_Feed_Parser
** LGPL license
** No maintainer
* XML_RSS
** PHP license
** No active development (last version from 06)
=== SimplePie ===
* BSD license
* Caching out of the box (flat file only right now, but could be overloaded with own DB-class)
* Meshing of multiple feeds out of the box
* Problems with some feeds, but workarounds exist
* Nice API
* Goodies such as feed auto-discovery (feels a lot like Firefox ;)
* Performance seems to be good with caching, but no idea, if it scales up nicely.

=== Other ===

Websites/Mozilla.org/Archive/Design Implementation/RSS

2009-05-14T21:47:06Z

FeyP: /* SimplePie */

== What we want to do ==

We want a feed parser that

* pulls latest feed info from feeds.mozilla.com for front page
* pulls latest feed info from news.rdf (for now) for front page
* optionally: creates mash ups of multiple feeds on sub-pages (e.g. ''Our causes'' > ''Education'')

== How to do it ==

Mozilla.org has a lot of visitors, so we probably want to '''cache feed items''' for some time to a) be nice to the feed provider and b) get better performance.

We probably want a '''database-based cache''' over a file-based cache, because it gives faster results.

'''TTL''' of the cached items can be relatively high (higher on the sub-pages than on the front page), because we offer the feeds to open up an additional window into the community and not to be a direct, always-up-to-date information resource.

== Implementation ==

There are several different options (subject to evaluation):

=== Write a parser from scratch ===
* + maybe better performance
* + would hopefully be exactly what we want
* - more development time
* - not as well tested as other solutions

=== Zend Framework ===
* New BSD license
* very modular and flexible
* PHP5 only (read: makes use of new OOP features, which is good)
* well maintained, active development
* DB abstraction layer, cache handling
* some known issues, API a bit counter-intuitive in places
* probably not as heavily tested as other solutions (because relatively new)
* generally long turnaround time (bug filed to fix released)

=== PEAR ===
* XML_Feed_Parser
** LGPL license
** No maintainer
* XML_RSS
** PHP license
** No active development (last version from 06)
=== SimplePie ===
* BSD license
* Caching out of the box (flat file only right now, but could be overloaded with own DB-class)
* Meshing of multiple feeds out of the box
* Problems with some feeds, but workarounds exist
* Nice API
* Little niceties such as feed auto-discovery (feels a lot like Firefox ;)
* Performance seems to be good with caching, but no idea, if it scales up nicely.

=== Other ===

Websites/Mozilla.org/Archive/Design Implementation/RSS

2009-05-14T21:43:10Z

FeyP: /* Zend Framework */

== What we want to do ==

We want a feed parser that

* pulls latest feed info from feeds.mozilla.com for front page
* pulls latest feed info from news.rdf (for now) for front page
* optionally: creates mash ups of multiple feeds on sub-pages (e.g. ''Our causes'' > ''Education'')

== How to do it ==

Mozilla.org has a lot of visitors, so we probably want to '''cache feed items''' for some time to a) be nice to the feed provider and b) get better performance.

We probably want a '''database-based cache''' over a file-based cache, because it gives faster results.

'''TTL''' of the cached items can be relatively high (higher on the sub-pages than on the front page), because we offer the feeds to open up an additional window into the community and not to be a direct, always-up-to-date information resource.

== Implementation ==

There are several different options (subject to evaluation):

=== Write a parser from scratch ===
* + maybe better performance
* + would hopefully be exactly what we want
* - more development time
* - not as well tested as other solutions

=== Zend Framework ===
* New BSD license
* very modular and flexible
* PHP5 only (read: makes use of new OOP features, which is good)
* well maintained, active development
* DB abstraction layer, cache handling
* some known issues, API a bit counter-intuitive in places
* probably not as heavily tested as other solutions (because relatively new)
* generally long turnaround time (bug filed to fix released)

=== PEAR ===
* XML_Feed_Parser
** LGPL license
** No maintainer
* XML_RSS
** PHP license
** No active development (last version from 06)
=== SimplePie ===
* BSD license
* Caching out of the box (flat file only right now, but could be overloaded with own DB-class)
* Meshing of multiple feeds out of the box
* Problems with some feeds, but workarounds exist
* Nice API

=== Other ===

Websites/Mozilla.org/Archive/Design Implementation/RSS

2009-05-14T21:40:56Z

FeyP: /* Zend Framework */

== What we want to do ==

We want a feed parser that

* pulls latest feed info from feeds.mozilla.com for front page
* pulls latest feed info from news.rdf (for now) for front page
* optionally: creates mash ups of multiple feeds on sub-pages (e.g. ''Our causes'' > ''Education'')

== How to do it ==

Mozilla.org has a lot of visitors, so we probably want to '''cache feed items''' for some time to a) be nice to the feed provider and b) get better performance.

We probably want a '''database-based cache''' over a file-based cache, because it gives faster results.

'''TTL''' of the cached items can be relatively high (higher on the sub-pages than on the front page), because we offer the feeds to open up an additional window into the community and not to be a direct, always-up-to-date information resource.

== Implementation ==

There are several different options (subject to evaluation):

=== Write a parser from scratch ===
* + maybe better performance
* + would hopefully be exactly what we want
* - more development time
* - not as well tested as other solutions

=== Zend Framework ===
* New BSD license
* very modular and flexible
* PHP5 only (read: makes use of new OOP features, which is good)
* well maintained, active development
* DB abstraction layer, cache handling
* some known issues, API a bit counter-intuitive in places
* probably not as heavily tested as other solutions (because relatively new)

=== PEAR ===
* XML_Feed_Parser
** LGPL license
** No maintainer
* XML_RSS
** PHP license
** No active development (last version from 06)
=== SimplePie ===
* BSD license
* Caching out of the box (flat file only right now, but could be overloaded with own DB-class)
* Meshing of multiple feeds out of the box
* Problems with some feeds, but workarounds exist
* Nice API

=== Other ===

Websites/Mozilla.org/Archive/Design Implementation/RSS

2009-05-14T21:32:01Z

FeyP: /* How to do it */

== What we want to do ==

We want a feed parser that

* pulls latest feed info from feeds.mozilla.com for front page
* pulls latest feed info from news.rdf (for now) for front page
* optionally: creates mash ups of multiple feeds on sub-pages (e.g. ''Our causes'' > ''Education'')

== How to do it ==

Mozilla.org has a lot of visitors, so we probably want to '''cache feed items''' for some time to a) be nice to the feed provider and b) get better performance.

We probably want a '''database-based cache''' over a file-based cache, because it gives faster results.

'''TTL''' of the cached items can be relatively high (higher on the sub-pages than on the front page), because we offer the feeds to open up an additional window into the community and not to be a direct, always-up-to-date information resource.

== Implementation ==

There are several different options (subject to evaluation):

=== Write a parser from scratch ===
* + maybe better performance
* + would hopefully be exactly what we want
* - more development time
* - not as well tested as other solutions

=== Zend Framework ===
* New BSD license
* very modular
* well maintained, active development
* DB abstraction layer, cache handling
=== PEAR ===
* XML_Feed_Parser
** LGPL license
** No maintainer
* XML_RSS
** PHP license
** No active development (last version from 06)
=== SimplePie ===
* BSD license
* Caching out of the box (flat file only right now, but could be overloaded with own DB-class)
* Meshing of multiple feeds out of the box
* Problems with some feeds, but workarounds exist
* Nice API

=== Other ===

Websites/Mozilla.org/Archive/Design Implementation/RSS

2009-05-14T21:16:04Z

FeyP: /* Write a parser from scratch */

Websites/Mozilla.org/Archive/Design Implementation/RSS

2009-05-14T21:02:30Z

FeyP: /* How to do it */

Websites/Mozilla.org/Archive/Design Implementation/RSS

2009-05-14T20:55:05Z

FeyP: /* Implementation */

Websites/Mozilla.org/Archive/Design Implementation/RSS

2009-05-14T20:48:47Z

FeyP: first evaluation results

Websites/Mozilla.org/Archive/Design Implementation/RSS

2009-05-14T18:58:05Z

FeyP: some initial thoughts

Websites/Mozilla.org/Archive/Design Implementation

2009-05-14T18:52:52Z

FeyP: /* What we need to get */ RSS parser page

== What we have now ==
Right now, we have a full "build" system. There's no dynamic part of the site. Each HTML file has the following:

* part of a header (<title>, <meta>, <link feed> sometimes
* a full body (including <body> tag)
* end tags for the <html>

The build system than pulls in a real header and footer along with an optional sidebar. There are a few varying templates for this which change the selected tab in the header and select the sidebar (if it's chosen). ([http://mxr.mozilla.org/mozilla-org/source/html/template-community.html?force=1 Template sample])

The inclusion for templates is done using HTML comments, e.g., . ([http://mxr.mozilla.org/mozilla-org/source/html/about/index.html?force=1 Sample HTML file])

There are, however, some pages that don't use the templates and, as I said above, some don't have a sidebar. To do this, there are two files that, when present in a directory, change the display of a page. If a NOMENU file exists, every listed HTML page listed will not receive a sidebar. Likewise, if a NOWRAP files exists, the entire styling for a page is not applied.

== What we need to get ==
To move to the new design, we need to do the following:

* write a script to determine which pages need overall styling and sidebar (based on NOMENU and NOWRAP)
* write a php header, footer, and sidebars for inclusion
* figure out and implement a localization plan (mozilla.com or different)
* create a script that cycles through principles in the footer (see Causes page for the design)
* [[Mozilla.org/Design Implementation/RSS|pull latest feed info from feeds.mozilla.com for front page]]
* [[Mozilla.org/Design Implementation/RSS|pull latest feed info from news.rdf (for now) for front page]]
* write a 404 handler that forwards to www-archive if a page exists
* land these changes in SVN instead of CVS

== Timeline ==
''TBD''

== Who and what they're doing ==
The following people are available to help:

* reed (scripting, php work)
* ss (whatever I can help with)
* david
* stephend (testing)

Websites/Mozilla.org/Archive/Causes/Accessibility

2009-05-08T23:10:27Z

FeyP: + Orca; At least in 2007 Mozilla made some grants to Orca, see Frank Heckers blog for more info

__NOTOC__
:''The Internet is an integral part of modern life, a global public resource that must remain open and accessible. - [http://www.mozilla.org/about/manifesto.en.html Mozilla Manifesto]''

Meeting this goal includes ensuring that Internet and web services are accessible to people with disabilities (whether permanent or
[http://www.utexas.edu/disability/ai/resource/tutorials_classes/Art_of_ALT/lesson1/situational.php situational]) through [http://www.asktog.com/columns/077InclusiveDesignPart1.html inclusive design] for Internet and web software and applications. We not only work to improve the accessibility of Firefox, Thunderbird, and other Mozilla-based products, but also work with others to help design and develop [http://en.wikipedia.org/wiki/Assistive_technology assistive technologies] that are used with Mozilla-based products to help make them more accessible.

== Priorities ==
* We work to ensure that everyone is able to access the Internet, regardless of their computer platform, economic situation, native language, or other factors, through our support for
** development of accessible free and open source software such as Firefox and Thunderbird
** development of free and open source assistive technologies such as screen readers
* We work to ensure that as the Internet and web evolve to encompass innovative new applications and technologies, those innovations are accessible. This includes making a commitment to accessibility in new innovations developed at Mozilla.
* We work to ensure that making applications accessible is a core task of Internet and web developers, including developing tools to integrate accessibility testing and accessible design into the standard web development process.

== Software ==

* [http://support.mozilla.com/en-US/kb/New+Accessibility+features+in+Firefox+3 Firefox 3 accessibility features]
* [http://http://live.gnome.org/Orca Orca open source screenreader]
* ''need more examples''

== Advocacy ==

* We helped create and have promoted the new WAI-ARIA standard for improving the accessibility of complex web applications.
* ''need more examples''

== Grants ==

* $X to support addition of WAI-ARIA support to Firefox.
* $X to support development of the NVDA free and open source screen readers for blind and other visually-impaired users of Microsoft Windows.
* $X to add accessibility testing functionality to the popular Firebug extension for web developers

== Get involved ==
* Learn more about
** [https://wiki.mozilla.org/Accessibility/Strategy our Mozilla accessibility strategy]
** [https://wiki.mozilla.org/Accessibility overview of Mozilla accessibility efforts]
** [https://developer.mozilla.org/en/Accessibility accessibility information for Mozilla and web developers]
* Connect with the Mozilla accessibility community
** the [irc://irc.mozilla.org/accessibility #accessibility] channel on the [https://wiki.mozilla.org/Education/Learning/Irc Mozilla IRC network] provides an interactive way to communicate with others interested in Mozilla and accessibility.
** the [news:news.mozilla.org/mozilla.dev.accessibility mozilla.dev.accessibility] newsgroup and the corresponding [https://lists.mozilla.org/listinfo/education dev-accessibility@lists.mozilla.org mailing list] and [http://groups.google.com/group/mozilla.dev.accessibility/topics Mozilla accessibility Google Group] support more structured discussion on Mozilla and accessibility topics.
** [http://www.marcozehe.de/ Marco Zehe's blog] is a good place for topical information on Mozilla and accessibility.
* Help support Mozilla-related accessibility projects through your [http://www.mozilla.org/access/donate.html donation].

Mozilla.org/Redesign/Questionnaire

2009-02-11T00:49:44Z

FeyP: /* Feedback */

__NOTOC__

[[Mozilla.org/Redesign|« Mozilla.org Redesign Central]]

Happy Cog has provided us with a questionnaire to fill out to get a better understanding of the mozilla.org redesign. We've reproduced it below. Please provide feedback in the last section.

== Goals & Strategies ==
=== User Goals ===
* Who are the core users of the site? How old are they? More demo info, please.
** The core users are Mozilla community members. They range in age from 13 to 60 and beyond. There's no set demographic for who participates in the Mozilla community. Traditionally, community members have been male programmers, but this has grown quite a bit and now includes programmers, testers, marketers, writers, designers, and more of both sexes, all races, and every continent in the world.
* What does the user want to accomplish when they arrive at the site? What is the primary action you would like them to take?
** We believe people are coming to the site to find some information about the community. Many people will be looking for how to download Firefox or Thunderbird, but others will be wanting to find out about other parts of the Mozilla community (such as a link to the Romanian localization community's web site).
* How long do you want them to stay on the site?
** Some users will stay quite a while as they delve into Mozilla and learn more about it. Most will likely stay on the site for a short period (seconds or minutes) as they're handed off to an affiliate site.
* Do you expect that they’ll have the latest technologies/browsers/plugins?
** We *hope* they will, but some certainly won't. We'll provide some browser stats for current visitors and aim to provide the site in terms all of them can view. We may want to take the opportunity to teach people with older browsers about the benefits of new browsers and new web standards. For instance, if we host a video on the site, we could insert a short introduction about open standards for anyone who needs to use a plug-in to access the video.
* What are the five most important things the home page MUST have? Why?
** This is a challenge since the community is big and diverse and there's a lot of content that is important to feature. We'll need to work through this, but an initial list includes:
*** Some intro text about Mozilla (seems obvious but there's not really any intro text in the current design)
*** A call-out for Installing Firefox/Thunderbird (and, likely, links to other products)
*** A feed from and a link to Planet Mozilla (maybe also one other news feed?)
*** A Donate button
*** Perhaps a button for the Mozilla Store

=== Marketing Goals and Strategies ===
* What are your current marketing goals? How will you promote this thing? Word-of-mouth? Blogs? Press? All of the above?
** Our users will arrive from all over, but most of them will know mozilla.org through word-of-mouth and blogs. Many visitors will already be members of the community and will know mozilla.org because of their interactions with other Mozilla properties. New visitors to the site will likely have heard about it through a blog or link from a different Mozilla property (like mozilla.com).
* Do you have any existing campaigns established? Do you have documentation for them?
** mozilla.org has never been traditionally marketed and there's no intention to change this.

== UX/Information Architecture ==
* What other sites out there do you feel does a great job from an experience point of view? Why?
** http://www.whitehouse.gov/ (at a recent discussion about site issues, someone mentioned that change.gov had a great design for a community-driven site)
** Feel free to add more links to this list...
* How are you envisioning the navigation working? Why?
* Are you of the feeling ‘less is more’ (37 Signals approach), or give them the works (Microsoft)?
** We're open to advice. There's a lot of content on www.mozilla.org (although we're reducing that through an archiving campaign) and a lot of content across the Mozilla community and it's not clear what's the best way to make that content easy to access.
* Do you like fixed width or liquid layouts? Why? What resolution do you want to support (if fixed)?
** We're open to feedback. One concern is that however we design the site that people can be able to use it on mobile devices. Our target is for general, Fennec-like mobile browsers (as in, the Real Web™), however.
* What words (category labels) do you feel would be meaningful to your audience?
** Hoping for community feedback on this...
* What content is searchable? Will there be metadata for content?
** Right now, all content is searchable and most of it (if not all) has been indexed by Google over the years.

== Content ==
* Who creates the content for the site? Is it written?
** A wide range of people are updating or have updated content on the site. Currently there is a group of community members who is driving the content update (and content archiving and migrating) process. More information about what this group is working on is on the [[Mozilla.org:Planning]] page.
* Whose responsibility is it to make content edits?
** Whoever owns the page is responsible for edits, although anyone with CVS access to the site can make changes and edits. For the home page and other key pages, the set of owners is listed in the document above.
* How often will the content be refreshed?
** It depends on the page. Some pages on the site haven't changed much, if at all, since 1998.
* Will you syndicate content via RSS? What types of content?
** Right now www.mozilla.org is consuming some feeds but doesn't have any feeds of it's own. I think this will change as the site work continues.
* Do you know what types of content your users will want?
* Do you ever anticipate adding an e-commerce component to this?
** There is a Mozilla Store (and a Mozilla Community Store) that we will need to link to, although the store itself is on a different site and has it's own design (there are three stores in fact).
* Do you plan on implementing forums as well as chat?
** We will likely not have forums hosted on www.mozilla.org but there are certainly forums in the community.

== Feedback ==
Please provide any feedback regarding the questions/answers above below.

* Don't know, if this is covered by "Some intro text about Mozilla", but what I would really like to see on mozilla.org (and prominently featured on the home page) is content on the goals and work of the Mozilla Foundation like openness, preserving choice and innovation on the internet, education programme. E.g. a monthly feature on one of those aspects, telling new visitors what Mozilla does to advance the goal and why it is important. Don't emphasize too much on products, emphasize on values.

User:FeyP

2007-02-21T13:20:02Z

FeyP:

Blog: [http://blog.nachtarbeiter.net/ http://blog.nachtarbeiter.net/]

Mozilla-related emails: bugzilla at nachtarbeiter dot net

= Current Mozilla-related work =

== Improving relic ==

=== Turn relic into a Tinderbox test ===

If I'm not to spend the rest of my life checking licensing, we need to turn relic into a tinderbox test, so people know immediately when they've checked in bad files or blocks. That is, we need a command line switch which puts it into a mode where it returns 0 if the results are of a certain form, or 1 (and some errors) otherwise (See http://developer.mozilla.org/en/docs/How_to_add_a_build-time_test for more info)

The form would be that all files either have MPL/LGPL/GPL (complete), unknown license or no license, and there are no processing errors.

User:FeyP

2007-02-11T10:44:08Z

FeyP: /* Continuation chars fix */ Examples added

Blog: [http://blog.nachtarbeiter.net/ http://blog.nachtarbeiter.net/]

Mozilla-related emails: bugzilla at nachtarbeiter dot net

= Current Mozilla-related work =

== Improving relic ==

=== Continuation chars fix ===

If you run relic on some of the new Tamarin files (js/tamarin), you'll see the problem. These have had a duff license block applied which relic doesn't correctly fix - it doesn't insert the "continuation character" at the beginning of each line because it's not there in the original. " *" is an example of a continuation character for the /* */ comment type.

The change: when writing out the new license block, we need to use the continuation char defined inside relic for that comment type, not one scanned from the file itself.

Examples:
* mozilla/js/tamarin/core/abcFormat.txt
* mozilla/js/tamarin/test/shell.as
* mozilla/js/tamarin/test/as3/AbcDecoder/useNS.as
* mozilla/js/tamarin/test/as3/AbcDecoder/typeAnnotation.as
* mozilla/js/tamarin/test/as3/AbcDecoder/accessSpecifiers.as

=== Make relic cope with non-tri-license Version headers ===

People have started using the LICENSE BLOCK headers with a different license name, and relic doesn't cope well. It should. One example is ./gfx/thebes/src/gfxQuartzFontCache.mm . Relic should probably categorise these as "unknown license" for now.

=== Make relic stop scanning a file if it detects a proper complete MPL/LGPL/GPL license block ===

At the moment, several files are labelled as silly things like "mpl/gpl/lgpl/mpl/gpl/lgpl", because they have a proper license block, but then another copy of the license in the body (because they autogenerate a file, for example). That needs to stop, but ideally without preventing us flagging up the case where there are two license headers in a file, one after the other.

To fix this, we stop scanning, if the second license block is more than 10 lines away from the first license block.

Some examples:
* mozilla/calendar/base/src/maketzdata.pl
* mozilla/extensions/java/xpcom/interfaces/gen-nsError.pl
* mozilla/intl/chardet/tools/genverifier.pm
* mozilla/intl/chardet/tools/gencyrillic.pl
* mozilla/intl/chardet/tools/charfreqtostat.pl
* mozilla/intl/chardet/tools/GenCyrillicClass.cpp
* mozilla/intl/lwbrk/tools/anzx4501.pl

=== Turn relic into a Tinderbox test ===

If I'm not to spend the rest of my life checking licensing, we need to turn relic into a tinderbox test, so people know immediately when they've checked in bad files or blocks. That is, we need a command line switch which puts it into a mode where it returns 0 if the results are of a certain form, or 1 (and some errors) otherwise (See http://developer.mozilla.org/en/docs/How_to_add_a_build-time_test for more info)

The form would be that all files either have MPL/LGPL/GPL (complete), unknown license or no license, and there are no processing errors.

User:FeyP

2007-02-11T07:57:18Z

FeyP: /* Make relic stop scanning a file if it detects a proper complete MPL/LGPL/GPL license block */ Possible fix

Blog: [http://blog.nachtarbeiter.net/ http://blog.nachtarbeiter.net/]

Mozilla-related emails: bugzilla at nachtarbeiter dot net

= Current Mozilla-related work =

== Improving relic ==

=== Continuation chars fix ===

If you run relic on some of the new Tamarin files (js/tamarin), you'll see the problem. These have had a duff license block applied which relic doesn't correctly fix - it doesn't insert the "continuation character" at the beginning of each line because it's not there in the original. " *" is an example of a continuation character for the /* */ comment type.

The change: when writing out the new license block, we need to use the continuation char defined inside relic for that comment type, not one scanned from the file itself.

=== Make relic cope with non-tri-license Version headers ===

People have started using the LICENSE BLOCK headers with a different license name, and relic doesn't cope well. It should. One example is ./gfx/thebes/src/gfxQuartzFontCache.mm . Relic should probably categorise these as "unknown license" for now.

=== Make relic stop scanning a file if it detects a proper complete MPL/LGPL/GPL license block ===

At the moment, several files are labelled as silly things like "mpl/gpl/lgpl/mpl/gpl/lgpl", because they have a proper license block, but then another copy of the license in the body (because they autogenerate a file, for example). That needs to stop, but ideally without preventing us flagging up the case where there are two license headers in a file, one after the other.

To fix this, we stop scanning, if the second license block is more than 10 lines away from the first license block.

Some examples:
* mozilla/calendar/base/src/maketzdata.pl
* mozilla/extensions/java/xpcom/interfaces/gen-nsError.pl
* mozilla/intl/chardet/tools/genverifier.pm
* mozilla/intl/chardet/tools/gencyrillic.pl
* mozilla/intl/chardet/tools/charfreqtostat.pl
* mozilla/intl/chardet/tools/GenCyrillicClass.cpp
* mozilla/intl/lwbrk/tools/anzx4501.pl

=== Turn relic into a Tinderbox test ===

If I'm not to spend the rest of my life checking licensing, we need to turn relic into a tinderbox test, so people know immediately when they've checked in bad files or blocks. That is, we need a command line switch which puts it into a mode where it returns 0 if the results are of a certain form, or 1 (and some errors) otherwise (See http://developer.mozilla.org/en/docs/How_to_add_a_build-time_test for more info)

The form would be that all files either have MPL/LGPL/GPL (complete), unknown license or no license, and there are no processing errors.

User:FeyP

2007-02-10T10:12:05Z

FeyP: /* Make relic stop scanning a file if it detects a proper complete MPL/LGPL/GPL license block */ More examples

Blog: [http://blog.nachtarbeiter.net/ http://blog.nachtarbeiter.net/]

Mozilla-related emails: bugzilla at nachtarbeiter dot net

= Current Mozilla-related work =

== Improving relic ==

=== Continuation chars fix ===

If you run relic on some of the new Tamarin files (js/tamarin), you'll see the problem. These have had a duff license block applied which relic doesn't correctly fix - it doesn't insert the "continuation character" at the beginning of each line because it's not there in the original. " *" is an example of a continuation character for the /* */ comment type.

The change: when writing out the new license block, we need to use the continuation char defined inside relic for that comment type, not one scanned from the file itself.

=== Make relic cope with non-tri-license Version headers ===

People have started using the LICENSE BLOCK headers with a different license name, and relic doesn't cope well. It should. One example is ./gfx/thebes/src/gfxQuartzFontCache.mm . Relic should probably categorise these as "unknown license" for now.

=== Make relic stop scanning a file if it detects a proper complete MPL/LGPL/GPL license block ===

At the moment, several files are labelled as silly things like "mpl/gpl/lgpl/mpl/gpl/lgpl", because they have a proper license block, but then another copy of the license in the body (because they autogenerate a file, for example). That needs to stop, but ideally without preventing us flagging up the case where there are two license headers in a file, one after the other.

Some examples:
* mozilla/calendar/base/src/maketzdata.pl
* mozilla/extensions/java/xpcom/interfaces/gen-nsError.pl
* mozilla/intl/chardet/tools/genverifier.pm
* mozilla/intl/chardet/tools/gencyrillic.pl
* mozilla/intl/chardet/tools/charfreqtostat.pl
* mozilla/intl/chardet/tools/GenCyrillicClass.cpp
* mozilla/intl/lwbrk/tools/anzx4501.pl

=== Turn relic into a Tinderbox test ===

If I'm not to spend the rest of my life checking licensing, we need to turn relic into a tinderbox test, so people know immediately when they've checked in bad files or blocks. That is, we need a command line switch which puts it into a mode where it returns 0 if the results are of a certain form, or 1 (and some errors) otherwise (See http://developer.mozilla.org/en/docs/How_to_add_a_build-time_test for more info)

The form would be that all files either have MPL/LGPL/GPL (complete), unknown license or no license, and there are no processing errors.

User:FeyP

2007-02-10T10:06:01Z

FeyP: Added example for file autogenerating a file

Blog: [http://blog.nachtarbeiter.net/ http://blog.nachtarbeiter.net/]

Mozilla-related emails: bugzilla at nachtarbeiter dot net

= Current Mozilla-related work =

== Improving relic ==

=== Continuation chars fix ===

If you run relic on some of the new Tamarin files (js/tamarin), you'll see the problem. These have had a duff license block applied which relic doesn't correctly fix - it doesn't insert the "continuation character" at the beginning of each line because it's not there in the original. " *" is an example of a continuation character for the /* */ comment type.

The change: when writing out the new license block, we need to use the continuation char defined inside relic for that comment type, not one scanned from the file itself.

=== Make relic cope with non-tri-license Version headers ===

People have started using the LICENSE BLOCK headers with a different license name, and relic doesn't cope well. It should. One example is ./gfx/thebes/src/gfxQuartzFontCache.mm . Relic should probably categorise these as "unknown license" for now.

=== Make relic stop scanning a file if it detects a proper complete MPL/LGPL/GPL license block ===

At the moment, several files are labelled as silly things like "mpl/gpl/lgpl/mpl/gpl/lgpl", because they have a proper license block, but then another copy of the license in the body (because they autogenerate a file, for example). That needs to stop, but ideally without preventing us flagging up the case where there are two license headers in a file, one after the other.

Examples:
* mozilla/calendar/base/src/maketzdata.pl

=== Turn relic into a Tinderbox test ===

If I'm not to spend the rest of my life checking licensing, we need to turn relic into a tinderbox test, so people know immediately when they've checked in bad files or blocks. That is, we need a command line switch which puts it into a mode where it returns 0 if the results are of a certain form, or 1 (and some errors) otherwise (See http://developer.mozilla.org/en/docs/How_to_add_a_build-time_test for more info)

The form would be that all files either have MPL/LGPL/GPL (complete), unknown license or no license, and there are no processing errors.

User:FeyP

2007-02-09T17:34:28Z

FeyP: added info on relic work

Blog: [http://blog.nachtarbeiter.net/ http://blog.nachtarbeiter.net/]

Mozilla-related emails: bugzilla at nachtarbeiter dot net

= Current Mozilla-related work =

== Improving relic ==

=== Continuation chars fix ===

If you run relic on some of the new Tamarin files (js/tamarin), you'll see the problem. These have had a duff license block applied which relic doesn't correctly fix - it doesn't insert the "continuation character" at the beginning of each line because it's not there in the original. " *" is an example of a continuation character for the /* */ comment type.

The change: when writing out the new license block, we need to use the continuation char defined inside relic for that comment type, not one scanned from the file itself.

=== Make relic cope with non-tri-license Version headers ===

People have started using the LICENSE BLOCK headers with a different license name, and relic doesn't cope well. It should. One example is ./gfx/thebes/src/gfxQuartzFontCache.mm . Relic should probably categorise these as "unknown license" for now.

=== Make relic stop scanning a file if it detects a proper complete MPL/LGPL/GPL license block ===

At the moment, several files are labelled as silly things like "mpl/gpl/lgpl/mpl/gpl/lgpl", because they have a proper license block, but then another copy of the license in the body (because they autogenerate a file, for example). That needs to stop, but ideally without preventing us flagging up the case where there are two license headers in a file, one after the other.

=== Turn relic into a Tinderbox test ===

If I'm not to spend the rest of my life checking licensing, we need to turn relic into a tinderbox test, so people know immediately when they've checked in bad files or blocks. That is, we need a command line switch which puts it into a mode where it returns 0 if the results are of a certain form, or 1 (and some errors) otherwise (See http://developer.mozilla.org/en/docs/How_to_add_a_build-time_test for more info)

The form would be that all files either have MPL/LGPL/GPL (complete), unknown license or no license, and there are no processing errors.

User:Dria/On Tagging

2006-01-19T21:53:04Z

FeyP: /* Default Tags */ Corrected typo

Mozilla.com/Localization

2005-12-14T00:33:26Z

FeyP: /* The Team */

[[Mozilla.com|< back to Mozilla.com wiki page]]

This page is a resource for discussing changes and updates to mozilla.com to improve access for non-English speaking users.

Here is a stub of discussion areas to be filled in with input from the international community.

=Use Cases=
These are the use cases that require internationalization of mozilla.com pages. They are listed in order of expected frequency.

* '''(primary)''' International users coming to main mozilla.com URLs to learn about our products and obtain our software.

* ''(secondary)'' Users looking for a build in a specific language which may or may not be their primary language (for testing, exploration, etc.)

* ''(secondary)'' Users looking for support in their language.

=The Team=
Who'd like to help us? We'll need:
* translators
* sysadmins
* testers
Request for volunteers posted to:
http://groups.google.com/group/netscape.public.mozilla.l10n/

Volunteers:
* Catalan-Valencian [ca]: [[User:Toniher|Toni Hermoso]], [http://www.softcatala.org/wiki/Mozilla Projecte Mozilla en català] Translators, sysadmins, testers
* Czech [cs]: [http://www.czilla.cz/ CZilla] (Czech Mozilla Project) - [[User:Pawell|Pavel Franc]]. Translators, testers.
* Dutch: [[User:up north|marco casteleijn]]. Translator, Tester.
* Georgian [ka]: [http://www.gia.ge/ GIA team] [http://www.mozillage.org/ MozillaGe], [[User:Giasher|Gia Shervashidze]] translators, sysadmins, testers.
* Hungarian [hu]: [[User:AndrasBarthazi|András Bártházi]] [http://firefox.hu/ Firefox.hu] translators, sysadmins, testers.
* Italian [it]: [[User:dalco|Michele Dal Corso]] [http://www.mozillaitalia.org/ Associazione Italiana Supporto e Traduzione Mozilla] translators and testers.
* Polish [pl]: [[User:Marcoos|Marek Stępień]] and the whole [http://aviary.pl/ AviaryPL Team] - translators, testers;
* Portuguese [pt-BR]: [[User:Hultmann|Jeferson Hultmann]]. Translator.
* Russian [ru]: [[User:Unghost|Alexander Slovesnik]]. Translator.
* Spanish [es]: [[User:Villa|Jorge Villalobos]]. Translator, sysadmin, tester.
* Turkish [tr]: [[User:Asteko|Ahmet Serkan Tıratacı]], [http://mozilla.org.tr Mozilla Türkiye]. Translator, sysadmin, tester.
* Ukrainian [uk]: [[User:didaio|Denis Davydov]], didaio''[at]''gmail.com. Translator, sysadmin, tester
* Danish [da]: [[User:Dikrib|Jesper Kristensen]], translator.
* French [fr]: [[User:Mathieu Deaudelin|Mathieu Deaudelin]], translator, tester.
* German [de]: [[User:FeyP|Patrick Fey]], Translator, sysadmin, tester.

=Potential Solutions=
Add ideas for how we can best design the internationalization experience for our users. No idea is too wacky, simple or complex. For each, please list:
* the idea in a nutshell
* implementation requirements
* any pros/cons you can think of

== Use Accept-Language Headers ==
Use Apache's support for [http://httpd.apache.org/docs/2.0/content-negotiation.html content negotiation] to serve the pages in the language requested by the browser's "Accept-Language" header.

'''Requirements'''
* user's browser sends the appropriate accept-language header
* mozilla.com's apache can be configured to serve appropriate pages
* fallback for languages we don't support / default language
'''Pros'''
* transparent to user and makes best use of available technology
'''Cons'''
* requires that user has browser that sends correct header

'''Feedback from netscape.public.mozilla.l10n''' 
''Author: Victory'' 
To use content-negotiation, you should use 'filename'.'lang'.html or 'filename'.html.'lang' form, not 'filename'.html.
Note that there's a problem that typical users don't configure their
browser correctly so this often doesn't make sense by only
content-negotiation so Apache docs use trick in their httpd.conf. 
''Author: Sebastian.Moser'' 
most users don't configure their browser at all, because they are bundled with the operating system (it's the same with linux). users that are capable of changing their browser's configuration should also bbe able to either configure it correctly or read english text.
i like the mozilla-europe.org-approach more (a folder for every language), with making it able for users to switch the language they use. an additional possibility would be to save the language used in a cookie, so that if the accept-language-header-value doesn't fit to the user's selection, this will be saved. 
''Author: Tsee'' 
Obviously, there should be a prominent link for, say, users who travel from the U.S. to China and have no idea what they're looking at.

'''Some practical advice from mozilla-europe.org''' 
''Author: fantasai'' 
The home page uses Accept-Language Headers to redirect to appropriate to the appropriate directory, named after the language code, e.g. /fr/ for FR-fr users. When they are there, no more language sniffing is done, which enables them to switch language if needed, using the list of links in the page footer.

'''Cons'''
* For specific documents people will always be linking the non-negotiated URLs
* Doesn't handle partial translations (some files, not others)

== Use Gerv's method ==

I've [http://www.gerv.net/hacking/language-selection/ written up a method] for using Content-Negotiation with a per-page override and sensible bookmarking, that I use on another site. It'll handle partial translation. The only restriction is that all URLs within the site must be relative; whether that's reasonable or not depends on what the site is. Feel free to use it if it works for you.

=Timeline=

* Dec 17 - collect potential solutions, build out team
* Dec 20 - have plan for solution in place
* Jan 20 - have implemented solution in place

=Track implementation=
Any bugs created to implement the plan will be listed here for tracking purposes.

User:FeyP

2005-12-14T00:29:12Z

FeyP:

Blog: [http://blog.nachtarbeiter.net/ http://blog.nachtarbeiter.net/]

Mozilla related emails: bugzilla at fey dash network dot de

User:FeyP

2005-12-14T00:28:51Z

FeyP: Added some content.

Blog: [http://blog.nachtarbeiter.net/ http://blog.nachtarbeiter.net/ My Blog]

Mozilla related emails: bugzilla at fey dash network dot de