Final thoughts on the project

Well, today is presentation day, so it is finally time to hand in the project and start sleeping at night again! The final product is looking really good, but there is a long list of improvements we could make.

Maybe we were overly ambitious in our project plan. But I think that it’s better to take on something greater and only get half way there than take on a mediocre project that you know you can do easily. Perhaps that’s not true when you’re doing paid work for a client, but it is definitely true for a uni project. We pushed ourselves this semester – with the new skills we were required to learn, and the amount of time we needed to commit.

It is hard to find enough time to give to a project when it is one out of four subjects you’re studying. Due to a lack of time or inadequate planning, we haven’t been able to test the product as well as I’d like to. We’ve been testing things as we go along, but there will be some bugs in it. I am also aware of some security holes that could be used by students to place bookings in other students’ names. But people would have to know a bit about the system to exploit them.

Despite the problems outlined above, in the end we have a product that I think would be beneficial for the client to implement, because it will save them a lot of time. I also think we have a quality working prototype that we could use to approach investors if we decide to continue working on the system. It wouldn’t be much extra work to modify the system to work for different clients, so potentially this product could be sold to different universities, and anyone else who needs to loan things out on specific days. If we don’t pursue this idea, we have a quality portfolio piece anyway.

UI design work on student interface

Today I did some user interface design work. Here's some before and after shots of the timeline component:

Before:


After:


I also added popup tips to the interface. These will explain how to use the application. They don't require any interaction from the user and disappear straight away if the user interacts with the application.

Integrating and optimising the Timeline component

I spent my Saturday integrating the Timeline component into the customer interface, and I've gotta say, it was looking pretty hot!



But when I looked at it again today with a fresh mind, I noticed its performance wasn't living up to its looks. It was taking a really long time for the data availability to load when you drag a product onto the timeline. So I added some tracking variables to my code which grabbed the current time at various points through its execution. By subtracting the times from each other I could see how long each part of the script was taking to run. Here's what I saw:



It was pretty obvious that something funny was going on in the section which processed the XML for the days on the timeline. When I knew where I was looking it was pretty easy to fix it and speed things up. Here's what I got after a few tweaks:



I reckon 8.8 times faster isn't bad!

Timeline component

For the last two weeks I have been working on the timeline component. This is the centrepiece of the customer interface because it is the tool students will use to visualise the equipment availabilities over a period of time and place a reservation. But it is taking a lot more time than I had expected.

First I had to write a PHP interface between Flex and the database. Long had written a function that would do this already, but the problem was it only checked the availability for one item on one date. That would mean if we had three items and two weeks on screen, we would have to make 42 HTTP service requests. This would slow down the application because there would be 42 queries going to and from the client and the server. So I wrote a function that takes an array of product IDs, a start date and an end date and returns all of the appropriate equipment availabilities. That was a 250 line beast so I guess some of the time went in there.

Here's an excerpt of the code:


The function returns XML in a structure like this:


I am using Repeater elements to display the rows of products and columns of days in Flex. First I got the component to display static data that was saved in a variable in Flex, and then I got it to display data that was loaded in from an XML feed. This is what the component is looking like now:


The next step will be to hook this up with the rest of the student interface. Users will need to be able to drag products onto this timeline. They will also need to scroll horizontally to view the dates they are looking for. After that I will need to make the buttons actually place a reservation when they are clicked.

Teamwork

I think what makes our team successful is our open communication, even though we only have time for one face-to-face meeting a week. Over the last week for example, Long has been testing the web server and integrating our application with the University's authentication protocols. He has had numerous discussions with Mark Szota and Dave Sole from the faculty, and has CC'd Justin and myself in on the communication. That has kept us in the loop of what he's been up to, and given us the chance to throw in ideas too.

Justin and I have been working on different parts of the interface, but by using the SVN we can constantly update each other's files. Its really interesting to do an update and be able to see all his latest work straight away. When I see that he's done something cool, it motivates me to do a bit more as well.

Beginnings of the customer interface

This week I got the customer interface structure laid out, and did a bit of work getting some of its components up and running. So far, the application loads in the categories dynamically and then loads the products based on the user's choice of category.

I learned about Item Renderers today, which I haven't had to use before. When I was working on Vizzl at Deloitte the Item Renderers had already been done for me. It turns out that they're pretty easy, I did waste a few hours though because I didn't realise that Item Renderers where the thing I needed.

Item Renderers allow me to take a standard component like a TileList (which I have used here to display the products) and display it in a different way. In this case each item in the list has an image and tool-tip as well as the standard label. If I was just loading in static data I could display an image and tool-tip without using an item renderer, but as soon as I start to load data during run-time, it necessitates using one.

Admin interface

I set up the structure for the staff interface today. It is divided into four tabs: Dashboard, Loans, Equipment and Settings. Each tab is a separate canvas so we can work on different tabs without worrying about interfering with each other's work.

I set up the loans tab, which allows users to apply different filters to the loans stored in the database and find specific loans. I am going to work on the dashboard tab next. Long is going to set up the settings tab.

Project structure

I set up a structure for the Flex part of our project. It is divided into three parts:

ELS_admin_interface
This is the AIR application that runs on the staff computer in the BSIT office. ELS stands for Equipment Loaning System.

ELS_components
This part contains components that can be shared between both interfaces. By sharing them we will reduce data redundancy during development.

ELS_customer_interface
This is the Flash browser-based interface students will use to place bookings.

Outputting SQL results as XML

We are using XML as a format to pass data from PHP to Flex. We have a few different options for how to do this. We have opted to write a function that automatically converts SQL results into XML documents. Another option would have been to convert the results within each separate function, which would have allowed us to sort results into function-specific tree structures. But this would have been a lot of extra work for each function.

I wrote a function called sql2xml() which takes an SQL query as input, runs this query, and returns either the query results or an error message as XML. This is what it looks like (you can click the image to see it at a readable size):

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

All of the posts prior to the 16th of April were submitted as the first half of the process diary and workbook.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Monash Web Server

Yesterday Mark Szota sent us the details for a Monash webspace we can use to host this service. Dave Sole set it up for us. Long is going to test it out, and make sure all these things work: MySQL, PHP 5 and the PHP mail() function or the Pear:Mail function. He is also going to test out the LDAP integration so we can verify student usernames and passwords and retrieve basic information about students.

Writing PHP functions

We have started writing PHP functions that interact with the database. We are trying to keep our PHP as object oriented and reusable as we can. None of the functions read values directly from the GET or POST vars, instead they are passed them by a handler function. For testing, we put an HTML form in front of the PHP functions, but soon we will be calling them from within Flex.

Here's a screenshot of the HTML form in front of the getLoans function I wrote. It shows all the different optional filters we are using to select loans from the database.


While writing this function I learned that MySQL provides search functionality. You need to set up FULLTEXT keys for the items you want to be searchable, and then use MATCH () AGAINST() in the SELECT query. It supports natural language search and conditional search, where users enter symbols like +, -, "" to change the meaning of their keywords. It is apparently more efficient than using LIKE in the SELECT query, which could achieve a similar result.

Subversion

I set up a subversion space for our project at the Assembla website, which offers this service for free. Subversion allows us to synchronise and merge our work with each other. Last year we would copy all our files onto one PC once or twice a week and use WinMerge to combine them. Using SVN will streamline this process, and provide us with automatic backups every step of the way.

Optimising the equipment collection process

In studio today we went through our database schema with Matt, and he pointed out an area where we could improve our design. We had been allocating specific equipment items to loans when students placed a booking. This added unnecessary complications to the loan process because it meant we had to check if a specific item was available for the duration of the booking, rather than just checking if any suitable item was available on each day.

Matt suggested that we link a piece of equipment to a loan when the student collects it instead. That will also make it easier for Mark and Shelley to process collections, because they will be able to pick up any suitable item off the shelf, instead of having to look for specific items (i.e. DV Camera #564).

Fixing this problem in the database meant simply adding a relationship between the loan and product tables.

Final database design

Data visualisation interfaces excite me

There are so many variables our system has to consider before it can approve a booking for a set of equipment.

• If a student requests a camera for two days, we have to go through our inventory and examine the existing bookings for each camera. We have to determine whether one of the cameras is available for both days.
• We have to make sure that camera is not out-of-service for repairs.
• We have to verify that the student is permitted to borrow that camera (there are postgrad/undergrad cameras, and the student may have gone over their borrowing limit).
  
• We have to check whether the collection or return date is a University holiday, and modify the dates of the booking accordingly.
• If the student also wants to borrow a microphone and lights with their camera, we have to repeat this process for those items too - and make sure that they are all available at the same time.

The challenge for us is to develop an intuitive interface that lets users visualise equipment availabilities whilst simultaneously tweaking variables like collection date, booking length and required equipment. I love this stuff!

Prototype interface

This is a prototype interface I put together in Flex 3. It shows how a user can select a category and then a specific product, and add their desired products to a timeline. The timeline shows when each product is available, so that they can place a booking when all of their stars align.

Visualising item availability over time

This morning Long, Justin and I had a group meeting over Skype. It was my first time using Skype and I found it much easier to just talk rather than typing with MSN Messenger. We had a very productive meeting especially considering it was held online. We began by reviewing a database design that Justin had done. We went through each table and worked out what changes needed to be made.

After agreeing on the database structure we discussed the interface design. I sent Long and Justin a link to the Flex component explorer, so they could get an idea of what built-in interface components were available to us. We realised that the information we need to present in our interface is pretty complicated. We have to let students select a number of different items, such as a video camera, microphone and lights, and then see the availability dates for each separate item. The camera might be available on a certain day, but if there is no mic available the student might not want to make a booking.

One of the early ideas we had was to have a calendar for each item, with dates coloured to show availability. But having three or four different calendars on one screen would be very messy and provide for poor usability.

A better way of presenting the information is with a timeline metaphor. Each row on the timeline would represent a piece of equipment, and users would scroll horizontally along the timeline to see availabilities. This would be much more intuitive than a set of calendars.

The three of us will have a bit more of a think around interface possibilities, and collate our ideas soon.

Barcode scanner research

Mark Szota has informed us that he wants the system to be as efficient as possible, so I have been assigned the responsibility to research bar-code scanners as a potential data input interface for staff.

During my research I discovered that nowadays bar-code scanners give the computer the same kind of data as keyboards, so we don't need any special drivers or libraries to integrate them into a system - even a web based system.

The most basic way to use bar-code scanners is to enter data into a form. The user would click an input text box with their mouse, scan a bar-code, then click another text input box, and scan another bar-code. We can do better than that of course. A more user-friendly method is to print a unique character combination at the start of each bar-code. The system could then listen out for this character combination, and know when it heard it that this input was coming from the bar-code scanner, not the keyboard. The system could then select the appropriate input text boxes on the form automatically, eliminating the need for a mouse.

Early database design

This is Justin's hand drawn schema with some of my notes on top in green.

Project Plan

Our Project Plan is due next week, so we have divided up the work between the three of us. I am responsible for the Detailed Project Requirements, Work Breakdowns and Work Schedules & Deadlines.

I had already pretty much done the project requirements by writing up the current process students go through to make a loan, and the ways in which this process could be improved. I also added technical requirements and file naming conventions to this section.

I used MS Project to do the work schedules and deadlines. My experience at Deloitte helped with this. I was involved in a project there from start to finish, and I saw how important it was to think through the development process before starting work. I learned that if there are any problems or complications in a project, you need to talk these through with your client to ensure you both understand what the issue is and how you will solve it. But it saves a lot of time if you can figure all these out before you start developing.

Brainstorm with Mark Szota

Project concept and scope

Justin and I met with Mark Szota on Wednesday this week to discuss the school's requirements for this project. To run the discussion we walked through the current process for making a loan, step by step. Mark explained where the problems were, and Justin and I made some suggestions for additional improvements.

I think that we gained a good understanding of the booking process that Mark would like to see implemented in the new system. We didn't move the discussion onto the more technical details, because we can talk about that next week. This week is about defining the project scope and requirements, and it was important that we focused on that to make sure we weren't getting ourselves into a project that wasn't right for us.

We asked Mark to send us some documentation on the current system. That included:

• Form that students fill in when they come to collect the equipment
• Database schema for equipment list
  
• Screen-shot of the FIT Call Logging System
• Photocopy of a page of the diary they use to record bookings
  

Over the next week we will have a look at this documentation and then meet with Mark again next week to determine what entities and attributes will be required in the new database. Justin will do some research into existing loan software. I will do some research into integrating a website with a barcode scanner, and write our project concept document.

Project selection

Long, Justin and I will be working together again this semester in studio. We discussed a number of ideas during the summer holidays and this week, and we have selected one to pursue. In this post, I'll go through the ideas.

1. Random Brainstorming

Keegan says:

we could make a map that shows all our locations when we walk around

Long says:

errr

google does that

and so does Nokia

Keegan says:

we could make an application that people use to document their lives with cameras

Long says:

have you seen justin.tv?

Justin says:

justin.tv? dammit long how many times have i told you not to install tiny cameras in my house!

As you can see that one didn't make it very far...

2. When's it Coming?
Long had an idea to develop a web 2.0 search service for anything with a date. So people would type in "When is Powderfinger playing in Melbourne?", or "When is Easter this year?", and the service would give them an answer. When's it Coming? would have a mobile web interface so people could use it on the go, and we could test it on the website www.testiphone.com. For data collection, When's it Coming? would use a crawler like a traditional search engine, have plugins for a lot of different web services, and/or accept user submissions and corrections.

3. Sports Stock Exchange
Justin had an idea for an online sports stock exchange game. Players would start with a small amount of play money, and would buy and sell shares in certain players or teams to end up with the most profit. The SSX would be based around real sports events like the AFL or Australian Open, and wins would be based on actual game results.

4. Monash Mobile
A web interface to a university CMS, like WebCT, Blackboard, Moodle, etc, etc, etc, etc, etc. It would have updates and announcements from lecturers, timetables, email access and subject discussion boards, but it would be accessible from your mobile phone.

5. Mobile Web Polling Service
Sometimes on game shows contestants can ask the audience what the answer is to a tricky question, but wouldn't it be useful if they could ask the entire country? Or if students could answer their lecturer's question in a quiz, or members of an audience could vote for the next song, or commuters tell Connex how useless their service is? Our service would let organisations easily set up their own poll or survey that is accessible by mobile phones. The answers would be collated in real time and presented on a website.

6. Equipment Loaning System (our chosen project)
The Berwick School of IT loans equipment like video cameras and microphones to its students. The current system they use is a combination of paper forms, a diary and the faculty's call logging system. It is a cumbersome process for students to loan equipment, and moving this process to the web could greatly improve it. Our solution will include a web interface for students to view available equipment, make reservations, and renew existing loans; and a desktop interface for faculty staff to process loans and returns, and track equipment.

Next week Long is going to Las Vegas to write his blog, but Justin and I will meet with Mark Szota from the Berwick School of IT to discuss the requirements for the system.