Kukuicup Design - pt II

So last week's meeting went pretty much as expected - the PM tells me my theme is "too gloomy" and reminds him of vampires.  Additionally, the PM agreed that there was "too much stuff" in the theme.css file, and instructed the groups to make a separate "style.css" file to contain all the non-theme related items (e.g. items needed to override/negate previously defined elements).  A discussion took place about not meeting as often.  The PM said he didn't like the idea and felt that frequent meetings (and thereby feedback) were important to the rapid prototyping methodology.  Interestingly enough, all our meetings this week were cancelled. 

I spent this week pulling extraneous elements out of theme.css and migrating them into style.css.  To the top of my theme.css file I added:

@import url('style.css');

I later discovered that issues arose when I sometimes removed elements from theme.css which were not defined by syle.css.  This resulted in certain elements having their settings defaulted to whatever was defined by the original kukuicup theme.  To resolve the issue, I essentially copied whatever css items were necessary to make the page (including both theme and style elements) into style.css, and then re-defined the same item in theme.css.  This lets theme.css have first-priority over what an element looks like, but if I accidentally (or lazily) fail to define a property of an element, style.css will still render it.  This occurs because I have the above nifty little import statement at the top of my theme.css page.

Another issue was that sometimes I wanted to change what was in the style.css file, but style.css was used by more than just one theme.  This made making style changes nearly impossible.  The answer was to have a separate style.css file for each theme.  While this is sub-optimal, it gives me the greatest flexibility over design options.

Anyway, to break up this giant wall of text, I'll show off a couple of the themes that I worked on this week.

"Theme-2"
Aiming for a "less gloomy", vampire-free theme.

"Theme-4"

We later got an email from the PM instructing us to createa "clean" white-based theme

If you're wondering what happened to "theme-3", trust me, your better off not knowing...

CSS Refactoring

So I spent the better part of the week reworking the CSS files for Makahiki.  As mentioned last week, the PM wanted us to factor out all of the relevant portions of CSS that affect the theme of the site.  The catch is that the files have to be able to support the old version of the site, as well as our newly proposed theme.  This doesn't leave a lot of room for design.

I got it done, but I'm not happy with the way the theme turned out (too many restrictions to realize my vision).  I'm also a bit hesitant to present the CSS file (theme.css in the SVN repository), as I feel that there's just too much stuff in it.  There were a bunch of specifically named divs that had custom properties that I had no choice but to include in the CSS file in order to overwrite their style.  Everything in the CSS file is necessary, but it's way too verbose.  I have a nagging feeling that there's a better way to do it.  I was looking at LESS and SASS, but had a feeling the PM wouldn't be too happy about that.  LESS and SASS provide the ability to template CSS files, and replace color/style references elegantly.  They do however have to be compiled.

From a design point of view, I feel like I could have made the site more vibrant and given it a higher contrast, however, this would have broken the "no dark backgrounds" rule.  I initially had some nice gradients, and transparencies, which provided enough contrast to pull off a color scheme that was heavily focused on shades of grey.  Unfortunately, some of the darker portions of the background and certain content boxes became too dark to pass the before mentioned rule.  I still have the dark theme floating around in my subversion files, and hopefully I can work it into a presentable product, but for now I'm submitting the lighter, lower contrast theme.

link to project:
http://code.google.com/p/kukuicup-rui/source/browse/#svn%2Ftrunk%2FCSS-Refactor

Kukuicup Design

I'm taking a step back this week from tinkering with the RUI code in order to make the site "pretty".

Last Friday, the PM(Project Manager) tasked the group with redesigning the Kukuicup website. 
Let me rephrase that - Last Friday, the PM  asked a group of twenty-something year-old CS-majors to redesign a website...


What happens when you ask a group of twenty-something year-old CS-majors to redesign a website?  You get Matrix-themed websites. 

The PM was not amused. 

To be fair, there was only one Matrix-themed website, but we were all thinking about it. 

The following Tuesday, we had a rapid-prototyping session, where we presented our ideas, and were given immediate feedback.  The PM pointed out that large amounts of time and money had been poured into the HCI aspects of the site, and that we weren't improving on that temporal/monetary investment.  As a result, we were instructed to simply change the "theme" or "look and feel" of the website rather than mess with any of the layout or display elements. It was also dictated that there be no "dark" backgrounds.

Later in the week, we were told to modify a few CSS files to pull out the snippets of CSS that controlled the look/theme for elements so that they might be more easily modified.

My initial idea for the Tuesday presentation was to go with the PM's desire (and numerous related e-mails) for a brightly colored "gamey" theme.  Since the Kukuicup will potentially be used by institutions other than UHM(University of Hawaii at Manoa), I had to have a relatively generic design.  However, I still wanted to incorporate the idea of team/school colors.  My solution was to have a generic Kukuicup banner with bright "gamey" team colors thrown in as accents. 

*Note the banner shown to the right is not the one I had wanted to use, but the one I was forced to use as I didn't have access to the $100 required to purchase the not-to-be-named program, required to open the desired file.

After the criminalization of "dark" backgrounds, I decided to go with a mid-toned grey with black stripes thrown in to break up the monotony.  I also followed one of the suggestions the PM directed at me and added a ghosted-logo.  I would have liked the image to be darker, but was worried that the PM might prosecute me for my repeated transgression.  I also tried adding the brightly-colored accents back in, but they just didn't seem to 'fit' anymore. 



The current mockup:

And mobile...

Kukuicup Responsive UI - Part I

For the past few months I've been working on developing a mobile layout for the Kukuicup, an energy conservation project at the University of Hawaii at Manoa.  The mobile version of the site sported a series of list-like menus (similar to the Yelp application), but user comments at the end of the competition said the mobile site was too different from the desktop site, and therefore confusing. 

Enter Responsive UI (RUI). 

Essentially, RUIs are webpages that re-arrange (or replace) content based on screen size.  The canonical example our group has been throwing around is the BostonGlobe's website (try re-sizing your browser window from wide to skinny).  The goal of creating a RUI is to have one dynamic webpage for any screen size, and hopefully giving users a sense of continuity and uniformity.

You're probably thinking to yourself "this sounds like black-magic".  Well, you're right.  But you don't have to deal with it (much).  There are a slew of prepackaged frameworks out there designed to do just such sorcery.  There seem to be two schools of thought on RUI frameworks - grids and magic hot-swappable CSS.  Grids are pretty much what they sound like, predefined grids that either scale or have a few fixed layouts.  With grids, content gets pinned to a row/column, and flows around as the screen re-sizes.  With CSS magic, media queries are used and load various CSS files based on screen size.  Essentially you build several CSS files and the media query figures out the screen size and points to the right file (in real time).   These methods are completely integrable, but frameworks usually swing one way or the other.

I've chosen Skeleton.js for this project, and so far it's working pretty well.  Skeleton favors the grid-system, rocking class tags for up to sixteen columns.  Skeleton also features a nice in-line labeling system:

<div id="a" class="two columns alpha">A</div> 
<div id="b" class="four columns omega">B</div>

The above divs will try to render on the same line if possible, with A preceding B. When space becomes limited, B will pop under A.  This is a nice feature that I didn't see in most other frameworks, and was a motivating factor in my decision.

I've been toying around with it, and find simply relying on the framework to do ALL the re-arranging isn't going to cut it.  So I've integrated some media queries to make things run more smoothly.  Media queries are part of HTML5 and part of the CSS3 standard.  They work in both HTML and CSS files, although each has its own syntax.  For example, in HTML:

<link rel="stylesheet" type="text/css" href="a.css" media="screen and (min-width:975px)">

 The above code loads the file a.css if the screen size is at least 975px.  However, placement is still important, as CSS files loaded farther down in code have priority.

In CSS, a media query looks like this:

 @media only screen and (max-width: 924px) and (min-width: 438px){
    #className {
        //new CSS definition
   }
}

This snippet will provide an alternate CSS definition for className IF the screen size is between 924 and 483 pixels.
Again, placement within the code matters as later definitions take priority.

Hopefully Skeleton, paired with media queries, will be enough to produce an elegant webpage. 
Details as they unfold.

API Development

If you think about it abstractly enough, Lego has one of the most powerful APIs in existence (Yes, I'm really using Legos as a segway into API design...).  Simple and elegant, anything with those iconic plastic nubs will connect to anything else with the same plastic nubs.  The only restriction? No diagonals.  Of course there's various extensions and spin-offs, but at it's core, lies a simple system of nubs and circles.  This simple system allows users to manifest almost any physical construct that gravity and static-friction will allow.

I've spent the past week and a half working with a group to design the API for a energy efficient house (Solar Decathlon).  Basically we had to figure out how to shuttle data between Sensors, Actuators, the back-end Database, and of course the user.  I wanted our API design to be like Lego bricks.  Ideally, it would be simple but powerful, just a few abstract classes and interfaces that let the user decide how to handle their data.  So I went off and wrote up the divine code.  Then my team informed me that my design used too much energy.  Crap.  A long afternoon spent at a round-table in the library found us quibbling over energy, extensibility, and a few other point-less grains of sand.  Eventually we settled on a very static and manual approach that saved a few watts. 

One area of interest worth expanding on is the method of data transfer.  It should be realized that passing everything around as a String is not the best idea.  After all, you'd have to spend time parsing data out.  Java objects might be a nice compromise, except they tend to take up a lot of memory, and still have an associated Class type.  XML is my new go-to-guy.  Storing a Document in a database is like saying there's molecules in my house, they could be anything.  Documents are nice and generic, and support OOP designs.  They enable a single-typed database that actually stores a range of different object types.  Our API relies heavily upon the mysterious, but generic XML Document.  Processes know how to access their designated Documents, and only their designated Documents.  Thus, processes are the only thing responsible for knowing how to handle the Document's internal format.  This helps to promote encapsulation, extensibility and information hiding.

...And now,I humbly offer these low-hanging fruits of wisdom regarding API design:

1.  Figure out what's important.  

  Will energy savings trump extensibility and elegance of design?  Is simplicity the better part of valor?  Odds are you'll have to take one aspect at the cost of another.  Figure it out before you start.  It'll save you a long afternoon of face-palming.

2.  Make sure the design is at least as extensible as it needs to be.

  We made concessions in our extensibility because there's only so many sensors that a house can have (plus were on a budget).  But make sure its flexible enough to grow.

3. Trace transactions from end to end.

We scrapped several ideas only after coding them, and then realizing they didn't work.  Make sure the functionality is there.

4.  "When in doubt, leave it out"

What does it mean? Who knows.  But if you can find an applicable context, apply it! 

5.  Don't tell them how you did it.

A wise man once told me  (I saw it on a Google Video) that users should never know exactly how a method does what it does, or else they may come to rely on it's process rather than it's result.  For example, if you tell users how a hash value is calculated, they may use the hash function else where.  If you ever change the hash function, you break their code.

BerkeleyDB

This week's assignment focused on bringing everything together into one monster webservice.  The build requirements called for a Wicket Client which accessed a RESTful Restlet server, which stored data in a BerkeleyDB database.  Basically, a nice web-based GUI that pulled data from a Server that stored stuff in a Database; a Turducken if you will. 

Recursively-stuffed fowl aside, the focus of this week was on Persistency (read: saving stuff).  Prior to this, my only method of storing data was in a Property Map, or Static Class, which unfortunately didn't stick around after execution  <insert guillotine joke here>.  The answer of course is to put things in a database. 

BerkeleyDB (BDB) is a neat little database service that runs in Java and a myriad of other languages (but most importantly, Java).  Having worked with DBs and webservices before, let me tell you, this thing rocks.  Set up is a breeze, and BDB is pretty darn flexible.  The best part?

NO CONNECTION STRINGS.

In this exercise, I had Contact objects which had unique IDs as primary keys.  All I had to do to was throw a @PrimaryKey attribute above the uniqueID attribute in the Contact class, and BDB associated it as the PrimaryKey.  Then, in the ContactDAO Class, a few lines of code let me define a "mini-DB" object, which let me call out mini-DB.get(key), mini-DB.delete(key), etc. BDB supports multiple mini-DB objects for various keys; in Kata 01, I used two (one for the PrimaryKey, and one for the SecondaryKey).  BDB even has built-in iterators if you need to return multiple entities.  Long story short, if you need a java database, go with BDB.

While I praise BDB for its ease of use and great utility, I should point out that Wicket (*glare*) is not so nice and took up all of a very nice Saturday afternoon.

On to the Katas!
Kata 01:
Easy Peasy introduction into BDB, simply add a timestamp as a secondary key, and add functionalities for a get-timestamp and get-range function.  <3 hrs (actually less than 2, but I accidentally overwrote it and had to do it again :c )

Kata 02:
The mastery Kata, combining Wicket, Restlet, and BDB to make an end-to-end Java-based web-service.   I theoretically had all the pieces from previous Katas, but putting them together took some thought.  I had to draw a diagram...twice.  Coding the back end was easy enough, and took about an hour.  Although many painful hours were spent on Wicket, which sent me maliciously deceptive error messages, before mysteriously clearing itself up. 


BerkeleyDB: http://en.wikipedia.org/wiki/Berkeley_DB

Distribution:
NOTE* Katas are in two separate files in the zip.
http://ics414-spring2011.googlecode.com/files/BerkeleyDB-GBurgess.zip

Restlet pt II

Distribution: http://ics414-spring2011.googlecode.com/files/restlet-contactservice-gburgess-1.0.122.zip
This past week my ICS 414 class dove deeper into Restlet.  Interestingly, we started using XML, which had me overjoyed, because I've had quite a bit of self-taught experience with XML, webservices and java.  Sufficed to say the assignment this week was pretty simple.  After completing the assignment, I ended up with a cute non-persistant local server hosting a little webservice that sent both XML and Java objects back and forth between client and server applications. 

The back-end(java) database used for this assignment was a single, static (black magic!) class that held a map between keys and values.  The important part was the static declaration, which meant that StaticClass.class.get() from anywhere returned the database.  Pretty nifty.

As disussed in a previous post, the REST interface supports GET, PUT, POST and DELETE protocols for resources living on the web.  You may be asking yourself how XML fits into the equation.  Well, most webservices available online or over intranets usually pass data formatted as XML.  XML is extremely well suited to being a "go between" language as data and metadata can be presented in a universally-readable format.  In fact, many proprietary software systems (I'm looking at you Microsoft) use XML as a back-end data storage mechanism.  If you think about it, this is pretty handy, it means that you, the average (or maybe not so average) Joe can parse data out of these files (granted theres a lot of meta-garbage floating around in there). 

DOM (Document Object Model) is used extensively in XML based webservices.  Basically its a Document object (read: box) that has a root element (read: tree).  The nice thing is that because XML is well suited to handling objects, so Java objects translate over nicely, and since XML is implemented as a linked-list/tree heiarchy, you can easily loop/iterate through the whole thing, pulling whatever data you need.  Handling these DOM objects in Restlet is a bit troublesome (LOTS of auxilliary method calls), however it should be noted that most XML extention libraries have fairly simmiliar method names.  One of the cool things about Java is that it supports a system by which XML and Java Objects can be encoded and decoded between eachother.  This is extremely useful as constructors on the Java side can be passed XML representations of Objects, saving you a bunch of method calls. 


If your planning on investigating on your own, here are a few tips:
1. Make sure you're using a browser that can parse XML (almost anything except chrome and safari), or else the tags will disappear, and you'll never know whats going on.
2. If in doubt about traversing/handling the DOM, getChildNodes() will return a NodeList of child nodes, and getItem(x) will return the node at position x in a NodeList.
3. You may have to call getChildNodes() twice to get to the NodeList that contains all the data.


As for the Katas:
Kata 05: Agregate Contacts
This kata focused on creating a DOM object that held the URIs of objects in the database.  My experience with the DOM system made this one pretty easy, less than two hours.

Kata 06: Implement a get-all and delete-all command for the database
This was more like Kata 05 pt II, basically parsing the URI's from the first part and getting the data out of each link in order to display.  Deletion was even easier, just grab the unique ID and call delete().  <2hrs

Kata 07: Extend Contact to implement a phone number
Easy peasy, until I had to deal with a FindBugs/PMD argument over somestupid Exception.  Basically updating the Contact object, and all calls & adding the phone number variable to various locations.  <2hrs

Distribution:
http://ics414-spring2011.googlecode.com/files/restlet-contactservice-gburgess-1.0.122.zip