The Circle of Life

     Ah the life of a programming project-- whether it's a website, a software program, or an internal computer system, they are all born out of a few hands, and nurtured throughout their life. Some unfortunately don't make it through many years while others go on with the longevity of a Redwoood tree. It seems like just yesterday that I picked up my current project-- the Kukui Cup website, already a young adolescent at this point-- and helped it grow into a mature young adult. I have many proud moments to remember when it made some giant leaps forward, as well as heartbreaking moments when it was rebellious and refused to listen to me. But nonetheless, I am extremely proud of the progress that was made, and I am certain that in the near future, the Kukui Cup will make even more phenomenal advances forward and become something that contributes very positively towards society. As my time with this project comes to a close, I would like to just share a few words about its latest progress and my hopes for its future.

     The latest advancements in my version of the Kukui Cup interface are the Home and Prizes pages. The Home page retains the basic look and feel of the original, with no major changes to the layout. I tried to keep the look very simple yet elegant:

Home:

As for the Prizes page, I kept the same two-column layout that was originally there, but this time, I completely overhauled the HTML code, at least as far as those widgets went.

Notice the nice use of Twitter Bootstrap's fluid rows and spans?
This is in contrast to the "old" way of doing things with tables (yuck!), which was how it originally was:

What's with all those id's, man? Totally unnecessary.. --oh, and extra yuck! There's even "style" attributes in there! I totally blocked them out of my mind upon getting rid of them. Everyone knows that styling should be done with CSS!
Here's the final output of the Prizes page. There's still a lot that could be cleaned up and fixed, but I think it's generally likeable.

Prizes:

     Finally, one thing that I finally got working was the responsiveness (cue the fanfare and fireworks). In the beginning, I was trying to implement Twitter Bootstrap's responsiveness through the supported classes, but to no avail. But one night earlier in this week, I took a final stab at getting those darned things to work, and it did! --hurray for 2:00 AM epiphanies..
Frustratingly enough, the solution is actually very simple:

1. Get the responsive-utilities.less file from the Twitter Bootstrap GitHub repository.
2. Reference it in your HTML page like so: <link rel="stylesheet/less" type="text/css" href="./css/responsive-utilities.less"> (I saved mine in a folder named "css"). *note: it must be done in this format! Otherwise it will not work.

And that's it! Now all you have to do is pick a component that you want to make responsive, and add one of the support classes to it. I wanted the Quest Bar to disappear when it got to a small size and be replaced by a smaller one, so I added the class "hidden-phone" to make it magically disappear:

 ...and likewise I added "visible-phone" to the collapsed version, so that it magically appears when the browser is much smaller.

To see it in action:

Pretty darn cool, if you ask me.

     Certainly this project is far from being complete; there are still design issues to resolve, bugs to weed out, and many more things to figure out. But considering where this site was just a few months ago and where it is now, I know my team and I have made enormous leaps forward and have taken this project to a whole new level. I hope that it can continue to be nurtured and improved, for I know that it is definitely on its way to being something spectacular.

Slow and Steady Progress

     As I had run in to problems last time working with Twitter Bootstrap-- specifically with getting the responsiveness (via the support classes "visible-*" and "hidden-*", with * being one of "phone", "tablet", or "desktop") to work, I am apologetic to announce that I have not found a solution yet. I have posted a question on the Twitter Bootstrap Google Group, but am yet to receive a definitive answer from the authorities. Disappointed, I decided to move on-- leaving responsiveness for a later day-- and focus on cleaning up the site in the meantime, implementing the other components of Twitter Bootstrap such as the fluid grid system and also converting CSS files to LESS. While these two components aren't much trouble, there were several other much more basic things that I had to tidy up before getting to use these tools. These menial tasks included: getting rid of the white backgrounds of icons, getting the LESS files to read properly, and whatnot.

     When using LESS, it is important to remember to import them into the html pages using this format:

<link rel="stylesheet/less" type="text/css" href="styles.less">

I did not realize this, and instead I used the standard CSS base of

<link rel="stylesheet" type="text/css" href="styles.css">

and just changed the href file name. This, apparently is a big no-no, and is easy to forget about.

     Secondly, as I was coding my LESS files, I became rather frustrated with not being able to recognize errors because of the lack of syntax highlighting (my IDE is Eclipse). It is difficult to read code when it is all one color, not to mention a strain on the eyes when yours is fluorescent green against a black background like mines. I decided to try and find a sort of plugin or editor that includes syntax highlighting support for LESS, and stumbled upon this plugin for Eclipse. Unfortunately, as of now I have not been able to get it to work properly, but hopefully this is to be resolved soon.

     So as far as actual progress being made... truthfully it's not much.. yet. But as soon as I get all the preliminary environments set up properly, I can really get to the meat of the issue, which is to fix up all the pages (and hopefully with responsiveness too!). There's lots of work to be done, but thankfully the basic components of Twitter Bootstrap and LESS are extremely easy to use.

Getting feet wet with Twitter Bootstrap and LESS

In the past week, I took a stab at trying out the Twitter Bootstrap that I marveled at last week. I was excited to try out the tons of great features and components that it promised, but I was also prepared to struggle a little due to the fact that I was going to be transform an entire page (not to mention an entire site!). Nevertheless, I was happy to try it out, and as it turns out, I did in fact meet both satisfying success and disappointing difficulties.

First off, as expected, it was extremely easy to implement some of the basic layout components by using the handy classes; I just tacked on a few classes, and like magic, the site transformed itself instantly with no trouble at all. Of course this was just for the basic classes like "container" and "fluid-row", and there are more advanced tools to use, what with the fluid grid system that will take some thought and trial-and-error to perfect, but that will be one of the steps from here on. At least for the simple pages, I don't foresee much more complex implementation being used than just these basic containers. However, responsiveness is a key part to our site, and getting this to work was what gave me some grief this past week. According to the Twitter Bootstrap documentation, adding responsiveness can be as easy as adding classes to the containers that are desired to be made responsive. These classes are: "visible-phone", "visible-tablet", "visible-desktop", "hidden-phone", "hidden-tablet", and "hidden-desktop", which as one can probably guess, makes the container visible or hidden according to the size of the browser. I eagerly added these classes to my page, but to my dismay I saw no change in the responsiveness of the page. Thinking that I must've missed something, I searched around and tried to get it to work, but to no avail. The closest that I got so far was getting "hidden-desktop" to work by importing a "responsive.less" file that I had to obtain through GitHub (it wasn't contained in the zip file available for downloading). So I got a phone feature to hide when the browser was large, but strangely enough, it wouldn't pop up like I thought it would when it got to a smaller size. At this point, I didn't have much time to fiddle with it very much, so as it stands, responsiveness is very limited. Either I must figure out how to get this to work, or I will have to end up implementing it the old-fashioned way-- by hand using media queries, but that would ruin the spirit of using a framework. Sigh.

As for LESS, I was met with less stubborn parts, but as anticipated, it did take some time to get used to coding in the style of a programming language. As a result, I did not get to finish restructuring the theme CSS file to fit the LESS style, but nonetheless I was able to cross several basic components into LESS, such as the use of variables and nesting rules. There is not much that is difficult with this, except for making sure that the changes don't mess up the styles. This means that changes need to be done carefully, especially where we have previously used chained rules (using the comma to specify multiple containers). Therefore, it might be better to take out all unnecessary components and slowly add them in according to each page, because we want to write less CSS. I will probably end up following this approach, and hopefully I will come up with a working, simple, and concise page very soon.

Bootstrapping with Twitter

     So it's been a while since the last post where we were continuing with rapid design development for our site here. Progress has continued with some rather pleasing results from the team, and it seems that we are finally able to take a big leap in development and head toward creating a responsive user interface. While we have considered using frameworks before, we never really got deep into one before and therefore we never found one that would work well for us. But taking a look at the hottest websites out there today, Twitter is definitely among these ranks, and so certainly they must be utilizing carefully crafted pages, scripts, and style sheets in order to keep up with growing trends. As a toolkit from this trending site, the Twitter Bootstrap is a friendly set of files that is designed to help web developers just like us to get started with creating beautiful websites. And it is based off of Twitter, so it is bound to look and feel good.

     Browsing through the Twitter Bootstrap project page, I quickly saw the hundreds (if not more) of features that this toolkit has to offer, and was greatly impressed at how nice everything looked as well. But the thing that really, truly impressed me was how incredibly easy they made it to implement the features that we want. I've used libraries such as JSTL (JSP Standard Tag Library) and YUI (Yahoo User Interface) before, but none of them have had documentation that is as clear as the Twitter Bootstrap one. When implementing external resources, the most important thing (in my opinion) is the usability of it; reading other peoples' code and understanding their intentions is one of the most time consuming parts of web development, so having clear documentation is something that can save an enormous amount of time. The Twitter Bootstrap documentation includes not only visual examples, but also the code that we need in order to use them; all we have to do is copy and paste it into our page, and customize it for our specific needs. They also provide, suggestions, best practices, and additional options, and all of it is concise, so we don't get scared or deterred by long, confusing explanations. Things are looking very promising so far!

     So, following these excellent tutorials, I quickly set up my environment to get ready to begin using Twitter Bootstrap. With the arrival of version 2.0, a fully responsive layout is accommodated, which is just what we need for our project. I played around with the features for a bit, and found that as expected, it was very simple to implement the different features available. Some of the features are slightly complex and as a result require a little more effort into getting them to work nicely, but overall, I am very pleased with it.

     The major issue that I forsee in our project is porting everything over to this new framework. We could just add the features to our existing code base (since it's mostly adding classes and rearranging tags), but it might be quite confusing and messy as we merge the two together. My approach would be to start with a "blank canvas" and add components one at a time, making sure that they are correctly implemented before adding the next. There is a flaw with this approach too, however; namely the fact that many components are not separate; rather they are largely and continuously nested, so it might be difficult or even impossible to add a sizable component to our "blank canvas". I suppose that we will just have to try it out and see if there are any infeasible parts that we come across, and assess the options.

Rapid Design Development

     So after being away from the project for a week, I was ready to jump right back in and help move things along further. While everyone else on the team managed to pump out their own original theme, I-- having missed a week-- unfortunately did not. But at this point, since my peers have made substantial progress, rather than continuing from my current standpoint, I decided to try my hand at jumping on someone else's idea and further enhance it. Taking this approach of depth over breadth turned out to be quite a good idea, as I was able to make just a few small changes and take it further to see what a closer-to-finished product would look like, for additional temperature checks. The result was positive, and this route definitely could be pursued further. Of course, other members of the team can take it from where I left off and enhance that even further, and this process can be repeated forever until a point of satisfaction is reached.

     If we ever get to a point where we can toss this theme file around and have all the team members add in their two cents very rapidly, I think that we'll have a pretty solid system of development here. It's quite exciting to be able to look at someone else's code-- which is a mildly modified version of familiar code--, make a few small changes, send it back, have others change it, and see the results stack onto each other. At this point, it's also easy enough to make rather large changes because of the structure and our familiarity with the structure. We know what to change and how to change them so that we don't spend an unreasonable amount of time figuring out how to do something. For example, I took a preexisting CSS theme file for our site and changed the background picture and the color scheme, so that we have a substantially different theme while keeping the rest of the features such as resizing of the background, the opacity, shadows, and bevels of other components, and many other features that had to be altered. Now it's only the custom, specific changes that need to be made to fit the theme itself. When someone makes a global change, we can share those changes and not waste time individually making those alterations, which I find very, very nice.

     But, what this means now is that I need to take this site to the next level-- in fact, to the next several levels. Because we can work fairly rapidly, that means that we aren't stuck on the same one or two issues for a week any more. So if I don't make major leaps in development and quickly, then I'll be left behind with nothing to do. I guess this weekend will be a good time to get inspired by stunning designs so that I can contribute some major implementations or perhaps start working on the responsive layout, because it seems like we are close to being able to work on the layout portion of this project!

Theme-ify-ing

After last week's design bust, our team decided to go with the idea of creating and applying custom themes that would run across all pages in the site, rather than customizing each page individually. One member in our group already had this sort of thing going on, and it was working rather nicely, but the only problem for me was that the color scheme wasn't quite to my taste. Perhaps I just have a strange taste in design (which I probably do), but I would still like to go with an extremely simple, lightly-colored theme for the site.

Once I got my files set up correctly with all the HTML files pointing to a common theme.css file, I was ready to get down to business and find a color scheme that I really liked. At first, it seemed pretty simple, just picking colors that looked nice to me and applying them to the page. But of course, as I should have known, it's never that easy. What looks nice as a color doesn't necessarily look nice on a page, and once you get to the point of combining colors, things get quite disastrous and you enter this infinite loop of:
                       while (ugly) {
                         pick (color)
                       }
for what seems like forever. Even when using a color scheme generator, it was difficult to get it just right for our site. A little color goes a long way, and even the least-saturated colors seem to be too much.

Although I'm not very satisfied with it, the current theme that I have is what I would call a "tree" theme. As I was playing with greens and browns for that au naturel look, a branch struck me in the face and made me realize, "I should make this page emulate the look of a tree!" We had to get rid of the foliage-rich backgrounds, but who said we couldn't integrate them into the pages' components themselves? Starting from the bottom, the widgets are the brown "tree trunks", and as you work your way to the top, you transition into the green leaves that lighten up as you get towards the "canopy". Some of the widgets are quite tall, so even more so I thought it was appropriate to apply this sort of color scheme. While it doesn't exactly look appealing, the idea is pretty neat (in my opinion), and I would very much like to keep working at this for a little while longer to see if I can get a really clean and nice looking theme. Part of the issues I had were due to structural limitations with the page, so if I want it to look really nice, then I might have to do some major reconstruction across all the pages.

Surely enough, progress is indeed being made, but hopefully this portion will round off soon so that we can get back to the fun stuff: the responsive layout of the pages!

Challenging Design Challenges

     So the results of submitting my design mockups are in!-- and it looks like a bust.. well, not really a bust, but I'm sure it would not have been very successful. And I say "would not have been" because we didn't even get to take a look at my design. As a group, our entire team presented our ideas to our supervisor, as he gave immediate feedback on our choices. One of the first stipulations was, "no dark backgrounds!"-- oh jeez, that's great, my whole theme is based on a dark background! I guess it's time to scratch that idea and go back to square one, or rather, square zero. What seems to be the common issue in all of our implementations is that we don't exactly understand the functionality of the website. Many of us omitted important components that we did not know were necessary, and as a result, no matter how nice we could get the color scheme and layout done, we'd still have to redesign it in the end. And that's one particularly challenging part about web design-- you can't just be a designer. You have to know the ins and outs of each web page and the site as a whole. But, that's also where this rapid feedback system comes in handy. I've seen far too many times where an idea or design gets criticized and ultimately shut down by a supervisor, and I always feel bad when I see the designer-- who put so much effort into it-- get told that it wasn't good enough. Well, now it's my turn to be in those shoes, but the fact that I've only worked on it for several days and not several weeks or even months makes me alright with it, because it prevents me from putting in any extra, unnecessary work into it.

     So what I have done this week was go back to the basics and work carefully: strip out all the styles from the HTML and place them into a separate CSS file, then slowly start customizing it to make it look beautiful, yet still completely functional with all its intended purposes. I've also been thinking a lot about design choices in general, and have been looking for nice examples of color schemes. In fact, one site that I particularly like is actually Google. Looking at GMail, Google Docs, and Google Calendar, they all use a very clean palette-- whites and grays for most of the components, with vibrant but soft colors for buttons. Even Blogger, the site that I'm using and looking at right now has a very simple yet appealing taste to it. The buttons are geometrically nice and the layout is very simple, which makes for a very modern, simple look.

     With all the talk and thinking about design and color choices, I find myself constantly looking at things and analyzing their design choices. Just the other day, I was walking by some modern-looking fashion stores, and found myself staring at it for a long time, not to admire what was inside, but rather its color scheme, use of space, and layout. I suppose it's a good thing to be paying attention to such detail, but at the same time, I feel like I've become some sort of design-analyzing robot! All in all, however, it is really interesting to notice these qualities that most people walk by without even noticing them.

Breakthroughs and Hardships in the Early Stages of Responsive Web Design

After presenting to our boss our product so far (that we were proud of-- me being quite impressed and satisfied myself), we realized (with the help of some constructive criticism) that we need to focus on getting a solid design framework concept down first, rather than just shoot around in the dark and hope that we hit something. So we put down the IDEs for a bit and decided to discuss design possibilities and choices for the time being. Since the website that we are designing for deals with energy conservation but in a highly interactive way, it was strongly recommended that we attempt to achieve a "game" sort of look to it-- that is, an interface that is very inviting and user-friendly.

One fellow group member had a neat idea of pursuing a "Tron" sort of theme, utilizing colors such as electric blue, neon orange, and red. Oh and black, of course. Lots and lots of black. This sounded like a good idea, and a pretty reasonable one too, since the site deals with electricity-- albeit the conservation of it. Everyone seemed to love the idea as well, thinking that it would be simple enough yet nice looking. However, for me who always questions the consensus, I had to think in my head whether or not this was actually an effective design theme or not, because it is quite a stretch from the "game" scheme that was originally suggested. "Would it be friendly for all users, or just for guys?" "Does/can it come across as having that 'game' sort of feel?" These are just some of the questions I have about using this theme, although if it can be achieved, then I have no problems with it. We decided to just bring this idea (along with others) to the table, and see what sort of feedback we get from others.

As for other design ideas, we agreed that having a floating navigation bar (such as the one utilized in this site) would be not only aesthetically pleasing but also functionally effective, although we came up with the idea of having it stick to the bottom of the screen instead of the top. We also came up with a whole bunch of other concepts, such as having navigation buttons that float on the bottom-right and bottom-left side of the screen in tablet size (and possibly mobile size) for those users who prefer to hold their iPads in their hands while using it (giving their thumbs a workout), and we also had the idea of borrowing the layout of Facebook, which has an intriguing design that nearly everyone can recognize and use.

In the past few days, my team and I met and discussed all these ideas (and more) to quite some extent, and it seems like we're making a lot of progress, but I must say that I cannot help but think that perhaps we're not thinking about things in the right way. Design and layout needs to cater to the users-- what they would enjoy and be able to navigate easily-- not what we the developers think is cool or easy to understand. Of course we're going to be able to think that it looks great and understand how it works just fine (after staring at it for months and months), but will the users be just as satisfied when they take their first glance at it and walk through the pages? We never really know for sure. But that is something that definitely needs to be kept in mind throughout the course of this website's construction, so that we can be proud of what we have built, and at the same time the users will be happily utilizing what the site has to offer.

Hands on with Responsive Web Design

After reading 12 Sites to Responsive UI (along with many other references), my team and I decided to take a stab at getting our hands on creating a responsively designed web site. Taking a working page and attempting to modify it with responsive design, we collaborated for many hours and worked individually to hack out whatever we could with hopes of making it all work nicely. As is the case with most things (especially web pages), we ran into several problems and setbacks along the way.

One of the first issues was figuring out how everything worked; the HTML file was about a thousand lines long, with references to CSS and JavaScript files, making it quite an effort to sort through everything and understand what was going on. Many of the styles that were being applied came from CSS files that were not available in the page's directory, but instead were on the server that the site was being hosted on. Thus we realized that we needed to copy those style sheets and save local copies of them so that they can be edited. Finally, with everything that we needed, we could get started with editing. One of the main changes we did was to change the size of many of the components to percentages instead of hard-coded pixel widths, which allowed for fluid resizing according to the browser's width. Feeling a bout of success when this worked, we thought that we were on the right track, and to a certain point, we were. Continuing in this fashion, we made tweaks little by little to get it working, to say the least. Now, I know what you're thinking-- you're thinking, "hey, wait a minute-- changing element sizes from pixels to percentages isn't really responsive web design, that's just resizing things! Responsive web design means shifting things around and changing the layout! You didn't even mention media queries!" And you are absolutely right about all of that. Fortunately for us, the page that we were working on did shift things around when the browser was resized, but still, I don't think we could really call it responsive web design.

Eventually what I realized was that we should have kept most of the page-- that is, the HTML file along with the CSS files-- the way they were, and instead made just one style sheet that could be used to override styles when the browser was resized (using media queries to detect this, of course). This is probably the intent of using media queries, and would have made things a lot simpler, neater, and more consistent, rather than editing the HTML and at least two other style sheets. I created a style sheet just for media queries (following the format of this example page's CSS file, and sure enough, it worked, and made things a whole lot simpler. Now I really felt some success with working out responsive design, and as my team and I discussed and agreed, this is probably the route we should go in order to crank out the final design. Using media queries is quite simple once you get the hang of it, as it is essentially a conditional statement that allows you to apply certain styles under certain conditions.

One of the biggest challenges in undertaking this crash-course experimentation was the tediousness of checking to see if everything was working how it should be. Whenever I work with web design, I always use Mozilla Firefox and one of its extensions called Firebug, which is an incredible tool that lets you look at the page's HTML, tells you what styles are applied to it, and even lets you temporarily change the styles so that you can sample what the page would look like, before you actually edit the files themselves. However, with responsive web pages, you have to be constantly resizing the browser and checking to see how wide the browser is, so that you can apply the correct value in the media queries. I found a neat tool that tells you the dimensions of your browser, but it only works in Google Chrome so far, and so I could not integrate it with Firefox and Firebug, which made it a hassle to switch back and forth and also blindly guess values for the media queries. From what I've learned and experienced, with web design, it's all about the tools. If you have tools such as Firebug that allow you to efficiently and quickly test values out, it will save you a ton of time with styling the page because you won't have to guess or keep fiddling with it.

Overall, everything has been going well so far, if I do say so myself. We as a team have made some major accomplishments in discovering how things work, and what we can do to make it work. And at this point, it's all about making discoveries: learning what works, what's better, what not to do, and so on. I believe that we are ready to graduate from practice, and take on the task of tackling the real project. Bring it on!

12 Sites to Responsive UI Design

It is a new year, and time once again to tackle on a new project. This time, I will be taking on a larger, more long-term project regarding Responsive User Interface Design of a webpage. Now, what is Responsive User Interface Design (or Responsive Web Design), you ask? According to this article, it is "the concept of developing a website design in a manner, that helps the layout to get changed according to the user’s computer screen resolution." Why, you ask? Well, if you think about it, just a few years ago, the only thing that webpages were being viewed on were computer screens, and although screens came in various sizes, even the smallest ones were at least 11 or 12 inches in length (this is before netbooks became popular). But within the past decade, portability has become a major desirability in consumer electronics, and the smartphones and netbooks were born as answers to this distress call. In even more recent history, just two years ago in 2010, the first iPad was launched, bringing another portable electronic product type to the market-- tablets. It's difficult to fathom that the iPad has only been around for two years, given its enormous popularity today, which is shared by countless other tablets out there. Casting a large shadow over its similarly-sized, underpowered, and less portable counterpart the netbook, tablet computers have dominated the market of mid-sized computing devices with its 7- to 10-inch screen size range. Therefore we can say that the three largest markets for computers-- and therefore website viewing-- are desktops/laptops, tablets, and smartphones. Now, these three categories of computers all have extremely different screen sizes, from small (2-4 inches on smartphones) to medium (7-10 inches on tablets) to large (12-27+ inches on desktops/laptops). Viewing the same webpage on different screen sizes is bound to be difficult if they are laid out the same way across all of them. Users would have to do a lot of scrolling and zooming on smartphones and so forth in order to navigate around the page-- and this is what people do have to do on most webpages, because the pages aren't designed with Responsive Web Design. Oh, what a pain!

But that is why my team and I will be exploring and implementing Responsive User Interfaces for our webpages, and hopefully you will begin to do so too! Just look at the examples shown in the article linked to above, and visit those sites and play around with the width of your browser to watch the magic of Responsive Web Design as the layout automatically shifts around nicely. Try them on your tablet or smartphone, if you've got one, and compare it to all the sites that aren't using Responsive Web Design. You'll wish that all sites would use it!

To get started with Responsive Web Design, there are two things that you will need to incorporate with your web site: HTML5 and CSS3. HTML is the language from which the core of all webpage structures are built upon, and HTML5 is the latest version. The following four links are those that I found the most useful in learning about and using HTML5.

The first is an indispensable reference for website building-- the W3Schools site for HTML5. This site has everything from detailed descriptions, tutorials, examples, and even sandboxes for trying out the various components.

http://www.w3schools.com/html5/default.asp

This next link provides a concise and visual explanation to what HTML5 is, and what it's all about. It is very useful as a reference as well as a starting point for beginners of HTML5.

http://www.focus.com/images/view/11905/

Next comes an intro to some of the new features of HTML5, and is a good starting point to learning what things are possible with HTML5. It also has some examples and provides links to other sites, which can be used to learn more about the topic.

http://www.whatcreative.co.uk/blog/tutorials/html5-for-beginners-use-it-now-its-easy/

Finally, a very handy resource with any programming language is a cheat sheet, and HTML5 is no exception. This cheat sheet is one that I find to be concise and sufficient. Paired with the W3Schools resource, using HTML5 is easy, as well as efficient.

http://www.webgranth.com/wp-content/uploads/2011/07/HTML5-Visual-Cheat-Sheet1.pdf

The other essential component for building websites is styling, and the standard way of doing that is with Cascading Style Sheets, or CSS. As with HTML, standards and features of CSS have changed over the years, and the latest standard for CSS is CSS3.

As with HTML5, my main reference of choice for CSS3 is the W3Schools site, providing useful explanations, examples, and opportunities to test-drive features.

http://www.w3schools.com/css3/default.asp

To get started with learning about and using CSS3, the following site provides a couple of simple examples to walk you through some basic features of CSS3. A good place to get a feel for CSS3.

http://www.webmonkey.com/2010/02/get_started_with_css_3/

The next site provides 10 techniques using CSS3. Some of these techniques are a bit advanced, but if you are looking to spruce up your website and really make it look professional, you will probably need to use these features.

http://www.netmagazine.com/features/top-10-css3-techniques

Finally-- as you can probably guess-- is a cheat sheet for CSS3. Now, there are a lot of CSS3 cheat sheets out there, but most of them are lengthy, hard to understand, and basically, I would not be able to use them. However, this cheat sheet is an interesting one (it's actually a "Click Chart") as it provides visual examples (along with the code for it), clear descriptions, and includes only the features of CSS3 that you are likely to (or want to) use.

http://www.impressivewebs.com/css3-click-chart/

With HTML5 and CSS3 covered, the only thing left to learn about is-- well, the Responsive Web Design, of course. The following web sites offer introductions, examples, and tutorials to get you on your way to creating Responsive User Interfaces for your web site.

The first site provides a "beginner's guide" to learning about Responsive Web Design, giving a rather in-depth look inside. The article is lengthy, but gives a very good overview of the subject.

http://thinkvitamin.com/design/beginners-guide-to-responsive-web-design/

The next two sites go hand-in-hand, the former describing three essential components for Responsive Design, and the latter going in detail on one of these components, Media Queries, which is a CSS3 feature. This is what allows the page to figure out what size the browser is, therefore allowing the layout to be set and scaled accordingly.

http://webdesignerwall.com/tutorials/responsive-design-in-3-steps

http://webdesignerwall.com/tutorials/css3-media-queries

The last link is to another article detailing in great depth the concept of Responsive Web Design, how it works, and gives tips on how to design a Responsive site. It also provides MANY example sites and explains the features that make them work nicely. Lengthy, but a very good read.

http://coding.smashingmagazine.com/2011/01/12/guidelines-for-responsive-web-design/

These twelve web sites are sure to give you an overview of not only Responsive Web Design, but also HTML5 and CSS3, which are essential core elements for creating a Responsively Designed web page. Read through these articles and use these references, and you'll be cranking out awesome webpages in no time!