Mozilla UK/revamp

From MozillaWiki
Jump to: navigation, search


Project Overview

Mozilla UK recently had a meet up in the new London space, where there was a lot of talk about what the point of the UK community is, what it should be doing, and what the future of the community portal was to be.

These discussions led to the agreement that the site should be stripped back, include less duplicate content, and more in the way of key information specific to the UK community only.

This has lead to this new project aimed at streamlining the website.

Current System

Currently the website is a Drupal instance, containing:

  • a planet
  • an about Mozilla and the admins of the portal page
  • a get involved with Mozilla and the UK community page
  • an events calendar
  • a link to the un-used wiki page
  • a page about getting support with Mozilla product issues
  • a contact the Mozilla UK portal admins page

All this is front facing to the user. There is also a separate bugzilla instance, an owncloud instance, and possibly more.

Social Media

The UK community also had (until the meet up) a Twitter, and Facebook account. Both of these have now been left to gather dust until such a time as the community is larger, and has real need for them.

Why is this all a problem?

Well it was deemed that all this is just work for the sake of work. Gervase Markham came up with a beautiful analogy that helps explain the issue.

The Mozilla UK community as it currently stands is just scaffolding for a non-existent building. Th building being the core reason and purpose of the community, and the scaffolding therefore being the tools and infrastructure that supports it. We spoke about how realistically, we need to reduce the amount of scaffolding we have, as we do not have a building that warrants the amount we have.

This document is focusing on the scaffolding, and the problem is having too much of it. By having too much scaffolding we are spending more time and effort on something that does not move the community forward. To move forward we need something that is lower maintenance, easier to use, and presents the information needed quicker and clearer. We also need to remove duplication of content that others are working on elsewhere in Mozilla, i.e. the about Mozilla content and the get involved with Mozilla content.

Requirement Analysis

Specification for any solution

So when considering what to do with the community portal there are a number of requirements which do need to be fulfilled. The following list contains the requirements that should be met by any system.

  • should use the latest web technologies (html5/css3)
  • should utilise any existing APIs for content that is to be included, e.g. events if possible, and should include the provision to do so in the future if not.
  • should provide upcoming events in the UK that are Mozilla related.
  • should have a very basic planet implementation
  • should follow most of the Mozilla design guidelines.

Data Flow of proposed system

The data flow diagram (DFD) is a useful guide on showing the kind of data that the proposed system will come into contact with. It shows this at the highest possible level without losing meaning in a Level 0 (the below). With this project due to the simplicity of the proposed system there is not much point going down to level one. Essentially will be a database and a couple of workers that get data. This data is then formatted and sent back out to the user.

Data Flow Diagram Level 0


Entity Relationship Diagram

Within the proposed new system there are several entities however we can easily model them with little complexity to show how the new system allows the flow of information between each entity.


Description of entities


An event is, well… an event! It has the following attributes as far as we are concerned that need to be presented to users:

  • a short event description
  • the date the event starts
  • the events main webpage where more information can be found.
  • wether or not a Mozillian is attending

A tag is something that belongs to an event. It shows what type of event it is and what it is focusing on. i.e. web making, popcornjs, etc…

A tag consists of the following:

  • a name (how people recognise the tag, i.e. web making)
  • a short description as to what it implies

A feed, is either an RSS or ATOM feed from a member of the Mozilla UK community. It is possibly the most basic entity we have in the proposed new system. It consists of just one thing. The url to the feed in question.


A user is someone who has one or more feeds in the system, OR is an admin who is able to add / remove / update data in the system in some way.

A user will consist of the following in regard to the system.

  • an email address
  • what type of user they are
  • some login credentials
  • a name for the user that can be publicly displayed

At this stage event tag should be ignored and is only there due to forward thinking about a potential database schema.

Agreed system objectives and scope

This section details all the requirements / objectives for the new system in light of this analysis

  • must be modular so that some they can be modified to work with other systems that are being developed within Mozilla and so others can pick and choose the bits they want.
  • must be lightweight so as to ease any maintenance that may be needed in the future
  • should utilise the design guidelines set forth by Mozilla
  • should be easy to add / remove / update data
  • must not store passwords in plain text (obvious but lets be thorough)
  • users should be able to delete / manage their own accounts
  • should protect from both XSS and CSRF attacks
  • should support RSS 1 and 2, as well as ATOM feeds
  • could use progressive enhancement for the UI
  • could provide the event data in a read-only JSON api