The Grid

As the semester draws to an end, so too does this project.  PM gave us notice that this would be the last week we work on our sites.  I'm a little sad to see it be over, there have been some really neat ideas, awesome designs, and creative solutions.  It was fun to see what everyone else was doing from week to week.  Plus, have multiple people working on the same problem made the project a whole lot less stressful.  It took away a lot of the burden and mediocrity of what otherwise would have been a belly flop into a sea of endless divs . 

My goals for the last week were to finish cleaning up the site (the energy, prizes, & activities pages).  I also wanted to integrate Elton's Epic Grid.  I'll simply point to Elton's blog, and leave it up to the reader to educate themselves.  Elton's Grid is pretty slick.  At the last meeting, Elton pulls out his phone, brings up his Grid, and the group is wowed.  He pulled it off.  He made a hulking 9X12 interactive grid fit on a mobile screen. 

So of course I had to beat him... of course.  But the fact is, I can't.  Elton did a bang up job, the only small thing I could add was to fix a small issue where the title boxes for each row overflowed.  I did so by rotating the titles sideways, and elongating the divs.  The result is that the gird fits nicely on a 290px wide screen, which is just about any phone screen in portrait mode. 

Desktop View

Mobile view

Back to Square One

So after a pair of meetings on Friday, the PM lays out the following requirements for the Homepage:
1.  It should be in a list (and wrap freely)
2.  Elements should always be centered.
3.  By default, 3 elements per row.
4.  Flexible enough for 6-8 elements.
5.  It should be responsive.

The list seems simple enough, but in reality, items 1 and 5 are contradictory.

The original homepage had two rows of three elements (there were only 6 elements at the time), which were responsive, but overflowed their rows.  The result was that each row of three elements rendered as two elements pushed to the left, and one lone element wrapped on the next line.

My fix for this was to throw all the elements in a list, so that they wrapped freely, maximizing the number of elements in a row.  But this caused difficulties in centering elements.

The (lame) solution was to simply fix the over-flow problem, and have two rows of responsive elements.  However this looks strange on a very wide monitor, as you have three super long elements in each row.

The ultimate solution would probably to use jQuery or MVC-templating to dynamically determine how many elements to put in each row based on the screen size, and handle margins accordingly.  However, I felt like the PM might view this as "hackish" or too time-consuming, and so avoided it.

The Latest Build

Mobile view

Anyway, back to the meeting.  The PM tells us to ignore the larger screens for the moment, and try to get something that works well at a width of 1050px (his laptop resolution) and lower.  My latest bid goes back to square one: fixing the responsive rows to keep them from overflowing.  I did however integrate the multi-column mobile view from last week. 


A cool trick that I picked up this week was the use CSS selectors

:nth-child({ number expression | odd | even })
and

:nth-of-type({ number expression | odd | even })

I'll direct you here for a more detailed explanation and some nice samples:
http://css-tricks.com/the-difference-between-nth-child-and-nth-of-type/

But essentially they let you (in CSS) select elements of a parent using values and expressions.  Notably, they let you select every other, every third, or every nth element.  In my case, I used them to select the seventh element and give it a margin-left: 20%.  This essentially centers the last row of elements.  Neat right?

Link to the file in question:
http://kukuicup-rui.googlecode.com/svn/trunk/Bloggable/4-17-2012/home.html

and the CSS file:
http://kukuicup-rui.googlecode.com/svn/trunk/Bloggable/4-17-2012/css/home.css

Sometimes the Best kind of Responsiveness is no Responsiveness

After playing around with the HTML, and exploring Twitter Bootstrap's CSS, I've finally found the difference between class="row-fluid" and class="row".  Both containers scale with the page size, but row-fluid will also scale the components within that fluid row.  A plain row will keep the items a static size, and wrap them when there's not enough room.  After this week, I can appreciate having both options. 
  When doing my news page, I had the choice of either letting my elements flow and wrap as the page re-sized by using rows or making them stay put simply scale using row-fluid.  I would have opted for the standard row, but there's still a little bit of glitchyness caused by the overrides to the Bootstrap codebase made by senior developers.  So I ended up going with the fluid rows to keep things from hopping around excessively.



  Speaking of trouble with jumping elements, I had an issue in my homepage.  The homepage normally features several large icons-links with accompanying text.  Originally these icons were centered above the text, but I felt that this took up too much room, and so pushed the images inline with the text, and pushed them over a static number of pixels. 






This caused chaos when the divs were re-sized, images and text boxes went flying ever which way.  To rectify this, I had to make sure that the divs stayed a static width.  This effectively meant I couldn't use Bootstrap's built in responsiveness (but that didn't prevent me from trying for several hours).  Anyway, after a hard-fought but pointless battle, I realized I had a simmiliar issue weeks before.  The news page features a widget called "Lounge Members" which is made up of a div containing imagelinks that don't scale, and arrange themselves to fit within a scaling div.  Bingo.  After looking through the source, it turned out that the widget was an unordered-list (<ul>), with each imagelink being a list item (<li>).  To fix my homepage, I did the following:

<div class="dynamicallyResizingDiv">
    <ul>
          <li>
              <imageicon goes here>
          </li>

         <li>
              <imageicon goes here>
         </li>
        ....
   </ul>
</div>

 Of course I messed around with the margins on the li elements to make things look pretty.  And now that's sorted.


links:
news page: http://kukuicup-rui.googlecode.com/svn/trunk/Bloggable/news.html
home page: http://kukuicup-rui.googlecode.com/svn/trunk/Bloggable/home.html

BootStrap Take-2

So after playing around with bootstrap for the past week, I've come to the conclusion that it's pretty smart.  I mentioned last week a potential problem regarding the arrangement of divs of varying heights.  Well, it was a non-problem, I just threw the divs in question into another div and gave that div a span6 class (which makes that div dynamic).  I also gave a row three span6 divs (the sum of spans in a row should not exceed 12), and it handled them nicely, aligning two on the same row, and throwing the third to the next row, left justified.  The biggest challenge in this project is that the senior development team overwrote the auto-sizing/dynamic placements with media queries so that the navbar and infobar (the two strange looking bars) would span the entire width of the page.  This means that I have to handle my own margins, and that some of the custom-defined scaling parameters cause bad/awkward placements at some browser widths.  I've been trying to deal with these oddities on a case-by-case basis, but I've ended up writing a long series of media queries for very small,specific ranges of width.  Not very dynamic at all.  I think the solution in this case is to ditch the screen-spanning nav and info bars (plus the overridden CSS), and maybe use a hero-unit (one of BootStrap's features) instead. 

"A difference that makes no difference is no difference".
At the last meeting, I had a discussion about using rows vs fluid rows (class="row-fluid") .  It was advised that I use fluid rows, but from what I've seen so far, the difference is negligible.   This might stem from the fact that some of the CSS was overridden. It may end up being of some significance down the line, but I'll deal with it when I get there.  In the mean time, I can't complain about the performance of standard rows.

LESS is GREAT!
Last entry, I griped about how it had to be compiled, but honestly, it isn't that bad.  But after getting to play around with it, I found that "LESS-ifying" my CSS files was a simple matter.

<link rel="stylesheet/less" type="text/css" href="your-theme.less">
<script src="less-1.3.0.min.js" type="text/javascript"></script>

The above snippet is all that's needed to "compile on the fly".  Essentially there's a .js file that compiles the .less file on demand.  Pretty nifty.  My biggest fear was having to compile a LESS file every time I made changes, but this approach is just wonderful :).  For performance, once the LESS file is perfected, it can be compiled to a straight CSS file for faster page loads.
 
Here's the link to the .js file: http://lesscss.googlecode.com/files/less-1.3.0.min.js

Twitter Bootstrap & Dynamic CSS

BootStrap
This past week I took a look at BootStrap, Twitter's New(ish) RUI Framework.  Overall, I'm fairly satisfied with what I see.  Bootstraps similar enough to other RUI frameworks (like Skeleton, SimpleGrid, etc.) that it's easy to get into if you have prior experience, but offers a bunny-hill of a learning curve even if you haven't.  Being grid-based, it offers the usual flexibility of defining dimensions based on columns (the responsive grid offers 12 columns in a 960-pixel page), or fractions (one-third, one-fourth, etc).  It also offers basic alignment and in-lining class definitions, but nothing really special. 

 Aesthetically, BootStrap's default theme is very clean, with a color pallete of white, soft-greys, and bright blue accents.  This makes it great for quick mockups that still look professional.  Of course, these can all be overridden, and when combined with BootStrap's compliment of well-drawn icons, makes for a nice "grab-n-go" package.

Where BootStrap really comes into it's own is in it's Responsive package.  The elements scale very nicely, down to a certain point before jumping into a mobile-friendly, wikipedia-style format.  I also appreciate how navigation links collapse into a drop-down menu for easy access that doesn't take up a lot of screen space. 

The PM linked our group a nice little tutorial:
http://webdesign.tutsplus.com/series/twitter-bootstrap-101/

With respect to the Kukuicup site, it seems like moving to BootStrap would be fairly straight forward.  (Note I didn't say easy)  I'm thinking that the "widgets" can be migrated into the gird fairly easily.  The only obstacle I can foresee is that the widgets are different heights, and BootStrap probably wants divs to be the same height.  This might cause issues where the left side of a page is one long widget, but the right side has two shorter ones.  This might be overcome by using negative spacing to "stack" the two shorter divs on top of each-other.


LESS (and it's peers, SASS & CoffeScript)
The PM also raised concerns over the high-levels of repetition within the Kukuicup CSS files, and suggested LESS as a solution.  LESS is a Dynamic CSS language that lets you create methods and variables for CSS files.  For example, one could define a variable

@primarycolor: #FFF; 

and reference primarycolor anywhere in the CSS.  Additionally, LESS allows users to apply classes to other classes by adding the .class notation into another class definition.  For example, I define .shadow to have a drop shadow, I can add that shadow effect to a .box class by

.box {
      .shadow
}

Finally, LESS supports paramaterized methods, for example, letting you dump

     //radius defaults to 5px
.rounded-corners (@radius: 5px) {
      border-radius: @radius; 
}

#header {
      .rounded-corners(10px);
}

The downside to all this is that it requires compiling.  In a world where scripting languages run the web, this seems a bit odd. 

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:

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.