I came here because Clive Walker tweeted about the project. I loved the concept of 12 achievable learning goals in 2012. However I wanted the goals to have a meaning for the whole year. A Series of new foundations in understanding which would work together to form a whole project for 2012 and 2013. To that end I needed to begin with good management of my code and so I picked Github for myt January task. As a old school Linux sysadmin and Perl, PHP developer I had enough experience building out code with CVS and had never actively focussed on git for managing my code and version control; so now was my opportunity .
This post is not about learning about Git; because that is something you can learn in many many other places. This post is about what I have learnt in my methods in learning; and these have been.
State my problem.
In this case; I need to use git and Github to start, maintain and manage any project i am going to learn about over the coming months.
Seek Good articles explaining how people solved those problems.
There are always plenty of tutorials to be found but researching in the first few days of the month leads to a number of good articles which are then filed ( thanks to Evernote ) under the 12412notebook with the tag ‘tutorial’ for recovery during the month.
Make note of how I responded to that and tracked them.
Again thanks to Evernote I can add my own notes to the articles and using comments in the code and my own .plan file ( hey I am that old ! ) I tracked my thoughts in preparation for ending the learning of that skill set.
Re-iterate and practice until the skillset is founded.
The best way to learn anything new is to practice with your hands and your mind on small topics and issues that you can relate to. In the case of git and Gitub I was able to bring an existing project into my git repository and push it to Github ( a private one though ) and experiment and play with the commands until they felt as normal as all the old cvs commands had been .
Do I feel I have become an expert on Git and Gitgub ? Well no I do not. What I feel is that I have learnt how to learn quickly without stressing over the task of adhering to the lessons or examples and enjoying the process of discovery by experiment. Which leads me neatly into learning about node.js for February. Yes you can expect to see my Github repository public appearances then.
Thanks for reading.
2 Comments »
January’s 12412: Researching LESS & SASS
My first 12412 project was to research and learn about SASS. After the recommendation from several people, I also decided to check into LESS. I’d been hearing a lot about the two techniques and was quite skeptical – in fact it seems I’m often skeptical of new things out on the web. Most frameworks, shims and other “add-on”s are only a passing faze and tend to do more harm than good – and so with some trepidations I jumped in.
What is SASS & LESS?
Both SASS & LESS are CSS preprocessors, basically they’re created to help you code CSS quicker by allowing the use of basic programming principles. Both allow you to use variables, mixins, nested elements, functions and operators.
You basically put your CSS into a special file, and then when finished, your CSS is run through the preprocessor and it kicks out “normal” CSS. Huh.
I found LESS to be a lot easier to understand and install, although both of them worked pretty much the same way. You’re able to create variables within your CSS so you can reuse certain elements (for example, a hex code), and if it needs changing, you only have to do it in one place. Here’s where my inner-awesome-developer-sense kicks in. You can pretty much already do this with a basic class.
Another major feature in both SASS and LESS is the use of nesting, where you can “save” on repeating code by indenting elements instead of having to retype them, for example, if you indented p {} underneath an id of #header, then the CSS that’s printed out is actually #header p {}
While this seems pretty cool at first, I can easily see this as becoming cumbersome and crazy really quickly. When you’re not paying attention to what’s being outputted, your’re more likely to be lax in your coding.
Important Questions
I had several important questions before and after I read up on the technologies, and most of them really weren’t answered by any of the articles I read:
What happens if another developer needs to edit the CSS and doesn’t know or realize a preprocessor is being used? How do you sync the two?
When no longer writing CSS yourself, how do you control the structure and organization of the code? How do you ensure you’re optimizing it correctly?
What happens if JS is down?
Does it work with one line CSS?
All in all, I don’t think I’ll be using either SASS or LESS. Installation time, upkeep and the fact that it ruins the simplicity of CSS will keep me away. If you’re a developer who’s spent a lot of time optimizing your code and really learning the in’s of CSS (not just top level stuff), then you’ll find this pretty useless, as you already can quickly do the type of code it spits out.
I’m also worried on our recent reliance on Javascript and the trend of forcing languages and browsers to do something they’re not meant to do. It wasn’t even a year ago that everyone was worried about best practices and making sure we didn’t rely on Javascript for anything but the beauty layer. Now this is one more thing that can break.
Some of the features, like mixins and operators actually made the code a lot more convoluted an jumbled, and seemed to take a lot more code than if you were just to type it out correctly in the first place. I also don’t see the point of operators – CSS isn’t a programming language and you can’t dynamically update styles so why not just type in the correct number in the first place?
Final Thoughts
Perhaps I’m wrong and you disagree – maybe you think SASS or LESS is the greatest thing since sliced bread. It’s just not for me. I would love your thoughts on it though!
4 Comments »
Media Queries & IE
Throughout the past month, I’ve been reading up on Responsive Web Design and have been utilising some of the code on my own site, mrqwest.co.uk. It’s been fun learning something like this but as always in the web industry, there is always a fly in the ointment.
That fly is IE.
IE 8 and below do not support Media Queries, but IE9 and above do. In order to get our sites working on IE8 and below, we’ll have to utilise a handy javascript Polyfill called Respond.js by Scott Jehl.
The goal of this script is to provide a fast and lightweight (3kb minified / 1kb gzipped) script to enable responsive web designs in browsers that don’t support CSS3 Media Queries – in particular, Internet Explorer 8 and under.
Adding this to your site is really easy. Go grab the code from Github, upload the .js file to your server and then reference it in the <head> of your page.
Don’t forget to change the src so it links to your respond.min.js file!
Now, when you visit your site in IE8 or below (or any other browser that doesn’t support Media Queries), the Respond.js file will jump into action and add that functionality in so it will work as intended. As Scott says, now is the time to pump fists in delight!
Scott has outlined some issues and notes worth keeping in mind when using Respond.js on the github page so I’d recommend you give those a quick read; there are some pretty important notes there and some that may make IE7 & 8 hang on load.
11 Comments »
Text Scaling
Those of you who have been following along with my previous posts and have been curious enough to load the examples up on your mobile devices may have spotted that the text & layouts are incredibly small and you’d be right!
This happens because mobile browsers tend to draw the page on an extended viewport which is generally bigger than the screen itself. It then shrinks the viewport down to fit the physical width of the screen.
Not much good really when we’re trying to build a responsive site that works on mobile devices.
The Mozilla Developer Network said that Mobile Safari (iOS) first created the Viewport Meta Tag to allow developers to manipulate the size & scale of the viewport; which is handy for us!
This sits in the <head> part of your page and it tells the browser that it should render the width of the page equal to the screen width. It works this out by calculating the width of the screen in pixels, and then drawing the viewport at that width.
The initial-scale property tells the browser not to scale the site when it’s first loaded (so it doesn’t shrink the layout to fit the screen).
Check out Example five on your mobile or tablet device and see how it now shows the correct scale.
The maximum-scale property stops the user from zooming in or out. In theory, with a responsive layout, there is no need to change the zoom. Some people would have an issue with the maximum-scale property as it can affect usability so it’s more personal choice.
5 Comments »
Flexible Images
Over the past few months, whilst building client and personal sites, I’ve started adding %; to my image selectors so that any images will resize to fit within its parent. It worked great from the limited tests I ran so I stuck with it. It was only at the tail end of December whilst I was writing a custom style sheet for Google Reader did I realise an issue with using %;.
Our current example page we’ve been working with shows the main content area at approximately 39em (or 624px) in width (it’s 65% of 60em which is the equivelent to 960px). If we inserted an image with a width of 800px, it’d reduce down to fit within the 624px parent. Resize your browser, and the image resizes with it.
Nice!
But if you inserted in an image with only a 300px width, the browser would enlarge the image to fit the parent by making the image almost 210% larger. As you can imagine, this looks pretty pixelated… and pretty bad!
Then I read about using max-%; instead of the regular ‘width‘ property. Using max-width still allows the image to shrink down along with the parent element so it’ll fit your layout regardless of what device you’re using but it won’t go above 100% width of the original image.
So going back to the previous example of the 300px image, using max-width would mean it’ll shrink down to suit the layout on mobile devices but it won’t actually increase above 300px in width!
Fantastic – however there’s one more thing we need to deal with and that’s the height of the image; But it’s actually quite easy. Setting your height to auto always helps the aspect ratio.
Here’s what I’ve added to the stylesheet
.content img {
max-%;
auto;
}
and here is Example Four which shows an image of a coffee cup (I like coffee!) – resize your browser and watch the image respond to it’s changing viewport.
8 Comments »
Real Quick Media Queries
In my last post, I was looking at setting up a multi-column layout using percentages which made it adapt to different viewports. Twinned with the max-width declaration we set in a previous article, we had a fluid width design with multiple columns that adapted with the ebb & flow of the screen size.
Our max-width declaration stopped the design of the page getting too wide and becoming uncomfortable to read, but what about the other end of the scale?
There is a function called min-width which works just like max-width but stops the design from becoming too small. Problem with that is if the viewport is thinner than the value specified in min-width, you’ll end up with horizontal scroll bars and that’s kind of one of the things we’re trying to avoid.
So how do we do it?
Media Queries are the answer. That and a ‘mobile first’ approach.
If you’ve not heard of the ‘mobile first’ approach, it’s about designing and developing your layout for a mobile first; and then using media queries, you build your layout up to work on larger devices such as tablets & desktop machines. But I’m not very good at explaining things, it’s best to let guys like Luke Wroblewski tell you all about it in a blog post or book!
So first things first, I’m going to be working off my previous Example (#2) as it makes sense to stick with it through the project. What we’re going to do is introduce our first media query.
@media screen and (min-px) and (max-px) { }
This goes into your CSS file at the bottom. The syntax is saying that the code within the curly braces ( { } ) is for screens / viewports between 601px & 1900px wide. You don’t need to set a minimum and a maximum limit, but using this will allow us to have a different layout for screens which are less than 600px wide (mobiles) and screens that are over 1900px wide (really big screens & TV’s).
As a note, you could also swap the min/max-width for min/max-device-width which works on the screen size the page is being viewed on rather than the viewport.
So now we know what the syntax is, I’ve dropped that into our example and I’ve moved the code from my previous post to within my curly braces of my media query.
@media screen and (min-px) and (max-px) {
.content {
%;
float:left;
}
.sidebar {
%;
float:right;
}
}
What this means is that the .content and .sidebar rules will only be called if the viewport is between 601px & 1900px. Any size outside of these dimensions will result in a single column layout at a maximum width of 60em (approx 960px) because we’ve not specified any styles to match dimensions outside of our media query yet.
Chris Coyier also has a very good snippet over at CSS-Tricks which has a whole bunch of media queries set up for standard devices. It’s well worth a look to understand what’s happening and to see the correlation between device widths.
Additionally, my team member Paul Adam Davis also wrote an article for ’12 Devs of Xmas’ on getting responsive using LESS.
Not bad going. Have a look at Example Three. It looks a lot like my past example, yet if you resize your browser down below 600px wide or above 1900px, it’ll change layout.
Why not give it a go?
5 Comments »
Digibury and impress.js
Last night Paul and I had the opportunity to present 12412 and talk about our aims for the project and how we got it started at Digibury, a new creative community event for Canterbury. The format of the evening was for a couple of short talks, mixed with socialising and nibbles at The Farmhouse, a slightly eccentric venue on the edge of the city centre (but great salmon sandwiches!).
First we heard from Tendayi Viki with a really entertaining talk on how (not) to go about creating a lean startup, somehow combining cargo cults, CRB checks and a little self-admonishment to great effect.
In the spirit of learning we decided to put together our presentation using a brand new Javascript tool – impress.js – which has been created by Bartek Szopka as an attempt to out-prezi Prezi in the browser. At version 0.1 its early days, but there is already an impressive slide transition system using HTML5 data-* attributes to define each chunk of the presentation and CSS 3D transforms to navigate between them.
Obviously this has implications for wider browser support but when you’re putting together a deck to run on your own laptop you can tailor it to what the hardware can handle.
Creating the slides is essentially as simple as coding and styling a single HTML page. We used the basic branding from the 12412 site as well as few screenshots of our analytics reports so far and various other mentions of the project around the web.
There’s a huge amount of potential in impress.js and I’m planning to continue using it as it develops. I have some ideas of my own to possibly contribute – a slide composer for it would be handy to save on manual coding – so perhaps there is a future month’s project in there!
You can look through the presentation at extra.12412.org/digibury or grab it from Gitub at https://github.com/12412/digibury. Be aware that it requires Chrome or Safari to view (and hardware acceleration also helps), the impress.js documentation states that Firefox 10 and Internet Explorer 10 should also be compatible but we haven’t tried them out.
Our thanks go to Digibury, and Simon Bostock at Deeson, for setting the event up and inviting us. We’d love to do more of this kind of thing throughout the year, so do get in touch if you’d be interested in hearing more from us.
1 Comment »
Multiple Columns in A Responsive Layout
The last two posts here on 12412 have been about creating a responsive layout using relative units such as em‘s. We’ve made a single column layout which responds to the browser view and changes size to suit.
Not every site will be single column though, a lot of websites feature a sidebar, or even two!
For this example, we’ll be working with em‘s again. Our <body> tag will look something like this.
So to explain quickly, we’ve got our body tag. This in turn has a div tag with a class of “wrapper” and within that, we’ve got another two div tags for the main content & sidebar. This will be the HTML required for what we want, a responsive content & sidebar scenario.
Next we move to the CSS and it’s incredibly basic.
Like the last example, we’ll keep our body widths using percentages & em’s for max-widths
body {
%;
max-em;
Then for the actual columns. The we need to make sure that the two column percentages don’t go over 100% as they wont fit side-by-side in our layout. We’ll also be floating the columns as you would normally. Here’s the code.
That’s the code in its simplest form. It creates two columns side by side, and they’re set in percentages so they’ll shrink and grow with the browser window.
For an example of the code, take a look at example two which demonstrates the code we’ve done here. Try resizing your browser up & down to see how they columns adapt with the ebb and flow of the viewport.
You’ll also notice the columns get uncomfortably skinny when the browser window shrinks down too far. The answer to that lies with Media Queries which I’ll cover in my next post!
6 Comments »
A Word On em’s
In my last post, I mentioned that I had set my <body> tag to max-px;. After both Clive Walker & Phil Wareham posted comments regarding the use of em‘s instead of px on the max-width rule, I thought I’d do a bit of research.
To be honest, it did seem a bit daft to avoid using px values to make the site fluid / responsive but still use px to specify layouts.
So after a bit of digging, here is what I’ve found.
Generally, the browser standard for em sizing is 1em = 16px. So if you wanted to set your headings at 32px in size, then you’d use em;. If you wanted to set your footer text at 10px, you can work out that out by taking the size you want and dividing it by 16. So 10px / 16px = 0.625. To achieve a 10px font size, we’d then use .625em;.
Notice I said generally. All browsers allow the user to change the default font size. Lets say Mr Smith has trouble reading type at 16px so he ups his default size to 20px. This’ll then mean that 1em = 20px.
It may seem complicated but em‘s are a lot more flexible than px values.
So back to my original point, we can set our max-width in em‘s by taking the size we want and dividing it by 16. In this instance, it’d be 960px / 16px = 60em.
Setting our max-width to a value of 60em doesn’t actually change the appearance of our site at all, but it does remove the fact that it relied on a fixed unit of value, and is now elastic.
ADDENDUM
I’ve done a really quick example page to show the code so far. Load it up and resize your browser to see how the body of the page responds to the browser width as you shrink, and how the body sticks to its limits when you make your browser window wider!
Example One
23 Comments »
Responsive Layouts
This is my first post on 12412, and its about responsive & fluid layouts in web design. I’ve not really played around with fluid layouts in the past. I’ve tended to stick with pixel widths purely because I *thought* I had greater control but the past year or so, I’ve come to realise that is certainly not the case.
Fluid layouts adapt and change the layout of your site dependant on the size of the viewport /device your using.
So in my first month of the 12412 project, I’ll be learning all about responsive layouts and will be applying my knowledge to my own personal site (mrqwest.co.uk) which I have recently stripped bare of it’s previous pixel-based grid layout and design.
I’ll come armed with my iPad loaded up with some choice ebooks including ‘Responsive web design‘ by Ethan Marcotte and ‘Adaptive Web Design‘ by Aaron Gustafson. Additionally, my team mate Paul Adam Davis recently wrote a really nice article on responsive web design for the ‘12 Devs of Xmas‘ which will help in my learning too!
Units
First things first. How will I be making my layout responsive? Percentages are your friend.
I’m setting the width of my body tag to 90% and centrally aligning the tag using margin:0 auto;. This means my body tag will fill 90% of the browser window; regardless of whether the browser is full screen or only taking up a quarter of the screen. Setting to the width to 90% also gives the body some breathing room and ensures that any text or content within doesn’t run right upto the edges.
This looks great on a mobile device but looks extremely odd when viewed on a large desktop screen. The line lengths of text are extremely long and uncomfortable to read so we’ll want to reduce the line-lengths.
I’ve done this by setting a max-width on my body tag. I’ve set this as max-px;. This means that the content area will take up either 90% of the screen width until it hits 960px wide and then it’ll stay at that width. This gives me an element of control over my design at larger screen sizes.
I know I can take this even further by changing my layout for larger screens using media queries but I’ve yet to tackle that so that’ll be saved for my next post.
For a start though, I’ve set up my site to utilise a linear, yet responsive layout. It works nicely on mobile devices, tablets, desktops and *should* work well on almost all internet enabled devices using up to date browsers & technology.
