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.