If you want to compete in today’s recession-crippled job market, you can’t just be good… you have to be great. Otherwise move over, because a great designer will always be there to snag your dream job.

Experience ? Greatness

Experienced designers are often asked by aspiring designers for tips to rapidly improve their design skills. Surely there’s got to be some secret technique or trick of the trade, which can accelerate your designs from good to great. Not surprisingly, most designers will tell you this is not the case. By and large people seem to agree that the only way to become great at anything is through gaining experience over time. That’s why most job postings require a minimum amount of experience to qualify.

I disagree with this notion; I believe what really makes you great is your ambition and devotion to self-betterment, not your experience. If experience were all that mattered, then older designers would always be better than their younger counterparts, and this is far from the case.

Your time in the game doesn’t matter half as much as how hard you work. While it’s true that becoming a flawless design god doesn’t happen overnight, the amount of experience required depends on how hard you work to become better. There are methods for accelerating your growth and talent at a faster rate, to becoming great much faster than traditional knowledge dictates. You don’t need “five to ten years experience” to become the best. You just need a clear methodology for consistently developing and finessing your skill set. The top 10 tips to quickly become an amazing designer are:

1. Look at Great Design – Constantly.

If you want to be a great designer, then you should always be on the lookout for great design. Start a comprehensive design collection for inspiring and educating yourself. Browse through the design books and magazines at your local bookstore, buy or subscribe to the ones you love, and start your own design literature collection. There’s nothing quite like the experience of paging through a kick ass design book for the first time. It is a wonderful and tactile experience and it’s sure to put you in the mood to create something great.

Of course the internet is a cheaper and more direct resource to look at great design. Follow design blogs, such as: Smashing Magazine, Web Design Ledger, DesignM.ag, The Design Cubicle, Spyrestudios, where design inspiration galleries are consistently posted. Browse the online portfolios of artists/studios that you admire. Join and peruse the popular online communities like Behance, Coroflot, and Deviantart, where you can view the work of fellow artists.

Also, when you’re out and about in the real world, don’t forget to take notice of all of the great designs surrounding you. It could be the environmental design of your local movie theater, the amazing wall signage at the Gap, or a really cool birthday card you just received. There’s wonderful design everywhere you go, design that’s invisible to most on a conscious level. As a designer however, you should take notice of it, analyze it, and scrutinize it whenever you can.

Now that you’re consistently looking at great design, the next step is start collecting it. The books take care of themselves, but for everything else, start a design scrapbook. Cut out and keep all of the great designs that you find in magazines, brochures and other printed pieces. For anything you find online, start a digital scrapbook, saving screenshots of all work that you love. Evernote is a great tool for this. It allows you to pull text and images from anywhere online and store them in an online notebook for later reference. And when you’re out on the town, don’t hesitate to whip out the cell phone, and take a snap shot of any design that strikes your fancy.

Observing and collecting the great design that’s all around you will help your work stay relevant while inspiring you to get better.

2. Copy! Copy! Copy!

Now that you have a collection of great design, the next step is to COPY YOUR HEART OUT! This is one many will likely disagree with. Many people suggest not to directly copy work, but instead to be inspired by it, to create something original. After all, copying is dishonest. And besides, you won’t learn anything. Right? Wrong! Ironically enough, when it comes to design and other creative pursuits, copying is an integral part of the learning process. I’m not suggesting that you copy all of your work out of a book. That’s absurd. Use copying, only as a learning exercise for acquiring new skills.

First, choose a design that you absolutely love, and challenge yourself to replicate it identically from scratch. The purpose of this exercise is to expose you to new techniques and possibilities that may not have been on your radar before. At the very least, you’ll learn some new Photoshop tricks, become acquainted with a new design trend, or stumble upon a new keyboard shortcut, as you attempt to reproduce someone else’s work. Do this multiple times, and you’ll find that you gain some new technical skills each and every time. After you’ve successfully reproduced a few designs, begin to loosely copy them instead, while bringing in some of your own technique. This will help you understand how to implement these new skills into your own workflow.

Another great practice is examining how other designers build things. Open up their Photoshop, InDesign, or Illustrator files, or read through their code. Another option is to flat-out ask them how they did it.

You will undoubtedly gain priceless knowledge from replicating other peoples’ great design, staying current by familiarizing yourself with the latest trends while adding an ensemble of great techniques to your own design arsenal.

3. Dissect Great Designs

So you’ve collected great designs, and you’ve copied them to a “T”. The next step to becoming great is dissecting those designs. While copying teaches you technique, dissecting builds your understanding of design theory.

For starters, choose a piece of work that you really like. Ask yourself, why is this good? What draws me to it? What aesthetic principles are employed successfully? What design rules are enforced, what design rules have been broken? What effect do the colors have on the design? What artistic style or cultural indicators are used? How about the typography? Photography? Negative Space?

At first, you won’t understand what makes it good, or why you like it. You must work to understand the aesthetic rationale behind the great designs you love. What components are working together to make this design great? If you figure this out for each and every great design you see, you’ll have a solid foundation of priceless knowledge on what works and why. You’ll have gained a true understanding of sophisticated design theory, from which to base future decisions on. You’re one step closer to being great.

4. Use original materials whenever possible

Have you ever looked at a brochure or browsed through a website and noticed generic, contrived, and lame stock photography? How did that make you feel about the design? The major drawback of stock is that (unless carefully chosen) it can have a cheapening effect on your work.

There’s no doubt that stock photos and stock art have their place and are often necessary depending on budget and time constraints. But whenever possible, you should use originally created materials when designing. There’s nothing quite like custom illustrations, hand-rendered type, or original photography. It generates prestige and authenticity in your designs. Anything custom-created will always fit like a glove. It will be exactly what you intended each and every time. The alternative is trying to retrofit your concepts onto previously produced materials. Keep your designs warm and authentic whenever possible by using original materials.

5. Network Online—Follow the Design Communities

Gone are the days when niche information was hard to come by. Nowadays, no matter what your industry is, there’s probably at least a blog or two out there covering it. In the case of design, there are literally hundreds! The benefits of following these blogs are endless. News, editorials, inspirational galleries, resources, tutorials, interviews, are all at your disposal and available for free! I can’t think of a sweeter deal than that. So follow the design community online, and start tapping into this limitless resource to improve as a designer.

To get your feet wet, get yourself an RSS feed reader. I recommend Google Reader, but there are many to choose from. Now simply begin subscribing to design blogs you’d like to follow. Here’s a great list to start you off. Explore these amazing resources and learn everything you can. All of this great content is only half of the overall value, however. Contributing to the community is equally rewarding. Leave comments on blog posts where you have valuable input, or begin writing your own guest posts on your favorite blogs. You might even consider starting your own blog to get your voice out there.

After joining and contributing to the online design community, you’ll begin making friends and connections that will benefit you both professionally and personally. You’ll meet other great designers who have a lot to teach you, and you’ll have a lot to teach them. You might be able to collaborate with others on designs and projects, give or receive references, or provide services to each other. The possibilities are endless.

Through following and contributing to the online design community you’ll tap into a priceless collection information and forge friendships and networking opportunities that will surely help you on your path to become a great designer.

6. Be Competitive – Out Think and Out Work Your Competition

Although it is important to embrace the design community and contribute graciously, don’t forget that you’re also competing with other designers to pay the bills. There’s nothing wrong with a little healthy competition. Competition forces you to become better and to push your boundaries.

Think of someone you know who’s really good at something. It could be anything: poker, sales, sports, or designing. Do they take pride in it? If you think for one minute that they didn’t make a conscious effort to become really good at it, you’re wrong. The truth is that people don’t just happen to become experts, and it’s not just natural talent that gets them there either. They got there, because they wanted to be better than the rest. They made up their mind and were willing to work harder than others. They simply wanted it more.

There’s a method for becoming competitively good. First, become determined to be better than someone else. This could be your classmates, colleagues, or actual competitors. Make notes of their strengths and weaknesses. Then learn from them. Once you’ve pinpointed what they do good, make an effort to do it equally as good. Make sure to keep this goal in perspective though. Be mindful of competitors, but don’t obsess over them. If you’re consistently focused on improving, you shouldn’t have to.

Don’t be afraid of the competition; as they say, “competition drives innovation.”

7. Find a “Design Buddy”

Having a “design buddy” or “design mentor” can be a great way to grow and improve as a designer. Having discussions/critiques with another designer, collaborating with them on projects, or simply bouncing ideas and concepts off of each other are mutually beneficial exercises. This collaboration will help expose you to different ways of thinking. This person will have their own set of opinions, tastes, and biases, and will keep your perspective fresh.

It’s also great to have someone around to hold you and your work accountable. Accountability is imperative when improving yourself; it helps to keep your ego in check by keeping an objective eye on your work and ideas.

8. Specialize

Many designers claim that in order to stay competitive, it’s important to provide the large selection of services typically offered within the industry. To do this, having a broad range of diverse skills is necessary. This is certainly true to some degree.

I believe, however, that it’s equally important to have a core competency. After all, why is anyone ever going to choose you if nothing that you do is unique? Specializing in one area or another helps you shine. Play off of your natural talents and inclinations, and develop your specialty.

For example, some designers are great at creating playful vector characters with tons of personality; others are amazing photo-manipulators who create incredible conceptual imagery. Some designers love playful hand-drawn type treatments and fluffy ornaments; others prefer a crisp clean minimalist style. Own your style. Don’t shy away from it, embrace it and show it off to the world. Practice and improve on your specialty constantly. No matter how good you are at something, you could always be better.

Diversification is important, but why spend most of your time on something, if you only have the potential to become mediocre at best? Instead, focus that energy on getting even better at what you do well. Your specialties are your identity; they’re what make you extraordinary.

9. Do real work

There’s an ancient Chinese proverb that goes “I hear and I forget; I see and I remember; I do and I understand.” This is so true. No amount of research or online tutorials is going to make you a great designer. Knowledge alone is useless, because until you’ve actually applied it, it’s simply an abstract idea in your head. It’s only after you’ve applied it that you truly understand it. So then, if you really want to become a great designer, you have to design a lot!

There’s no reason why designers should learn all of their skills on tutorials or class projects. Get out there, and get your hands dirty. Take on real-life jobs, and do them to the best of your ability. If during a job, you need to know how to do something new, then simply research it and then do it. It’s as simple as that! Google is your friend, and there’s not too much information that’s more than a “Google” away.

The best part of this “learn as you do” strategy? You walk away from all of your projects, a better designer than when you began. Now here’s the clincher… do it again, and again, and again! You’re learning while you make money! That’s a pretty good feeling.

If you can’t find paying work, do pro bono stuff to learn. Your cousin’s wedding invitation, a local band’s album artwork, or a website for a local non-profit, are all great examples. Craigslist is a great place to start when searching for low pay or charity work for experience. You’re getting your name out there and building a reputation for yourself, but the most important thing is that you’re actually learning and improving! The more you do, the faster you’ll get better!

10. Always Do Your Absolute Best—Push Your Limits

It’s easy to half-ass something to just get it done, especially if you’re under a pressing deadline or on the verge of an “all-nighter”. But for the great designers out there, the opposite is actually true. When you take unwavering pride in your work, it’s hard to deliver something in haste that doesn’t reflect your true potential. It’s difficult to put your name on something that could have been much better with a little more effort.

If you want to be a great designer, you have to develop a sense of pride in everything you do. Realize that your reputation and career are at stake, and hold yourself to the high standard of always doing your best while pushing the limits of your own potential. Be your own harshest critic. Make all of your work as good as you humanly can, and then force yourself to do even better. Accept nothing less.

As you progress, take a look backwards at your older work. If you’re developing at a steady pace, then progress should be crystal clear. As an exercise, rip apart your old designs where you see flaws and make them better. Seeing flaws in your old designs is a great sign, because it means that you’re learning and improving.

Reference high-end design work from notable studios or designers whom you admire. Strive to become as good as these top players. Always put forth your best work and maintain high standards; it’s essential to self improvement and to becoming a great designer.

Some people may not agree with this last point because they see perfectionism as a hindrance. After all, perfectionism can lead to missing deadlines and scope creep on projects. This much is true. So in fairness, always do your absolute best within reason. Take into account any constraints such as deadlines, budgets, and overall importance of projects. Keep things in perspective, but generally speaking, always try to do your absolute best by pushing the limits of your potential.

BONUS: Tip 11. Exploit Your Own Weaknesses

Every designer has things that they excel at, and other things that they don’t. For instance, maybe you’re an incredible layout designer in Photoshop, but frontend coding just isn’t your thing. Or maybe your illustrations are unmatched in their sophistication and beauty, but your typography skills are underdeveloped and leave much to be desired.

This is nothing to be ashamed of. After all, everyone has strengths and weaknesses; it’s not a bad thing it’s just a fact of life. What isbad however, is not acknowledging these weaknesses by either ignoring them, or worse yet denying their existence altogether. Some people deny their weaknesses because they feel like they lack the potential for improvement. Or perhaps they’re just being lazy and don’t want to invest the time and energy necessary for improvement.

Whatever the case may be, these are ultimately just excuses that get in the way of what needs to be done. Weaknesses should not be ignored, because other people do notice and will exploit your weaknesses when competing against you. Because of this, weaknesses can take a very real toll on your work and career. They might be pulling-down your self-confidence, stopping you from winning jobs, or holding you back from getting that promotion you desire.

Here’s the good news: you DO have the potential to improve on your weaknesses. You are constantly growing as a designer and a person and as a result, your self-standards are constantly being raised. The fact that you’re aware of this means that you’ve got what it takes to improve. The trick is to focus your energy where you know you need it most.  Take the time to focus on that gaping hole in your skillset, instead of gracefully dancing around it. Force yourself to attempt the skill in question, instead of finding creative methods to avoid it. The result might not be ideal, but every time you do it you will improve. By preemptively exploiting your own weaknesses, you can focus your efforts on strengthening them.  You can turn them into one of your strengths, or at the very least become adequately proficient at them.

Instead of running away from your weaknesses, embrace them. Sure at first it will be tough. But if you think back far enough, I’m sure you can remember a time when what you do best was tough. Everything is hard before it’s easy. Make the time to pursue your weaknesses and you will see a definite improvement as a designer.

The post 10 Essentials Tips to become a Great Web Designer appeared first on Kruger David.

KISS – Keep it Simple Stupid

The simplest explanation tends to be the right one.

In the late 19th century, physicists struggled to explain how gravity, magnetism and optics interact, when it comes to large distances – like the distances in our solar system. Hence, a medium named aether was postulated. It was said, that light is traveling through this medium, and that it’s responsible for effects that couldn’t be explained otherwise. Through the years, the theory was expanded with assumptions that adjusted the aether postulate to the results of experiments. Some assumptions were arbitrary, some introduced other problems, and the whole theory was quite complex.

An employee of the swiss patent office, Albert Einstein, suggested to get rid of the whole aether theory when he introduced a simple, yet revolutionary idea: All the oddness in calculating with large distances would fade away if we’d accept that time is not a constant; it’s relative. This incredibly of out-of-the-box thinking to come to the simplest explanation with the fewest assumptions to select between competing scenarios is referred to as Ockhams’s Razor.

There are similar concepts in many areas. In software development (and others), we refer to it as KISS. There are many variants for this acronym, but they all mean that you should strive for the simplest way of doing something.

HTTP

The Hypertext Transfer Protocol is widely considered to be a perfect example for a simple solution: designed to transfer hypertext based documents, it is the backbone of highly interactive and desktop-esque applications nowadays. Maybe we have to find solutions for limitations in the protocol, and maybe we have to replace it someday. However, status quo is: based on a few request methods (like GET and POST), status codes and plain text arguments, HTTP has proved to be flexible and robust. That’s why HTTP has been repeatedly pushed to the limits by web developers – and is still standing.

We take this approach for granted, but the history of software development and standardization is full of overly complex and half-baked solutions. There’s even a dedicated made-up word for it: bloatware. Software like this is also described to be DOD, dead on arrival. I have a theory that is very similar to my theory of unDRY code, when it comes to bloatware … However, the success of the internet can be described as a success of simple, yet efficent solutions.

So what’s required to come to the simplest solution possible? It all comes down to maintainability and comprehensibility in software development. Hence, KISS kicks in during the phase of requirements engineering. When you think about how to transform a client’s requirements to implementable components, try to identify the following parts:

• Functionality that has an inappropriate ratio between benefit and efforts.
• Functionality that is highly dependent on other functionality.
• Functionality that is likely to grow in complexity.

There are many people involved in the conceptual process, who do not have the technical expertise to make a reliable cost-benefit analysis

I was once working on a project, where the client wanted to import Excel spreadsheets into his crew management software. This was a clear match. Excel is a proprietary software with a complex document format. The format is complex, because it’s feature-rich: You can add graphs and other things to it – features that were not needed by the client. He was simply interested in the numbers. Thus, implementing the Excel import would require the implementation of a lot of unnecessary functionality. On top of that, there are multiple versions of Excel versions, and Microsoft fires off another release each year. This would have been hard to maintain, and it comes with additional costs in the future.

We ended up implementing a comma-separated-value import. This was done with a few lines of code. The overhead of the data was really small (compare an Excel sheet to it’s CSV equivalent) and the solution was maintainable and future-proofed. Excel was ready to export CSV anyway (as well as other programs that the client might want to use in the future). Since the solution was low-priced as well, it was a good application of the KISS principle.

To sum up: try to think out-of-the box if a task looks complicated to you. If someone is explaining to you his requirements, and you’re thinking that it’ll be tough and complex to implement, you’re right under almost any circumstances. While some things are just that – hard to implement – overcomplicated solutions are quite usual. This is the case because there are many people involved in the conceptual process, who do not have the technical expertise to make a reliable cost-benefit analysis. Hence, they don’t see the problem. Double-check the requirements whether they are really stripped down to the essence that the client needs. Take the time to discuss critical points and explain why other solutions might be more suitable.

The post 3 Key Software Principles you must understand, Part 2: KISS appeared first on Kruger David.

What’s true for love, is true for code. The fundamental things will always apply. If you have an understanding of the underlying ideas of software development, you will quickly adjust to new techniques. In this article, we will discuss about the first of the three basic principles and mix them with many more.

DRY – Don’t Repeat Yourself

This principle is so important to understand, that I won’t write it twice! It’s commonly referred to by the acronym, DRY, and came up in the book The Pragmatic Programmer, by Andy Hunt and Dave Thomas, but the concept, itself, has been known for a long time. It refers to the smallest parts of your software.

When you are building a large software project, you will usually be overwhelmed by the overall complexity. Humans are not good at managing complexity; they’re good at finding creative solutions for problems of a specific scope. A basic strategy for reducing complexity to managable units is to divide a system into parts that are more handy. At first, you may want to divide your system into components, where each component represents its own subsystem that contains everything needed to accomplish a specific functionality.

For example, if you’re building a content management system, the part that is responsible for user management will be a component. This component can be divided into further subcomponents, like role management, and it may communicate with other components, such as the security component.

As you divide systems into components, and, further, components into subcomponents, you will arrive at a level, where the complexity is reduced to a single responsibility. These responsibilities can be implemented in a class (we assume that we’re building an object-oriented application). Classes
contain methods and properties. Methods implement algorithms. Algorithms and – depending on how obsessive we want to get – subparts of
algorithms are calculating or containing the smallest pieces that build your business logic.

The DRY principle states that these small pieces of knowledge may only occur exactly once in your entire system.

They must have a single representation within it. Note the difference between the piece of knowledge, and itsrepresentation. If we’re implementing the database connection in our CMS, we will have a code snippet that will initalize the database driver, pass the credentials, and save a reference to the connection in a variable. The code snippet is part of the knowledge, it’s about how something is achieved. The variable with the reference to the connection is the representation of that knowledge – and this can be used by other parties. If the database credentials change, we will have to change the snippet – not its representation.

In a perfect application, every small piece of business logic encapsulates its knowledge in a representation, namely a variable or a class property.
This variable itself is encapsulated in a class that can be described as a representation of a responsibility. The class is encapsulated in a component that can be described as a representation of functionality.

This can be proceeded until we reach the top level of our software project – that is, a stack of representations with increasing complexity. This way of looking at the complexity of software is called modular architecture, and DRY is an important part of it.

Achieving DRYness

There are many ways of achieving DRYness. Hunt and Thomas suggested (among other things) code generators and data transforming. But, essentially, DRY is a philosophy that packages logic into representations.

As every part of your application can be seen as representation, every part exposes specific fragments of your underlying logic: The user management exposes access to registered users of the CMS, the user class represents a single user and exposes his properties (like the username). It retrieves the properties, via the representation of the database.

DRY and modular architecture require good planning. To achieve a representational hierachy from bottom-up, divide your application in a hierarchy of logically separated smaller parts and let them communicate with each other. If you have to manage larger projects, organizing them into components and using DRY within the components is a good idea. Try to apply the following rules:

• Make a visual hierarchy of your software application and map the main components to it. Complex projects may require a dedicated map for each component.
• If you’re arriving at a level of connected responsibilities, you may want to switch to UML diagrams (or similar).
• Before writing a chunk of code, name its hierarchy in your software project. Define what it’s representing, and be sure you know its role in the surrounding component.
• Define what the representation should expose to other parties (like functions to execute SQL in a database driver) and what it should hide (like the database credentials).
• Ensure that representations do not rely on representations of another complexity level (like a component that relies on a class in another component).

The database driver is a simplified example, as there are many more layers involved in the real world (such as a specific database abstraction layer), and there is much more you can do to encapsulate logic – especially diving into design patterns. But even if you’ve just started with coding, there’s one thing to keep in mind:

When you find yourself writing code that is similiar or equal to something you’ve written before, take a moment to think about what you’re doing and don’t repeat yourself.

In the real world, applications that are a 100% DRY are hard, if not impossible, to achieve. However, applications that are unDRY to an unacceptable degree – and therefore hard to maintain – are quite common. Hence, it’s not surprising to learn that more than 50% of all software projects fail – if you’re taking a look at the code.

Many people tend to think that bad code is produced by bad coders. In my experience, this is very much an exception. More often than not, bad code is produced by bad account managers and an overall misconfiguration of process management in companies.

An Example

As an example, say you’re hired as a technical consultant by a company that has problems with code quality and maintenance. You review the source and you see hacks and code duplication – the code is not DRY. This is a symptom of bad code quality, it’s not the reason. If you take a look at the version control system – aka the history of the code – chances are that you may find hacks that were introduced at times near deadlines and milestones. Take the time to review what changes are made, and you will likely be confronted with a change in requirements.

As noted above, DRYness is achieved by good planning. Forced changes on a tough deadline are forcing developers to implement dirty solutions. Once the code is compromised, the principle of DRY is likely to be sacrificed completely upon further changes.

There’s a reason why the most successful corporations in the IT business were founded by people with very good technical understanding – or even coders themself: Bill Gates, Mark Zuckerberg, Steve Wozniak, Steve Jobs, Larry Page, Sergey Brin and Larry Ellison know (or knew) what efforts are needed to implement something. Contrary, many companies tend to lay the requirements for engineering into the hands of account managers, and the conceptual part in the hands of business consultants…people who have never implemented anything.

Hence, many technical concepts work only in Powerpoint, Photoshop, and on 27″ widescreen displays. This may have been a successful approach in the days of, more or less, static websites, but it’s not nowadays – with interactive applications on multiple devices. Because coders are the last in the line, they are the ones who have to apply quick fixes on errors in the concept. If this is accompanied by an account manager, who can’t stand up to a client that likes to make last-minute changes, plans are thrown in the garbage, and something quick and dirty is implemented. The code becomes unDRY.

This example is a bit extreme (nevertheless, I have witnessed such scenarios), but it demonstrates that DRY is a theoretical concept, which is challenged by various parties in the real world. If you’re working in a company that forces you to work in this manner, you might suggest some changes to the process (like introducing technical expertise at an earlier stage of technical projects).

The post 3 Key Software Principles you must understand, Part 1: DRY appeared first on Kruger David.

As good design cannot be measured in a finite way he set about expressing the ten most important principles for what he considered was good design. (Sometimes they are referred as the ‘Ten commandments’.)

Here they are.

Good design is innovative

The possibilities for innovation are not, by any means, exhausted. Technological development is always offering new opportunities for innovative design. But innovative design always develops in tandem with innovative technology, and can never be an end in itself.

The post Rams’ ten principles of “good design” appeared first on Kruger David.

If this is your first install, automatically load on login with:
 mkdir -p ~/Library/LaunchAgents
 cp /usr/local/Cellar/postgresql/9.1.3/homebrew.mxcl.postgresql.plist ~/Library/LaunchAgents/
 launchctl load -w ~/Library/LaunchAgents/homebrew.mxcl.postgresql.plist

If this is an upgrade and you already have the homebrew.mxcl.postgresql.plist loaded:
 launchctl unload -w ~/Library/LaunchAgents/homebrew.mxcl.postgresql.plist
 cp /usr/local/Cellar/postgresql/9.1.3/homebrew.mxcl.postgresql.plist ~/Library/LaunchAgents/
 launchctl load -w ~/Library/LaunchAgents/homebrew.mxcl.postgresql.plist

Or start manually with:
 pg_ctl -D /usr/local/var/postgres -l /usr/local/var/postgres/server.log start

So to crank up Postgres you want me to pass that entire path to launchctl?

Lunchy – “Start your agents and go to lunch”

Thank goodness there’s Lunchy from Mike Perham. Lunchy simplifies the command line interface to launchctl. To get started, install the gem:

$ gem install lunchy

Now we can list all of our agents with ls

$ lunchy ls

at.obdev.LittleSnitchNetworkMonitor
at.obdev.LittleSnitchUIAgent
com.adobe.AAM.Updater-1.0
com.adobe.ARM.202f4087f2bbde52e3ac2df389f53a4f123223c9cc56a8fd83a6f7ae
com.adobe.CS5ServiceManager
com.apple.FolderActions.enabled
com.apple.FolderActions.folders
com.google.keystone.agent
com.macpaw.CleanMyMac.helperTool
com.macpaw.CleanMyMac.trashSizeWatcher
com.macpaw.CleanMyMac.volumeWatcher
com.teamviewer.teamviewer
com.teamviewer.teamviewer_desktop
homebrew.mxcl.postgresql
org.virtualbox.vboxwebsrv

… and start PostgreSQL with:

$ lunchy start postgres

To see the full range of options, just type lunchy with no arguments

$ lunchy

The post lunchy – A user friendly packaging for OS X launchctl appeared first on Kruger David.

I started with a clean system, and the following are the steps that worked for me. If you run into an issue, or find an error in this tutorial, please let me know and I’ll update it.

Step 1: Download and Install Xcode

The Xcode 4.2 download for Snow Leopard is only available to those registered in the $99/year developer program. I confirmed that the latest version of Xcode for Snow Leopard available to me while signed in with a free account is 3.2.6

Go to http://developer.apple.com/downloads and sign in with your Apple ID (the same one you use for iTunes and app purchases).

Search for “xcode” (in the search field on the left), then click on “Xcode 3.2.6 and iOS SDK 4.3 for Snow Leopard”, and click on the the .dmg link to download it. Once the .dmg has finished downloading, it should automatically mount the disk image and open a window in your Finder that looks like this:

Double-click on the “Xcode” package installer. Once the installer launches, make sure all the checkboxes are checked. Click “Continue”, and go through the rest of the installation. If the installation fails, quit the installer, then run Software Update and install any updates that it finds. If no new updates are available, restart your computer and try installing Xcode again. Once Xcode is successfully installed, you can move on to Step 2.

Step 2: Verify that GCC was installed

Launch the “Terminal” application, which you can find in the “Utilities” folder in “Applications”. From now on, you will be copying and pasting (or typing) a lot of commands in Terminal. They will be formatted like so:

$ some command you will run

The “$” appears automatically at the end of the command prompt in Terminal after every command that you run. You will not be copying and pasting or typing the “$”, only what comes after it. After entering the command, you will press “return” to execute the command.

The first command we will run will serve to verify that Xcode successfully installed GCC:

$ gcc --version

If all went well, you should see the GCC version in the output:

i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5666) (dot 3)

Step 3: Install Homebrew

Homebrew, “the missing package manager for OS X”, allows you to easily install hundreds of open-source tools. The full instructions are at https://github.com/mxcl/homebrew/wiki/installation, but you should only need to run this:

$ /usr/bin/ruby -e "$(/usr/bin/curl -fksSL http://ow.ly/aAiPj"

I shortened the URL for the installation script

https://raw.github.com/mxcl/homebrew/master/Library/Contributions/install_homebrew.rb

to allow you to easily copy and paste the whole command.

Once the installation is successful, run the following command:

$ brew doctor

If you get Error: No such file or directory - /usr/local/Cellar, run the following command, which creates the /usr/local/Cellar directory:

$ sudo mkdir /usr/local/Cellar

sudo allows you to run commands as a user with higher access rights, which is why it prompts you for your password, and mkdir stands for “make directory”.

Next, run the command below, which makes you the owner of the /usr/local directory, in addition to all nested directories. This is needed in order to install Git in the next step.

$ sudo chown -R `whoami` /usr/local

chown stands for “change owner”, the -R flag applies this to all nested files and directories, and whoami is a variable that represents your OS X username. You should copy and paste the command above as is.

Run brew doctor again. If you get Your system is raring to brew, you can move on to the next step.

Step 4: Install Git

Git is the version control system of choice among many web developers. With Homebrew, installing Git is as easy as this:

$ brew install git

Run brew doctor to make sure everything is still working. You might get this:

Warning: /usr/bin occurs before /usr/local/bin

If you see that warning, run this:

$ echo 'export PATH="/usr/local/bin:/usr/local/sbin:~/bin:$PATH"' >> ~/.bash_profile

This command takes everything between the single quotes and adds it (>>) to a file called .bash_profile in your user’s root directory (~/). Every time you open a new Terminal window or tab, .bash_profile is called. The export PATH line tells your system to look in /usr/local/binfirst. This is important because Xcode installs an older version of Git in /usr/bin, but we want to use the latest version that Homebrew installed in /usr/local/bin.

Quit and relaunch Terminal, then run brew doctor once more. Your system should be raring to brew now. To verify:

$ which git

You should get /usr/local/bin/git.

Step 5: Configure Git with your Name and Email

$ git config --global user.name "Your Full Name"
$ git config --global user.email "Your Email Address"

Make sure you use the same email address for Git, GitHub, and Heroku. To learn more about Git, check out the various resources tagged with “git” on Pinboard.

Step 6: Install RVM

RVM stands for Ruby Version Manager, and is one of the two most popular tools that allow you to install and manage multiple versions of Ruby on the same computer. The other is rbenv.

$ bash -s stable < <(curl -s https://raw.github.com/wayneeseguin/rvm/master/binscripts/rvm-installer)

Step 7: Load RVM into your shell session as a function

$ echo '[[ -s "$HOME/.rvm/scripts/rvm" ]] && . "$HOME/.rvm/scripts/rvm" # Load RVM function' >> ~/.bash_profile

By placing the script in .bash_profile, it ensures that every time you start a new Terminal session, you will be able to use all of RVM’s commands.

Now that .bash_profile has been modified, it needs to be reloaded. For initial RVM installations, the preferred way to do this is to quit and relaunch Terminal. Otherwise, you can use the following command:

$ source ~/.bash_profile

If all went well, you should see rvm is a function after you run this command:

$ type rvm | head -1

Step 8: Install Ruby 1.9.3

Before you install Ruby with RVM, you should make sure you have the latest version of RVM:

$ rvm get head

You should also read carefully through the requirements after running this command:

$ rvm requirements

According to the requirements, we must first install libksba. This applies to both Snow Leopard. We can do that easily with Homebrew, but first we should make sure it is up to date:

$ brew update
$ brew install libksba

Since Homebrew is updated regularly, it’s advisable to run brew update before installing anything with Homebrew.

Now we’re finally ready to install Ruby 1.9.3! If you’re on Snow Leopard, you need to add a flag to the command (as specified in the RVM requirements):

$ rvm install 1.9.3 --with-gcc=clang

Once Ruby 1.9.3 is installed, we have to tell the system to use it. We can also set it as the default version for new shell sessions:

$ rvm use 1.9.3 --default

To verify:

$ ruby -v

You should see something like ruby 1.9.3p194.

Step 9: Install Rails

And that’s it! You’re all set to go! If you’d like to experiment with Ruby’s syntax, type:

irb
2 + 2

The next step is to install any gems that you require. For example, if you want to work with Ruby on Rails:

$ gem install rails

Then sit back and relax as RubyGems downloads all the Rails-related gems and assembles the documentation. After a few minutes, you should end up with a couple dozen gems installed.

When it’s done installing, verify that the correct version of Rails was installed by typing:

$ rails -v

Rails should answer with 3.2.3 or higher.

Step 10: Install PostgreSQL

$ brew update
$ brew install postgres

Follow the instructions at the end of the install to initialize the DB, add startup items, and start Postgres.

This installs the “pg” gem that Matz himself wrote. It is recommended over the old “postgres” gem.

$ env ARCHFLAGS="-arch x86_64" gem install pg

Some tips after the installation

Fixing the ‘ruby-debug’

$ gem install ruby-debug19
Fetching: linecache19-0.5.12.gem (100%)
Building native extensions.  This could take a while...
Fetching: ruby-debug-base19-0.11.25.gem (100%)
Building native extensions.  This could take a while...
Fetching: ruby-debug19-0.11.6.gem (100%)
Successfully installed linecache19-0.5.12
Successfully installed ruby-debug-base19-0.11.25
Successfully installed ruby-debug19-0.11.6
3 gems installed

So after some research on the internet I found out that the author of ruby-debug had a fix for it which he considered unstable and didn’t push it to rubygems.org yet. Since I prefer an unstable ruby-debug than a non working one, I gave it a try…

First download linecache19-0.5.13.gem and ruby-debug-base19-0.11.26.gem from http://rubyforge.org/frs/?group_id=8883

$ gem install linecache19-0.5.13.gem
Building native extensions.  This could take a while...
Successfully installed linecache19-0.5.13
1 gem installed

and

$ gem install ruby-debug-base19-0.11.26.gem -- --with-ruby-include=/Users/myuser/.rbenv/source/ruby-1.9.3-p194
Building native extensions.  This could take a while...
Successfully installed ruby-debug-base19-0.11.26
1 gem installed

If all went well, you should type and see:

$ irb
irb(main):001:0> require 'ruby-debug'
=> true

The post How to Install Xcode, Homebrew, Git, RVM, PostgreSQL & Ruby 1.9.3 on Snow Leopard appeared first on Kruger David.

One of the most common problems in usability is a lack of focus. In this video, you’ll learn how removing elements, reworking a layout, and even rewriting copy, can bring focus to your page.

The Think Vitamin Membership video library Nick looks at the idea of “focus” in regard to user experience design.

The post UX Focus – Video Tutorial appeared first on Kruger David.

‘Staying out of the way’ means not distracting your users. Rather, good UIs let your users complete goals. The result? A reduction in training and support costs, and happier, satisfied and highly engaged users. When getting started on a new interface, make sure to remember these fundamentals…

1. Know your user

“Obsess over customers: when given the choice between obsessing over competitors or customers, always obsess over customers. Start with customers and work backward.” – Jeff Bezos

Your user’s goals are your goals, so learn them. Restate them, repeat them. Then, learn about your user’s skills and experience, and what they need. Find out what interfaces they like and sit down and watch how they use them. Do not get carried away trying to keep up with the competition by mimicking trendy design styles or adding new features. By focusing on your user first, you will be able to create an interface that lets them achieve their goals.

2. Pay attention to patterns

Users spend the majority of their time on interfaces other than your own (Facebook, MySpace, Blogger, Bank of America, school/university, news websites, etc). There is no need to reinvent the wheel. Those interfaces may solve some of the same problems that users perceive within the one you are creating. By using familiar UI patterns, you will help your users feel at home.

3. Stay consistent

“The more users’ expectations prove right, the more they will feel in control of the system and the more they will like it.” – Jakob Nielson

Your users need consistency. They need to know that once they learn to do something, they will be able to do it again. Language, layout, and design are just a few interface elements that need consistency. A consistent interface enables your users to have a better understanding of how things will work, increasing their efficiency.

4. Use visual hierarchy

“Designers can create normalcy out of chaos; they can clearly communicate ideas through the organizing and manipulating of words and pictures.” – Jeffery Veen, The Art and Science of Web Design

Design your interface in a way that allows the user to focus on what is most important. The size, color, and placement of each element work together, creating a clear path to understanding your interface. A clear hierarchy will go great lengths in reducing the appearance of complexity (even when the actions themselves are complex).

5. Provide feedback

Your interface should at all times speak to your user, when his/her actions are both right and wrong or misunderstood. Always inform your users of actions, changes in state and errors, or exceptions that occur. Visual cues or simple messaging can show the user whether his or her actions have led to the expected result.

6. Be forgiving

No matter how clear your design is, people will make mistakes. Your UI should allow for and tolerate user error. Design ways for users to undo actions, and be forgiving with varied inputs (no one likes to start over because he/she put in the wrong birth date format). Also, if the user does cause an error, use your messaging as a teachable situation by showing what action was wrong, and ensure that she/he knows how to prevent the error from occurring again.

A great example can be seen in How to increase signups with easier captchas.

7. Empower your user

Once a user has become experienced with your interface, reward him/her and take off the training wheels. The breakdown of complex tasks into simple steps will become cumbersome and distracting. Providing more abstract ways, like keyboard shortcuts, to accomplish tasks will allow your design to get out of the way.

8. Speak their language

“If you think every pixel, every icon, every typeface matters, then you also need to believe every letter matters. ” – Getting Real

All interfaces require some level of copywriting. Keep things conversational, not sensational. Provide clear and concise labels for actions and keep your messaging simple. Your users will appreciate it, because they won’t hear you – they will hear themselves and/or their peers.

9. Keep it simple

“A modern paradox is that it’s simpler to create complex interfaces because it’s so complex to simplify them.” – Pär Almqvist

The best interface designs are invisible. They do not contain UI-bling or unnecessary elements. Instead, the necessary elements are succinct and make sense. Whenever you are thinking about adding a new feature or element to your interface, ask the question, “Does the user really need this?” or “Why does the user want this very clever animated gif?” Are you adding things because you like or want them? Never let your UI ego steal the show.

10. Keep moving forward

Grandpa Bud: If I gave up every time I failed, I would never have invented my fireproof pants!
[Pants burn up, revealing his underwear]
Grandpa Bud: Still working the kinks out a bit.

from Meet the Robinsons

Meet the Robinsons is one of my favorite movies. Throughout the movie Lewis, the protagonist, is challenged to “keep moving forward.” This is a key principle in UI design.

It is often said when developing interfaces that you need to fail fast, and iterate often. When creating a UI, you will make mistakes. Just keep moving forward, and remember to keep your UI out of the way.

The post 10 User Interface Design Fundamentals appeared first on Kruger David.

But – in five minutes, I’ll try to simplify the process of working with custom fonts as much as I possibly can. Services like Font Squirrel help to make the task a cinch!

Final CSS

@font-face {
font-family: 'blok-regular';
src: url('type/Blokletters-Potlood.eot');
src: local('Blokletters Potlood Potlood'),
 local('Blokletters-Potlood'),
 url('type/Blokletters-Potlood.ttf') format('truetype');
}

@font-face {
font-family: 'blok-italic';
src: url('type/Blokletters-Balpen.eot');
src: local('Blokletters Balpen Balpen'),
 local('Blokletters-Balpen'),
 url('type/Blokletters-Balpen.ttf') format('truetype');
}

@font-face {
font-family: 'blok-heavy';
src: url('type/Blokletters-Viltstift.eot');
src: local('Blokletters Viltstift Viltstift'),
 local('Blokletters-Viltstift'),
 url('type/Blokletters-Viltstift.ttf') format('truetype');
}

h1 { font-family: blok-heavy, helvetica, arial; }

Notice how we’re referencing both an .eot and .ttf font? This is because, of course, Internet Explorer only uses its own format, that has yet to truly catch on. As such, we must first import that .eot file, and then move on to the different formats for Firefox, Safari, etc. It’s essential that you load the .eot version first.

Next, we search for the font on the user’s computer by using the “local” attribute. If it’s unfound, only then do we pass a url that will load the font.

Why Doesn’t IE Try to Load the TTF Fonts?

This was definitely a concern. If Explorer can’t work with the truetype format, we don’t want to waste time trying to download the font. Luckily, because of all those local attributes, and the commas, IE won’t understand any of it. As such, it will simply skip the line all together, thus, only utilizing the .eot version.

The post How to Work with @Font-face appeared first on Kruger David.

1. What is Blueprint CSS?

If you are like me, as in more of a developer than a designer, then you are familiar with the process of starting a new project and not knowing what to do with your CSS. You know that your design will likely change as the project goes on, but you want to have a nice looking design from the beginning. So you spend some time writing some CSS that works in Firefox and Safari, oh wait, don’t forget IE, right, right. Then you write some HTML that you think you will use, and work at getting all of the spacing to look right. Great! Finished! Now, three days later, the requirements for your project have changed and you find yourself redesigning the layout again. Hmm… Now, even if you are a rockstar designer who already has all this CSS stuff figured out, or if you aren’t worried about how your layout will change over time because you are working from a PSD template or something, that doesn’t mean that there is nothing to learn here. Blueprint can still provide you with some tools so you can… Spend your time innovating, not replicating.And I think that this is exactly what Blueprint accomplishes. Blueprint provides a solid foundation to build your project on top of. It does this by providing sensible defaults across all browsers, nice-looking default typography, a grid framework, nice-looking forms, and a print stylesheet built with printers in mind

2. Blueprint Source Files

reset.css This file sets sensible defaults across all browsers. I’m sure we are all familiar with starting a new project, going to our main CSS file and adding a few default styles to the body selector, such as ‘margin: 0; padding:0; font-family: Helvetica, Arial, sans-serif;’ or something along those lines. This is what reset.css does, and more. It resets default styles for spacing, tables, fonts, etc. so you can work from a clean slate.

typography.css This file sets up some nice default typography. I won’t explain all of the styles but I will say that this is my favourite parts of Blueprint because, to me, there is nothing more discouraging than trying to lay out a page and seeing some black Times New Roman text jammed up into the top left corner of a page. Ugh. Blueprint’s typography.css keeps me from ever seeing that again. The typography.css also sets up some really nice styles around font sizes, line-heights, default styling of tables, etc.

grid.css This file handles the grid layout portion of blueprint. We will have a look at the classes that it uses in a bit. One important thing to note with the grid, by default it uses a width of 950px, with 24 columns each having a width of 30px and a 10px margin between columns. This may sound constrictive, but if this is not the layout you want, you can always use a Blueprint Grid CSS Generator to generate a custom grid layout. If this last paragraph completely confused you, please read on as we will build a layout using a grid in a bit.

ie.css Blueprint supports IE, so of course it needs it’s own specific stylesheet to take care of those little details that makes IE so special The nice thing is that Blueprint does handle this for you, so all of its core styles will work in all of the major browsers (I think it even supports IE 5).

print.css This file sets some default print styles, so that printed versions of your site looks better than they usually would. The print.css file also has an option where you can fill in your domain name so that relative links are shown in parentheses behind the text link in the printed version of your page. Without filling in this section only remote links will print properly. Check out the bottom of the print.css src file, linked above.

forms.css This file provides nice looking default forms as well as classes for error notifications or even flash notifications if you are using something like Rails. Since this is the only section I will not cover in more detail, here is some of the default form styles in use:

Does this mean that I have to include six different stylesheets?

No. Blueprint comes with three compressed stylesheets for your HTML pages, screen.css which contains #’s 1-3 & 6 from above, print.css, and ie.css. The reason that I outlined the different parts of the framework above is because the framework is modular, each of those pieces works independently of each other. The nice thing about this is that if you decide that one aspect of Blueprint, such as a grid layout, doesn’t fit your project but you still want the benefits of reset.css and typography.css, you don’t have to use the the grid but the other styles will still work.

3. Building a Layout with Blueprint

The head of the document

</pre>
<head>
 <meta http-equiv="Content-type" content="text/html; charset=utf-8" />
 <title>Book Haven</title>

<!-- Framework CSS -->
 <link rel="stylesheet" href="blueprint/screen.css" type="text/css" media="screen, projection" />
 <link rel="stylesheet" href="blueprint/print.css" type="text/css" media="print" />
 <!--[if IE]><link rel="stylesheet" href="blueprint/ie.css" type="text/css" media="screen, projection" /><![endif]-->

<!-- Import fancy-type plugin. -->
 <link rel="stylesheet" href="blueprint/plugins/fancy-type/screen.css" type="text/css" media="screen, projection" />
</head>
<pre>

This is how a typical <head> tag should look when you are using Blueprint. You need to include the framework’s CSS files, which consists of screen.css, print.css and ie.css. A great thing about Blueprint: it’s just CSS, so it can be overridden like any other CSS. This is how Blueprint plugins work. In this example I am using the Blueprint fancy-type plugin which offers some fancy typography styling. You can see that I’ve linked to the fancy-type CSS file below the framework’s CSS files, so the fancy-type CSS has the ability to overwrite styles defined by the framework. To this end, there are several BP plugins available which simply overwrite aspects of the framework or add new styles for you to use. Lastly you should include your CSS file where you could overwrite styles from the framework and add your own styling to the page.

The Page Header

 <body>
      <div class="container">

        <div id="header" class="span-24 last">

          <h1 id="book_haven"><img src="images/header.gif" alt="Book header image" id="header-image" /></h1>
        </div>

        <hr />
        <div id="subheader" class="span-24 last">
          <h3 class="alt">Get opinions on your latest novel, and read what other people are writing about.</h3>
        </div>

        <hr />

The most important thing to note about this code: your grid must be surrounded by a <div> with a class of ‘container’ otherwise it will not display as a grid. The <hr/> tags are used by Blueprint to separate sections of your page vertically. The ‘alt’ class is brought to you by the fancy-type plugin and provides a nice way to spice up some text (can be applied to any text element).

Main Content

    <div class="span-17 colborder" id="content">
          <h3 class="loud">Featured Book: "The World Without Us"</h3>
          <p>
            <img class="right" src="images/world-book.gif" alt="featured book" />
            Lorem ipsum dolor sit amet, consectetuer adipiscing elit.
          </p>

          <p>
            Cras sagittis. Fusce porttitor felis sed massa. In hac habitasse platea dictumst.
          </p>

          <hr />
          <div class="span-8 colborder">
            <h4 class="prepend-5">Upload a Book</h4>
            <p>
              Nam vitae tortor id ante sodales facilisis.
            </p>
          </div>

          <div class="span-8 last">
            <h4 class="prepend-5">Write a Review</h4>
            <p>
              Nam vitae tortor id ante sodales facilisis. Mauris ipsum.
            </p>
          </div>
        </div>

        <div class="span-6 last" id="sidebar">

          <div id="recent-books">
            <h3 class="caps">Recent Books</h3>

            <div class="box">
              <a href="#" class="quiet">Hygiene</a>
              <div class="quiet">Nov. 29, 2008</div>
              <div class="quiet">by Craven</div>
            </div>

          </div>

          <div class="prepend-top" id="recent-reviews">
            <h3 class="caps">Recent Reviews</h3>
            <div class="box">
              <span class="quiet">Thor reviewed Hygiene</span>
              <div class="quiet">Rating: 4/5</div>
              <a href="#" class="quiet">Read this review</a>
            </div>

          </div>
        </div>

        <hr />
    

There is lots of important stuff in this code snippet! Let’s start at the top with <div class=”span-17 colborder”>. This tag declares the largest outlined div on that page, the one that contains the Featured Book section as well as the two smaller sections below. The class ‘span-17′ relates to the Blueprint grid layout. It declares that the width of this div should span 17 of the 24 columns on the page. The other class being used, ‘colborder’, is short for column border and tells Blueprint to put a border to the right of this div between it and the sidebar.

Important: using the ‘colborder’ class actually takes up an entire column. Since our main div is using 17 columns (span-17), you would expect that the sidebar could occupy 7 columns (since 17 + 7 = 24, the number of columns on our page), but since the ‘colborder’ property takes up a column to itself, this leaves only 6 columns left for the sidebar div to occupy (17 + 1 + 6 = 24).

Before we get to the sidebar we need to look at those two smaller div’s, the ones titled ‘Upload a Book’ and ‘Write a Review’. This is actually one Blueprint grid nested another Blueprint grid. Since the inner grid is nested inside a div spanning 17 columns, the max width for this grid, instead of 24, is 17.

So, the first div has the classes ‘span-8′ and ‘colborder’, meaning it’s width will span 8 columns and it will have a border to the right. The second div here has classes ‘span-8′ and ‘last’. This is an important part of the Blueprint grid framework. The rightmost column in a grid must have use the ‘last’ class. This tells BP that this is the last column in this grid and it doesn’t need to make space for any more. Notice how we had room for 17 columns to begin with, each of the divs spanned 8 columns and the ‘colborder’ property took up the last column (8 + 8 + 1 = 17).

OK, back to the sidebar. The sidebar div has classes of ‘span-6′ and ‘last’. I’m sure you guys have caught on now to how these classes work. This sidebar completes the grid that the main span-17 div began. In case you didn’t notice, the ‘span-#’ class can take any number between 1 and 24, unless you decide to use a bigger grid, in which case the ‘span-#’ class can take any number so long as the number is less than the total number of columns in your grid.

This is about the simplest HTML I could come up with to demonstrate the grid.

<div class="container">
 <div class="span-24">
 Header
 </div>
 <div class="span-4">
 Left sidebar
 </div>
 <div class="span-16">
 Main content
 </div>
 <div class="span-4 last">
 Right sidebar
 </div>
 </div>

Let’s look at a few more of the CSS classes that we used in the layout.

1. ‘caps’: This class is used in the sidebar titles. It is brought to us by the fancy-type plugin and provides nice styling for capitalized titles.
2. ‘box’: This is a great one for displaying list items. It easily distinguished these items from the rest of the page and provides a nice margin between elements and nice padding for the elements inside.
3. ‘quiet’: This is a CSS class that changes the color of text to be that soft grey that you see in the sidebar text.
4. ‘prepend-top’: This one is used on the ‘Recent Reviews’ section of the sidebar. It simply applies a margin of 1.5em to the top of the element. There is a similar class called ‘append-bottom’ which has the same effect on the bottom of an element.
5. ‘prepend-5′: I am using this class to push the titles in the smaller div’s to the right. In Blueprint there are several classes for spacing: prepend, append, pull, and push. Prepend and append add padding to the left and right, respectively. Pull and push add a margin to the left and right, respectively. Once again, you can do as much appending, prepending, pulling, and pushing as you want so long as you don’t use a number bigger than the total number of columns in your grid (such as prepend-25 in a grid with 24 columns).

If you are not familiar with the CSS box model and don’t know the difference between padding and margin, here is a a brief lesson. In CSS, padding adds space within the borders of the element and actually increases the size of the element. For example, if you have a table with borders and you add padding to that table, it will actually push the borders away from the table. Margin, on the other hand, adds space outside of the border and does not increase the size of the element. This may have the effect of push other elements away from the current one or moving the current element on the page. Here is a great image to demonstrate the CSS box model:

4. Summary

This tutorial intended to show you how Blueprint CSS can be used to lay the groundwork for your next project, or at least take some of the weight off of your shoulders around resets and typography. Also, if you are using Blueprint with Rails, check out their repository on Github as they have some features that allow you to easily integrate and configure Blueprint to work with your Rails project.

The best thing about Blueprint is that it’s just CSS. It’s all CSS. So if you are interested in Blueprint go check out the source and if you have any knowledge of CSS you should be able to understand how it all works. Blueprint also is not a very large code base, it probably has less CSS than most of us use on a typical project. You can even read the source in your browser over at the Blueprint repository on Github.

Afew resources on Blueprint:

• The Blueprint web site is at blueprintcss.org. This is the easiest place to download the framework.
• By default Blueprint uses a fixed layout, if you are in favour of liquid layouts here is a plugin that you will allow Blueprint to function with a liquid layout.
• More Blueprint plugins

The post Understanding Blueprint CSS Framework appeared first on Kruger David.