A Work in Progress

The past two weeks have an interesting time.  I've been addressing formatting and styling issues with the responsive web design project.  In particular, I've been focusing on the activities page, and the formatting issues of the "smart grid game".

Earlier, I decided that the table approach was too cumbersome to work with in HTML as the grid was divided into several table bodies, each using a series of table rows (<tr></tr>) and cells (<td></td>) to organize and separate the information in the grid.  Each cell then contained a class particular to each type of activity in the grid.  There are excursions, commitments, activities, events, and specials.  I added another class called "grid-title" to handle the styling issue of having to deal with two seemingly unrelated tags (div id="activity category" and div class="get-started").  This made it easier to specify styles and formatting in the styles.less file and the makahiki-structure.css file.  The site is not currently using the makahiki-structure.less file, which I will explore at a later time, but for now I'm making changes in the appropriate places.

In response to the cumbersome table, I re-created the entire "smart grid" game area from scratch, using a series of nested spans to create the grid as a series of columns.  This would allow all the categories to remain in position and new grid elements could then be added to the bottom of each respective column without ruining the format of the grid.  The HTML for the row-fluid and span version of the "smart grid" was much easier to look at and edit.  Unfortunately, I realized that neither grid really looked that good when actually viewing the site.  The main reason is that each grid element had different heights, which caused the grid to fall out of alignment.  This was the case for both the table and the row/span versions.  Interestingly enough, I realized that the table version was formatted similarly to my approach as only the table header elements shared a particular row.  Each column under the header was contained in a single table data tag, or cell, which then contained a series of rows of single cells.  Given this structure, it is no wonder the grid does not stay aligned well with cells of different sizes, and why the HTML is so difficult to follow.

I did solve the main problem by setting a "min-height" for each grid element to be 55px.  This gave the elements a unified structure and everything seemed to work well enough in response.  Below are some images of the results:

Before:

 After:

 This is still a work in progress, however, as I have to continue to work on the style and structural formatting for each version.  In the images above, the images on the top are the row/span version and the images below are the table version.  The table version continues to have inconsistencies in size, which I have been trying to find.  It is unclear as to why certain elements are more narrow than others.  I've even tried to set min-width values, but that didn't seem to fix it.  I'm still working on a way to remove the extra space between the three major spans of the row/span version.  I feel the solution is to add the spacing to the each element and not the span.  I will be making that change later today.

I have also been removing the style tags for the text within the "smart grid" elements, as they were utilizing the header 5 tags (<h5></h5>) and header 3 tags (<h3></h3>) which should be reserved for page elements unrelated to the grid.  That way, if the header styling changes for the page, it will not affect the grid elements.  I did change the color of the text in the grid to the @black variable in the sky-theme.less file, but it has not yet applied when viewing the site.  I've been searching the other LESS and CSS files to find out where this is being overwritten.

Thus, while I feel that I have learned a great deal about table formatting and alternative approaches, I still have a lot of work to do before our team meets again.  Even though I have spent a great deal of time working on these issues, some of the problems still elude me and I would like to have a clean looking version to demonstrate at the meeting.  I will be continuing to work on these issues in the meantime.

Gearing Up With Twitter's Bootstrap 2.0

Our project has finally come full-circle.  We initially started by trying to take the Kukui Cup site and revamp it with a responsive user interface, or RUI.  Our team started out well with some "basic" responsiveness added to the site.  We quickly realized that our site did not respond all that well aesthetically speaking, so we diverted from responsive design to focus on the style of the site.  After finding some pleasing styles which were above threshold, we decided to refactor our CSS files to improve readability and ease of modification.  Now, we have finally come back to the beginning with a new approach to making the site responsive.

This time, we plan to do things in an easier and structured way, which is to use a framework for the HTML and CSS files, using Twitter's Bootstrap.  First of all, Bootstrap has a couple tutorials which can allow anyone with little-to-no experience in HTML or CSS to jump right in and get started.  The first two tutorials deal with Bootstrap 1.4, but the third one introduces Bootstrap 2.0 and all of the RUI elements it contains.  After completing all three tutorials, I have gained a good understanding of using Bootstrap.  Secondly, Bootstrap has pages and sections for everything that you will need to customize and incorporate any responsive elements from overall layout, typography, components such as buttons and navigation, and even an extensive list of usable Javascript plugins to name just a few.  Each area has descriptions of what the element does, how to use it, and even sample code that you can copy and paste into your own custom CSS files.  In fact, you can utilize anything from their site as they use the liberal Apache 2.0 License, which only requires that you credit Twitter Bootstrap for the content that you decide to use.  Lastly, you can even create a custom CSS file with all of the components which you think you might need in your site.  You simply check off the components and JQuery plugins which you want to add, customize all your variables for each element, and then click the download button to get a fully robust yet streamlined CSS file.  With all of these features, Twitter's Bootstrap makes our next task simple and straightforward.

Bootstrap is built with LESS, which is a CSS preprocessor, and allows you to easily customize and extend Bootstrap's existing framework.  One thing LESS makes easier is the ability to utilize variables when coding, which any coder can tell you is a near necessity!  Variables allow you to change values across your style-sheet by changing only one line of code.  Another thing LESS allows you to do is to use "Mixins" which allow you to imbed one class into other classes, giving them all of that class's properties.  You can even pass the imbedded class parameters, which is even cooler!  Yet another feature of LESS is the ability to nest selectors, eliminating the need to construct long selector names to specify inheritance.  Furthermore, you can use LESS to do operations on colors and property values, which lets you set up relationships between the various elements in your site.  The LESS site has all of this information and more, including examples of code and how it looks after it has been compiled into CSS.  This will make our project much easier to customize, enabling us to easily build upon the Bootstrap framework and easily adjust style-sheet elements across the site.

In conclusion, now that we are about to dive back into the responsive design aspect of the project, it is really exciting and encouraging to have the prospect of using the tools and flexibility of Bootstrap and LESS.  The site's style-sheets and HTML should become more easily wielded and manipulated.  And the best thing is that Bootstrap 2.0 can be utilized to incorporate an already fully responsive user interface!

Adjusting my Design Approach

This week, while continuing work on the makahiki-rui project, I had an epiphany.  Rather than trying to "create" a decent color palette from scratch, I decided to try another approach.  When creating a palette from scratch, you have to think creatively about how different colors work together, contrast, juxtaposition, etc.  I haven't studied color theory in well over 10 years, so I did not want to go that route.  Instead, I was thinking about how awesome nature looks and the colors out there seem to complement each other very well.  So, if nature's color palette is so darn perfect, why should I try to redesign the wheel?

That's when I decided to pick a series of different Hawai'i and beach related images to work with.  Although the images I found did not have explicit copyright information, they're not all that great.  I plan to take a trip out to the beach to get some pictures with a better camera.  For now, I decided to go with an ocean cliff theme.  Something that would represent the goal of sustainable energy and friendliness to our environment, which the Kukui Cup represents.  I really liked the colors represented in the ocean.  There are lots of blues and greens, which all work well together.  Beaches are particularly interesting, as they have some nice muted browns and yellows to add to the blue sky and ocean.  I will be doing some beach themes next, but for now I decided to stick with an image of the ocean next to a cliff.  This was the base from which I implemented my test of extracting a color palette from a nature scene.

The first step towards integrating a color scheme from nature is to figure out which colors you feel represent the image.  I used a color-picker tool to sample different colors from various parts of the image.  Oddly enough, many of the colors in an image are darker than I would expect them to be.  This prompted me to be deliberate about light versus dark colors, and to get a good sampling of both.  You want some colors to be darker, so that you can use them as shadows for page objects, text, borders, or as part of a gradient effect.  You also want lighter colors to use a backgrounds for your text, and to lighten the page so that people do not feel as though they're in a dark closet when they look at your site.  Once you find colors that you like, most graphics editors have the option to add those colors to a palette, for use later in editing.  From there, you can see the RGB values of each color.  RGB stands for Red, Green, and Blue.  Those are the colors of light which your computer screen uses to mix together for each pixel to produce all the colors you see on the screen.

Now, I realize that you can use RGB values when editing colors in CSS files.  But I am a coder at heart, and I randomly felt like writing a short java app to translate a string of integer values, separated by commas, into a hexadecimal representation.

That can be found here: https://gist.github.com/1900814

After getting the color scheme figured out, I made some changes to the navigation bar, and the header area to homogenize the look and feel.  I borrowed some style inspiration from Gregory Burgess with regards to the header area.

Here's a link to what he did: http://code.google.com/p/kukuicup-rui/source/browse/trunk/CSS-Refactor/theme-2.png

All-in-all, this was a good test.  I learned how to take a better approach to color palette creation and I have some inspiration with which I can move forward to create new themes.

Issues With Design

This last week has been filled with frustration and disappointment regarding a redesign for our makahiki-rui project.  Our team was running into issues working with the current design structure of the site, which we felt was a little cumbersome for responsive design.  We then spent a good amount of time trying to come up with some image mockups for design ideas.  Suffice it to say, I have not used an image program in over 10 years.  I spent hours trying to relearn vector based images and just trying to make rectangles with curved corners proved to be an annoying task.  It sort of turned out decently anyhow, as all my design ideas and "wants" were summarily shot-down by the project leader.  At least I was spared the shame of having to present my shoddy design, since some of the other designs were really terrific.

I'll have to spend some more time in the future to relearn basic design elements and theory.  It is going to be a significant issue when it comes to making user interfaces for just about anything else that I plan to make in the future.  It is definitely a stretch, to put on an artist hat after only wearing a coder hat for the last few years.

Since I decided to leave the design aspects up to those in our team more qualified, I thought about approaching a different problem.  It was suggested that we keep most of the basic structure from the old site, but spruce it up by doing color changes to the CSS files.  The caveat being that we have specific style sheets across the site and so we wanted to have convergence with regards to the colors at least.  Thus, I created a new theme.css file and moved over all the relevant color settings.  I found most of the color settings were found in the screen.css file, which we could just as easily manipulate, but we want to have color schemes in a separate file for now.  If all goes well, we might be able to offer different color scheme which users can choose from whilst accessing our site in the future.

Designing with Design in Mind

It has been three weeks of development so far on responsive web design, and it seems like progress on our group site is currently on hold.  Oh sure, we've been able to implement responsive elements such as fluid grids and media specific style-sheets using media queries, but our site does not really look all that great right now.  Instead of wasting time adding all sorts of responsive web elements, only to have the overall design remain a lasting issue, it seems prudent to take a step back and look at the big picture.  As web design incorporates many "cool" technologies and features, it primarily hinges on having a good overall design.  The design aspect of the site is what keeps the feeling of cohesion and purpose.  Without a good design, or a good design plan, changing elements individually or even rearranging existing elements will not bring a site closer to a cohesive and appealing appearance.

In that light, our team has been focusing on brainstorming ideas for overall site designs and styles that would lend themselves easily to a responsive format.  We want a design that doesn't "jump around" or look tacky when transitioning between viewing sizes, but which also looks engaging and purposeful.  We also wanted to bring more of a relevant theme to the energy aspect of the makahiki framework.  This is supposed to be a site that is related to power and energy, and something that is fun and engaging.  So when you think of energy, there are two ways to go stylistically.  We can either go towards the conservation aspect and have a very organic feel with lots of trees and foliage, or we can lean towards a more industrial/technical design, which is what we did.  We decided that having a "Tron" feel might be the better design on two fronts.  It is a very simplistic design, which incorporates a combination of black backgrounds with "lit-up" color panels and lines which give us the feeling that there is energy coursing through the site.  Right now it is still in brainstorming mode, but such a design would be much easier to adapt to a grid layout than something that has a more organic feel.

Our group is still in discussion phase on how it will ultimately be implemented, but I would like the site to also have a game user interface "feel" to the navigation elements.  In this, I'd like to see page links and links to widget pop-ups all collected into a control/navigation bar at the bottom of each page.  We all agreed that this navigation bar should be "stuck" to the bottom so that as someone scrolls down a page it will remain in the same place on the screen so that users can always access it.  We also looked at having a "menu button" for mobile devices which would cause a navigation menu to pop up on screen and allow you to jump to different sections of the site.  This menu would therefore be "hidden" from view until called by the menu button, so that we don't lose valuable screen real estate on mobile phone devices.

We've made a lot of progress conceptually, but we haven't started implementation of these ideas just yet.  Right now, we still need to flesh-out the ideas a bit more and have an overall consensus in the group before we move forward.  Site design is a really interesting and fun process, and I'm excited to see these designs take shape!

First Crack at Responsive Web Design

I currently have a mix of elation and frustration.  I recently joined a team of developers to redesign pages of a website with responsive web design.  First things first, we set up our project site here at Google Project Hosting.  Before you go and checkout the repository, you should know that we haven't officially started the project yet.  All we have uploaded to the repository is a test page and corresponding files needed to render it locally.  Once we get things finalized conceptually, we'll be removing that repository and replacing it with the entire site.

Okay, so after we got our test page uploaded we got to work on changing the design from a standard 960px resolution to one that would be responsive not only to resizing of the browser, but also to specific size of mobile media devices.  Initially, we were at a bit of a loss in deciphering all the HTML and CSS code.  Mainly, we had to read through and understand how the divs, or HTML body divisions, were set up.  In addition, we were looking through the CSS files to see how the page styles were organized.  This took a little while, but then we started to gain an understanding of the elements on the page and how they were controlled via the CSS files.  The Firebug add-on for Mozilla Firefox was extremely useful and made the whole process proceed quickly and with ease.

Initially, we started by looking at tips for fluid grid design.  One of the underlying techniques is to change widths of containers and elements from pixels to percentages.  This had pretty amazing effects, as it allowed objects to "float" around the page and reorganize themselves to fit within the browser after its size was reduced.  Unfortunately, the results were not perfect.  For instance the navigation bar stayed at the same height and overlapped with other elements.  That's when we decided to remove specific object heights.  Instead, we decided to provide the needed spacing between objects on the page by adding margins to the top and/or bottom as needed.

After making these changes, the site behaved better, but it was still not very attractive at certain browser sizes.  That's when we decided to do specific media queries which would load separate style-sheets based on browser size.  We decided not to query for specific media types, although that is another valid option.  At the moment, we've decided against querying specific mobile devices because we wanted the page to also adapt when people want to re-size their browser to look at other things.

We started by adding one other CSS file to override the current style-sheet when it detected a browser size that is approximate to that of a mobile phone.  We quickly learned that it was easy to implement media queries, as you simply need to create specific style-sheets for each device's approximate browsing width.  After that, you simply link to those style-sheets in your HTML file.  You can either do the media query in the HTML file, and load a corresponding CSS file, or you can link to a CSS file that has media queries as internal elements and corresponding style coding for each element.  At the time of writing this blog, I have recently discovered that one of my team members had uploaded a media-query CSS file that had attributes for several of these approximate browsing widths.

While a media-querying CSS file is sufficient to make small changes to page elements based on detected browser sizes, I believe we still need to implement separate style-sheets for each mobile device approximation.  The reason I feel this way goes back to basic coding practices.  Just as we do not want to have one method that contains hundreds or thousands of lines of "spaghetti code", it is much easier to maintain separate files of shorter length.  That way, when maintaining or adjusting styles for specific devices we can simply go to the corresponding file, rather than having to browse many lines of code to get to a particular media query's style overrides.  Furthermore, we may want to have completely different interface designs based on the size of the browser, and separate style-sheets would facilitate that better.

Overall, the project started out very well, and we are poised to move on to the next portion of the project, which would be to modify the entire site and not just one page.

At this point you may be wondering where my frustrations manifested.  Well, certain elements of the page seemed to disappear, mainly some of the small navigation bar images.  Also, I ran into a few problems with getting subversion mime-types to work from our project site.  My goal was to be able to see the HTML page render itself straight from the repository, but it doesn't.  While you can easily browse the HTML code, the page doesn't render properly when to you try to view it.  There are still some issues to work out, but we've made a lot of great progress.  I'm looking forward to our next step in the project!

Responsive Web Design is the Future

When we think about how trends in technology have changed over the last few years, we usually think about mobile devices and mobile app development.  More and more, we see people using Androids, iPhone, tablets, etc.  Everyone knows that you can browse the web conveniently on any of these devices, so what does that mean for web based application development?  It means that the future of application development is in web-based applications.  Where iOS and Android developers that develop mobile apps for each device have to write code that is native to those operating systems, web-based application developers can make one product that can be used on every device!  This means you can create an application that is usable on your desktop, laptop, or any device that can browse the web.

The trick to all of this is in creating responsive websites that cleanly adjust depending on the size of the browser.  So when you look at the page on a desktop computer with a massive monitor, you'll perhaps see the most expanded content with multiple columns of text, images, or large movie objects.  The same site viewed on a mobile device would see fewer, narrower columns, and smaller versions of the same movies or images.  This is made possible by using HTML5, CSS3, and responsive designs.

HTML5 is the latest version of HTML, which is the language used to structure and present content on the web.  It marks the end of an era as HTML5 allows for the use of complex media elements without the need for additional plugins like Adobe's Flash or perhaps Microsoft's Silverlight.  Most new mobile devices are compatible with HTML5, which is great news because HTML5 contains markup for application programming interfaces (or APIs).  This makes it easier to develop web-based applications as you no longer need to deal with stand-alone APIs.

CSS3 is the third level of Cascading Style Sheet languages and allows for the formatting and presentation of information in HTML.  It allows for cross-browser compatibility as well as new features like animations and transitions.  As the web evolves quickly, it became apparent that large CSS specifications were unwieldy and so CSS3 is divided into modules that can be changed and updated independently of each other.  You can also do media queries which allows you to detect what kind of device is being used and allow you to adjust the style to work with those constraints in mind.

With clever use of the above technologies, and designing with responsiveness in mind, you can have cross-platform and cross-browser applications that can be used by anyone!  That means you have access to the largest market-share possible, which also means more people will be using your product and hopefully making you more money.

Below are some links that I've found while doing research on this topic, may they be of great use to everyone who is interested.

HTML5:
http://www.w3schools.com/html5/html5_intro.asp
http://www.smashingmagazine.com/2009/07/06/html-5-cheat-sheet-pdf/
http://www.alistapart.com/articles/previewofhtml5/
http://www.thehtml5tutorials.com/

CSS3:
http://www.w3schools.com/cssref/default.asp
http://www.designyourway.net/blog/resources/top-100-useful-and-detailed-css3-tutorials-and-techniques/
http://blog.templatemonster.com/2011/04/08/20-css3-tutorials/
http://css3generator.com/

Responsive Web Design:
http://www.alldesignstuffs.com/2011/creating-responsive-html5-page-using-media-queries/
http://thinkvitamin.com/design/beginners-guide-to-responsive-web-design/
http://www.elated.com/articles/responsive-web-design-demystified/
http://www.catswhocode.com/blog/awesome-tutorials-to-master-responsive-web-design