To use a Javascript framework?

I haven't been using a Javascript framework to write my AJAX, so I've been writing everything in raw Javascript. Today Justin Morris (not the Justin in our group), noticed that, and suggested I consider using a Javascript framework because it would make the coding more efficient. However using raw Javascript is a good learning experience. I will discuss this with my group members today.

Justin recommended two good Javascript frameworks:

• jQuery
• Prototype

AJAX on the Profile and Settings Page

The Profile and Settings page is almost completely functional now. Users can change their email address, name and password. Later today they should be able to change their display pictures. I have enjoyed learning AJAX over the last few days for this page.

Using AJAX in Tabletop

Early in the design stage of Tabletop we decided that we wanted it to be fast to use, and that would mean using AJAX to perform functions without loading new pages. Over the last couple of days I have been learning how to use AJAX. The best tutorial I found was at w3schools. I have been working on the "Edit Profile" page. Data is collected on a form and sent to a PHP file, which validates the data before saving it to the database. An appropriate message is shown to the user on the original page.

Combining Long's login system with Justin's timestamp formatter and my news feed

Today Long, Justin and I combined what we had each been working on over the week. Long had created a login system that verified a username and password and created a session for logged in users. Justin had written a function that took a timestamp as input and gave it back in English (i.e. it turns "1185955434" into "two days ago" and "1185959034" into "next week"). I had created the dashboard page, including a news feed of recent activity and a task list. When we put them all together, here's what we got:



As you can see it is starting to look a bit nicer. We had to tweak a few things to get our work to fit together, but nothing major had to be done.

Dilemma solution

I will define the difference between the way to-do list items are displayed and ordered on the dashboard and project pages.

Dashboard page

• Displays only the to-do list items that are assigned to the logged in user, but for all of their projects.
• Items are ordered by due date, and are categorised under the following headings: Overdue, Due Today, Due Monday, Due Tuesday, Due Wednesday, Due Thursday, Due Friday, Due Saturday, Due Sunday and Upcoming Tasks. Items without a due date are put at the bottom under the "Upcoming Tasks" heading.

Project page

• Displays all of the to-do list items associated with a project, no matter which person they are assigned to. Doesn't show items from other projects.
  
• Items are by default ordered in the order they were created, and can be re-ordered by clicking and dragging.

Here is a screenshot of the task list on the dashboard.

The dilemma of how to order items in the to-do list

Due dates are optional for to-do list items in Tabletop. This is because when people work on projects, some of their tasks will have due dates and some won't, and we need to reflect this reality.

However, this introduces a challenge for our development team. If all tasks had due dates, then it would seem intuitive to order them by due date. But how do you order a list by due date when some of the items don't have one?

We have previously discussed this dilemma in our group. We noted that effective people work on important, rather than urgent, tasks first. So we decided that it is important for users to be able to re-order their to-do lists, and move the most important tasks to the top. The default order for to-do lists in Tabletop will be the order in which the items were added, not their due dates. Users will be able to drag and drop tasks into the desired order.

This introduces a problem for me today as I work on the Dashboard page. I need to collect to-do list items from all of a user's projects, and put them into a list so the user can see what to work on. I would like this list to be due-date based, so overdue tasks appear red, today's tasks are bold, etc. But I am wondering if this conflicts with our earlier decision...

Creating the skeleton

Today Long, Justin and I began working on the PHP for our website. Long was mainly focusing on creating a login system with sessions. I started working on the dashboard page, which gives users an overview of their projects. I got the page to show a list of the user's projects and a News Feed of recent activity. This screen shot shows how much I got done:



I ran into my first problem with the database design today. I forgot to include a variable in the user table for last_login_date and in the to_do_list_item table for created_date. I needed these to be stored for the news feed. So I amended the schema.

Completing Process Diary

Today we handed in our project proposal. Long had almost finished it, so today I wrote the technical requirements and file naming conventions, and Justin and I added the database plans and project timeline. We proof-read, edited and printed the document, and then handed it in.

Over the next week, I am going to start to write some PHP functions for the website. Justin is going to do some research into PHP and AJAX.

Reviewing the Project Scope as a Group

In studio today we stepped through the process a user would go through when they used our website. We figured out a few changes I would have to make to the database. They included adding a project_description to the project table.

We also made these decisions:

• When a user invites people to a project, the invitees are sent an email and have to click a confirmation link before they are added as a member of the project.
• We will use automatically appearing input-text boxes (like on flickr), for users to change text on the website.
  
• Users can drag and drop items in their to-do list to re-order them. We will save their position in the database.
• When a project is created, if it has a due date we will automatically create a to-do list item called "Project due" on the due date.
• Comments can be deleted NOT edited.

We want to highlight unread comments to users on our website. I think we should store an unread/read value for every user/comment combination, but Long thinks this is too inefficient. I understand that it will create a huge number of entries in our database ([C x U] x P, where C=avr no of comments in a project, U=avr no of users in a project, and P=number of projects in our database). But databases are made to handle heaps of records. Plus we will only be storing two integers and a boolean for each record so it won't be much storage space.

After class I stayed back til 8pm and made the appropriate changes to our database design. I then exported a schema and a test data insert file, and checked them for errors. I eventually got everything ironed out, so we've got a working MySQL database that is propagated with test data. We can now start writing functions as soon as we like.

Long is going to a Microsoft conference on the Gold Coast next week (lucky guy!.. except for the Microsoft part), so he is going to finish all his work by the end of the week, and that will give Justin and I a chance to go over it before the plan is due next Wednesday.