Responsify isn’t Responsive. Wait, what?

Posted on by KrooKedUK

I’ve been putting off this post as I haven’t been sure exactly how to approach it, but I guess it needs to be written. Anyway it’s gonna be one of the shorter posts I’ve written.

So you’re probably thinking this is a bit crazy, a browser tool which allows you to create a Responsive grid template, but it’s not Responsive itself. Well I have a couple of reasons for this which I’m going to outline below.

I’m really not expecting web designers/developers to be working on their phones, well at least not for a few years yet. If you are, I think you may be a workaholic, please get some help! Seriously though making a grid or template on my phone doesn’t appeal to me and I am assuming most of you would be the same. I am however planning on tweaking the layout for tablets at some point, but since Responsify works fine on them currently it’s not on the top of my to-do list.

I could have made the site Responsive purely as a proof of concept, but I decided my time would be better spent on other areas like getting some sleep and working on other features. I may re-evaluate the situation at some point and make something that works on mobile devices, but again I feel my time would be better spent on adding new features.

Anyway that’s my stance on it and why nothing exciting happens when you resize your browser!

Posted in Design

Percentages are really bugging you WebKit, aren’t they?

Posted on by KrooKedUK

For those of you with a good set of eyes, you’ll probably have spotted some strange alignment issues with the grid on Responsify.  I’ll forgive you for thinking I’ve got my calculations wrong, it seems WebKit browsers (and Opera) have some weird issue with correctly calculating percentages, yet Firefox manages this fine.

I’m not going to bore you with technicalities in this post as there is a great article on CSS Tricks which covers the issue, but here is a sentence from the article which describes the problem:

For example, if a container is 657px wide currently, and has four columns at 25% each, they would be 164.25px each wide, and WebKit doesn’t handle that well (rounding issues?) Other browsers handle the “subpixel” value OK.

I’m not sure how many people are aware of this bug, I mean I knew nothing about it either until I came across it working on Responsify. Initially I thought I was being stupid and had made a mistake with my calculations but after triple checking I figured something else was the cause. After a few Google searches I found out that WebKit and percentages don’t get on so well.

Let me show you exactly how it looks when WebKit gets it wrong.

Obviously this isn’t ideal, we’re not working with pixels as units but we still want our designs to be pixel perfect. I carried out a little research into the problem to see if anyone had come up with a decent solution, but unfortunately there isn’t a whole lot out there about the issue, let alone fixes. Maybe this is because the issue isn’t widely known or because it doesn’t cause a problem in most scenarios, I really don’t know.

I did however come across a clever approach which does solve the problem, albeit a bit more complex than the standard grids we are used to.

Negative grid was created by Chris Planeta for his own personal use, but he put it online for everyone to use. Here’s what he has to say about it:

Negative grid uses a different approach to positioning columns than ordinary grids. Normally, the position of a column is relative to the column on its left (distance set with a left margin). In NegativeGrid the position of all the elements are calculated from the left border of the container. It is all possible due to a simple margin-right: -100% added to columns.

This is a great solution that works well and I did consider building this technique into Responsify, but I wanted to keep things as simple as possible so that the grid is easy to use and more importantly so that it’s easy to understand what’s going on. You should definitely check it out though, as it’s a very interesting technique.

This bug has made me think long and hard about how I will build Responsive sites in the future. I’m still going to use percentages as the bug is barely noticeable in most situations, but I plan to start experimenting with ems for layout and find some way to incorporate them into Responsify, so expect an update in the near future.

As always, I’d love to hear your thoughts!

UPDATE: Good news, subpixel rendering is coming to WebKit, so when this eventually reaches the browsers, we should have no more issues with percentage based layouts. Success!

Posted in Design, Development

Responsive design. Is it always the right solution?

Posted on by KrooKedUK

We all want to work with the latest technologies and techniques on the web, that’s only natural. This is what makes our industry so exciting. You want to show these techniques off on sites you create and that’s great, it shows that you are passionate, but when it’s at the expense of the client this becomes an issue. You should never charge a client for something if you aren’t sure it will benefit them in some way!

So let me be a little clearer about what I mean. The purpose of creating a Responsive website is to create the best experience for the user no matter what device they are viewing on. So how do you find out if your client’s target audience will benefit from a Responsive site? The obvious place to start looking is at their site traffic and get a good idea of the number visits they receive from mobile & tablet devices and desktops. Only then can you make a decision, based on these figures. In the scenario that they don’t have these stats available, you’ll have to do a little research of your own, if that’s an option.

There is an argument that you could future proof a site by making it Responsive. Yes mobile traffic on the web is increasing at a staggering rate, but who’s to say that in the future mobile traffic will increase for a particular site, you just can’t know! If you can identify a pattern where mobile visits are increasing each month, well then you could very well consider doing this.

So what if a client comes asking for a Responsive website?

Awesome, a client who knows what they want! But do they really? It’s our job as designers to make sure the client understands what exactly they are asking for and how it will benefit their business. You should never assume that a client coming asking for x and y knows exactly what is right for them, they might but it’s up to you to make sure!

Take the time to find out what they understand and if you need to, tell them that a Responsive website just isn’t for them and explain why. It’s easy for clients to think the newest trend will work for them and it’s your job to figure out if it will, or if their money would be better invested somewhere else. You will get satisfaction knowing that you helped your client spend their money wisely, by caring and advising them. They will appreciate this!

So you want some Responsive sites in your portfolio?

Ok, so just because the client doesn’t need it doesn’t mean that you shouldn’t make the site Responsive. There is nothing wrong with making a Responsive site and not charging extra for doing so! Take the hit knowing that you are getting another Responsive site under your belt.

However if making a site Responsive negatively impacts on the user experience, avoid it. So for example, say you decide to spend less time on one aspect of the site and put more time and effort into making it Responsive, this might mean one area of the site is lacking. You need to look at all areas and work out which are most important and make sure your focus goes to these first. At the end of the day your client wants to see results and if making a site Responsive helps, great! If not, you are still doing your job and providing the client with the best solution to their problem.

Just to be clear, I don’t agree with charging for Responsive design as a feature, but charging for the extra time it takes to properly plan and build a Responsive site! Maybe you agree with something I’ve said, or see things completely differently, so I’d love to hear your opinions and how you decide if going Responsive is right for your client!

Posted in Design, Development

Getting Responsify out there!

Posted on by KrooKedUK

responsify

After a few months hard work I’ve finally been able to get Responsify to the stage where I feel comfortable putting it out there and seeing how well it’s received. I’ll be honest, I get very nervous about how others will perceive my work and I guess this is something I need to get over and embrace feedback, whether good or bad as I know it will always be beneficial to me. So if there is anything at all that you think would help me improve Responsify, please take a few minutes and get in touch, I would be very grateful!

So why did I make it?

For those of you who don’t know me, I’m a student in my Final year and Responsify started as my Major project, but I see it as much more than a University project. It’s a tool I hope will help out others in the industry and I intend to continue its development after I graduate. I am a huge fan of Responsive design, not because it’s cool or trendy, but because it allows us to tailor the experience that a user receives on their device. I love the fact that we are no longer designing for a fixed canvas, the desktop browser.

What have I learned?

I’m a designer, I’ve never strayed much into web development, so having the option to choose what I wanted to create was excellent, I could do design and development. I suppose there is an argument that I should have played to my strengths and created something more design focused, but I feel that it’s always good to challenge yourself, knowing that you will learn loads along the way! I now have a much better understanding of web development, using PHP and jQuery and I’m eager to keep learning more. So no matter what grade I get, I know I’ve gained a lot from this project so far!

I must give a shout out to Simon Fraser, who has been a great help to me when I was struggling to get something to work, which usually turned out to be stupidly simple. I have learned a huge amount from him! So thanks Simon!

I don’t really have much more to say other than this post should’ve been up a couple of days ago. It wasn’t my intention to work over the weekend but I ended up writing this post, so it’s not so bad! Anyway, I hope that you find Responsify useful and can use it as a starting point for your next Responsive website.

Taking Semantic.gs for a testspin

Posted on by KrooKedUK

Semantic Grid system

I thought I’d follow up from one of my previous posts CSS Grids & Responsive Frameworks by having a play around with Semantic.gs; this will give me a little exposure to LESS and it will be interesting to see how this grid system stacks up!

This post isn’t intended as an in depth look at how to use Semantic.gs, it’s main purpose is to show you the minimal amount of code you need to write in order to create a fairly complex layout.

I experimented with a fixed and a responsive fluid layout, the reason being that the documentation makes it seem very simple to switch between using pixels and percentages and I wanted to give it a go. To start using percentages I just had to add the following to my LESS file:

@total-width: 100%;

This overrides the variable, which by default is set to:

@total-width: @_gridsystem-width;

I’m not going to delve into any more detail about the default values, as the purpose of this post is not to explain the inner workings of the Grid system.

A look at the layouts

The HTML layouts will give you a better idea of what I’m talking about, you should have a look around in the source of the fixed pixel layout, if you are that way inclined, as I will not be covering it in this post; Like I mentioned earlier this was my own experiment to see how easy it would be to change the layout to use percentages instead of pixels.

Let me show you how simple it is

I didn’t need to change the default grid settings, so they just stay like so:

@column-width: 60;
@gutter-width: 20;
@columns: 12;

To make the grid system work with percentages we override the total-width variable like so:

@total-width: 100%;

Then you simply define the amount columns you wish an element to use in the .column() mixin.


#top{
  .column(12);
}

.larger-block {
  .column(4);
}

.block {
  .column(3);
}

.smaller-block {
  .column(2);
}

At this stage, we now have a fully fluid grid and this has all been achieved by writing a minimal amount of code. Ok, the next step is to make it responsive, so let’s break out the media queries. I’m just going to show you the media queries for mobile devices, as you only need one example to understand what’s going on.

@media screen and (max-width: 480px) {

	#wrap{
	  width: 100%;
	}

	.larger-block {
	  .column(12);
	}

	.block {
	  .column(12);
	}

	.smaller-block {
	  .column(12);
	}

}

You’ve probably guessed what I’m doing in the above code. If you haven’t, I’ll explain: To create a 1 column layout I want the elements to use all of the horizontal space available to them i.e the 12 columns. This means the elements will stack on top of each other creating a simple layout optimised for mobile devices.

I don’t think I’ve come across any other framework which allows you to create a fairly complex layout as quickly and effortlessly as Semantic.gs does. I will definitely be making use of this grid system in the future and recommending it to others.

Posted in Design

CSS Grids & Responsive Frameworks

Posted on by KrooKedUK

I require a fairly robust grid for Responsify.it and I am still in the process of deciding if I should use an existing framework (possibly one listed in this post) or roll my own solution. All of these frameworks have their benefits, but they also lock you into working in a certain way. I suppose I could modify a framework/grid to suit my needs, but then I could just as easily start from scratch. I’m going to take a look at some Responsive Frameworks & CSS Grids to see if I can find anything suitable.

One gripe I have with CSS grids is unsemantic classes like grid-x or 6col. This is something I can live with though, but Responsive design has created a new problem in this area. Class names like grid-6 or col3 are no longer relevant when describing responsive layouts. For example say we have a normal element which takes up 6 columns of our page, called grid-6, this is fine and describes the element accurately enough in structural terms, but say we want to create a 1 column layout for a mobile device, then the class grid-6 loses all meaning in our markup because we have changed its context. This will bother some and others won’t give it a second thought, but thankfully there is a grid system which provides a solution, Semantic.gs which I will have a look at later in this post.

Setting aside what I said above, I realise CSS frameworks can offer many benefits, including:

  • Being able to quickly prototype to show a client something functional and tangible.
  • The structure of the site will be well organised, although this should be true even when you aren’t using a framework.
  • Those new to web design, can play around with these frameworks to gain a better understanding of how CSS works.

Let’s take a look at the Frameworks

Foundation

Foundation Grid Framework

The Foundation framework, true to it’s word includes much more than a grid, there are buttons, forms, and loads of UI elements like tabs, alerts, navigation bars, pagination and a lot more. This is definitely a feature packed framework, but I expect no less from the creators, Zurb.

Here is an overview about the grid from their well written documentation:

The grid is built around three key elements: containers, rows, and columns. Containers create base padding for the page; rows create a max-width and contain the columns; and columns create the final structure. Everything on your page that you don’t give a specific structural style to should be within a container, row and column.

What you need to know is that columns don’t have a fixed width: they can vary based on the resolution of the screen, or the size of the window (try scaling down this window to see what we mean). Design with that in mind.

This is a very well put together framework. It would lend itself well to quick prototyping thanks to all of the additional elements, but would work just as well for a proper production website. It’s nice to see there is nesting support also, so you can just include rows inside columns. Very polished framework, with solid documentation, we’re off to a good start!

Goldilocks Approach

The Goldilocks Approach

Front take a completely different approach from any of the other grids. According to the Goldilocks site:

The Goldilocks Approach uses a combination of Ems, Max-Width, Media Queries and Pattern Translations to consider just three states that allow your designs to be resolution independent.

The idea of resolution independence is very interesting and the concept behind this solution is that we shouldn’t be selecting certain devices as a guide for our layout, especially when we want that layout to work seamlessly across the myriad of devices that exist today. Instead we should be focusing on designing around the content, not the device itself.

Clearly the guys at Front have put a lot of thought into this method of designing for all devices and I think this concept will crop up more and more over the next few months, it’s definitely something I will be keeping a close eye on. I can’t help but think that this would be a great approach to take for my Responsive template generator, but I’m even considering the fact that I could offer a choice between several CSS grids. I need to have a good think about the feasibility of that one!

Skeleton

Skeleton Framework

This is another full featured framework, with solid typography set to a baseline grid and a lot more, or as stated on the website, it is:

A Beautiful Boilerplate for Responsive, Mobile-Friendly Development

Skeleton is a platform which sets the foundation for quick development, according to the creator it’s not a UI framework, instead, serving as a development kit with the basics for you to build upon and add your own style to. One thing I really love about Skeleton is the naming convention for the grid; you want one column? that’s easy just add the class one, 5 columns? the class five, you get the picture! This makes me happy to see that someone else is on the same wave length in regards to naming columns, as I would do it exactly the same way!

The only gripe I have with this framework is that it relies on pixels; sure it may be responsive, but I really feel we should be leaving behind the old mindset of working with fixed dimensions. I suppose you could make the argument that, anyone who wants to could quickly modify it to suit their needs, but I’m sure most people looking for a framework, would expect the hard work to be done for them!

Skeleton is without doubt, a great foundation upon which to build a website. I do however think it would benefit greatly by having a fluid grid, based on percentages, included as an option.

Frameless

Frameless Grid

Created by Joni Korpi, Frameless is the successor to the Less Framework and is another unique solution to creating a responsive grid. Korpi outlines his approach with the following three steps:

  • Make a regular fixed-width grid.
  • Make it repeat infinitely.
  • Center it in the viewport.

Basically the concept is to create a grid, and give that grid an infinite number of columns, so that no matter how wide the viewport, more columns will appear and fill the space. The final step is to a align the grid to the middle of the viewport. When using media queries you won’t be adapting pixel by pixel, instead column by column, an interesting way to achieve a responsive layout. I really like this concept, this solution will let you quickly and easily create new layouts for any viewport width and that is something to shout about.

960 LESS

960 Grid Adaption

David Turner, a good friend and very talented developer has adapted the popular 960 Grid system to take advantage of LESS. This is what he has to say about it:

960 LESS is an adaption of the 960 Grid System available at http://960.gs. This adaption is done to make use of LESS Mixins to, in theory, allow for less code to be used in the creation of a site. The flexibility of the mixins allows for pretty much any grid system to be usable, with margins of 2% per column. This allows, in theory, 2, 3, 4, 5, 6, 8, 10, 12, 15, 16, 20, 24 or more columns to be used without having to create excessive amounts of code.

One great benefit of this adaption is how quick and painless it is to define how many columns an element takes up, thanks to the use of LESS mixins. Have a look at the code below:

.grid_1{
    .grid(24,1);
} 

.grid_2{
  .grid(24,2);
}

.grid_3{
    .grid(24,3);
}

If we look at .grid_1 we see that it calls in the mixin .grid() and passes in two values; the first being the total number of columns you want in your grid (24) and the second, how many columns you want the element to take up (1). So with this mixin you can quickly define how much space an element will take up with a quick change of the second value! A simple but well executed idea!

David includes additional options you’d expect to find, such as the prefix, suffix, alpha and omega elements, all familiar to anyone who has used the 960 Grid System before. He also notes that you are not limited to the CSS which has already been defined, that you can customise it and gives the example of creating a half-column by making use of decimals. This revised version of the 960 Grid System, gives you a highly customisable grid and requires minimal effort to make changes.

Semantic.gs

Semantic Grid System

This by far is my favourite grid system. It does not rely on unsemantic classes in the markup, meaning there is not going to be any irrelevant classes, like I described earlier. LESS variables allow quick changes to the main layout as you can see below.

@column-width: 60;
@gutter-width: 20;
@columns: 12;

To create a percentage based layout we just need to define the @total-width variable like so:

@total-width: 100%;

To create a responsive layout, you would write the following:

article {
   .column(6);
}
aside {
   .column(6);
}

@media screen and (max-width: 960px) {
   article {
      .column(12);
   }
   aside {
      .column(12);
   }
}

This method makes much more sense to me than using classes in the markup. You can quickly see how many columns an element is using and can therefore work out that the first article takes up half of the grid and using media queries it is then set to use all of the columns in the grid. I’m leaning towards this as my grid of choice for Responsify.it, but I will have to look at how well this would work, if at all, with writing CSS dynamically with PHP.

Conclusion

All of these solutions have their benefits and will all do a great job of providing you with a great foundation to start building web pages. It all comes down to personal preference on the following areas:

  • Do you want a fixed or fluid grid?
  • The level of customisation you require.
  • How quick and easy it is to get up and running.
  • How much you care about Semantics

Choosing a grid system for Responsify.it will require a lot of thought and I am still considering coming up with my own solution.

References

Posted in Design

Creating order through grid focused design

Posted on by KrooKedUK

I think almost all designers will be aware of the use of grids in design, whether or not they utilise this method of presenting information is a different matter altogether. It is interesting to note that the application of designing to a grid only really came in to play in the early twentieth-century; beforehand information was presented in basic 1 column or 2 column layouts, you could argue this is a very basic form of grid, which I suppose is true, but this method gave no consideration to the precise measurements that we are familiar with in today’s grid systems.

The Art movements during the early twentieth-century—futurism, dadaism, surrealism, constructivism, suprematism, and expressionism had an impact on the development of the grid as we know it today. At the time all artists were embracing the new industrial age and together were trying to reflect this new period which introduced faster travel and communication, similar to what we are doing today thanks to the extremely socialised world we now live in.

These designers/artists recognised the power of words and set aside previous print notions in favour of being more expressive and began experimenting with type at opposing angles, using type in varying sizes; using drawn, abstracted letterforms; and sometimes ignoring the vertical and horizontal nature of type altogether. This seems to completely go against the concept of the grid, but thanks to this disorder it gave the opportunity to de Stijl, the Bauhaus, and typographers like Herbert Bayer and Jan Tschichold, to bring back some harmony and organisation to the chaos.

It’s interesting to see how the development of grids came about by breaking all previous rules and then realising that to effectively communicate through design you have to create some order for the content. If they didn’t take this approach I believe design today would be very boring; designers back then needed to experiment and go wild in order to come up with new techniques and ways of displaying content, which could then be applied to a grid.

Ordering Disorder – Grid Principles for Web Design

I purchased Vinh’s book on the recommendation of the Standardista’s and I can see why. It covers everything from the Concept, Process and Execution. The book has a great layout with generous margins for the content to breathe, at 177 pages it doesn’t take long to read, especially since a lot of pages in the Execution chapter are mainly just page layouts.

Obviously I’m not going to cover the whole book, and by that I mean I’m not going to try and summarise it either, instead I will pick out the pieces that I found most interesting and useful.

The purpose of the book is to show us how the grid applies to digital media and Vinh does a great job of this by walking us through the creation of a fictional site Designery.us.

Benefits of Typographic Grids

In Chapter 2, Concept, Vinh gives us a list of the major benefits of designing with a typographic grid.

  • Grids add order, continuity, and harmony to the presentation of information.
  • Grids allow an audience to predict where to find information, which aids in the communication of the information
  • Grids make it easier to add new content in manner consistent with the overall vision of the original presentation.
  • Grids facilitate collaboration on the design of a single solution without compromising the overall vision of that solution.

Vinh makes the point that for some designers the idea of using a grid would restrict their design and hamper their creativity, which over time has been proven to be false and states that now a large proportion of experienced designers have embraced grids. To make his point he quotes the designer Ellen Lupton who said:

“To say a grid is limiting is to say that language is limiting, or typography is limiting.”
Ellen Lupton 2009

Vinh then likens grids to a springboard for creativity, which are a foundation through which we solve problems.

This section of the book perfectly describes me a couple of years ago. I was of the opinion that using a grid would limit my creativity, I suppose the only reason I can give for this is that I had never tried designing to a grid and didn’t know how to, or what to expect, unfamiliarity can be a dangerous thing. I don’t have a problem saying that back then I was naive in the way I perceived design. I think for many of us, we form ideas ideas about things before giving them a chance and trying them out.

Principles to keep in mind

Vinh outlines some principles that we as designers should keep in mind:

  • A grid should focus on problem solving first and aesthetics second.
  • A grid is a component of the user experience.
  • The simpler the grid, the more effective it is.

The first point is fundamental, I’d take a bet any day that the aesthetics of a site very rarely register in most users heads, instead they care much more about achieving a certain task effectively and easily. We can create this experience by carefully considering every possible interaction on the page and how these relate to each other, which is made much easier by utilising a grid.

This post does not cover any technical aspects of designing to a grid as I will cover that to some degree in a future post. Writing this post has made me even more curious about what can be achieved with grids and more importantly the types of grids we can create by using Mathematical Formula. It’s definitely something I am going to continue to research as I am considering creating my own fluid grid, or modifying an existing grid to use with Responsify.it.

References

Posted in Design

Getting to grips with GitHub

Posted on by KrooKedUK

As promised in my previous blog post I will be taking a look at GitHub. Like I mentioned before I have heard of GitHub and understand its purpose but that’s about it, I find the concept slightly confusing, so hopefully I will have a better understanding when I finish researching and trying out GitHub.

What is Github?

Well one thing I do know is that it’s a repository for the version control system Git. Here are the definitions given on the Github Homepage:

git
Git is an extremely fast, efficient, distributed version control system ideal for the collaborative development of software.

github

GitHub is the best way to collaborate with others. Fork, send pull requests and manage all your public and private git repositories.

Ok so those two definitions make sense but they don’t give any insight on how to use them, but I figure the best way to get to grips with something like this is to try it out. Luckily there are plenty of resources available for newcomers. I’m going to stick to the basics as I believe that’s all I need to get up and running and I can learn more as I need!

There are a few advantages to using Git over SVN

  • You can work offline in Git, although obviously push or pull to a remote server will not work
  • Git is a lot faster than SVN
  • Git takes up a lot less space than SVN
  • Finally you can push and pull to more than one server

How to set up Git

So obviously since GitHub relies on Git I better go and download it. You just install it like any other application, but it doesn’t to act like any other application, there is no GUI, it relies on the command line, or terminal to us Mac folks, hardcore! This didn’t put me off as I knew the GitHub team had created a very nice Mac App with a very nice GUI, which as far as I can tell offers most of the features/functionality I need.

I will cover this in more detail as I am not a huge fan of using Terminal (yet). I am going to use the Mac App for a while but I wanted to get Git setup and ready to use with GitHub incase I change my mind!

So once I installed Git I wanted to check if the install went ok, the easiest way to do this was to open Terminal and type in the following:

$ git

This is what I saw:

The most commonly used git commands are:
   add        Add file contents to the index
   bisect     Find by binary search the change that introduced a bug
   branch     List, create, or delete branches
   checkout   Checkout a branch or paths to the working tree
   clone      Clone a repository into a new directory
   commit     Record changes to the repository
   diff       Show changes between commits, commit and working tree, etc
   fetch      Download objects and refs from another repository
   grep       Print lines matching a pattern
   init       Create an empty git repository or reinitialize an existing one
   log        Show commit logs
   merge      Join two or more development histories together
   mv         Move or rename a file, a directory, or a symlink
   pull       Fetch from and merge with another repository or a local branch
   push       Update remote refs along with associated objects
   rebase     Forward-port local commits to the updated upstream head
   reset      Reset current HEAD to the specified state
   rm         Remove files from the working tree and from the index
   show       Show various types of objects
   status     Show the working tree status
   tag        Create, list, delete or verify a tag object signed with GPG

Now that Git is setup I need to create an account on GitHub.com. The next step is to set up SSH keys, to allow my computer and GitHub to transfer data through a secure connection. There is a great help section provided on the GitHub site which I found very useful.

Using the GitHub App for Mac

I decided that I would give the GitHub application a go and see how I get on with it, I admit I have a thing for well designed apps!

Installation done, account details entered. Now to create a Repository for my Major Project. It couldn’t have been any simpler, all I had to do was click the New Repository button on the lower left and up popped the window that you can see below. I entered in the name and located the folder I wanted to use, leaving out the description which is optional and can be added at a later date. I unchecked the ‘keep this code private’ box as I will not be paying for an account.

I was then taken back to the main window and the repository was now added to the list. Clicking the arrow on the repository revealed the history, changes, branches and settings.

Above you can see the history relating to the repository in this case the addition of a style.css file, a README file and a rule to ignore .DS_Store files which flag up to be committed when a new folder is created.

When any changes have been made to any of the files on the MajorProject folder, it will flag them here and ask me to commit them. I have two options, I can go with commit (offline) or commit and sync which pushes the changes to GitHub.

Thoughts on the GitHub App

I’m sure many people out there would wonder why I would want to use an application which surely would be a much slower way of doing things, but that’s the problem, for me using the application would be much quicker than having to type out commands that I have to keep looking up online. I’m not saying I will never use Terminal but for now I am happy to learn all of the fundamental concepts and get used to working with a different mindset.

The app itself is excellent in terms of the UI, it’s gorgeous. It’s very straightforward to use and the designers have done a great job of creating content focused layouts and a well thought out task flow, between all of the key features like history, commit and branches. The only negative is that it is quite buggy, although that could be be due to me doing things wrong. I do think error messages could be a little clearer in describing what went wrong, but overall it’s very impressive and will do the job perfectly for me until I am ready to jump ship and use Terminal.

To Sum Up

I am glad that I took the time to play around with GitHub as I have a much better understanding of how everything works (committing changes, pull requests etc.) and the fundamental concepts behind version control and how beneficial it will be for me to use for my Major Project in terms of having an online backup, being able to roll back any changes and the option to use people’s pull requests, if they wish to contribute to what I’m working on. I can definitely see myself using GitHub in the future for other projects, the only thing stopping me before was that I thought it would negatively impact on my workflow, but this is definitely not the case.

References

Posted in GitHub, Major Project

Generating dynamic CSS using PHP

Posted on by KrooKedUK

This will be the core technique powering Responsify.it. The CSS styles have to be generated on the fly according to the options selected, this means I have no other choice than to involve PHP or Javascript. It was an easy decision to rule out Javascript, simply because it would result in either messy markup or CSS.

Thankfully PHP will allow me to keep the markup and CSS files free from any unnecessary code, thanks to it doing its thing on the server and spitting back a nice clean CSS file as the output, unless I do something wrong.

Let the server know what we are doing

The server is sitting there doing things exactly as it should, but we are about to change things up a little and tell it to do some things it normally wouldn’t, exciting! We are utilising the all powerful .htaccess file and pasting in the following code:

  <FilesMatch "\.css$">
  SetHandler application/x-httpd-php
  </FilesMatch>

This tells the server the it’s alright to have PHP in our CSS files, it basically treats them as PHP files. In any of our CSS files we now need to include the following line of PHP:

<?php
   header("Content-type: text/css");
?>

This tells the PHP to output the contents as CSS. That’s the setup finished, now it’s time to experiment.

So what’s possible?

Let’s have a look at something basic.

<?php
   header("Content-type: text/css");
   $block-width = 25;
   $block-margin = 5;
?>

As you can see above we can declare variables as normal. You can output these values as you would expect, shown here:

#block {
    width: <?php echo $block-width;?>%;
    margin: <?php echo $block-margin;?>%;
}

Below is what the CSS will look like when it’s sent to the browser. No-one will ever know that you are writing dynamic CSS using PHP.

#block {
    width: 25%;
    margin: 5%;
}

This is a very basic example, but what you can normally do with PHP you can do here, just treat it like writing a normal PHP file, because essentially that’s what it is. I am looking forward to experimenting more with this technique as it really has no limits.

References

  • SteveST, Serving Dynamic CSS with PHP, Steve ST’s Blog [Steve ST's Blog | The Most Stevest Blog on the Web]. Available at: http://stevest.com/2011/serving-dynamic-css-with-php/
  • Posted in Design

Vertical Rhythm – Making Type Sing

Posted on by KrooKedUK

Up until recently I hadn’t been giving any attention to the vertical rythym of my designs. That’s not to say that I never altered the line-height or margins of my type, but what I did not do was calculate these, instead using my own instinct and how much spacing I thought there should be. This didn’t result in some disastrous piece of work, but now that I am setting my type to a baseline grid I notice it creates a different feel and flow to the content, one that is pleasing, but it’s hard to say why. It could be because we are creating content which does not change unexpectedly, we are creatures of habit after all.

Below is an explanation of what Vertical Rhythm is from the 24 Ways article – Compose to a Vertical Rhythm.

On the Web, vertical rhythm – the spacing and arrangement of text as the reader descends the page – is contributed to by three factors: font size, line height and margin or padding. All of these factors must calculated with care in order that the rhythm is maintained.
Richard Rutter

So we can see that it boils down to spacing, which is true of everything in design, essentially we are just moving and spacing elements around. OK, so vertical rhythm is important, but how do we achieve this? Simple, by creating and utilising a baseline grid. This involves some Math; saying I’m not fond of Math would be a great understatement but I don’t find this task tedious at all, it’s very easy.

Next I’ll cover the process I took when creating a Baseline Grid for my blog.

Setting type to a Baseline Grid

The blog post – How to Set Up a Baseline Grid by Joshua Hibbert is excellent at explaining this and is where I learned how to create a baseline grid instead of relying on Baseline grid calculators.

I will be using ems as I believe setting type with pixels isn’t a good practice, but I do include the pixel values as a reference to help with the calculations. You will see what I mean when you read on.

body {
    font-size: 100%;
}

Setting the font-size to 100% means we are using the browser’s default size which is 16px. If you wanted 12px you would set the font-size to 75%. To work this out you take the base size (16px) and divide it by the target size (12px) and multiply it by 100 to get the percentage: 12 / 16 = 0.75 * 100 = 75. Next I chose the font sizes I would like to use, which are 16, 18, 21, 24, 36 and using the same formula as above created these values in ems and ended up with the following:

h1 {
    font-size: 2.25em; /* 36 / 16 */
}

h2 {
    font-size: 1.5em; /* 24 / 16 */
}

h3 {
    font-size: 1.3125em; /* 21 / 16 */
}

h4 {
    font-size: 1.125em; /* 18 / 16 */
}

h5, h6 {
    font-size: 1em; /* 16 / 16 */
}

Adding the pixel values in comments helps serve as a quick reference if you need to change things in the future. So that’s the font sizes sorted, but you can’t just declare any old line-height or margins or you will break the vertical rhythm, instead you must use the same formula again to calculate these values.

For most text the line-height should be roughly 1.5 times the font-size for optimal readability, so we perform the following calculation: 16 * 1.5 = 24. Now we have our line-height we want to convert it to an em value. Using the same formula as we did to convert or pixel values to ems we can see the line-height is 1em. We can do the same to work out the margins. You’ll notice I have doubled up the line-height for the h1, this is just to give it a little more room to breathe.

h1 {
    font-size: 2.25em; /* 36 / 16 */
    line-height: 1.333333333333333em; /* 48 / 36 */
    margin-bottom: .6666666666666667em; /* 24 / 36 */
}

h2 {
    font-size: 1.5em; /* 24 / 16 */
    line-height: 1em; /* 24 / 24 */
    margin-bottom: 1em; /* 24 / 24 */
}

h3 {
    font-size: 1.3125em; /* 21 / 16 */
    line-height: 1.142857142857143em; /* 24 / 21 */
    margin-bottom: 1.142857142857143em; /* 24 / 21 */
}

h4 {
    font-size: 1.125em; /* 18 / 16 */
    line-height: 1.333333333333333em; /* 24 / 18 */
    margin-bottom: 1.333333333333333em; /* 24 / 18 */
}

h5, h6 {
    font-size: 1em; /* 16 / 16 */
    line-height: 1.5em; /* 24 / 16 */
    margin-bottom: 1.5em; /* 24 / 16 */
}

Setting type to a baseline grid isn’t at all hard and the small amount of work you have to do results in content which has a nice flow and is made easier and more enjoyable to read. I would say that’s worthwhile to do that little extra bit.

Of course it doesn’t stop with the type, all other elements on the page will affect the vertical rhythm. Robert Bringhurst puts this well in his book – The Elements of Typographic Style when he writes:

Headings, subheads, block quotations, footnotes, illustrations, captions and other intrusions into the text create syncopations and variations against the base rhythm of regularly leaded lines.
These variations can and should add life to the page, but the main text should also return after each variation precisely on beat and in phase. This means the total amount of vertical space consumed by each departure from the main text should be an even multiple of the basic leading. If the main text runs 11/13, intrusions to the text should equal some multiple of 13 points: 26, 39, 52, 65, 78, 91, 104 and so on.

If we adhere to these principles we can create type which takes on the characteristics of music, we can almost make it sing to the reader.

References

Posted in Design
← Older posts