Never say never: Improving Stoplight Gadget

We are closing in on our 2nd milestone , this day next week, and we are in confident on finishing the two gadgets in time. For this week, we are still working on the Stoplight gadget, a continuous work of improvement, as well as the Wattdepot gadget. The Stoplight gadget had a major rework in terms of the formatting of the data it retrieves from. During our weekly meeting, we agreed that our messageSourceUrl formatting was too error prone from the user end. A user might get confused on setting the upper and lower bounds that relates to the corresponding message to be displayed. Our solution is to create a new format. This new format differs by having two columns, one to include the integer values to be evaluated and the other with the corresponding messages.

A significant feature are the empty spaces to visually show the upper and lower bounds of the values to be evaluated. In conjunction with the format change, we also stopped parsing the value as integers and instead parsed them as floats to better represent values a user might use which includes decimal values. Jarret created an updated message script to facilitate these changes. The updated script can be seen here.

As for the Wattdepot gadget, the main improvement we did was that we've successfully got our gadget to connect to the Wattdepot server. We are mainly using tests information gathered from Wattdepot. Other changes includes changing the source into a user input source instead of drop down menu, lowering the retrieve interval from minutes to seconds and including the source and the type of data in the gadget itself. The type of data that a user can choose from are Power Generated, Energy Consumed, Power Generated, Power Consumed. The data types' description can be accessed to Wattdepot's site.

New gadget! Wattdepot Gadget

For this assignment we start a new gadget but we also worked on polishing our Stoplight gadget. The main thing we had to do is to give a user choice on what size the image is shown. This was the solution we came up with since we couldn't get the scalable image working within the gadget. Some other things we did was to add a 'title' input to personalize the gadget. We also had to a few typos and completed information to our gadget and our project hosting site's user guides, which Robert pointed out.

In conjunction with polishing the Stoplight gadget, we also are to create a new gadget that retrieves data from Wattdepot. Wattdepot is an electric database that we used for last semester's projects such as the Oscar web applications and the resulting Ecologineers web application. This gadget retrieves information from a source and displays a set of data which can be anything from current power use to overall power consumption. These are information are displayed after filling out the required information such as the source, refresh rate, and the type of data. The main information that is to be displayed consists of the power (kW) and a time stamp of the current refresh and the the last checked.

Stoplight Gadget 1.4

Stoplight Gadget version 1.4 is the last version that our group is going to work on. Our meeting with Prof. Johnson last week has resulted in the introduction of a new gadget idea. It was only an idea so we didn't go into details and so the meeting shifted into how our group is going to finish up the Stoplight Gadget and get it ready for publication. I thought that this was a good idea since I feel that if we added more functionality to our gadget it beats the purpose of having a gadget that is easy to use, returns a concise information to the user and most importantly keeping it clean and uncluttered. For our final version, it is mostly about three issues that we've discussed which are error handling, unit addition, and the stoplight image. The stoplight image is still one of the problems since we tried to have a scalable image in order to accommodate users with lower resolution screens. Some other things we talked about in the meeting is the addition of better message and mainly the addition of the units.

The error handling issue, which was delegated as my job, was to add a text error messages to be displayed whenever a user input and data source errors arise. The process was not that hard but it took me a long time to finish it and go through my initial testing. It was mainly because of how I edited my code locally and then commit the changes through SVN and lastly test inputs through iGoogle with the gadget editor. This is one of the more frustrating time for me since I know that there are alternatives out there such as Google's own deskstop application. This is something I am highly considering in regards to working for the next gadget project.

Even though this is going to be the last version that we've worked on, I know that this project will never be labeled as finished. The Stoplight Gadget project will be an ongoing project to improve not only because it will be published but a way to showcase this as my accomplishment for possible employers.

Our project Hosting site can be accessed here.

Google Gadget: 1st Milestone

For our first milestone, we are to present a working and professional looking gadget that is simple but useful. Our version 1.3 Stoplight gadget is our project's first milestone. The gadget's functions include automatic refresh and threshold related messages, other functions that was implemented from the past versions include stoplight image, user inputted data source and threshold values. The stoplight messages is something that Yichi and I worked on and it was a little hard. After some research, we learned that the the gadget can only send and receive one query at a time so our solution was to separate the gadget query for the data and messages. Two script files, one for to display the stoplight image and the other to display the message, were created as a solution. Some other enhancements are purely aesthetic enhancements and it includes a better stoplight image and a drop down menu for the required input fields.

Since we've built our gadget by adding new functions on top of older ones for each version, I find that working on this first milestone project was fairly easy. The things that we've worked on most is improving the functions from the old versions and then implementing the new ones that we decided should encompass version 1.3. Such is the case with our stoplight image. During our meeting with Prof. Johnson, he told us that we needed a better image, one that shows the different colors clearly and resembles a real stoplight for a professional look. Other things we had to do was a major organizations of our files. Having the 'trunk' directory contain only the latest source codes, 'branches' as our individual repositories, and 'tags' which contains our gadget's past versions. We also had to improve the Stoplight Gadget site to reflect upon the changes we've made and to add user and developer guides.

After this first milestone we are planning on continuing with this project. For our next version we are shooting for the inclusion of error handling, scalable stoplight, and also maybe implement the 'plug' images from the HEEP project. I had a great time working on this project with my team. We always try and meet up at least twice a week which helped us delegate jobs easier and to keep us on track.

Stoplight Gadget 1.2, a leap from 1.0

For this week's gadget version, we've managed to combine two version functions into one, hence the leap from 1.0 to 1.2. We have combined two similar functions that we seemed easy to do so. Our initial meeting with Prof. Johnson had resulted in the split of these function into different version. The two functions are user input data source and the threshold values. Some of the other things we have accomplished is the addition of the stoplight image itself. Since we only have to display the stoplight for different threshold values it was fairly easy to implement the stoplight.

My task for the combined version was to do the user input threshold values, but since we decided to combine it this job fell into Yichi's hands since he was doing the other function, mainly the input data source. My new job was to research for a solution to a problem that we've encountered during our implementation of the new functions. We needed to find a better way to access our script and xml files because they were saved from Yichi's Unix account. We initially tried to gain access to these files through our Stoplight Gadget project hosting site. We have presented the problem to our weekly meeting with Professor Johnson and they have provided us with the best information to solving our problem. They have suggested that we needed to change the svn:mime-type of the files were trying to access. It turns out that Prof. Johnson had encountered such similar problem and has written a blog entry about it. The posting was very helpful but a reply to the posting helped me directly with my problem. It links to a different project hosting site called Flexlib and within its Wiki pages they explained how to access the SVN config to enable auto-props and provided a list of file format values.

After finding out how mime-type works, we have discovered anther way we can access our scripts withing Google project hosting and without changing the properties of the file. When browsing the files in the source, there is a link to the view the raw file in the right details panel. This is the easiest way for us to link the our scripts url with the gadget.

Next week will be our first milestone for our Stoplight Gadget and we hope to be able to have a version ready for release. Some of the function that we'll be working on are the addition of messages that interprets what the stoplight is showing or to return errors, scalable image and error handling.

Stoplight Gadget v1.0

This week's accomplishment included a finished Stoplight Gadget version 1.0 and a project hosting site called Stoplight Gadget. Version 1.0 is just our starting point for the whole project which is mostly about setting up the requirements and getting a feel of the basic functions. Our group meeting with Prof. Johnson has been the most significant part of this and last week's work. The meeting clarified all the gray areas about this project. First, we learned that our stoplight is supposed to be a general stoplight that people can download and use with relative ease. We initially thought that our stoplight is about Wattdepot and therefore constrained by it's functions; A stoplight that bear some similarity with last semester's Oscar WebApp. We learned that our stoplight gadget is supposed to work with any data, something that users can add to their iGoogle page and be used for different data by entering their own threshold and data source.

During our meeting, we also outlined the various functions and requirements for each version that we need to produce. We decided to create the basic functions first and then expand from there on. For version 1.0's visualization aspect, our gadget displays an integer that was taken from a hard coded source, which is from google spreadsheet. From that basic function we turned it into a gadget. Our next assignment is to add more functionality such as an actual stoplight image, a hard coded threshold, user inputted data source and the accompanying user interface.

An important lesson I learned from the first two weeks of working on this project is that a clear and concise instruction on what the project is about is a very important feature of software development. It helps developers to easily plan an outline of how the project is to grow. Extensive and periodic group meetings is also an important part software development in order to fix problems that arise during development period and to keep the group heading to one direction.

Stoplight App

New year, new semester and new project. Welcome back everyone and glad to have you back to ICS 414 Software Engineering weekly blog entry. For this semester, Prof. Johnson decided to continue on with last semester's sustainability project, Wattdepot, and use it a the key theme for this semester's projects. Prof. Johnson has given us 6 sustainability projects and let us decide which one we want to work on. The projects are Wattdepot Apps, Google Stoplight, HEEP website collaboration, Kukui Cup Design, Kukui Cup Prototype and Energy Meter. Another thing that is different is that we have to meet up with our professor every week which is different from our class time to discuss and present our weekly project development.

The Wattdepot apps are just a continuation of last semester's project and Google Stoplight is a stand alone application based on the Wattdepot stoplight page using Google visualization. The others are newly introduced projects that included collaboration with Hawaii Energy Efficiency Program (HEEP) to create a web application that will be included with their upcoming website and UH Electrical Engineering in creating a smart energy meter with the Energy Meter project. The last two are part of the Kukui Cup Competition that includes a project mock-up creation by the design team and the UH dorm integration by the prototype tech team.

For this project, I am part of the Google Stoplight. I picked this project because I wanted to try and do some of the extra components that was included in the Wattdepot apps, which is the use of Google visualization to help graph and chart hourly carbon output. The main difference is that we have to use Google visualization to incorporate the stoplight information. So far our group have only met yesterday and we talked about the things we have to do. We just delegated jobs such as the creation of project hosting site and we also talked about our experience with Google Gadget tutorials.