Sunday, March 30, 2008
Thursday, March 27, 2008
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.
Wednesday, March 26, 2008
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.
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.
Saturday, March 15, 2008
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.
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.
Friday, March 14, 2008
Thursday, March 13, 2008
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.
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.
Friday, March 7, 2008
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:
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
Saturday, March 1, 2008
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
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.
1. Random Brainstorming
As you can see that one didn't make it very far...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!
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.
Subscribe to:
Posts (Atom)