Friday, February 24, 2012

Kukuicup Design - pt III

This past weekend, the PM responded to my submission, and that both have "potential".  Additionally, he posted a laundry list of improvements to make to all of our sites.  The most notable item was that none of us had really touched the info, nav, and quest-bars.  I had been under the assumption that we weren't supposed to touch these.  Moreover, I had actively chosen to leave the quest-bar in theme-2 black. 

In our last meeting, the PM elaborated on his list of grievances, and noted discontinuities in shadows, rounded/square corners, and color palettes for the aforementioned bars.  So I spent this past week trying to revamp these elements.  Initially I tried using an image manipulation program to modify the existing images, but found it EXTREMELY difficult to get the radial widths (despite knowing their values) of my rounded corners to match with those generated by the webpage's CSS.  After a while I realized this approach was a dead-end and ditched it.  My next (and only other obvious) avenue of attack was by manipulating the images/divs with HTML/CSS.  As it turns out, this works really well. 

I ditched the actual image, instead compressing the containing div, and using a combination of padding and margins to keep things in their proper place.  In the illustration, the blue area is the actual div that contains the area highlighted in yellow.  Naurally, shrinking a div of this size down creates layout problems.  I was able to overcome this by adding a small top margin and a giant bottom margin (margins are shown as the yellow area).  This keeps elements in their proper place, while allowing me to use the encompassing div as a useful background for my nav and info bars.  The rationale behind this whole song and dance is  that I can't actually mess around with the html files, as they have to be the same for every theme.  So I had to use CSS to mess around with existing divs.

I also found that I was able to make transparent gradients using the rgba() method.  For example:
    background-image: -moz-linear-gradient(100% 30% 90deg, rgba(239, 214, 120,.67), rgba(255, 255, 255,.67));
    background-image: -webkit-gradient(linear, 0% 0%, 0% 50%, from rgba(255, 255, 255,.67), to rgba(239, 214, 120,.67));
the above two lines normally define a gradient, but by using the rgba method, I was able to set an alpha transparency, and make them transparent.  Neat trick.  The only caveat is that you have to convert color codes from Hex to Decimal.

I present, the finished product:

Friday, February 17, 2012

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...

Friday, February 10, 2012

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

Saturday, February 4, 2012

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...