JavaScript is a unicycle

This past week, we learned JavaScript and jQuery. Before this I didn’t know the difference between the two languages, other than hearing people say jQuery is easier to work with.

How I see it

Let’s say you want to take a ride around the block. You have two “vehicles” from which to choose: a plain old bicycle, and a unicycle. JavaScript is the unicycle. It takes some time to learn to ride it and you might fall (a lot) and hurt yourself (a lot) in the process but, once you get the hang of it, you’ll feel really proud of for conquering something that many people would stay away from. Since JavaScript can be a bit tough to work with when all you want to do is ride around the block, remember that you have the option to ride the bicycle instead. jQuery is that bicycle; it’s built on JavaScript and makes doing what you want to do much easier.

Since jQuery is essentially JavaScript, everything done in jQuery can be done in JavaScript. But you wouldn’t always want to ride a unicycle.

I kept on pedalling and got lost

This weekend, I got really carried away with jQuery. I was writing a lot of what I think is probably very bloated, redundant, and very roundabout code. And that’s totally fine; it’s part of the learning process. Oh and I went to bed at 4 am.

Keep in mind, however, that if an effect you’d like to achieve can be done with CSS, do it in CSS. CSS is becoming increasingly powerful with features previously only achievable with JavaScript. And because it’s much easier to write CSS, this saves you time. There are performance-related reasons as well, but perhaps I’ll save that for another time.

In conclusion… let CSS do the heavy lifting, and leave the rest for JavaScript and jQuery.

Fluid-width Twitter widgets

Twitter’s timeline widget isn’t very pretty; but the reality is many of us are forced to make do with this thing. While there are ways of customizing it, we’re still left with a widget that is never wider than 520px. This limit is especially evident (and ugly) on mobile devices where, for the most part, elements are stacked on one another and take up the full width of the browser. But the widget refuses to be as wide.

Why 520px? That’s what I’d like to know. Fortunately, there is a way around this.

When grabbing embed code from Twitter, they’ll give you something that looks like this to paste into your document:

<a class="twitter-timeline" href="https://twitter.com/crazy_joe_davola" data-widget-id="1234567890123456789">Tweets by @crazy_joe_davola</a>

and

<script>!function(d,s,id){var js,fjs=d.getElementsByTagName(s)[0],p=/^http:/.test(d.location)?'http':'https';if(!d.getElementById(id)){js=d.createElement(s);js.id=id;js.src=p+"://platform.twitter.com/widgets.js";fjs.parentNode.insertBefore(js,fjs);}}(document,"script","twitter-wjs");</script>

Paste in all that code, and then forget about the script tag; you will need it for the widget to work but there’s no need to mess with it. The first element – the a element – is what we’re concerned about.

What you may not know about this link element is that it is a way of placing an iframe onto your page. Let’s have a look.

Let’s say I have a footer and in it, I have a div containing the widget. It would look like this in our HTML file:

<footer>
	<div class="tweets">
		<a class="twitter-timeline" href="https://twitter.com/nathanfoon" data-widget-id="411954987346825216">Tweets by @nathanfoon</a>
	</div>
</footer>

If we view the code in the browser dev tools, it looks like this:

<footer>
	<div class="tweets" data-twttr-id="twttr-sandbox-0">
		<!-- Imagine there is an iframe element here... -->
	</div>
</footer><

(For some reason, WordPress strips out the iframe element. Please use your imagination.)

The a has magically become an iframe! And guess what – you can style this in your CSS. If there’s any width-related inline styling in the a tag you pasted in your HTML, get rid of it. Now go ahead and write a rule to target your iframe, and give it a width: 100%.

.tweets iframe {
	width: 100%;
}

This, in combination with Twitter-defaulted max-width: 100% makes your widget no wider or narrower than its parent. Your widget will now look spectacular.

Mobile-first responsive design

There is so much information being forced into my head. I’d tell you if I hated it but, the thing is, I don’t. “School” is amazing. I’ve never laughed this much in a long time; I wonder if our instructor moonlights as a stand-up comic.

Our project for week two was to build a multi-page site. Very straightforward. I, however, decided to try out an idea I’d heard and read about—mobile-first styling.

I had a really hard time with this because designing for the desktop is the first and only thing I’d ever done. I would often forget that I was designing for smaller screens and completely screw up my layout. But I pressed on.

Responsive design is implemented in sites so that they display properly on any device with a browser. Generally, a (good) responsive site will not require visitors to zoom in/out, scroll horizontally, tilt their heads, and/or squint in order to view its content. When it comes to desktop devices, there is usually quite a bit of real estate with which to work, so there shouldn’t ever be any of the same issues that mobile users face.

When I first heard about it, I didn’t think much of it. But then I learned about performance concerns (loading time, in particular) and our increasingly short attention spans, and then the mobile-first approach made (increasingly) more sense to me.

Our CSS is leaner

Since desktops are such large canvases for sites, there’s a ton of complex things that could be done in terms of style. On smaller devices, element styles are much more simple; this usually means optimizing the use of precious space by reducing the number of columns, giving elements a full width and stacking them on top of one another.

Because mobile layouts are simpler, fewer selectors (and with those, properties and values) are required. As the browser size increases, styles can be added as required to jazz up the layout. This is in contrast with “desktop-first” design, where styling must be un-set and/or stripped away as browser space decreases. Because desktop layouts are for the most part more complex, it could take quite a few lines of code to reset the look of our elements for mobile.

Consistency

Believe it or not, there are sites out there that hide content because you happen to be visiting on a smaller device. Why aren’t you able to view the same amount of content as a desktop user? It’s because your device is too small, and those things were too hard to fit on such a small screen. It’s your fault.

Kidding!

It’s not your fault; device display size and/or performance is not a good reason to hide content from users. Mobile-first design isn’t only about looks. The mobile-first philosophy encourages you to evaluate your content to determine whether or not it’s worthy of existing on your site. Because your mobile content is nice and lean and streamlined, the desktop incarnation will inherit that as well.

Shorter load time

If you have a mobile device and use it to browse the web, it’s safe to say your connection isn’t ever as fast as if you were browsing on a desktop. Since we’ve gone through our content and kept only the important stuff, and since we have less code, our site load time is reduced. Less fluff = less work = less code = less styling = shorter load time = less banging head against wall = better quality of life.

Consider the mobile layout your base. Since your base content is consistent on all devices thanks to the mobile-first approach, it’s now cool to add bells and whistles for larger screens because those are just enhancements.

Learn more about mobile-first design at:
LukeW
Brad Frost Web

Project two can be viewed here. Images and copy are not mine.

Week calc(9 − 8)… done!

This past week was great; I met my classmates and learned about their unique backgrounds. We got a refresher on basic HTML and CSS, learned about personal branding, and even bought hosting for our future sites. Our instructor, Wes, is a very funny man. And the environment in general is pretty cool. It really doesn’t feel like school.

With week 1 all wrapped up, I can tell you I learned two big things: 1) I need to start using social media more often and with purpose—not just for retweeting Seinfeld quotes, and 2) the magical CSS calc() value.

We’ve been encouraged to use relative units (percentage, em, etc) to define the dimensions—especially the widths—of our elements (vertical scrolling is cool, horizontal scrolling not so much), and it makes sense to use dynamic values to style things that’ll be viewed on screens with unknown dimensions and proportions.

With that said, I was faced with a challenge while completing our first week’s assignment of building a one-page site. In my header, there is a h1 of fixed width (ie. the content here will never change), and to the right of it is my nav. I want the left edge of my content to align with the left edge of my nav, and I want my background image to be exposed in the empty area directly underneath h1.

I’m sure there are other ways to solve this; but I can be stubborn at times and I wanted my one-pager to look exactly the way I wanted it to look. No compromises for this guy.

If I assign my content wrapper a width of, say, 75% (pictured above), it looks great.

But what if I shrink the browser window (pictured above)? The content spills out into the space underneath h1 and it is no longer aligned with my nav and the layout is broken. That’s a shame. Essentially, the layout will look perfect only when the browser is a certain width, and that is ridiculous. I needed to mix a relative value with an absolute one. I had to make my content wrapper span the full width of the browser (100%), and then pull it back by subtracting the width of h1 and its surrounding padding (345px). Could it be done?

You bet!

I guess it could be said that calc() is a relative, or dynamic, value; its computed value is calculated on the fly as variables (such as browser width) change.

.content-wrapper {
	width: calc(100% - 345px);
}

calc() can be used whenever a number-based value is required. It can handle addition, subtraction, multiplication, and division. It’s got pretty good browser support, too.

Learn more about calc() at:
Can I Use
Mozilla Developer Network
CSS-Tricks

The finished product of my roommate’s site can be viewed here.

I’m BATMAN

There were many people I wanted to be as a child: a Power Ranger, Spider-Man, an engineer (I didn’t know what an engineer did; my dad just kept telling me to be one because of the money); but there was one that was way at the top on my list. I dreamed to become Batman. I was Batman for Halloween, had a Batman sweatshirt-sweatpants combo, games, toys. Batman: The Animated Series was the cartoon I watched the most and I loved it and would never miss an episode and it was the best. THE BEST. I wish I was five again.

In a way—in a way—I’m still pursuing that dream.

When I was in college for graphic design, we had one course on Adobe Flash and one course on web software. In total, that’s about 40 hours of class time for each course. It wasn’t enough; our Flash instructor barely showed up, and we were learning how to use Dreamweaver—not how to actually write code. It was a little disappointing but I convinced myself that I didn’t need to know Flash or Dreamweaver/web design (at the time, those were one and the same), because I just LOVED print design. You can hold printed pieces, touch them, feel them. We can leave web design to web designers. We can leave Flash to… to those Flash people. That’s what I kept telling myself.

In spring 2012—a year after I graduated—I landed my first real graphic design job. It was in the marketing department at the head office of a company (which shall remain nameless) on Bay Street. The dress code was business casual, it was downtown, I had to commute. I was finally all grown up. Awesome. I was loving it. My official title was Graphic and Web Designer. It turns out that I didn’t need to do much real coding; a lot of it was making edits to the company’s site through a CMS. The pay was quite decent. I was very comfortable.

By then we all learned that Flash was on its way out. I guess missing out on learning Flash was okay after all. Ah, but what about HTML5 and CSS3? People were excited for HTML5 and CSS3. Those were scary things with which I wasn’t too familiar.

One day, I looked at my nameplate that hung above my desk. I thought to myself, “How could I call myself a Graphic AND Web Designer if I knew only what I learned in one web design web software course I took in college four years ago?” I couldn’t. It was embarrassing. I also started to find my work clothes lame and uncomfortable. I decided that I really needed to do something. I started to check out the local colleges’ continuing education programs. My coworker suggested I enroll in an HTML and CSS course she stumbled on. It was offered by an organization called HackerYou. It wasn’t a school; it was something else. Something totally different. It lacked the bureaucracy and BS that plagues traditional schools’ curriculums (curricula??).

I learned so much in those 12 weeks. The atmosphere was very inviting, very welcoming. It was our instructor and mentors’ belief that anyone from any walk of life could learn this stuff without any prior knowledge of writing code. By the end of the course, I could do nothing but agree with them. I fell in love with what I was learning. The experience was, dare I say, life-changing.

Which brings me back to the whole Batman thing.

I learned about the full-time bootcamp. Perfect timing. Not only was it something I wanted to do—it was something I had to do, or else I’d be stuck in dress pants and tucked-in shirts for eternity. I’m leaving behind my stable office job, my stable office pay, and my business casual attire to train in the ways of (front-end web development) ninjutsu. I’ll have to climb to the top of an Urban Outfitters to a place called The Lab. I’ll assume you’ve seen Batman Begins.

Can’t wait to start training.