Saturday, July 28, 2007

Computer-Aided Database Design

After designing the database on paper, I used Database Design Studio to redo it on the computer. DDS helps create a schema with proper foreign keys and everything. This is the Entity Relationship Diagram made in DDS:

This is the Data Structure Diagram:

Friday, July 27, 2007

Wednesday, July 25, 2007

Defining the Scope of the Project

In studio today we defined the scope of our project. We explained the idea to Mark and he didn't have any problems with it. I drew this as a map of our ideas:


This is my understanding of the scope of our project:
A user creates, or is invited to be a group member of, a project. The number of users working on a project is not limited. The number of projects a user can be involved in is limited to 3, or unlimited for paying users. Users can leave projects if they no longer want to be involved. If all of the users involved in a project leave the project, the project is deleted. Projects have a name and a last update time.

When a user has write permissions on a project he/she can do the following:
  • Invite other users to a project. They are automatically added to the project (no approval required).
  • Add an item to the to-do list of that project.
    • To-do list items have a name, a due date (optional) and person/s responsible (required for group projects, and automatically set for individual projects).
    • Users can set items to be either in progress or completed.
  • Add a document to the project (could be an image, word file, PDF, etc)
    • Documents must have a name. The name should be editable by any user with write access (using AJAX - similar to the status change feature on Facebook).
    • Documents must have at least one version, but possibly many versions uploaded by different users. Versions must have a system date. Old versions are still accessible, but can be deleted by any user with write access.
  • Write a comment in one of two places - on the main page of a project (where the to-do list is located), or on a document page (i.e. "I like that version you just uploaded Fred").
    • Comments have a time and a body. They are not sorted into threads.
When a user has read permissions on a project he/she can do the following:
  • View the to-do list, documents and all comments. Nothing is hidden from them, they just can't change anything or write any comments.
When a user is a member of a project (with either write access or read access), here's the added benefits they get:
  • They will be notified in a 'news feed' whenever a new version of a document is uploaded. The notification will remain in their 'news feed' until they open the document page.
  • New to-do list items will have a star next to them the first time the user sees them.
  • They will be notified in a 'news feed' whenever a to-do list item is assigned to them as the person responsible.
  • They will be notified in a 'news feed' whenever a new comment is added to a document or to the project.
  • New comments will have a star next to them the first time the user sees them.
Users might have a number of projects on the go at the same time, so when they log in they see a 'dashboard' page with recent info from all their projects. This is what users can do on the 'dashboard':
  • Create new projects or remove themselves from old projects.
  • View their 'news feed' containing all notifications.
  • See a to-do list of items they are responsible for, across all of their projects.
  • See a visual representation of due dates (i.e. a calendar)
We also brainstormed for names of the project. Here are some of the ideas: projector (or projectr), project now!, chalkboard and tabletop. Some other words that are related to our project that could make up part of a title are: student, schedule, learning, books, time, calendar, project, planner, desk, web, lab and table.

Over the next week I am going to design the database, Justin is going to make a Gantt chart to illustrate our project schedule, and Long is going to work on the project plan documentation.

Tuesday, July 24, 2007

Review of To-Do Facebook Application

The description of To-Do in the Facebook Applications Directory includes a "still under development" disclaimer, so I didn't have huge expectations of it.

When you add a to-do list item, you enter a category, description, due date and priority. There is no clickable calendar in the due date field, but users can submit English answers like "tomorrow" or "Friday". A (plus) icon is used to save items, which I think is confusing for the user. To-Do is a one-page application; when the user saves a to-do list item, it is simply printed to the page. There is no calendar to visually represent due dates; dates are formatted like 07-24-07, which doesn't effectively highlight that THIS TASK IS DUE TODAY! To-Do doesn't make use of the social environment Facebook provides at all. It doesn't tell the users friends when they complete a task, or when they need help on a task, and it doesn't let users show off their achievements on their profile.

Don't set your expectations too high when using this application, or you might be disappointed.

Monday, July 23, 2007

Review of Basecamp Project Manager

Basecamp is an online project manager for small businesses. It helps organisations manage their projects by creating to-do lists keeping track of what needs to be done and who is responsible, sharing files within the organisation and with external clients, recording how much time people spend on different tasks and letting team members talk on message boards.

To review Basecamp, I will set it up to help manage one of MUBS' current projects, a student to student tutoring program.

I am working on this project with the Education Officer, so to begin I clicked a tab called People, and I was able to add him to the project.

I then clicked the messages tab, and added a description of what this project actually is. There were some simple checkboxes on the screen that let me notify the other team members that I had posted the message. One weakness I noticed in the messages section is that the post message form is on a separate page from the view message page. The user experience could have been improved if AJAX had of been used to allow the user to view and edit the message on the same page.


Next, I clicked the to-do tab to create a plan for the project. I gave the to-do list a name, "Set up tutoring program", and then entered in to-do items one by one. I specified who was responsible for completing each item, and was given the option to notify the person by email. I was glad to see that this time Javascript was used, and I didn't have to wait for new pages to load every time I made a change. I was able to drag and drop tasks into the correct order, and edit them where they were published.


Next stop: Milestones. The to-do list doesn't record deadlines - that feature is separated into the Milestones tab. To create a milestone, I was asked to enter a due date, a description and a person responsible. There was a checkbox offering to email the person I specified now and 48 hours before the task is due - a nice touch. A feed was automatically created to import milestones into iCal or Mozilla Calendar. I did have a strange feeling I was double handling the items I had entered in the to-do list though.

The next feature on the tab list is the Writeboard - a basic wiki. When I created a new document, I was forwarded on to the Writeboard website (which is made by the same company as Basecamp). Basecamp and Writeboard have been integrated quite effectively, and most users probably wouldn't notice they are moving between two websites. Unfortunately Writeboard is a very basic wiki; nowhere near the likes of Google Docs.

Being an internet website has both advantages and disadvantages for Basecamp. The file sharing feature is a good example. The fact that Basecamp is online makes it easy to keep colleagues and clients updated on your progress. However, if you are working with large files, it is just not practical to upload them to the internet to share - especially in countries like Australia with slow internet.

The to-do list and milestones were very nice to use, and although there were some problems with the website, I would love to use it in MUBS. I won't though, because I already introduced a wiki this year and I'm having enough trouble getting people to use that!

Sunday, July 22, 2007

The start of Studio 2!

This semester I'll be working with Long Zheng and Justin Tickner. The reason we formed a group is we're all interested in developing a database driven website. We want to make something that we can put on the net so other people can see it and use it. We're all studying double-degrees, so we're a year behind the people we started with and we're among the last cohort to do Studio 2 before it is phased out. Long and Justin worked together in Studio 1 and made a fashion website / CD-ROM. They did a fantastic job with it, so it will be good to work with them this semester.

This week in studio we talked about ideas for our project. Long explained an idea he'd been thinking about over the mid-year break, and that was a project manager for students. It would let students create to-do lists for their assignments, tick things off when they were completed, talk to team members on group projects, and work collaboratively using a wiki. We talked about our experiences of writing to-do lists for assignments, especially when all the assignments come at once, and we agreed that an computer based system could really help. A to-do list for a media essay might look like this:
  1. Research Second Media Age in the library - by July 27;
  2. Compile a list of good references - by July 27;
  3. Work out an essay plan and discuss it with tutor - by August 3;
  4. Write a draft for the body of the essay - by August 16;
  5. Write a draft for the introduction and the conclusion - by August 17;
  6. Proof-read - by August 21;
  7. Write a final copy - by August 24;
  8. Write a reference list - by August 28;
  9. Submit essay - August 31.
At times I've had three or four to-do lists like this on different scraps of paper. We could develop a system that helps students store all their assignment objectives and plan their work schedule. This would be much more effective than keeping to-do lists on scraps of paper. Ticking off completed tasks can also serve as a good motivator. Justing and I both admitted to writing elaborate to-do tasks of things we'd already completed, just so we could tick them off and feel good about our achievements.

I suggested that this idea would be useful for businesses as well as students. I know that in MUBS it can be difficult to make sure everyone has something useful to do, and that they are doing it. The last MUBS board meeting was focused on figuring out our goals for second semester. Throughout the semester I'll be ticking goals off on a white board as we achieve them. However, Long pointed out that a common mistake made by students in studio is to make their project too broad, and there are already really good project managers for businesses out there (such as Basecamp). I think it is a good idea to focus our product on students.

We also discussed the method of distribution for the product. Long suggested we package it as a standalone website that lets students create x number of assignments for free, but then requires payment for continued use. Group licenses could also be sold to schools and universities (if the government funded them adequately that is). I suggested that a good alternative would be to make our product on the Facebook platform so it could be distributed virally from students to their peers. It could have a free number of trials or be ad supported. During the mid-year break I made a Facebook application called Introduce Me, and now there's over 1,500 people using it. After discussing these options we decided to go with the standalone website. We think our product is better suited to be standalone because Facebook is for socialising, and our product is for studying. By putting it into the Facebook environment, there would be too many distractions for our users.

Over the next week, we will research whether our idea has been done before, and if so, how.