My group, Paul and I, have finished working on our gauge project and are now working on a billboard for the upcoming kukuicup competition with two other gadget group members, Kendyll and Edward. This billboard will be displayed on a screen within the eating area of UH campus during the kukuicup competition. We have decided to make this billboard using HTML, CSS, and Javascript.
This week Paul and I did the mockups for the billboards. These mockups can be found at our project hosting site in the images folder in the wiki page.
Since the we will be showing the billboard using HTML, we need to have the browser have a nice full screen so we tested out some pages in full screen to see how it looks. While looking at the full screen of the Chrome browser, I saw that there were boarders around the edges of the screen. It turns out that these boarders only show up on Windows 7 when trying to view a page in full screen. These boarders show up because of Windows 7's default glass theme, which allows the user to see a blurred view of what's behind the window. To fix this, all I had to do was change the default theme to something else and it was fixed. But I liked my theme so I decided to try to find another browser to test the billboard.
Next I decided to use Mozilla Firefox. This browser also has a problem with the full screen capability as it was setup to always have a small boarder at the top of the screen that shows the menu when it is scrolled over. Luckily this problem has been experienced by many others and someone already made an add-on that fixes this problem. The add-on is called 'Full Fullscreen' and can be found here. Once installed, all I had to do was change the options of the add-on by checking the 'Hide tab bar' option in the add-on's option menu.
My new group's project site can be found here.
Monday, April 19, 2010
Tuesday, April 13, 2010
Gauge Milestone Review
This week we made many small changes to our gauge gadget this week. There were no major problems that arose with the changes to I will just talk about the changes that we made this week and why and how we made these changes. Some changes we made were making the user input a wattdepot server url, we had to change the datatable that we receive from the wattdepot server to only show the units, added a timestamp and display the data type (power generated or consumed) below the gauge visualization in the gadget. The last problem (display the data type below the gauge visualization) is pretty self explanatory so I will not talk about it.
In our last gauge, we did not allow the user to input a specific URL to the wattdepot server but instead had the URL hard-coded. We did not know that there were many different URLs to different wattdepot servers so we took out the hard-coded URLs and added a user preference where a user can input the URL.
The second problem was that we decided to change the label within the gauge to just show the units of power generated or consumed. The following image shows our problem.
As the image shows, the label for the gauge is "Power Cons. (W)". The gauge retrieves the label from the first column of the data table. So to fix this problem we just used the setColumn() method in the dataTable class.
We also added a timestamp to the gadget where the timestamp will indicate the last refresh check. Adding this was pretty simple as we were just able to copy the code from our wattdepot monitor gadget.
After making the changes to our gauge the gauge currently looks like the following:
Something that I thought about for this gadget while writing this blog is to maybe have the url and sources be dynamically updated and be in a drop down format. Since the URLs are a little long and hard to memorize, having the URLs in a drop down menu will be much easier for the user. Also, since the certain wattdepot server URLs have specific sources that they are able to reference (ex. http://server.wattdepot.org:8188/gviz have sources kailua-house, saunders-floor-2) we could try to set the dropdown menus to display only sources associated with the selected server URL. So given the last example, if a user selects the server URL http://server.wattdepot.org:8188/gviz from the drop down menu, only the sources kailua-house and saunders-floor-2 will be in the sources drop down menu.I am not sure if this is possible but I will look into it have hopefully find a way to implement this idea in the coming weeks.
The gadget project can be found here.
In our last gauge, we did not allow the user to input a specific URL to the wattdepot server but instead had the URL hard-coded. We did not know that there were many different URLs to different wattdepot servers so we took out the hard-coded URLs and added a user preference where a user can input the URL.
The second problem was that we decided to change the label within the gauge to just show the units of power generated or consumed. The following image shows our problem.
As the image shows, the label for the gauge is "Power Cons. (W)". The gauge retrieves the label from the first column of the data table. So to fix this problem we just used the setColumn() method in the dataTable class.
We also added a timestamp to the gadget where the timestamp will indicate the last refresh check. Adding this was pretty simple as we were just able to copy the code from our wattdepot monitor gadget.
After making the changes to our gauge the gauge currently looks like the following:
Something that I thought about for this gadget while writing this blog is to maybe have the url and sources be dynamically updated and be in a drop down format. Since the URLs are a little long and hard to memorize, having the URLs in a drop down menu will be much easier for the user. Also, since the certain wattdepot server URLs have specific sources that they are able to reference (ex. http://server.wattdepot.org:8188/gviz have sources kailua-house, saunders-floor-2) we could try to set the dropdown menus to display only sources associated with the selected server URL. So given the last example, if a user selects the server URL http://server.wattdepot.org:8188/gviz from the drop down menu, only the sources kailua-house and saunders-floor-2 will be in the sources drop down menu.I am not sure if this is possible but I will look into it have hopefully find a way to implement this idea in the coming weeks.
The gadget project can be found here.
Tuesday, April 6, 2010
Gauge Ticker
While updating the gauge gadget for wattdepot this week, we ran into a few small problems. Initially, we ran into a simple problem that every programmer hits once in a while. I had a small bug where we missed typed an id for one of our id's in the XML google gadget. Instead of writing 'data_source_URL', I wrote 'datasourceURL'. This one small bug caused me problems for about 1-2 hours. We initially thought that the bug in our program was from the query request and retrieve that we made to the spreadsheet document. We thought that the query was the cause of error since the program would seem to bomb out every time it would enter the function that gets information from the spreadsheet. I had to figure out the program by trying to show the string on the screen through a 'div' statement in the xml.
After I finally fixed the problem I began to work on getting the gadget to refresh every 5, 10, 30, 60, and 300 seconds. I quickly got the gauge to refresh every x amount of seconds by using the setTimeout() function. But I couldn't figure out why the gadget wouldn't get the new values that were being updated on the spreadsheet. I found that the 'Query' function for the google visualizations needed to be called to get the more recent spreadsheet info. So i wrote the following code:
function moveTicker() {
queryDataValue = new google.visualization.Query(dataSourceUrl);
queryDataValue.send(handleDataValueQueryResponse);
setTimeout("moveTicker()", x);
}
This new function call to the spreadsheet at the given URL using the Query information every x amount of seconds. The function handleDataValueQueryResponse is a function that is called when the query is sent. The handleDataValueQueryResponse function, only retrieves the spreadsheet data and updates the gauge. This code runs in an infinite loop, since the program is designed to always retrieve data.
My project can be found here.
After I finally fixed the problem I began to work on getting the gadget to refresh every 5, 10, 30, 60, and 300 seconds. I quickly got the gauge to refresh every x amount of seconds by using the setTimeout() function. But I couldn't figure out why the gadget wouldn't get the new values that were being updated on the spreadsheet. I found that the 'Query' function for the google visualizations needed to be called to get the more recent spreadsheet info. So i wrote the following code:
function moveTicker() {
queryDataValue = new google.visualization.Query(dataSourceUrl);
queryDataValue.send(handleDataValueQueryResponse);
setTimeout("moveTicker()", x);
}
This new function call to the spreadsheet at the given URL using the Query information every x amount of seconds. The function handleDataValueQueryResponse is a function that is called when the query is sent. The handleDataValueQueryResponse function, only retrieves the spreadsheet data and updates the gauge. This code runs in an infinite loop, since the program is designed to always retrieve data.
My project can be found here.
Tuesday, March 30, 2010
Return from Break
Spring break was a very refreshing week. There was not much progress with our gauge application during the break. This was due to the face that we (me and my group mate paul) was assigned to work on getting the basics of the gadget running. This was a pretty simple task as both my partner and I worked on gadgets for the past 2 milestones. There is only one small problem with the gadget so far. There is an overlap in within the visualization.
At first I thought that this overlap may be a problem later on. But after talking with my partner, we figure that we will only be using one gauge at a time in each of the gadgets. So although we have two gauges shown in the gadget at the moment, we will cut it to one gauge.
Tuesday, March 16, 2010
New Group Project/Gadgets in review
After a couple months of working with Google gadgets, our group has moved away from the Google gadgets with visualizations and instead we are going to concentrate more on the visualization aspect. By focusing on the visualization aspect some of the coding should be a little bit easier. I am not 100% sure on what exactly we have to accomplish in this next portion of the course so I will write in more detail what we plan on working on in my next blog. So, since we are shifting our focus a little, I have decided to write a review some of what I have learned from the gadget projects.
In the Google gadgets projects, we had to pass a lot of information back and fourth and retrieve data from many different sources. While making the stoplight gadget and also making the wattdepot monitor gadget, we had to do two things to get the gadget working. We first had to get the visualization aspect of the code up and running, which is written in javascript. We then had to get the visualization code to run and work with the xml code that google gadget uses. So the gadget xml code retrieved the user inputted data, which then passes the information to the javascript where the visualization code runs. This visualization code retrieves the current api from the visualization website and draws up the information we need to get the visualization working. On top of that, both the stoplight and monitor gadget is looking at a data spreadsheet that is constantly changing. Having the code run through all these steps to get it running was a little of a pain. Luckily, while working on the project we never ran into a problem where something small that was out of our control went down. For example, we never had a problem with the visualization code not retrieving the library for the visualization. So by just having to work with the visualization portion of the code, I hope to sharpen my javascripting.
Overall, it was very fun working with the Gadgets and my group mates. I have learned a lot working on this project, especially about svg images and javascript. I enjoy coding and hope that the next half of the semester will just as fun.
In the Google gadgets projects, we had to pass a lot of information back and fourth and retrieve data from many different sources. While making the stoplight gadget and also making the wattdepot monitor gadget, we had to do two things to get the gadget working. We first had to get the visualization aspect of the code up and running, which is written in javascript. We then had to get the visualization code to run and work with the xml code that google gadget uses. So the gadget xml code retrieved the user inputted data, which then passes the information to the javascript where the visualization code runs. This visualization code retrieves the current api from the visualization website and draws up the information we need to get the visualization working. On top of that, both the stoplight and monitor gadget is looking at a data spreadsheet that is constantly changing. Having the code run through all these steps to get it running was a little of a pain. Luckily, while working on the project we never ran into a problem where something small that was out of our control went down. For example, we never had a problem with the visualization code not retrieving the library for the visualization. So by just having to work with the visualization portion of the code, I hope to sharpen my javascripting.
Overall, it was very fun working with the Gadgets and my group mates. I have learned a lot working on this project, especially about svg images and javascript. I enjoy coding and hope that the next half of the semester will just as fun.
Monday, March 8, 2010
Stoplight gadget 1.7
This week I am still working on the stoplight gadget. Hopefully, this will be the final touches on the stoplight gadget. The other two people in my group are working on the wattdepot monitor gadget. The modifications that we have made to the stoplight gadget this week are minor changes that will enhance the user experience while using the gadget.
The modifications are: for the gadget window to automatically adjust its height when the image size changes, the entire page does not refresh every time the reload time expires, and move the title of the gadget from the top of the gadget window to above the stoplight image. In our previous version (version 1.6), there is a lot of extra white space beneath the gadget when user would change the image size.
Luckily, this was very simple to fix since there is already a 'dynamic-height' feature in the google gadget api. So I only had to add a few lines of code.
The most tricky part of this weeks changes were getting the old values to change without changing the entire script. I originally thought that I would have had to add in some AJAX code to get the image, message, and units to all refresh without refreshing the entire page. I needed to find a way to trigger the event. Using the setTimeout() javascript function, I was able to get the images to reload without refreshing the entire page.
The modifications are: for the gadget window to automatically adjust its height when the image size changes, the entire page does not refresh every time the reload time expires, and move the title of the gadget from the top of the gadget window to above the stoplight image. In our previous version (version 1.6), there is a lot of extra white space beneath the gadget when user would change the image size.
Luckily, this was very simple to fix since there is already a 'dynamic-height' feature in the google gadget api. So I only had to add a few lines of code.
The most tricky part of this weeks changes were getting the old values to change without changing the entire script. I originally thought that I would have had to add in some AJAX code to get the image, message, and units to all refresh without refreshing the entire page. I needed to find a way to trigger the event. Using the setTimeout() javascript function, I was able to get the images to reload without refreshing the entire page.
Monday, March 1, 2010
More stoplight modifications
After looking at our stoplight gadget again at our weekly meetings, we yet again found some bugs and fixes that we decided to make to our gadget. This time, we found that we mistakenly used parseInt() to parse our strings to numbers instead of parseFloat(). This was a simple fix and didn't take much time to fix. However, we also found that the way we handled retrieving the message from the message spreadsheets needed to be changed. Previously we had our message spreadsheets have the upper threshold, lower threshold, and message fields. Comparing the thresholds in this manner had a few problems that we decided to get rid of my changing the format of the spreadsheets. Our previous format looked like this:
The problem with having the spreadsheet in this manner allows for too much error. If the data source that the user is looking at has the value 20.5, the stoplight returned would be a blank one, since the value is between 20 and 21. So we decided to change the layout of the message spreadsheets to the following:
The way the spreadsheet is now setup is pretty obvious after a small amount of explanation. The message would be 'low' if the value received from the data source is less than or equal to 10. The message would be 'medium' if the value received from the data source is less than or equal to 61. The message would be 'high' if the value received from the data source is less than or equal to 90. Finally, the message would be ' very high' if the value received from the data source is greater than 90. Having the spreadsheet formatted in this way removed the error that was previously discussed. This change, along with the parsing problem was fixed and is now implemented in the most current release of our stoplight project, version 1.6.
The stoplight gadget and any information about it can be found here.
The problem with having the spreadsheet in this manner allows for too much error. If the data source that the user is looking at has the value 20.5, the stoplight returned would be a blank one, since the value is between 20 and 21. So we decided to change the layout of the message spreadsheets to the following:
The way the spreadsheet is now setup is pretty obvious after a small amount of explanation. The message would be 'low' if the value received from the data source is less than or equal to 10. The message would be 'medium' if the value received from the data source is less than or equal to 61. The message would be 'high' if the value received from the data source is less than or equal to 90. Finally, the message would be ' very high' if the value received from the data source is greater than 90. Having the spreadsheet formatted in this way removed the error that was previously discussed. This change, along with the parsing problem was fixed and is now implemented in the most current release of our stoplight project, version 1.6.The stoplight gadget and any information about it can be found here.
Subscribe to:
Posts (Atom)
