Todo List

Outdated

This TODO list is deprecated, and very old, and reflects the state of the project as of around April 2011.

###Setup Dartmouth authentication

At this point Dartmouth Authentication is the biggest question mark. In addition to knowing that we can use it to log people in for editing group descriptions, we need to know what information it provides us. For example, will it tell us the name or DID of the user who just logged in? This is important because I want to be able to show who edited the descriptions and be able to block user's who abuse the system. Also, if we want a class of admin's on the site, then it would be easiest/most secure to give them a special status as opposed to having a backdoor or different login system.

Once we know what information the Authentication gives us we can build a sql table for users. I'm think the table will ideally have three fields (id, name, permission). Permission is the fun field, it can either be 0,1,2 from the start 0=blocked, 1=normal, 2=admin.

###Start admin system

The admin system is the easiest thing to ignore with sites like this. From day one, we should have tables for groups, categories, descriptions, and users. It should be easy for us or anyone we give access to add/edit/delete these things.

We can start off by trying out sferik's admin engine. It looks relatively easy to try and we can try it on a separate branch on git, so if we don't like it we can always scrap it. https://github.com/sferik/rails_admin

Also, I think email support will be really useful, so I'd like to think of some smart email integrations as well. One example is from the admin system, we could email all of the execs of an organization with a standard email to update their info. Or equally importantly, if we think that a description was graffitti'd we should have a simple way to notify all of the execs.

Lastly, I think it would be really cool to have a dashboard so that we could easily see which groups in each category have uptodate information and then follow up with them. Just an idea, but worth exploring given how easy it is.

###think about design and usability

We should begin thinking about how we want this site to look and how we're going to communicate impt messages and hints to the users. This will be especially important early on when we want people to add group information and know that this is a really good resource for seeing what groups are active on campus and how to reach them.

Usability can be broken into four sections

1. Designing for a first-time user
2. Designing for a site with little-to-no content.
3. Designing site with helpful hints and more information sections
4. Designing for most common use-cases. We want the most important stuff to be 1or2 clicks easy.

One thing we should definitely do, is show a message in the description spot if a group does not have a description.

One silly idea i'm thinking about is adding a leaderboard section off of the homepage to encourage a couple people to add a lot of group information.

###Miscellaneous

• google analytics
• feedback tracking system
• flag button for group descriptions
• homepage could show group status (star if updated recently, flag if stale)

###Email Support

We're going to want to be able to send lots of emails that encourage groups to update their information. This should definitely be automated.

email campaign

We should blitz all of the group execs on the getInvolved spreadsheet and tell them that we're building DGD and would love their help and feedback. I think with something like this personal emails with first names, group names, and thoughts go a long way towards encouraging a good response rate. We should divy up the list three ways and blitz everyone personally over the next month and then share results.

add group information into db

We should add the group names that are on the getInvolved spreadsheet into the DB.

setup markdown for descriptions

Markdown is an awesome markup format for text. It's what we're using in this wiki :) we should have it set up so that group descriptions can have headers, bold, italics, lists, whatever. Shouldn't be that bad

description history

Every time a group updates their description, it'd be nice if we create a new description so that we don't lose the old one. This has two obvious advantages, one if the new one is graffiti we can revert back, two over time we develop a nice history that's kind of cool. This is already partially implemented on the back-end. It's the reason why we want a second table for descriptions.

Also, this is kinda geeky, but if we use a diff tool - we can show how the description was changed. Call it edit-history, I cant think of a good reason why we need it, but it should be easy and cool.

SysAdmin stuff

1. hosting on heroku
2. error log tracking with hoptoad
3. get/join student assembly github acct
4. dartmouth domain name
5. dartmouth email address