This page has been locked for editing. Please use Web Team mailing list to offer suggestions.
This page will contain useful suggestions for the composc web development project.
The biggest problem the last time was not with working on it, but once it went live, because there was no SCM in place, trying to develop anything on it was likely to cause breakages. In addition there was no obvious way to setup a personal version to test the changes without impacting the production version.
Use of SCM and patch management is essential when using any Third party applications on the website. When using third party software such as horde/imp for mail services there really needs to be proper import, merge and change tracking, otherwise you will find it difficult to migrate through version upgrades.
I would suggest using 'git' as the SCM. It allows much better distributed development. Also a wiki with a development section, use of wiki.compsoc.nuigalway.ie would be good for this. Ideally with instructions on how to checkout code, setup a local test website on windows or linux and how to submit patches with fixes and/or enhancements.
You don't need to have a large core development team. Allow other people to see and edit the code (minus the files containing passwords :o ), and submit fixes to the main team. To encourage users to help out, add an authors file which can be viewed through the website and contains the names of everyone that has contributed.
Make the SCM you use publicly accessible, anonymous read access. Keep the main repository writable to one or two users. The dev team should review patches, and people with write access should only accept patches that have come by way of the dev team. It basically means that you allow user contributions but all contributions get checked before going into the repository. It tends to keep high code quality.
Use templates, if you do nothing else, it will save you so much pain. The current site is a nightmare of where HTML is interspersed within php includes, and various files, where one missing closing div tag can completely bugger up the site layout and be almost impossible to find.
There's a good few templating solutions out there already. I've used HTML/Template/PHPLIB from the PEAR project already and found it to be decent. It's a very simple templating scheme, for something the size of the compsoc website something like smarty might be better. It also allows you to use syntax highlighting within the html only templates to spot coding errors there.
We coded a lot of stuff from scratch the last time. To be honest it would have been much smarter to use code from PEAR instead. It would have had any additional functionality that was required in special cases rather than trying to catch everything ourselves.
PEAR tastes good, and its very extensive with libraries. If the site was to use the functions for the backend, it would probably be easier to incorporate any third party app into the site.
This might seem like overkill, but testing a website by hand is really,really boring. If you have decent unit tests in place, anyone changing code can verify that their changes do not negatively impact areas of the website that they did not realize was using the functionality. This can be expanded over time to lint the template files as well and make sure that you are not introducing layout bugs. Ideally this would be called via 'make test'. You could also include test to automatically trawl through the various webpages generated and verify that they mean any standards that you want the site to comply to.
If you decide to get fancy you could expand on this to have a tool such as buildbot monitor your main repository for commits and each time a commit occurs, run the tests and give a webpage display of the results.
Some of what I've suggest above, may appear as overkill for a website. But the one thing that really became apparent during the development of the old site, is that you really need to setup the correct infrastructure at the start, cause its too damn hard to put it in place later.
Padraic suggested personalized content for members when they log in, similar to iGoogle.
Use Google Apps as our mail and calendar application.
Use phpBB as our discussion board application and mediaWiki as our wiki.
Sync these on an LDAP directory.
eyeOS is a PHP-based operating system undergoing rapid development. Currently, it has many admirable features, including the ability to edit many office documents (including MS Office and OpenOffice formats). It also features a calendar and has a dedicated software repository. It doesn't need any backend database so Frink wouldn't be put under serious load by running it.
Reintroducing search functionality would be useful. Ironing out issues with logging in would be welcome if members are to get personalised content. Content wise, a few more howtos would be a welcome addition to the already top-quality material on the site.