Synchronous Scriblink

Heading into this new endeavor for the Billboard Mockup has become to a slight stagnant halt due to the lack of cohesion and communication. In past projects such as WattDepot-Apps and the BioHeatMap, the group size has never exceeded 3 people, including myself. But it seems that four people working on a single task deserves much more attention to detail in delegating tasks. One of the main lackings we faced was the ability to communicate with one another. With half the group with different schedules it was difficult to find time to talk about the billboard.

Previous collaborations yielded simple text messengers or exchange of e-mails sufficient, however, the billboard requires communication that cannot be conveyed in the two former mediums. For this unique situation, I remember using a site called scriblink.com with a friend who needed help with his Physics homework. Essentially, Scriblink is free online JavaScript-based white board that supports multiple users. Upon entering Scriblink you are automatically put into a private white board channel, from there you can invite people to your white board and each person has the same privileges to write/draw/import pictures all at the same time.

Although Scriblink is most enjoyable with a tablet (where you can freely draw like on paper), all you need is decent mouse skills to draw whatever. There's even a chat box on the side so if you can't participate in the drawing, you can still communicate textually to everyone else.

With the use of our new found tool Scriblink, a meeting was arranged with Kendyll, Jarret, and me, where we mostly talked about the specifics on the layout for the billboard. Here's a screen shot the mock-up we currently have:


Whereas here's the final 2 layouts we worked out on Scriblink:

The specifics for the columns are to be shrunk since some elements such as the Floor Standings can be tightened and made room for prizes/ads.

We also reasoned that if we sorted out and delegated tasks between the two sub-groups (Me and Kendyll, Jarret and Paul) we would still be working with those who we are most comfortable with and still be on task. Each portion of the module will be split between the two groups. Since Kendyll and I have been working on Google Visualization's the most out of our Software Engineering trek, anything that deals with charts/tables will be handled by us, where as prizes/ads will be dealt by Jarret and Paul.

Kukui Kup Continuous Display: What to Display?

With the conclusion of the WattDepot BioHeatMap gadget, I recently became involved in creating a billboard display for the Kukui Kup Competition. Ideally what this entails is a display for when students enter the lobby of their dorm, they can see various aspects of the competition such as dorm rankings, recent commitments, and upcoming events instantly as they walk by. This idea of a lobby display would be a cool addition to continually remind students to save energy and go green. Robert did some price comparing and this Samsung 46" LCD display seems sufficient to be the actual medium to display the billboard. It also features a built-in Windows computer as it will use a web browser to display content.

Tag teaming with the other gadget group, Jarret Mizo and Paul Galiza, Kendyll and I will be working together to create a functional mock-up for the billboard. To maximize development without worrying about cross-browser issues, we decided to develop everything using only one browser, the latest version of Firefox (3.6.3). Jarret recommended this plug-in: https://addons.mozilla.org/en-US/firefox/addon/1568 to install which removes the tabs at the top in Firefox when you Full Screen giving Firefox a clean look, which is a nice feature adding to the overall awesomeness of our developing billboard.

We'll post all of our functional mock-ups at a newly created Project Hosting site here.

In order to get a feel for the billboard I took a look at the mock-ups that were already done by a previous group here. It's got some great examples, especially the ones with the "Did You Know?", they'd make great transitions between the different set-ups. By the end of this week, we will have a functional mock-up of the possibly looking like the following:


The frameworks that we'll be using is a combination of HTML, CSS, and JavaScript. Since WattDepot already speaks Google Visualization, we'll mostly likely be using the Table Visualization to create any of the table data. Prof. Johnson also recommended some kind of ticker at the bottom of the page showing recent updates. I've been searching for an RSS Ticker that integrates nicely and this one: http://www.mioplanet.com/rsc/newsticker_javascript.htm looks promising.

Some modules I've been tossing back and forth with Kendyll are:

• RSS Integrated Ticker
• Display of Gauges, analogous to an International Wall of clocks
• Did You Know?

Go Go "Prototyped" Gadget: BioHeatMap v1.0

The completion of the BioHeatMap Gadget outfitted for WattDepot sparked one last test before totally labeling it as "finished." This was the cross-browser test to make sure that it did work properly in other browsers. So far, much of the work has been done in the latest version of IE, v8. This is sort of a contradictory action due to my past work in WattDepot-Apps. Much of the work was done through Safari and Firefox. However, since this was my first time coding for a Google Gadget, I felt a little more inclined to attach "training-wheels" to the whole process and start with Google Gadget Editor. But to my dismay, Google Gadget Editor does not load properly running Mac OS X Snow Leopard, on Safari 4.0.5 and Firefox 3.5.9. So I hoped on over to my Boot Camp'd Windows 7, and in IE and Firefox, the Google Gadget Editor worked, so I ended up doing much of my work there.

When it came time to view the BioHeatMap in Safari and Firefox, the gadget wasn't resizing it's height properly, and it seemed as though it stayed at it's default height of 200 pixels at all times. Here's a screenshot of what the gadget looked like w/o resizing:

This was a complete surprise to me since it resized perfectly in IE. I spent a good portion of my weekend trying to figure out how/why it wasn't resizing. Of course, the method that's supposed to do the auto-resizing is "gadgets.window.adjustHeight();" The first thing that I checked was that it was being called properly, which in fact it was... I scoured the Gadget Help Group to see if any other people had problems with the adjusting the height. But what I found was references to Google's deprecated method "_IG_AdjustIFrame();" which did not help. I tried replacing "gadgets.window.adjustHeight()" with "_IG_AdjustIFrame()", manually adjusting the height with window.innerHeight/window.outerHeight, nothing I did seemed to remedy the situation.

Looking at other Google Visualization Gadgets that used "gadgets.window.adjustHeight()" those gadgets resized perfectly. So it got me wondering, what's different about the BioHeatMap than other Google Visualizations. While sifting through the code I remembered that the BioHeatMap wasn't a visualization made by Google, so it had to use the Prototype library, an external open source JavaScript framework, to load the BioHeatMap. The "prototype" gave me another keyword to use to search for a solution.

Finally, I came across an existing issue in another Google Hosting Project. The issue found here: http://code.google.com/p/opensocial-resources/issues/detail?id=104 described exactly what I've been looking for. So turns out, there wasn't anything wrong with the way I was calling "gadgets.window.adjustHeight()", but the actual Prototype library itself and how it interferes with adjustHeight. The actual specifics of the problem can also be explained in the issue. About half a days worth of working out this problem and searching for a solution can be summed up into 3 lines of code...

Along with the auto resizing, I also implemented onboard time and date pickers for the BioHeatMap that is placed directly on the gadget itself without using the Gadget's Edit Settings menu. It was a real pain in the butt to code these things since all the HTML markup had to be manually coded and set. But nonetheless, I like how it turned out:

(Above is a picture of the last 24 Hours of real data from Prof. Johnson's house in Kailua, which features a Time Picker)

(Above is a picture of the last 14 Days of real data from Prof. Johnson's house in Kailua, which features a Date and Time Picker)

(Above is a BioHeatMap of multiple sources of UH's own Saunders Hall, displaying Kendyll's implemented multi-source capability)

Overall, I'm happy with the results. Creating a Google Gadget was a neat experience in that the output can be readily shown and easily distributed across many individuals just by linking to an XML document. However, the actual coding of the gadget itself was a little gruesome. Perhaps I've been spoiled by Eclipse and other IDE's, since I was mostly bounded to Notepad for this gadget. But now, instead of looking at lines on a chart, or numbers in a table, we can look at colorful blocks on simulated or live energy immediately showing trends and times of less and deep usage of energy.

The Google Hosting for all the WattDepot Google Gadgets can be found here.

Flux Capacitor of Transposition

Our BioHeatMap Google Gadget is well underway and almost complete. We've managed to move away from using Google Spreadsheet as our data source and can now take in Data Source URL's from WattDepot and user specified source to output a BioHeatMap of either the last 24 hours, last 7 days, or last 14 days. These options were chosen because of the width constraints set by Google. We didn't want a gadget that required scrolling, but wanted it to give a general idea of energy usage..using colors instead of boring numbers!

The most up-to-date version of the Gadget can be found here.
Whereas here's a screen shot of it running on my iGoogle page:
(Using Firefox and showing Last 24 Hours of SIM_HPOWER)


I'm extremely pleased with the output of this Google Gadget. Needless to say, this scant 3 liner gadget took a while to become what it is. After getting the query URL setup, and finally getting the auto-size height working, Kendyll and I ran into a huge problem with the visualization. Our very first WattDepot BioHeatMap visualization came out looking like this:


This is a step backwards because our proposed view of the gadget was to have the columns as dates, and the rows as sources. What we got instead was a completely transposed version of what we intended. The first thing I did was go to the Google Visualization API and look up the methods for the response tables. But to no avail there wasn't anything about a "transpose" method. At that point, I sent Kendyll a message on my progress. Kendyll scoured the Visualization Group to see if anyone had done this before, but his efforts for fruitless. So Kendyll decided to take on the task of creating a new Data Table and manually copying values to transpose the response table.

In order to get an idea on how to transpose the table, we had to get a little more information on what a response data table looks like. Using the toJSON() method on a response table, this is what a response table from a query to WattDepot looks like:


The table is column-typed/based, meaning each column defines the type of data that's placed in each cell for it's column. The columns are defined first ('datetime', then 'number' as above), then populated by rows. So in our case we would want the first column to be defined as a 'string' to list all the sources, and the rest of the columns to be defined as 'numbers' which hold the numerical value of whatever data has been queried. For the most part, the heart of the transpose function was implemented by Kendyll, however, to cross the finish line, he needed a fresh pair of eyes to look over the code as there were some minor details he over-looked. In this case, the column labels are strongly typed, and need to be a string. So we were using Date objects and had to explicitly call the toString method in order for the Data Table to process correctly.

Here's a snippet of the transpose function: (It takes in a response data table and returns a new table that contains transposed values)


After some final formatting of the dates, since blatantly using the Date objects toString method is extremely long for a Google Gadget, I coded a method to take only the parts that we needed and the final output of the gadget currently looks like my inserted picture above.

I added issues to Issue Manager for our Google Project, but the next thing we need to do is implement multi-source capability, because right now it only takes in a single source, but ideally it will be comma separated.