Update:Archive/2.0/Developers

From MozillaWiki
Jump to: navigation, search

Update: Home Page » Development »

v2.0 Goals

  • security
  • reliability
  • extensibility
  • reputation
  • communication
  • localization

Using sound teamwork, we will develop a secure, robust, extensible application that will bolster the success of the Mozilla Foundation and the community it supports.

Team

  • bsmedberg
  • chip
  • chrisblore
  • Colin
  • CTho
  • justdave
  • kveton
  • luser
  • mao
  • morgamic

Project Outline

  1. Planning / Requirements
    1. Project Standards
    2. Libraries and Tools
    3. Application Structure
  2. Development
    1. Public Pages
    2. Developer Tools
  3. Staging
  4. Debugging
  5. Beta Release

Project Standards

The following describes the standards and tools we'll be using for the v2.0 rewrite of UMO.

Language

PHP 4.3.x. PHP 5.0 does not tie in well with the existing MoFo infrastructure. We did consider alternatives.

Template Engine

Smarty. It is widespread and easy to implement.

Database Abstraction

PEAR::DB. A standard part of the PEAR suite with likeness to Perl's DBI.

Database Server (RDBMS)

MySQL 4.1.

Licensing

The original UMO uses a triple license: MPL 1.1/GPL 2.0/LGPL 2.1. We will continue to do the same for v2.0 of UMO.

Coding Standards

PEAR Coding Standards. This standards guide is fairly standard fare for PHP applications.

We will do our best to adhere to the Mozilla coding standards. Since not many Mozilla projects are written in PHP, we have developed our own where necessary.

TODO

  • lib/session.class.php
  • lib/auth.class.php
    • simple session checker and auth module.
    • PEAR::Auth?
  • addcomment.php - Colin
    • form
    • spam prevention - require login
    • input validation
  • addon.php
    • sidebar
    • show compat information
  • history.php - Colin
    • show all past versions - initially done but needs improvement...
    • simplify?
  • index.php
    • make it look more like overview.php?
  • previews.php - Colin
    • Show all Addon previews.
  • ratecomment.php - Colin
    • spam prevention This needs to be thought about.
    • other than that, this is a simple toggle script.
    • login isn't required for this particular page.
  • search.php
    • highlight search results
    • Create search form based on DB.
    • Filter inputs.
    • Document needed options.
    • Create jump-to for one-result searches.
  • header / footer / style
    • Fix key-menu so that it is simplified. Each app link should be a tab, instead of offering 3 different choices per.
    • Make the search stick out more -- this is a key feature of this site.
    • Make sure CSS changes work in multiple browsers.
  • addon.class.php
    • Move manual queries in constructor to respective functions (i.e. getLatestVersion() instead of a hard query)

Use-cases and Requirements

Users

User Use-Case Diagram

Main Page

  • Search
  • Featured items
  • Short blurb about UMO
  • Links
    • Developers section
    • About (Wiki)
    • FAQ (Wiki)
    • Affiliates (Wiki)
    • MoFo
I think we should have shortcuts like we have today for items such as Firefox Extensions and Firefox Themes. You'd hover over the application "tab" and then see what's available for it show up in the next row. -alanjstr 2005-06-01 14:10 EST
I disagree on the hovering part... it seems like it'd be nonobvious that you have to hover. --CTho 19:02, 13 Jun 2005 (PDT)
All (Wiki) content indicated above should be part of the main site, in my opinion. The wiki shouldn't be used for anything 'official' to do with the site, it is a lot easier to get an account and maliciously edit pages on the wiki than it would be to maliciously edit pages on the main site. --Colin 16:10, 15 Jun 2005 (PDT)
How about a "my favorite extensions" section with details of latest versions and comments. Users could then "bookmark" extensions they're interested in, but might not have installed. It could also automatically keep track of extensions installed, and visted but uninstalled extensions (something like Google's My Search History). It might encourage more users to register as it's providing something of value to them. Stats could be used for recomendations. You could also track which extensions are being removed from peoples favorites. --Sam 14:25, 17 Jun 2005 (PDT)


Heh. No one has written here in awhile.

Maybe I'm missing something, but the main page right now doesn't even have links to look for TB extensions, or extensions for any other Moz apps besides FF. Clicking on the extensions button on the front page automatically takes you into a page showing FF extensions. So... is there no way to get to TB extensions without either going through TB or doing some sort of search? --[[User:Wjjohnst|DigDug] 22:20 05 Oct, 2006

Search By...

  • Application [all]
  • Application Version [newest]
  • Category [any]
  • Keyword [blank]
  • Date [this week]
  • Operating System [any]
  • Locale? [en-us]
Date of what? What do you mean by "this week". -alanjstr 2005-06-01 14:12 EST

Results List

  • Allow ASC or DESC sorting per category via clicking on column header
  • Allow user to choose compact or expanded view
    • Compact -- Show only vital items, all in one row, text-only
    • Expanded -- Show everything UMO shows now
  • Give user a link to Download/Install or view Item Home page

We could alternatively use hover-divs to show item details when a user mouses over a simpler list... just an idea. An example of this would be the hover features found in WebCalendar (http://webcalendar.sourceforge.net/demo/week.php)

sorting is fine as long as we're not resubmitting. We should take advantage of DHTML here. An option to expand each/all would be good. I'm not a fan of hover-overs. What about pagination? Are we going to show 1000 on one page? -alanjstr 2005-06-01 14:14 EST
so, this means we need to use a column-type display for the results. I'm not sure if that's always good. Maybe only use it for advanced searches, but quicksearch gets the current-style result list? --CTho 19:05, 13 Jun 2005 (PDT)

I would go for search results that have an extended result by clicking on an image with the "more" concept. Those extended results would be hidden in DIVs that will be shown bellow the line of the extension summary when the user clicks the "more" image. This is client side or if we want smaller pages we can use AJAX to bring this extended content when needed. --DonGato 11:57, 28 Nov 2006 (GMT)

Item Home

  • Item home must contain:
    • Item previews and screenshot thumbnails
    • Links:
      • Download/Install

      • Revision history
      • Author information
      • View all previews/screenshots

      • View all comments
      • View comments which were rated most helpful by users
      • Rate comment's helpfulness (shown with a given comment)
      • Add a comment

[why not initially base these specs on what already exists on the current UMO site item-home page, and include everything which is on that page?]

Comments / Reviews

  • Complete listing of all comments
  • Sort by date or user rating
  • Link to rate comments, shown with comment
  • Link to add a new comment
this is getting into metamoderation, which needs more discussion. -alanjstr 2005-06-01 14:16 EST
Further to the discussion on #umo, I'm thinking we need some sort of trackability as with the approval log for comment reviewers. This gives a degree of accountability that we can fall back on if necessary.
We also need to prevent reviewers that are also developers from moderating the comments on their own extension.
Also, some sort of threadability would be useful so that you would be able to directly reply to comments in a sort of 'forum style'. This of course may not be necessary if we actually do build in a forum type system (possibly in collaboration with extensionsmirror.nl) but as I understood it, this has not been agreed yet. --Chrisblore 13:54, 27 Jun 2005 (PDT)

Adding a New Comment

  • Encourage account registration
  • Current rate limiting enough? Captcha? Thoughts?
Comments
I think it would be a good idea to have a preview of some sort for comments prior to their submission. While we are only dealing with plain text, it can increase the quality of the comments if people actually have the opportunity to double check their typing as it will appear when submitted. Bug 295322 was filed by someone requesting this.--Chrisblore 07:51, 24 May 2005 (PDT)
encourage ... or force registration? I agree that we should make them preview. It will also help throttle anyone running amuck. -alanjstr 2005-06-01 14:17 EST
if we don't require registration, we need a reasonable way to handle abusers. requiring registration would discourage abuse, but also probably discourage people who don't want to bother signing up. if we require a confirmation email, that would REALLY discourage quick commenters (e.g. someone downloads it, likes it, and wants to say, "cool!" but isn't willing to put up with registration or email confirmations) --CTho 19:09, 13 Jun 2005 (PDT)

Item Author Information

  • Same as current
please document anyways -alanjstr 2005-06-01 14:12 EST

Item Version History

  • Same as current
please document anyways -alanjstr 2005-06-01 14:12 EST

User Preferences

  • Set preferred OS
  • Set default application
  • Set default application version
  • Set default locale?
  • Set default view for listings (per-page, etc.)
  • Other cookie-based options?
if the user is logged in, can we store this on the server? What if a user has TB and FX? Can we save both? I'd skip app version and just track app/OS, assuming that most people will upgrade. -alanjstr 2005-06-01 14:16 EST

Supporting Site Content

  • About UMO
  • News
  • FAQ
  • Policy
  • Developer policies and guide - Wiki
  • Reviewer policies and guide - Wiki
Comments
I disagree with outsourcing most, if not all of this to a Wiki. I believe that pages about a site, updates and news about a site and FAQs about a site should be on the site in question. I'd also expect policies about a site to be on the site in question too. --Colin 09:42, 18 May 2005 (PDT
As would I. It's much easier to keep track of documents as well if they are on the same site. We need to make sure that the developer and reviewer guides are available directly and easily from their respective control panels.--Chrisblore 06:50, 22 May 2005 (PDT)
Policies should be read-only, signed off by legal, and posted on the site. Everything else can be in the wiki. -alanjstr 2005-06-01 14:16 EST
I agree with your comments. Guides, however, are constantly updated and should be placed in a Wiki where they can be maintained. They are relatively dynamic in nature and placing them in the application itself would be very limiting. -morgamic

Developers

Developer Use-Case Diagram

Up for discussion is:

  • Where if at all to insert locale support... ?
  • How are we going to tie-in to mentioned forums?
    • Would it not be simpler just to have a link? --Colin 16:08, 15 Jun 2005 (PDT)
Should be able to see the review queue -alanjstr 2005-06-01 14:38 EST

Edit Author profile

  • Username
  • Name
  • Homepage
  • Email (optional)
Email should be required, and should be valid IMO. --Colin 07:50, 24 May 2005 (PDT)
Email should be required and compulsarily shown in my opinion as it makes it possible to contact the authors privately about their extensions without having to use the content system --Chrisblore 03:41, 25 May 2005 (PDT)
I agree. email should always be required. We should have a bullet point for being on the mailing list. Also, any change of email address must be verified before further action can be taken. -alanjstr 2005-06-01 14:28 EST
What is the need for Real Name? -alanjstr 2005-06-01 15:14 EST
So it can be shown on the extension page - much nicer than the email address. --Colin 12:15, 7 Jun 2005 (PDT)
We don't show email address on the extension page unless they want to show it. -alanjstr 2005-06-15 19:45 EST
  • Show Email (yes|no)
  • Link to passwd change
Change Password
  • Simple chpw, as a new page or integrated -- either way
  • Verify it, also do not allow stupid passwords...

Create a new Addon

  1. Upload file
  2. Check details, choose category, etc.
    1. Name
    2. Authors
    3. Version
    4. OS
    5. Filename (read only)
    6. Applications: [minver] - [maxver] -- maxver should allow future versions as well (verify that minver < maxver)
    7. Homepage (url, use regexp)
    8. Description (bbcode)
    9. Version Notes (bbcode)
    10. Categories (multiple)
  3. Submit to queue
  4. Confirmation
We should pull as much of this from the install.rdf as possible. We should also determine whether it is an extension or theme based on the install.rdf. -alanjstr 2005-06-01 14:30 EST
Agreed, pulling as much from the RDF as possible would be useful. --Colin 12:17, 7 Jun 2005 (PDT)
Maxver should still be controlled by the admins. We just need to stay further ahead of the game. -alanjstr 2005-06-01 14:30 EST
Should allow multiple OSes without forcing OS ALL -alanjstr 2005-06-01 14:33 EST
Agreed --CTho 19:17, 13 Jun 2005 (PDT)
If addon authors are allowed to set maxver to future versions, many will just set it to a nominal large number such as 5.0, which will confuse some users into thinking Firefox 5.0 actually exists yet. Instead, maxver should be restricted to the current version (the app.extensions.version of the latest nightly; admins must keep this up-to-date), but registered users who know how to work around it should be allowed to increase the maxver for any addon (up to the current version). -- Greg K Nicholson 2005-06-03
Agreed. MaxVer should be limited to latest nightly's string. --CTho 19:17, 13 Jun 2005 (PDT)

My Addons

  • List of all your addons columns (sortable) are:
    • Name
    • Downloads
    • Rating
    • Version (latest)
    • Date created
    • Comments
    • # of Screenshots
    • # of Forum Posts
  • All actions can be executed from this page (see below... Edit addon details, View comments, etc.)
  • Alternatively, clicking on an Addon takes the user into "View Addon profile"

View Addon profile

  • Provide item overview, show a mirror image of public profile with edit links to:
    • Edit details
    • View/Edit comments
    • Edit Versions
    • Add a new Version
    • Screenshots
    • Forum discussions

Edit Addon details

  • Name
  • Authors
  • Homepage
  • Description
  • Forum / Support?

View Addon comments

Flag comment for review (give reason)
  • Flags comment for review
  • While under review it is no longer public
  • Developer must provide a reason why it was flagged
Reply to a comment
  • Developer may issue replies in a threaded fashion
Edit/delete a Reply
  • Any content created by the Developer may be edited or destroyed, it belongs to them
  • They cannot edit user comments, however

Add a new version

  1. Choose existing extension
  2. Read RDF and compare to current information
  3. Keep existing or overwrite with new?
  4. Require changelog (bbcode)
  5. Applications / compatibility
  6. OS
Should pretty much be the same as the regular Add screen. -alanjstr 2005-06-01 14:30 EST

Edit Version info

  • Target application min/max update
  • Changelog update
  • OS update

Screenshots

  • Show thumbnails plus captions
  • Clicking on a screenshot lets you edit the caption
Clicking on the screenshot should expand the screenshot to fullsize. Many screenshot thumbnails may look very similar. Instead, the text maybe should be a link to edit the caption, or if no caption exists "Click here to insert caption" may be appropriate --Blind487 16:40, 30 May 2005 (PDT)
Add new Screenshot
  • Upload image file
  • Validate size and dimensions
  • Make this your highlight image?
  • Caption (optional)
Remove Screenshot
  • Delete screenshot
  • Cannot delete highlight image
Make a Screenshot the highlight
  • Link next to the thumbnails that sets the "highlight" flag -- pretty easy

Forum discussions

  • Announcements / Stickies
  • Most active
  • Newest
  • Where will this come from? RSS? Direct DB conn?

Reviewers

Reviewer Use-Case Diagram

Approval Queue

  • List of submitted addons
  • Sortable columns
    • Title
    • Author
    • Date
    • Install / Download Link
    • # Previews
    • Date Submitted
    • Priority
    • # Reviews
    • Apps
  • Actions
    • View / Edit
    • Add a review
    • Approve / Reject
    • Email author

Addon Reviews

  • List of submitted reviews for a given addon
  • Sortable columns (something to think about)
    • OS
    • App
    • Install
    • Uninstall
    • App Works?
    • Clean Profile?
    • Visual Errors?
    • Theme Complete?
    • Previews?
  • Actions
    • Email Author
    • Add a Review
    • Edit Addon versions (compatibility, addon details)
    • View Previews

Email Author =

  • Send email to author - can be done from main list

Install or Download =

  • Must be able to install or download an addon, regardless of application.

Add a Review

  • Fill in addon checklist...
  • Items to check?

Edit Addon Versions

  • Adjust compatibility and app maps.

Approve or Deny

  • Deny requires a reason.

View Previews

  • Open in new window, next/prev/close window.

Administrators

  • Administrators should basically have all the general functionality of all other user groups, with added rights to _all_ records and the ability to edit/bless user accounts.
  • It's currently too hard to create new reviewers - it requires receiving an email (the intial request), replying to tell the user to create an account, waiting for the reply, then granting them Editor privileges. This should be streamlined - maybe just a "Volunteer to be a reviewer" button on the developer pages? --CTho 17:58, 4 Oct 2005 (PDT)

Systems

  • Work with client developers to determine improved interface for addon installations and updates.
  • The way it currently works is acceptable. When we decide on a new interface / API for how to handle addon updating, we can just increment the updater version.

Database Structure

v2.0 will be rewritten using the existing database structure.

Thanks to Colin for drawing up the diagram.

Known Issues

  • Lacks proper normalization
  • Incorrect typing
  • Non-optimal indexing
  • Non-optimal version comparisons

These issues will be worked on over time. They are not, however, so serious that a complete restructuring is required for v2.0.

Garbage

For fun, here is the now-obselete v2.0 db diagram (05/18). It was made with GraphViz; view the source file.

Application Structure

.htaccess 
Set up include_path, prepend and append options.
addcomment.php 
Add a new comment.
ratecomment.php 
Rate an existing comment.
comments.php 
View comments for an addon.
css/ 
CSS layout and formatting.
developers 
Developer tools used by developers, reviewers and admins.
faq.php 
Frequently Asked Questions.
history.php 
View an addon's previous versions.
img 
Site images.
inc 
Site includes. config.php, init.php, finish.php.
index.php 
Main page.
addon.php 
An addon's main page.
lib 
Supporting library and class files.
LICENSE 
Application license.
README 
Installation instructions for site developers.
previews.php 
Addon previews.
rss 
Syndicated information for addons based on type and application.
search.php 
Search for addons using a simple search, or expand simple search to refine your search.
sql 
Application database structure.
tpl 
Smarty templates placed in this directory are used for all output.

Expected Behavior (client-side)

Extensions

  • If a newer version is available, display update information.
  • If there is information on the current version, display information so client can update extension metadata.
  • Cases where there is no output (expected error code):
    • Bad inputs (1)
    • Failed query or no DB connection (2)
    • No results (3)
    • Client extension version is greater than anything in UMO database (4)
    • Downloaded .xpi does not match reported size (5)
  • There is a need client-side to implement better update features for addons, similar to those found in [Software Update]. In particular, hash checking and improved error handling (for errors above) would be great additions.

UI Tweaks

  • Alignment of title / drop-down on 'Search Options' sidebar would look better uniform (columned).
  • Blue bar at the top (below 'mozilla update' text) looks incredibly empty, especially towards the right. If it's going to remain empty, perhaps consider moving the search to the right.
  • Tabs on home page
    • Incredibly plain / square.
    • Blue on inactive tabs doesn't really fit with the rest of the UI.
    • Perhaps consider using the same style tabs as on the header of this wiki?
Retrieved from "https://wiki.mozilla.org/index.php?title=Update:Archive/2.0/Developers&oldid=55479"