Billboarding and Scripting: The Mysterious Spacer Image

A lot of progress has been made on the Kukui Kup Billboard and most of the functionality we set out to do has been implemented. We did get a little lost on the way with four people doing the same project and all, but we just had to keep reminding each other what things needed to be done and someone always stepped forward to do it. This is one huge advantage that I realized when working in a group where there seems to be more than enough people. When you finally identify some specific task that needs to be done, there will always someone willing to take on the job, or at least there will be someone to delegate the task to. ;)

When we decided on the layout we were going to use last week, we also needed to lay out the functionality we wanted the Billboard to have and we essentially came out with this list:

• Apply more advanced CSS concepts
• Transitions for modules
• Create Google Visualization mock-ups
• Energy Tips

Currently, the most up-to-date version features all of the above objectives, and can be found at our project hosting site.

For now here's one screen shot of the billboard in action:

There's been a lot more style applied to it from last week's mock-up. There has been more style applied to the billboard overall and especially the ticker on the bottom. We also incorporated a BioHeatMap Visualization, sadly the gadgetized BioHeatMap that I worked on previously is incompatible with web pages due to proprietary gadget methods being called. But since this is more of a read-only type of deal, it doesn't matter if the gadget was used or not.

Next, here's another screen shot of the billboard:

I got it mid way through a transition showing that it fades out to do so. It is also showing an energy tip in the middle.

My work throughout the project has mainly dealt with the ticker and the visualizations. One problem that I did come across with the ticker was that when it first started, it never started entering from the right.

Here's a screen shot of the desired entrance when the page first loads:
(Notice it entering from the right side)


Where as here's a screen shot of where it was actually starting out from:
(Started from the left side and started scrolling)


Reading the semi-instructions for the ticker, it seemed like I was doing nothing wrong. I mean, how would I error if I was just copying/pasting code. I finally decided to ask Kendyll to help me in identifying what was going on. So we sat down together and we both were staring at JavaScript for about an hour... What we came across was that in the source code, the JavaScript uses a spacer image that stretches the length of the ticker to make it appear that it is entering from the right. But the instructions just said to use the .js source code and that's all you need. But we needed to make our own spacer image in order to get the desired affect. I guess the lesson here is that you can't fully trust instructions from another developer, and that even the most simple of instructions might be too simple and you forget a step to include.

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.

Gadgetizing BioHeatMap: Colorful Squares of Energy

Shifting gears to coding a Google Gadget is a very interesting and different experience than previous endeavors. My past projects such as Greenometer and WattDepot-Applications have yielded fruitful results, but creating a Google Gadget is something that can be immediately distributed and displayed directly on the web without any complication between servers or multiple frameworks.

With my partner Kendyll, and using his idea of implementing a BioHeatMap visualization, we decided to take on this new challenge as one step further in creating a tool student's can use for the UH Energy Dorm Competition.

An example of a BioHeatMap visualization looks like this:

It essentially takes in a matrix of data and conditionally formats the data by displaying various colors. It finds the max and min values, assigns two colors to them and all other values in-between, assigns color appropriate to how close those values are to the max and min. We are currently exploring two options:

1. Rows are the floors. There are 24 columns, one for each hour of the day. The cell is the *cumulative* energy consumed during the competition for that hour of the day. That gives people on the floor a sense for when they're using a lot, as well as how they compare to others.
2. Rows are the floors. There are 28 columns, one for each day in the competition. The cell is the total energy consumed by each floor on that day. (A cell is blank if the day is in the future so there's no data for it yet.) This shows which floors used a lot on a particular day. If a floor is mostly red, it's using a lot of energy, and if a floor is mostly green, it's using very little. It also highlights which floors are consistent vs. which floors are "spiky"---one day using a lot of energy, the next day using very little.

Since this is something relatively new to take on, the first thing on the agenda was to get a working "dummy" version of the BioHeatMap visualization as a Gadget. By looking at the BioHeatMap visualization page, it was a little discouraging to see that most of the development for the BioHeatMap has ceased since the latter part of last year. But by looking at other visualizations that are backed by Google, I came across the Google Visualization Gadget Gallery. Sadly the BioHeatMap was not listed under here since it was originally created by Institute for System Biology, but I was still lucky enough to dissect one of the listed gadgets, mainly Gauge. I chose the Gauge since another group is going to try and implement it for the competition, so I helped myself to see what they would be dealing with.

The actual .xml file is being hosted in the Project Hosting here.

But for those who want to try out the "dummy" BioHeatMap the link to add to your iGoogle page is: http://wattdepot-ui-googlegadgets.googlecode.com/svn/trunk/BioHeatMap/test-bio-heat-map.xml

The data source is just a Google Spreadsheet: http://spreadsheets.google.com/ccc?key=0AhWy1L2qDnFYdGtuQTlJME9rN2pDOFhGRFBuMHZsbFE&hl=en.

Right now only I and Kendyll have access to edit the Spreadsheet, so if you want access, just send me an e-mail and I'll add you to the Google Doc.

Some of the issues I'm currently at is the default height of the Gadget is extremely long. I will have to correct that this week and try and get it to fit "snug" with the visualization. A general issue I came across is while browsing the example pages for the BioHeatMap. Most of the examples look pretty cool, however this one caught my eye:

It looks like a total mess, and judging by the size, I'd say that's a typical size we'll be looking at. Although I'm not sure how sporadic the data has to be in order to get it like that, but just by first glance it's hard to interpret or make heads/tails.

Advanced Visualizations, New Frontier on Familiar Grounds

As the planning of the UH Dorm Energy Competition continues, there are still other things we are considering to implement. Shifting from WattDepot Applications, I am going to be working on a new topic, Advanced Visualizations. This new group is sort of like the WattDepot-App's Visualizer, except we are going to explore the different Google Visualizations and see how we can apply some of them to WattDepot.

The main group consists of , but I will be working with Kendyll Doi, the same Kendyll Doi from WattDepot Applications, as a sub group.

In order to get started, Prof. Johnson provided a few suggestions of what we could do. Right now, I'm just looking at the different suggestions and getting the feel of how I would implement them. Details about which framework we should use, either Wicket or Google Gadget, will be sorted out sometime this week.

Here are some of the suggestions that I think would be duo-able:

Rolling Update of Sensor Data

This visualization basically combines the idea of the monitor (i.e. get the latest value) with the trend line (show changes over time).

The idea is to have a visualization where you specify the source(s),the update interval (i.e. 30 seconds, 1 minute, 1 hour, 1 day), and the window size (i.e. 5 minutes, 1 hour, 1 day, 1 week), and the result is a chart that is refreshed every update interval and shows the last window size of data.

The reason why I like this idea is that in theory it sounds like the WattDepot Visualizer, but with an added refresh event and without the messy-ness of multiple sources, although in theory it could accommodate multiples (since it already does that). The only problem I'm seeing right now is that if the refresh interval is set too short, say 30 seconds.

---

Gauge

An alternative visualization for the "monitor" gadget. Also has red/yellow/green capability like the stoplight.

A simple enough visualization, similar to a speedometer in a car. However, the challenge with this one is that the example Gauge visualization shows that the limits between red, yellow, and minor are hard-coded values out of 100. My thoughts would be to try and scale all the values to 100, but that would require some type of maximum calculation for all data being presented, and since the data would be streaming live, it would be hard to set a number to scale to 100.

Indeed there are a lot more other Visualizations to choose from, but at this point the refreshing annotated timeline, and gauge seem to be the most plausible. The other visualizations such as Bio Heat Map for displaying energy generated and Term Cloud for quickly displaying a source that's consuming the most energy also seem plausible, but Kendyll and I are going to play around with the refreshable timeline, and possible Gauge to get us going. Our first weekly meeting for this new group with Prof. Johnson is scheduled for this Thursday. More details to come as Kendyll and I decide which framework and visualization to attempt to implement.

Rolling Out Milestone 2: WattDepot-Apps v2.0

Introducing WattDepot Applications version 2.0! The second milestone is here, and with it comes a newly completed application, the WattDepot Monitor, and a whole new look to the WattDepot Visualizer. The past month has been devoted to the improvement of the Visualizer, as well as the implementation of the Monitor. Sadly, the WattDepot Browser is going to have to wait for another developer to pick up as the Visualizer and Monitor took up most of our resources.

Our updated Google Hosting site for WattDepot-Apps can be found here, complete with featured wiki pages for end-users as well as for developers curious about WattDepot and our project. For this latest release, there are 3 new downloads which can be found on the Downloads page. They include the individual .jar files for the Visualizer and Monitor, and the distribution .zip file which contains all the source code for each application.

I will briefly go over each application, and some of the new features. For more information you can look at the various wiki pages here.

WattDepot Visualizer

---

The WattDepot Visualizer is an application that uses Google Visualization's Annotated Timeline and Table to show data about a single or multiple sources throughout a given beginning and ending date in a WattDepot server.

Here's a screenshot of what the Visualizer looked like for milestone 1:

The major issue the Visualizer had in milestone 1 was that it could only display data about a single source, hence the drop-down menu. But for milestone 2, we were able to get that working properly, and now the Visualizer looks like this:

There was some discussion about the overall layout of the components. In milestone 1, the Display Data and Source started to hang on the left side, but ultimately we decided it would look more efficient if we had all the components at the top going left to right.

When running the Visualizer .jar you can specify three arguments, which are optional. These are the port number which the Visualizer listens through, and the Data and Rest URIs. The Data URI is used to query WattDepot when creating a Google Visualization, while the Rest URI contains sensor data and all information about each source in the server.

One of the tasks I had to do to make the configurable Data URI possible was pass a variable from Java to JavaScript using Wicket constructs. To get started, first I visited the Wicket Mailing List and tried to see if anyone already tried to do what I want. I searched a couple pages, but couldn't find exactly what I needed. There were some variants, but nothing directly I could use. However, searching through Google, I stumbled across a Chillenious' WordPress which was exactly what I was looking for. The post itself was done in '06 so some of the coding needed to be altered, mainly parameterization. What I needed to accomplish a "variable substitution" was to wrap a HasMap around a Wicket component (IModel).

Here's a snippet of the parameterized version:

Here's a snippet of the JavaScript of the variable being substituted:

Overall, the Visualizer works as intended, it may not be the most aesthetically pleasing as it is just a Developer level application, the functionally and groundwork has been implemented and I like how it turned out.

WattDepot Monitor

---

The WattDepot Monitor is an application that displays the most recent SensorData of a given source. The user simply selects a Source, Interval, and Data Type, and the Monitor will refresh every interval showing the most recent value of the selected data type. The development of this application was solely Wicket, which was an interesting experience. I had to learn by example from sifting through the Mail List and also going through the Wicket API.

During the initial phase of the Monitor Prof. Johnson drew a mock-up of how the Monitor should look like:

For milestone 2, here's what the Monitor looks like:

Much of the design of the Monitor was pretty straight forward. One of the new features that we added was a Portable URLs. What it does is pass parameters through the URL and configure the UI components accordingly. Ideally we wanted to have this feature in both the Visualizer and Monitor, but we only had time to implement it for the Monitor. It makes more sense to have it in Visualizer than the Monitor, but we wanted to start on a more simple case, and maybe the next developer can implement the rest. The components in the Monitor are all Wicket while the Visualizer is Wicket and JavaScript so it may require some modifications to work properly.

Closing Thoughts

---

It's been a long and arduous past couple months, yet I've learned quite a lot. A big part of it was just learning Wicket constructs, but the practices we used through Hudson, SVN, and Quality Assurance tools, helped carry the project forward as each step we took to create the final product. The weekly meetings helped set what we needed to do and the constant feedback at each development phase ultimately made the finishing touches on both applications.

Monitoring a Green Future, Tweaking WattDepot Monitor

The second milestone is almost near and by next week Tuesday will have reached the deadline. There has been much progress throughout both milestones for each of the sub-projects. Since last week, the basic functionality of the Monitor was complete. Our weekly meeting with Prof. Johnson and Robert Brewer awaited input on the Monitor as a whole. Much of the comments were on the design itself.

Here's a screen shot of how the Monitor looked last week:

The main comment about the Monitor was that it seemed too loose, there needed something to contain it since it looked like everything was just floating on the page.

After taking into consideration of the comments, here's what the monitor current looks like zoomed in:

Looking back at this past week, I realized what I was doing was more on the basic aesthetics of the Monitor. I was designing something for a kiosk, or for continuous display. So along with the added borders, I changed the font to Sans Serif so it would be better viewed from a distance, and also bold the labels on the right side.

During the meeting, I was on UH's wireless network, which doesn't always have the most reliable connection. So at times, the Internet would cut out, and to my dismay, here's a few screen shots that shocked me:

(Above: No connection on initial load)


(Above: Connection lose during monitoring)

I did not take into account a bad connection, thus some of the error messages actually blended in with the form itself as in the first picture, or a very unhelpful user-end error message as in the second picture. After some adjustments, the Monitor now displays these when the connection fails:

(Above: Drop-down menu just says No Sources when there is no connection on initial page load)


(Above: Right side simply says Connection Failure, and will resume monitoring when connection is restored)

With this new layout in hand, it awaits input for tomorrow's meeting with Johnson. What I am also looking into is a Reset button. For the most part, when the Monitor button is clicked, it simply sends a new form and theoretically should update the Monitor, however, at times when the Java is waiting for a response back from WattDepot, Java becomes dead-locked until the call completes. It is during this time that if a new form is submit, depending on how long the call to WattDepot takes to compelte, the form might revert back to it's previous state and dismiss the new form that was trying to be submit. A Reset button would be a sure fire way to ensure that the form will always submit and update.

We are also looking into creating portable/pretty URLs that take in parameters through the URL and adjust the components to match. So instead of clicking through drop-down menus, a user would simply edit a URL, and it would accomplish the same task. Right now, the page is able to parse arguments through the URL, but ultimately you still have to click "Monitor" button to start the process.

Also, when you click "Monitor" the URL of the active page becomes:

But as a release we want it to generate the appropriate URL in the address bar, not the console where we currently have it:


For this week, what we are aiming to accomplish is both the Visualizer and Monitor applications. We need to have completed the Visualizer and Monitor to the best of our abilities, get a distribution up on our Google Project site, and create new Wiki pages to match. If we're never going to touch WattDepot-Apps again, atleast we will have all the documentation necessary for any developer to pick up where we left off.

It's funny how these little things catch you when you're only programming for functionality and not actual use. The gap between a developer and end-user sometimes gets lost when just programming for a grade and not for actual deployment, which is exactly what this class aims to do.

WattDepot Monitor First Iteration

This past week for my Software Engineering class I've been working solely on the WattDepot Monitor. The WattDepot Monitor as a web application that displays the most recent sensor data of a selected source in WattDepot.

While the Visualizer dealt with JavaScript, Java, and Wicket as its background engine, the Monitor was solely based on Wicket constructs. During our weekly meeting with Prof. Johnson, we concluded that the person to do the Monitor would be the one who is most knowledgeable in Wicket. Since I was the one setting up all the other pages WattDepot-Apps uses and other various UI components that the Visualizer uses, I was the most likely candidate for the task. I actually wanted to do the Monitor because some of the elements that the Monitor needed (timer behaviors) were already incorporated in last semesters project, Greenometer.

I've completed the base functionality, with some assistance from my teammate Bao with the time conversion, of the Monitor. Here's a screen shot of the current interface.

Right now the trunk has the most up-to-date version of the Monitor with debug print statements active. As of now, there has not been a .jar created solely for the monitor, but I will not make one until probably after tomorrow's meeting.

The basic How-To goes:

1. Select your source. After you select a source, beneath the drop-down menu a text field auto-updates and notifies you how often the source gets updated.
2. Select the interval. The interval is how often you want to check WattDepot for new data.
3. Select the sensor data type
4. Click "Monitor" this will start the action of monitoring a source and output will be displayed on the right hand side.

The current issues for the Monitor page have been added to the Issues page in our hosting site. But here's a short list of the current issues:

• Some sources take longer than the specified interval to display. Say for example the interval is set to 5 seconds. Some calls to WattDepot (i.e. a call to SIM_OAHU_GRID, the largest source) takes as long as 10 seconds to respond and output the new data. So the difference between 2 successive "Last Checked" times are longer than 5 seconds.
• Need a way to notify the user if he/she sets an interval that is way lower than the source's update. Say the selected source updates every hour, but the user selects 5 seconds as the update interval.

A nice feature would be to have a nice URL for the "Monitor" button. Right now, when the "Monitor" button is clicked, it adds the Wicket action to the URL.

E.x.

http://localhost:7070/wattdepotapps/?wicket:interface=:3:1:::

to just

http://localhost:7070/wattdepotapps/monitor

So far these are the known issues that I can think of, just waiting for tomorrow weekly meeting with Prof. Johnson and Robert Brewer to review it.

WattDepot-Apps: Second Milestone

After my groups weekly meeting with Prof. Johnson last week Tuesday, it was decided that we will continue to work on the WattDepot-Apps project for the second milestone of the semester. Our most recent distribution of WattDepot-Apps implemented the basic visualizer without multi-source capabilities, and a skeleton structure for the WattDepot Browser page. Though the distribution itself is mainly for the Visualizer while still containing source code for pages in the next iteration (i.e. Browser page).

What seemed like would be natural to start working on the Browser page, Robert Brewer and Prof. Johnson decided that the next application to be developed will be the WattDepot Monitor instead. The WattDepot Monitor is an application that will display the most recent data from a chosen source, and while the application is active, will update every so often given a chosen interval.

During the meeting we established the week's To Do list which included:

1. Re-structuring of Visualizer layout
2. WattDepot Monitor
3. Multi-source functionality to Visualizer
4. Subsource capability for Visualizer
5. WattDepot Browser

(I've also ranked them in to the most to least important)

During the meeting we also delegated on who's to do what. Since there were 2 major things to be done between the 3 of us, Kendyll would handle the re-structuring and multi-source capabilities, I would handle the Monitor page, and Bao would be the go-between.

The main focus of last week Tuesday's meeting was the Monitor, so we pretty much did a run down of how the Monitor is to be set-up. This included the layout and functionality. What I accomplished for this past week was revert the trunk to before the v1.0 Distribution. I added back in the main page so that the user can select between the Visualizer and Monitor. I've also added the Wicket UI components to the page and created an Ajax behavior that changes a label on the page to show the selected Source's update interval. Even though Bao was supposed to be the go-between and facilitate my and Kendyll's work, he showed some interest in working with the Monitor so we are going to work together in creating the page.

Earlier in the week Kendyll had moved around some components in the Visualizer page and it caused the time drop-downs to no longer work. But just recently he had corrected the error by reverting to an older version and re-arranging the layout. As of now, the trunk currently has a re-arranged Visualizer and skeleton working of the Monitor.

WattDepot-Apps: Visualizer 1.0

The time has come for the first milestone in my Software Engineering class. My group and I are to unveil the first iteration of WattDepot-Apps. What we had boldly set out to do were the three applications I described in my previous posts (Visualizer, Browser, Monitor). Most of the past month was devoted to the development of the Visualizer, a web application with a User Interface that queries the WattDepot server and uses Google Visualization's Annotated Timeline/Chart to display the data.

WattDepot-App's updated Google Code Hosting site here

*Complete with featured wiki pages for end-users as well as developers curious about WattDepot and our project.

Both the stand-alone binary .jar for the Visualizer and the complete distribution .zip file can be downloaded at our Google Code site here.

The jar file is solely for the purpose of running the Visualizer whereas the distribution contains not only the classes for the Visualizer, but also the classes that are soon to be implemented, such as the Browser. There are still quite a few issues that need to be worked out with the Visualizer page, all the issues concerning the whole project can be found at the Issues Page here.

The gist of the Visualizers Issues includes:

• Multi-select capabilities
• Subsources Option

What I want to point out is that for this first milestone, what we wanted to present was "the" most completed aspect of our work. Therefore we actually downgraded the source multi-select to a drop-down menu since the multi-select checkboxes would only take the first source selected and ignore any of the other sources. We will definitely try and get the two mentioned issues completed and start working on the browser page. Those wanting to check out the trunk via SVN may do so, but v1.0 distribution and what's currently in the trunk is different. What's currently in the trunk is current work into v2.0 which is the multi-select elements.

Looking back this past month, there were a lot of constructs I had to revisit. Most of which being Wicket and Java, but I also dealt with some JavaScript, which I never touched, I even dived into some User Interface design aspects such as menu placement, browser compliance, and resolution issues.

The hardest part of this first milestone was just getting everything to work, reading up on how to implement specific elements such as Wicket's CheckboxMultipleSelect, implement JavaScript actions to invalidate options, and working with Google Visualizations. For the most part we always knew where we were headed, we just needed to get there.

An aspect I found semi-ironic was the laying out of tasks. Before and after every meeting with Kendyll and Bao, I always made sure we knew what tasks needed to be done, however, when it came time to actually do work, I still needed to see the Issues page and constantly remind myself and the others what we needed to get done.

What I've contributed to this first milestone included setting up the initial groundwork for all development, which included creating the Google Site, setting up a Continuous Integration job through Hudson, and creating the base site for WattDepot-Apps that runs through Ant. I've also added Wicket components to the Visualizer page, as well as other HTML components that is used to query WattDepot.

The next milestone we will probably resume work on this project and continue our same work habits. I believe if we maintain our work ethics and continue to output the same level, if not higher, we can truly develop the three stand-alone applications we set out to do.

WattDepot Status: Progress Retarded

It has been three weeks since this semester began and already is the first milestone for Software Engineering coming up next week.

What I thought to have started out strong with the initial setup and progress with WattDepot-Apps, has suddenly taken a huge bump in our road to completion. Although I can't blame anyone or anything in particular, a snag was bound to happen within the three weeks of working on this project.

To re-iterate our final project deliverable, WattDepot-Apps, was set to complete three stand-alone applications for the WattDepot service. This included:

• WattDepot Visualizer
• WattDepot Browser
• WattDepot Monitor

Our main focus was to work on each project before moving to the next. We compromised that it was better to have one completed, if not, near completed project, than having 3 partially functioning one.

By the end of this week, it will mark 1/4 of the semester gone by, which means the semester is in full swing, with midterms coming up, I believe it will be even more difficult to keep up the progress we once had.

For this past week, the momentum we had died down and we stood a more steady approach to things. Our weekly meeting with Robert Brewer, the WattDepot Wiz, was canceled due to inactivity. What we set out to finish by today was a working version of Visualizer with advanced User Interface components, meaning multi-select menus for sources and data types, and the initial setup of the Browser page.

What we did accomplish though is getting the Multi-select menu to render all the sources of WattDepot, setting up JavaScript to accommodate erroneous option selection, and re-designing page layout to better suite the new User Interface components.

The problems we encountered were between the different constructs we were using to get the site functioning. The base of our site is Wicket based, which is supposed to interact well with Java, however, we also need to use JavaScript in order to get Google Visualizations up and running. Between these three systems, it was hard to jumble between each of them. The way that Wicket is designed seemed to be a hassle to code JavaScript for what we needed. The most irritating I found with Wicket was that setting Default options for menus is a complete headache. When I converted the source drop-down menu to a "CheckBoxMultipleChoice" I ended up hard-coding a default value in the JavaScript of the page because I could not figure out a simple way to set defaults using Wicket.

For this week, we will have to haul double-time. Getting the multi-source selection is our top priority, once we get that done the Visualizer is pretty much complete. For the Browser page the initial workings is in progress. Unfortunately only half of the functionality can be implemented since half is Source summaries, and the other half is User data. The User data has yet to be completed, and even then, there seems to be permission issues with viewing non-public user information.

WattDepot Visualizer Underway

For this past week in Software Engineering, I have been working on the first stand-alone web application for WattDepot-Apps, the WattDepot Visualizer. The name hasn't officially been decided, but I'm just sticking with WattDepot Visualizer for now. So far, I believe that project WattDepot-Apps has met our set deadlines and is currently progressing nicely.

First off, by the next day, Tuesday 1/19 team WattDepot-Apps had a meeting with Prof. Johnson to talk about the general direction we'll be heading. We decided on which Google Visualization to implement, and with much debate had got it down to either Annotated Timeline or Multi-colored Bar Graph. Considering the pros and cons of each, it was decided that an Annotated Timeline would be much cleaner to use.

On the same day we discussed the overall functionality of what each page should do. The game plan is to complete one application at a time so most of the discussion was geared towards the functionality of the Visualizer page.

To split up the work, I would be the one to set-up the initial ground work for everything to do done. This included an initial Java/Wicket project that will be hosted in the Google Project Hosting - WattDepot Apps. Apply Software Engineering techniques such as Continuous Integration through Hudson and automated Quality Assurance tools with Ant.

Bao seemed to be the most eager and strong in JavaScript so he would be the one to set-up the initial JavaScript that will take the input through the UI elements on the page, and create a query to be sent to WattDepot, and hand the response to Google Visualization and output the Annotated Timeline.

After the Bao completes the initial JavaScripts, it would be Kendyll's job to convert the Annotated Timeline into another visualization, be a Table, so the user can interactively inspect WattDepot data through hard numbers instead of just a graph. Looking for project Carbonometer for inspiration, Kendyll also will look into why their visualization currently no longer works, which was also brought up at the meeting.

By 1/21, I uploaded an initial site that laid the general work area that the whole group will be using. For now, the project contains basic UI elements. The major thing that will be changed is the drop-down menus. They will eventually be changed to multi-selection boxes so users can select multiple sources and display multiple data types in a single visualization. But for now in this initial set-up we just want to get a running visualizer working that actually query's the WattDepot server, get a response, and pass that response to Google and get the visualizer to display on the page.

The end of this past weekend, Bao had completed JavaScripting and managed to get the visualizer up and running. Now that the visualizer is in place, Kendyll now takes over and will add in data tabulation, as well as look at some minor aesthetics since right now the page is pretty plain.

I'd say that the most difficult obstacles this week was planning out a general layout for all the User Interface elements such as drop-down boxes, date pickers, the visualization itself, and meeting general functionality requirements. There were a few coding issues that had to be addressed, but we got through them. We see each other everyday so the project is constantly being talked about and comments/suggestions are always being thrown around.

The goals for this week is to improve upon the current visualizer and hopefully get a start on the Browser page. To improve on the visualizer we will need to switch out drop-down menus and replace them with multi-selection elements and set-up more advanced JavaScript code that will gray out certain options depending on what the user selects. I believe this will be the most difficult stage since it deals more intense coding that any other step.

ICS 414: Software Engineering Season 2

It's the start of a new semester and for this one, I'm currently taking the second half of Software Engineering. Prof. Johnson, the same professor as last semester's ICS 413, is teaching this semester's ICS 414.

Continuing off from last semester, where the last stages of our final project was based on the idea of saving energy and going green, we are continuing with project WattDepot, but this time we are working together with graduates, and outside organizations such as HEEP - Hawai'i Energy Efficiency Program to expand the idea of going green and saving energy.

There were many ideas that were pitched on our first day.

Here are some possible sub-projects that are currently underway:

WattDepot apps:

    • A set of stand-alone webapps for WattDepot.

Google Stoplight Visualization:

    • General purpose stoplight widget.

Hawaii Energy Efficiency Program apps:

    • Oahu grid data inside the HEEP website.

Kukui Cup technology prototypes:

    • Dorm energy competition website.

Kukui Cup competition design:

    • Content and structure of the competition.

Energy meter design:

    • Hardware and software specs for dorm energy meters.

There will be 4 milestones throughout the semester, at each milestone we will be give a final report and a deliverable on what we accomplished.

For this first milestone, I am working in project WattDepot-Apps. For this project, I feel I am on familiar grounds since this is probably the only project that's almost exactly like what we were doing last semester. Essentially, for WattDepot-Apps we want to quickly visualize the WattDepot repository using Google Visualizations to accomplish this.

For WattDepot-Apps, there are 3 possible stand-alone apps we will be taking on:

WattDepotVisualizer:

    • Use Google Visualizations to interactively display various data from the WattDepot service.

WattDepotBrowser:

    • Interactively inspect WattDepot

WattDepotMonitor:

    • Provide real-time updates and automatically push recent data w/o constantly polling WattDepot.

We were assigned our groups last week Thursday and have begun the organization process. Within the past week we have set up our initial Google Project Hosting named WattDepot-Apps right now it's not much to look at, but we set up Issues for each member.

For inspiration we've taken a look at last semesters proto-type projects Carbonometer and Greenometer. The base functionality exists, but they require some tweaking in order to get each up to specifics.

Some of the difficulties in this first stage was how to divide the work. Since this was relatively new, and the deadlines were a little strict, it's hard to tell how much of each sub-project we would actually get finished. For this reason, we decided to take each sub-project as a 1 week deadline, and micro-manage each part. What we've decided to do can be summarized by looking at our Issues Page in our Google Project, I suggest clicking on Grid View to get a more organized view of what each person in our group is doing. Most of the initial tasks are research and determining what things we should add. Some of the more immediate coding aspects are setting up the initial site for each stand-alone application to run.

Our goal for this week is to get an initial site uploaded to the trunk of your project. The bare skeleton will have atleast 1 page, for the Google Visualization, Wicket UI elements, a test case, and also JavaScript to test querying WattDepot. Probably about mid-way through the week we will have settled on which Google Visualization to implement, and also start brainstorming on display elements for the WattDepotBrowser.