Mandat pour outsourcing
Sommaire
The big picture
This project is 100% web-based.
We want to propose a free service that internet users will benefit when communicating, especially via e-mail. Our customers will put a link in their e-mail signature that will be the address of their profile which relates how their technically prefer to be contacted (mail/IM/Skype/SMS/phone...) and some of their (e-communication) habits like: "how often they check their e-mails", "what style they prefer people use with them" (explicit, short, direct, cautious, polite...). In their e-mail signature, they could put a sentence like "Go there to know how I prefer to be contacted: http://www.mypreferences.com/jacky"
So the website we need to be developed is targeted at any internet user that is willing to express his/her "electronic communication preferences".
Actually, it's a matter of letting people create an account and fill a configurable profile that will have its own URL. Users will then be able to put this URL in their e-mail signature at the end of their messages. They may have several profiles depending on their e-mail signatures, which means different identities and different preferences (professional, personal, for their hobbies...).
It should be a relatively short project, whithout great technical challenge. Ergonomy will be one of the most important aspects.
At the end of the contract...
...the contractor will provide all what has been developed during this contract
- source code (files)
- data files
- SQL database(s)
- source images (not only bitmap version)
- documentation + source files (not only printable version)
- all works will have both copyrights: the contractor's and the client's ones
Terminology
Regarding the future website, there will be 3 kind of people:
- "administrators" of the future website. They will have a dedicated administrative interface, and some monitoring helpers
- "visitors" who are potential users or simply the ones who followed a link to a user's profile
- "users" that are registered visitors and have one or several profile(s) Regarding there will be 2
- the "contractor": the chosen person (or entity) that will do the actual job
- the "client": us (I'm the only coordinator and contact person)
Functional specifications
- visitors can read the website's homepage (editable content by admins) where they can (follow a link to) subscribe to a new account or connect to their existing account (form on one side column)
- visitors can also browse the rest of the public website whose content is organized by admins.
- admins can create pages (in an online WYSIWYG editing) and organize them into hierarchies (similar to any CMS)
- users can subscribe/login with their OpenID or Facebook connect account
- e-mail addresses should be sufficient as users' identifiers ("login")
- registration is the most simple and straightforward as possible: users are asked their e-mail address and an activation link is sent
- connected users have a private administrative interface
- once connected, the login form is replaced by the username/name of the user and a logout link, which links to their administrative interface
- for each of their profiles, users can choose that it is indexed (or not) by search engines
- statistics should be provided to each users about the visits to their profile(s). Something like Piwik (http://piwik.org/) could be used to provide such statistics
- profile information should be entered only once, which means asking to users for each item in which profile is is displayed (ex. : this is displayed in profile "Professional", "Friends", "Family"... depending on their profiles' names)
Technical specifications/options/constraints
- code should be written in PHP+MySQL+javascript (oriented-object when possible)
- standard hosting (PHP+MySQL+Apache URL_Rewriting) should be sufficient, and otherwise inform the client
- if based on an existing opensource CMS/blogware, Wordpress should be preferred, the code should be able to end up as a module
- unit testing will be done by the contractor and validated by the client at the end of the present contract
- non-MySQL storage (images, and other files) should be done through an abstraction that will allow future evolutions (Amazon S3 for instance) even if its done through local storage in a first implementation
- Javascript is a must-have but its features should be non-obtrusive (ie.: some clients could have it disabled and benefit from all core features anyway)
- Existing useful opensource libraries/resources should be used instead of creating equivalent features (AJAX libraries...). The potential alternatives should be submitted to the client before any option is taken.
- Code will be internationalized (i18n) and the contractor will propose & implement a solution for localization (l10n). Eg.: gettext functions + php-gettext-edit (http://www.php-gettext-edit.net) or poedit (but pure online interface should be preferred over client-installed software)
- solutions for asynchronously cleaning temporary files (expired sessions, expired invitations...) should be proposed to the client - HTML interfaces must be written with a templating system (propose options to the client) and contain no fixed-text (for l10n purposes)
- a documentation will be given to the client at the end of the contract
- installation should not be harder than unpacking an archive, configuring a simple text file (justify if it's not the case) and populating a database with SQL text-file
Organizational aspects
- technical options must be first validated by the client
- We prefer a regular reporting even (and particularly) when problems arise than no reporting (EVEN if there's no problem!)
- the contractor should not make any assumption about what the client wants in terms of technical choices or ergonomy. If such a question exists, please ask us!
- the contractor should not work more time than previously defined with the client. If he/she does it, he/she takes the risk of not being paid the extra work.
- the contractor has the expertise of projects like the present one. If some aspects seem unrealistic or the present specifications lack major elements, the client will consider an amount of responsibilities to be put on the contractor's side.
- the contractor should not reveal elements (information or documents) that he/she will be said during this contract
- the contractor should provide access to the ongoing development code through his version control system (VCS, like CVS, SVN, Git, Mercurial...). The latter should have a free software client version so that the client can "checkout" and test the code during its development.
- if some elements of this specifications seem adding too much time compared to the awaited benefits, the contractors (and potential contractors) can suggest modifications so that the goals are reached even if not fitting 100% the present initial specifications
Code good practices
- comments don't replace clear coding
- clear coding doesn't replace comments
- comments don't replace real documentation (phpDoc si a good option)
- Choose a symbol naming convention (variables, classes, functions); document it and stick to it
- do the same for indentation
- don't repeat yourself, think in terms of factorisation. Ex. Instead of this code:
if ($a) $string = "<a href=\"$ref_a\">$txt_a</a>"; else $string = "<a href=\"$ref_b\">$txt_b</a>";
Do that code: $ref = $a ? $ref_a : $ref_b; $txt = $a ? $ref_b : $ref_b; $string = "<a href=\"$ref\">$txt</a>";
- prefer readble/modifiable code to over-optimized one
- design and code with security in mind: always check external data, especially those who come from the users (GET, POST, COOKIES)
- avoid "quick and dirty" solutions, often home-made in favor of robust and standard ones, community validated and supported. eg.: don't create your own regular expression for filtering e-mail addresses; use PHP Filters instead. Cf.: http://www.phpro.org/tutorials/Filtering-Data-with-PHP.html#10
