2012-05-05
I’ve been reworking my responsive design project, Resizive, which now has an official home at Resizive.com! It’s all grown up!
The bigger changes:
- New domain, but same great looks and help!
- Reorganized and refactored a lot of the code, getting rid of some duplicate functionality and making it conform better to the DRY principle. I also tied it into a nice JavaScript closure with only one exposed
init() function.
- Now on Github as well: Resizive Repo. Technically it was already GitHub, but I hadn’t mentioned it. The about/help page also has a typical ‘fork me’ banner announcing it as well.
- Rewrote the about/help page so the content didn’t look like I wrote it in 3 minutes, which I did the first time.
I hope you continue to use and enjoy it!
2012-04-02
Introducing Resizive: a tool to help build responsively designed fluid websites.
Responsive Web Design Is Content First
Responsive web design is all the Next Big Thing in web design & development these days, as it should be. Using media queries to determine the width of the viewport, we can better serve content optimized for browsers and screens that aren’t the traditional desktop. Many developers, however, have taken to establishing their breakpoints – the width measurements that they target their media queries at – to common smartphone and tablet widths. This simply won’t last. Device fragmentation, especially it he world of mobile that is not iPad or iPhone based, simply doesn’t have common widths of screen sizes. There are hundreds; perhaps even thousands. So, what’s a poor developer to do when trying to figure out where to create breakpoints? The answer is simple, although by no means easy: base those breakpoints on the content.
I’m hardly alone in this thinking; I came to this realization by reading the words of many others, far better at this than I. Here’s what they have to say:
Disruption will only accelerate. The quantity and diversity of connected devices—many of which we haven’t imagined yet—will explode, as will the quantity and diversity of the people around the world who use them. Our existing standards, workflows, and infrastructure won’t hold up.
Future Friend.ly
I think a lot of people misunderstood what problems responsive design was claiming to solve. It was never specifically about mobile devices or users in a mobile context; it was always about adapting layout to varying viewport sizes.
Jeremy Keith
Mobile first = user first = content first. This is the way all our Web sites should be made… Start with the content. Go through the exercise of understanding what content & tasks your site needs before making any templates or designs… Use mobile screen size & limited bandwidth to focus on what is essential in your site. Then build up from there.
Luke Wroblewski’s notes on a talk by Jeffrey Zeldman during the An Event Apart (2011, DC)
Content First Is Progressive Enhancement
All of these ideas are part of a larger, more fundamental movement as well: progressive enhancement. It’s about making the basic raison d’être of a website it’s primary focus. For most web documents (as opposed to web apps), that focus is content. It’s what a user came to your site for: something to read, something to learn, something to enjoy. Users don’t visit to a website because of the navigation animations; they don’t visit to a website because of the clever Easter eggs on the 404 page; they don’t visit a website to see how solid our code is (although it would be awesome if they did). Users visit a website because they want to consume its content.
That means the first thing we worry about is making sure that content is accessible, to as many people as we can, on any device we can, on any internet connection we can. The One Web deserves no less. That doesn’t mean we need to ignore all of the other things we can do with a website, however. We just need to do them smarter than we have before. Add them on with media queries, with JavaScript, with feature detection and all sorts of other goodies. The point is to start at a baseline – accessible content – and add things on to users who’s device and browser can support them. Just make sure you don’t confuse this with graceful degradation, where the best experienced is assumed and then features are removed for less capable devices/browsers.
How Resizive Helps
Since breakpoints need to be done based on the content, and not on a guess of what device a user is reaching the website from, how are breakpoints for media queries determined? The answer for this developer during my first responsive web design (this website) was trial and error, and I don’t think I did as good a job as I could have. In fact, I plan on doing quite a bit of minor touch-up work on the site sometime in the near future.
I started by using rough guidelines based on some of the more popular device breakpoints because I had no better idea where to start. One key difference is that I didn’t limit myself to those breakpoints. As I was working, I kept constantly resizing my browser window from very very narrow all the way to fullscreen (on a 23″ monitor at 1920px wide), over and over, looking for places where some layout broke or just didn’t look well. And I would then figure out what width my browser window was at and make a breakpoint for an even-numbered pixel amount very near that area. And then test more, and test again, and again…
It was time consuming, and to be honest a bit frustrating. There had to be a better way. And while by no means do I think I’ve found a perfect solution, I think I have found one that’s at least better with Resizive.
Resizive allows you to enter a URL (even one based on localhost!) and starts animating the width of the body element, starting at the width of your current browser window and narrowing downwards to a smartphone-sized width, and then reverses and works its way back towards full browser width again. You can pause and resume the animation, enter a manual number, and (while paused) do slight width changes to find the perfect breakpoints. It shows your real website adapting to different widths as you watch, taking all of your media queries into account.
I did limited cross-browser testing, and while some of the features are less polished, and some browsers’ animations are far less fluid, I had it working in IE9 and the latest versions of Firefox, Opera, Chrome, and Safari (on Windows). I’m going to be adding the code to GitHub soon, in case others wish to modify things or make improvements. I plan on doing my next Responsive Design with Resizive, and I hope it will help you as well.
2012-03-26
A couple of months ago I made a simple card matching game I gave the joking name of Remember The Ginger. In the post describing it, I mentioned a few things I wanted it to do better. I’ve now done many of those, and you can now play the second version of the game.
Deck of Cards
I’m not sure why I didn’t do it this way the first time, but now it no longer uses classes to match cards, but instead creates each card as an instance of a Card JavaScript object, and keeps track of details as properties on those objects. I can simply compare the face and suit of each card against each other to see if they match, and it eliminates some causal cheating possiblities. Not to mention it’s simply much better code.
I got rid of all images; it’s now fully CSS3 based. This does cause browser support issues, however. The game is still functional in all of the browsers that I tested, but it is really ugly in older IE browsers, and the only way to support all enhancements is with a webkit browser. It has CSS3 gradients for the background of the front of the card as well as a more complex CSS Pattern for the back of the card. I used both Lea Verou’s CSS3 Patterns (modified from the Blueprint Grid) and ColorZilla’s Ultimate CSS3 Gradient Generator to help make these. It has some card flipping animations based off the concept at CSS# Playground. The faces and suits of the cards are now simply denoted by text:
Faces
- Ace: A
- King K
- Queen: Q
- Jack: J
Suits
- Hearts: ♥
- Diamonds: ♦
- Clubs: ♣
- Spades: ♠
I got rid of the table strucutre and just used floating divs. In the start, I built a ‘deck’ of cards by rotating them and staggering them to the left incrementally and then slightly downward to give them the appearance of spread out cards. I could never get that 100% looking the way I wanted it to, but I am decently happy with the result.
Same as last time, you can download the source files and do whatever you’d like with them. Enjoy!
2012-03-23
I’m really bad about letting my website content lapse. So much so that I hadn’t even put a whole lot of time into the design of the website; the last design was a theme I found on in the WordPress listings and installed with only a handful of modifications.
That’s done with. I developed my own theme based on a starting package from Amber Weinberg’s ‘Super Hijinksified’: a barebones WordPress template with the HTML5 Boilerplate rolled into it.
Despite starting with her setup, I’ve edited it fairly heavily. I added a couple of functions to modify how the standard scripts were being used, registering and enquing most of them through WordPress’ wp_deregister_script(), wp_register_script(), and wp_enqueue_script() functions. The theme is something I designed myself in Photoshop, and I picked two fonts from Typekit: Hayate by Typodermic and Museo Sans by exljbris Font Foundry. Keep in mind that I’ve never claimed to be a designer or interested overly much in typography, so I’m sure opinions of both of those aspects will vary. I’ve always been much more interested in the coding parts of web development.
The website is my first attempt at Responsive Web Design, and I tried to go all in. The vast majority of it is set up with percentages and ems for measurement units instead of a fixed-width pixel site like the majority of my experience has been with. It was definately a learning experience, but I had fun with most of it. By far the two hardest parts have been using ems and keeping track of exactly what 1em is at any given element’s scope, and checking to make sure that most things are readable at nearly every level of resolution and size. On the last point I still believe I have a good bit left to go as far as polish.
I chose not to limit myself to what I’ve seen listed as the standard breakpoints. I placed a few in there because they were approximately the size I wanted to change layouts of anways, but otherwise simply resized my screen and entered breakpoints at places where things seemed to not flow just right. As such I currently have breakpoints at: 480px, 720px, 860px, 960px, 1050px, and 1350px. I may introduce more or remove as few as I continute to do minor changes to fix layout quirks and to keep adding more polish to the site.
I’ve went with a ‘Mobile First’ approach as I’ve seen described by many of the developers involved with Future Friendly. As such the site gets it’s basic layout styles first for small resolution devices or those that do not understand media queries, and then I layer upward from that. This limits IE8 and under to more basic site, but they get all of the content in a usuable, easy to read fashion, so I’m not overly concerned about that on my personal blog. On a more serious website I’d look into either respond.js to polyfill media queries for older versions of IE, or I’d include a separate stylesheet for IE with conditional comments. I didn’t bother to polyfill many of the CSS3 presentational concepts, because the performance hit isn’t worth the extra partial transparency and drop shadows and other similar effects in my mind. If they aren’t understood by the brower, they’re ignored (or in the case of the transparency they use a full background color previously defined). I’m not sure how well I’ve done, but I’m a fan of the Progressive Enhancement line of thought and the whole Future Friendly ideology.
One thing I need to keep improving on is website performance. WordPress is very good considereing how often it makes calls to the database, but I still have a wide array of areas to better optimize. I played with a plugin to help cache files, minify and gzip documents, etc. However, I ran into a few issues with it in regards to styles not showing, JavaScript errors occuring (especially with google analytics / adsense code). I still intent to go down this route, but I’ll need to research it more before blindly throwing a plugin into the mix. I have a suspicion it’s do to the way I coded the JavaScript enqueing I mentioned earlier.
2012-03-09
Endings
Earlier this year I decided to quit my job that I’d been at for the previous four years. I was tired of coming home miserable, often to the point where it was affecting how I’d play with my sons or interact with my wife. At some point I finally had to tell myself that enough was enough; I talked it over with my wife, and quit, with no backup plan in site.
It was scary as hell, because I was the sole provider for my wife and kids, as my wife was trying to finish her college courses and was the primary caretaker of the kids. We didn’t want that to change – she enjoyed being able to go to college and having more time with the kids at home and I enjoyed getting out of the house.
So, after I quit my job, I took a few days to spend with the family. A very small sort of rejuvenation session, if you will. And then I hit the job hunt, and I hit it hard. I decided that living in Kentucky wasn’t productive for a prosperous web development career, so I decided to look into relocation opportunities. I applied for a few jobs at all sorts of areas, but my eyes kept coming back to California, and more specifically the Silicon Valley / San Francisco / Bay Area.
Changes
And then I got a small glimmer of hope – one of the jobs I applied for went through a recruiting company that did all of the middle-man work for the employer, pre-screening candidates and doing all of the negotiations on behalf of either side. I spoke with the recruiting agent, Andrea, and she was an absolute pleasure to work with. Andrea called and emailed multiple times along the process, before and after interviews, and made sure everything just worked, both for me and for the company she was acting as an intermediary for, named Buzz All Stars.
I was being considered for a JavaScript Developer job, which is something I’ve really wanting to get into for a while. I was asked to take a test online to show proficiency in OOP for JavaScript through Odesk. I took the test and got a 2.80 out of 5, for a 56%. I was horrified! And then I noticed something else: even with that low score, I ranked in the top 16% of over 2200 test takers. I got later confirmation when I found out the senior JS developer for Buzz only did marginally better than I did.
After the test, I did some more follow up work with Andrea, answering questions and such. And then I finally got interviewed over Skype. And I impressed them and within minutes after the end of the interview, they were negotiating with Andre (on my behalf) and I was offered the job. I accepted and immediately starting making plans – because I had to pack up my stuff and move across the country.
My wife and I had already talked this part over, and we’d decided that for now I was going to move by myself. She was in the middle of a college semester and didn’t want to have to owe money for student loans for no reason, and we also had made plans to allow her mother to move along with us; as her mother was in the school system as well, them waiting till the semester ends around May just made sense.
Let me say upfront, moving away from my wife and kids is the single hardest thing I’ve ever had to do. Rationalizations didn’t matter, it felt like I was abandoning them, and was very emotional for the both of us. But despite the fears and sadness, there was extreme happiness as well. Why wouldn’t there be? I was moving a world away to where developers could have a future (which wasn’t true in Kentucky, at least my area of it), to Palo Alto, California!
Lots of errands had to be done. Packing, getting a new bank that existing in both California and Kentucky, finding a temporary place to live, and all of the other fun stuff that comes with moving. I drove nearly forty hours over three days through the states of Kentucky, Tennessee, Arkansas, Oklahoma, Texas, Arizona, New Mexico, and California. I think I spent something like $450 in gas for the roughly 2,400 mile trip. And then I arrived in Mountain View, where I had decided to move to.
Welcome to California
Beginnings
I got to Mountain View six days before my job officially started. I wanted a few days to learn the layout of the area, to be able to explore a bit. I drove down to the office and met with the CEO and CTO. And finally, my job started.
It was a blast. We were working on a social game (initially for Facebook) that was sports-based. I was learning new things – for starters, back in Kentucky everything was sadly Windows based, and I was learning OS X for the first time with any amount of seriousness. It wasn’t bad, as I’ve used both command line and graphical versions of Linux, and I enjoyed it. Definitely much better for lots of development tasks! I always was using Eclipse (an IDE) with CVS for version control, both which were also new to me. But it was productive and enjoyable. Two weeks passed by quickly.
And then it was over.
I didn’t make it past my promotion. It wasn’t as if I weren’t doing my job, or had any issues. Buzz was simply trying to launch their game at the same time as I was hired, and I didn’t make a strong enough initial impression. They weren’t fully confident that in the future I could maintain the pace they wanted. As far as possible, the company was extremely nice and professional about it. It was the first time I’d ever been let go from a job. I didn’t take it very well, and was fairly depressed for a day or two. But as upset as I was, it was at myself and not at Buzz. I’d let them down, not the other way around.
After a few days of recovering, I talked it over with my wife and figured out what we were going to do. I’m staying in California and finding another job, and I’m pushing myself. I’ve been redesigning my website. Working on my projects. Updating and polishing and tweaking my resume. Reading online tutorials. Applying for jobs. Most importantly, I’m not giving up.
As a line quoted from the Wheel of Time says:
[It] was not the beginning. There are neither beginnings or endings to the turning of the Wheel of Time. But it was a beginning.
So let me finish with this. Hi, California. I’m Bradley Staples. Nice to meet you. I’m here to stay.
2012-01-31
I made a fairly simple card game based off the old childhood game of Memory (also known as Match, Concentration, and others) called Remember The Ginger. Click two cards in a row – if they match, they stay face up. If not, they flip back over. The object of the game is to flip all the cards up as quickly as possible with as flew flips as possible.
It’s a simple premise, and wasn’t that hard to set up the code. A few things I thought about as I coded it:
- I wondered if there was an easy way to prevent casual cheating. It doesn’t truly matter if someone cheats as there’s no community scoreboard; the only real scoring are some statistics shown at the completion of each game. I was just curious what if there was an easy fix for a full client side game (and I understand that any JavaScript developer could easily pierce that as well). Right now the game simply compares a series of class names, and matching classes correspond to matching cards. I considered using jQuery’s
data() method, but then I would have had no classes to use as a identifier for the sprite-based faces for all of the cards, and I didn’t really want to have 16 different images loaded as a data-URI or assigned directly via JavaScript, so I just left the matching using classes.
- I considered reducing a lot of the bandwidth by not using a sprite image for the card faces. I thought about using
:before and :after pseudo elements with each td element. The td could contain CSS3 for a border-radius, vertical gradient, and border to make the card stock. The :before element could hold the text, styled up with a web font and a text-shadow. And lastly, the :after element could hold either a font based icon or the literal characters for ♥, ♦, ♣, and ♠. I decided against it for no better reason that I had already made the .PSD for the sprite. It was a lazy decision, but gives me something to come back to on this project later on.
- The table cells are large enough that the game area is too big for my tastes. But making the cards smaller seemed to make it harder to remember which cards were where, according to the few friends I had play the game as a test. I think this might be solved bg going with the CSS based version above.
Feel free to take the source files and play with them. Or demolish them. Or make a properly awesome game with them. No attrition/link/copyright nonsense required, although an email/tweet showing me what you did would be cool – and completely optional. Cards.zip is ~129K and has all of the images, CSS, and JavaScript needed to fiddle with them.
As a side note, I had planned on learning how to use GitHub as my first month’s goal for the 12-4-12 site, but failed to do so. I’ve never used version control before, as sad as that is. The more I’ve been researching online, the more I realisze that my current job is further and further behind on commonplace industry standards. I don’t say this in a negative way; I merely mean it to mean I have to make myself learn these techniques on my own (limited) time, as they won’t come through my daily routines. I’m ashamed I couldn’t finish my fairly simple goal for this month, so I an fully committed to learning both GitHub and staring a project with backbone.js for February. I WILL do it this time!
