Category Archive: Design

A Fresh Coat of Paint

As with most things, a little change can be a great thing.

I’ve finally gotten the basics of my new WordPress theme finished and uploaded. I got so bored with all of these business themes with their straight lines and boring colors…

… so I decided to kick it up a notch!

This is the new version of my site. There’s a lot of angles, colors, and various insights to my life that aren’t work related. Eventually I want to do a lot more, but I know that the best things in life are built a bit at a time… Rome wasn’t built in a day, after all!

Everything is built with CSS and Flexbox. I debated using Grid, but I knew I could get Flexbox to behave – especially with the vertical timeline in the middle of the page.

I still need to add my portfolio, but I feel like this is a much more vibrant representation of who I am. I’m not stuffy, business minded… I want to make the web a more beautiful place.

The site also adds in a few of my other passions as well: specifically, gaming, ministry, and culture. I know this seems like a smorgasbord of topics, but they all come together to form who I am, and they (combined with my design and development work) are the lenses in which I view life.

Some things to note:

  • The lines are angled at 1.75 degrees
  • The backgrounds all scroll at the same rate, even those the images are different.
  • I created a function specifically to randomize the background color on some sections because I love a little bit of chaos 🙂
  • The calendar is running a customized version of Modern Tribe’s “The Events Calendar”. I wanted something where I could have a nice way to look at upcoming stuff. Eventually, I’ll have streams (Twitch or YouTube) and other ‘short term’ items that aren’t just conferences.
  • I have a few other ideas that will be coming soon. But I want to nail down what I have before I add on, and that’s nearly done!

I’ve never felt so good about a design as I do about this one, and I feel like it’s… me. It’s a little rad, a little chaotic, and bright – just like I aspire to be in real life!


“Cover Me!” Background-Size CSS for Large Image Backgrounds

While working on a few new projects recently, I needed a way to have a background image span a container (horizontally and vertically).  I tried every measure of background-size you could think of:

background-size: 100% auto;

This worked, at least until you got to smaller resolutions.  Then, the image would show the background color.

So, I tried to work out when that happened and use:

background-size: auto 100%;

But it was such a hassle to figure out when the exact break point of the image would be.

Finally, looking through some documentation last night I stumbled upon the answer.  And it’s worth sharing because It has some amazing effects if you do it right (and it’s entirely done with CSS!).

Background-size: cover

I poured through the W3C documentation and discovered that background-size has a boolean ‘cover’ option.  Instead of setting numerical values, you can have the background scale accordingly and still make sure that no color is bleeding through from the back.

A typical “covered” background image looks like this:

img{ background: url(images/background.jpg) no-repeat center center; }

Set the background image, have it to not repeat and center in the frame.

The “scrolling frame”

One of the popular visual effects in web design lately is this “scrolling frame” concept.  Imagine you have a photo, stationary on a wall.  You then cut out a hole in a piece of paper and put it over the photo.  Moving it up and down keeps the photo in one spot, but the “frame of reference” changes, so you may only see bits and pieces of the photo through the frame.   It’s an amazing effect, and it can be done with one line of CSS:

img{ background: url(images/background.jpg) no-repeat center center fixed; }

A good example can be found in the Sonnet theme by ThemeBucket.  Scroll down until you see the “blockquote” area shown below.

Beware the Bandwidth

The nice thing about these full screen backgrounds is the visual effect it brings, but make sure you’re optimizing those images.  No one wants to download a single image (or two or three or ten images) that are megabytes of data.  It’ll slow down your site and will hurt your page-ranking.


One Web to Rule Them All: The Elastic Grid

This series is meant to be an in-depth look at Responsive Design.  It covers the history, the how-to, and best practices on responsive design, taken from the view of someone who hates fluid layouts and has found a (seemingly) better solution.  This session will be expounded upon in detail at PodCampNashville, then again in more detail at BlogWorldExpo later this year.

In case you’re wondering, here’s the road map for this week’s series:

When last we spoke I had mentioned that I ended up releasing my core theme onto GitHub, and I’ve already gotten some fantastic feedback!  I’d love to see what you guys are doing with it, because it’s a labor of love and it’s sort of strange just turning it out into the wild… so I want to see good results!

If you’ve looked at the theme, you may have an idea of what we’re going to talk about today, but if not, then let’s just dive right in.

I may have mentioned once or twice that I absolutely hate fluid layouts. With a firey passion that burns greater than a thousand suns, actually. When I saw all of the responsive layouts that were made with fluid backbones, I cringed.  There had to be a way to retain the design integrity of a fixed layout and have the nice fluidity of a responsive layout.

Enter the “Elastic Grid”

Picture your typical layout:

You’ve got logos (black), navigation (grey), a slider (light grey), and footer widgets/columnized content (dark grey).  Now, we need something that will hold a fixed amount of fluid… say, an aquarium:

So we’ve filled our aquarium with water, and are laying these items in it to “float” on the water… some are sitting on top of others, but for the most part you can see how the elements are stacked.  We can assume, by the way, that each of these elements are a specific size.  The upper logo, for example, is 2/16 of the full aquarium.  We’re still going to think in pixels, but we know how many pixels now.  The widgets are exactly 1/3 of the full width (this includes margin on both sides [except on the edges]).

Now, if we change the size of the container, the elements will change, but only slightly:

The elements may look a little shorter in width, but it still retains the same shape.  This is our goal for tablet layouts; keep as much content on the screen without having to scroll.

But what happens when we drastically shrink our aquarium?

This is where a lot of fluid layouts start to really bug me, and where a true responsive design really shines.  We’ve lost the original concept because the elements are just too skinny.  What should happen is that the elements should stack on top of each other when the content area starts to become too skinny to be readable.

Notice our logo now spans the whole content region?  That’s because the logo was small enough before that it really doesn’t change sizes – we may orient it differently, but it doesn’t shrink.  The navigation now floats under the logo (and may take up either multiple lines or one line per menu item).  The slider has shrunk in ratio to keep the images looking sharp, and the widgets now span the entire content width.  But, the difference between this and some fluid layouts is that this layout will never show up unless you’re on a small screen.

Remember this?

[code]

/* #Media Queries

================================================== */

/* Smaller than standard 960 (devices and browsers) */

@media only screen and (max-width: 959px) {}

/* Tablet Portrait size to standard 960 (devices and browsers) */

@media only screen and (min-width: 768px) and (max-width: 959px) {}

/* All Mobile Sizes (devices and browser) */

@media only screen and (max-width: 767px) {}

/* Mobile Landscape Size to Tablet Portrait (devices and browsers) */

@media only screen and (min-width: 480px) and (max-width: 767px) {}

/* Mobile Portrait Size to Mobile Landscape Size (devices and browsers) */

@media only screen and (max-width: 479px) {}

[/code]

Now you can make more sense of what we’re doing.  This allows us to have a fixed layout that appears normal for both desktops and tablets, while giving us a stacked layout for phones (both tablet and landscape).  We get the best view for all devices, while keeping the integrity of the design.

Code Dump, Ahoy!

OK, now that you see the media queries, let’s look at some actual CSS:

[code]

/* #Base 960 Grid
================================================== */

.container { position: relative; width: 940px; margin: 0 auto; padding: 0 10px; }
.container .column,
.container .columns { float: left; display: inline; margin-left: 10px; margin-right: 10px; }
.row { margin-bottom: 20px; }

/* Nested Column Classes */
.column.alpha, .columns.alpha { margin-left: 0; }
.column.omega, .columns.omega { margin-right: 0; }

/* Base Grid */
.container .one.column,
.container .one.columns { width: 40px; }
.container .two.columns { width: 100px; }
.container .three.columns { width: 160px; }
.container .four.columns { width: 220px; }
.container .five.columns { width: 280px; }
.container .six.columns { width: 340px; }
.container .seven.columns { width: 400px; }
.container .eight.columns { width: 460px; }
.container .nine.columns { width: 520px; }
.container .ten.columns { width: 580px; }
.container .eleven.columns { width: 640px; }
.container .twelve.columns { width: 700px; }
.container .thirteen.columns { width: 760px; }
.container .fourteen.columns { width: 820px; }
.container .fifteen.columns { width: 880px; }
.container .sixteen.columns { width: 940px; }

.container .one-third.column { width: 300px; }
.container .two-thirds.column { width: 620px; }

/* Offsets */
.container .offset-by-one { padding-left: 60px; }
.container .offset-by-two { padding-left: 120px; }
.container .offset-by-three { padding-left: 180px; }
.container .offset-by-four { padding-left: 240px; }
.container .offset-by-five { padding-left: 300px; }
.container .offset-by-six { padding-left: 360px; }
.container .offset-by-seven { padding-left: 420px; }
.container .offset-by-eight { padding-left: 480px; }
.container .offset-by-nine { padding-left: 540px; }
.container .offset-by-ten { padding-left: 600px; }
.container .offset-by-eleven { padding-left: 660px; }
.container .offset-by-twelve { padding-left: 720px; }
.container .offset-by-thirteen { padding-left: 780px; }
.container .offset-by-fourteen { padding-left: 840px; }
.container .offset-by-fifteen { padding-left: 900px; }

[/code]

Look familiar?  If you’re familiar with the 960 Grid system it should – the CSS is very similar.  What we’re doing is starting off with a grid.  A grid that we’ll change as soon as our size does.

On tablets, for example:

[code]

/* #Tablet (Portrait)
================================================== */

/* Note: Design for a width of 768px */

@media only screen and (min-width: 768px) and (max-width: 959px) {
.container { width: 748px; }
.container .column,
.container .columns { margin-left: 10px; margin-right: 10px; }
.column.alpha, .columns.alpha { margin-left: 0; margin-right: 10px; }
.column.omega, .columns.omega { margin-right: 0; margin-left: 10px; }
.alpha.omega { margin-left: 0; margin-right: 0; }

.container .one.column,
.container .one.columns { width: 28px; }
.container .two.columns { width: 76px; }
.container .three.columns { width: 124px; }
.container .four.columns { width: 172px; }
.container .five.columns { width: 220px; }
.container .six.columns { width: 268px; }
.container .seven.columns { width: 316px; }
.container .eight.columns { width: 364px; }
.container .nine.columns { width: 412px; }
.container .ten.columns { width: 460px; }
.container .eleven.columns { width: 508px; }
.container .twelve.columns { width: 556px; }
.container .thirteen.columns { width: 604px; }
.container .fourteen.columns { width: 652px; }
.container .fifteen.columns { width: 700px; }
.container .sixteen.columns { width: 748px; }

.container .one-third.column { width: 236px; }
.container .two-thirds.column { width: 492px; }

/* Offsets */
.container .offset-by-one { padding-left: 48px; }
.container .offset-by-two { padding-left: 96px; }
.container .offset-by-three { padding-left: 144px; }
.container .offset-by-four { padding-left: 192px; }
.container .offset-by-five { padding-left: 240px; }
.container .offset-by-six { padding-left: 288px; }
.container .offset-by-seven { padding-left: 336px; }
.container .offset-by-eight { padding-left: 384px; }
.container .offset-by-nine { padding-left: 432px; }
.container .offset-by-ten { padding-left: 480px; }
.container .offset-by-eleven { padding-left: 528px; }
.container .offset-by-twelve { padding-left: 576px; }
.container .offset-by-thirteen { padding-left: 624px; }
.container .offset-by-fourteen { padding-left: 672px; }
.container .offset-by-fifteen { padding-left: 720px; }
}

[/code]

Notice how we keep the same classes, but just change their width.  It’s not quite a LESS approach, but it’s getting there.

And finally the drastic change for mobile:

[code]

/* #Mobile (Portrait)
================================================== */

/* Note: Design for a width of 320px */

@media only screen and (max-width: 767px) {
.container { width: 280px; }
.container .columns,
.container .column { margin: 0; }

.container .one.column,
.container .one.columns,
.container .two.columns,
.container .three.columns,
.container .four.columns,
.container .five.columns,
.container .six.columns,
.container .seven.columns,
.container .eight.columns,
.container .nine.columns,
.container .ten.columns,
.container .eleven.columns,
.container .twelve.columns,
.container .thirteen.columns,
.container .fourteen.columns,
.container .fifteen.columns,
.container .sixteen.columns,
.container .one-third.column,
.container .two-thirds.column { width: 300px; }

/* Offsets */
.container .offset-by-one,
.container .offset-by-two,
.container .offset-by-three,
.container .offset-by-four,
.container .offset-by-five,
.container .offset-by-six,
.container .offset-by-seven,
.container .offset-by-eight,
.container .offset-by-nine,
.container .offset-by-ten,
.container .offset-by-eleven,
.container .offset-by-twelve,
.container .offset-by-thirteen,
.container .offset-by-fourteen,
.container .offset-by-fifteen { padding-left: 0; }

}
/* #Mobile (Landscape)
================================================== */

/* Note: Design for a width of 480px */

@media only screen and (min-width: 480px) and (max-width: 767px) {
.container { width: 400px; }
.container .columns,
.container .column { margin: 0; }

.container .one.column,
.container .one.columns,
.container .two.columns,
.container .three.columns,
.container .four.columns,
.container .five.columns,
.container .six.columns,
.container .seven.columns,
.container .eight.columns,
.container .nine.columns,
.container .ten.columns,
.container .eleven.columns,
.container .twelve.columns,
.container .thirteen.columns,
.container .fourteen.columns,
.container .fifteen.columns,
.container .sixteen.columns,
.container .one-third.column,
.container .two-thirds.column { width: 420px; }
}

[/code]

See how all the columns are just given the same width?  That was the whole idea – we stack on top of each other the elements that would float side-by-side in a larger container.

This code is taken directly from the Skeleton framework, in my opinion one of the best elastic grid frameworks out there, and by far the easiest to design for (especially if you’re used to the 960 grid!)

Tomorrow we (finally) finish the series by looking at some examples, and Saturday if you’re in Nashville you can pop by PodCampNashville for a wrapup!

 


One Web to Rule Them All: Media Queries

This series is meant to be an in-depth look at Responsive Design.  It covers the history, the how-to, and best practices on responsive design, taken from the view of someone who hates fluid layouts and has found a (seemingly) better solution.  This session will be expounded upon in detail at BlogWorldExpo later this year.

Yesterday we mentioned the who and what behind responsive design – how it allows one website to (without relying on external services or subdomains) serve up the appropriate version of itself to the reader based on what device it’s viewed on (be it tablet or mobile phone).  But, how is this possible?  How does the system know what device you’re on?  The answer is very simple, and yet complex at the same time.

Media queries use a value and expression to define the specific medium that the content is shown on.  CSS2 already uses a very simple system of media querying: the “media” key:

<link rel="stylesheet" media="screen" href="example.css" />

CSS3 expounds upon this concept by allowing more flexible variables to be entered, such as color, width, etc.

Types of Queries

First off, one major difference between the old version and the new is that CSS3 queries can be run right in the stylesheet.  This means that instead of having a “mobile stylesheet”, you can use one stylesheet and organize your styles by screen type:

@media screen and (min-width: 400px) and (max-width: 700px) { … }

This allows you to have specific styles for only screens between 400px and 700px wide.  That said, there are a number of different queries you can run, based on a number of different set-ups:

  • screen width
  • device width (there is a difference)
  • screen height
  • device height
  • color
  • orientation (portrait vs landscape)
  • aspect ratio
  • device aspect ratio
  • resolution
  • scan (for televisions)
  • grid (tty terminals, for example)

There’s a LOT of different variables here, but if you’re just starting out, the only one you really need to focus on is screen width, since you can set a lot of different values.

Most websites today are built on a system of 960 – whether that’s a grid or otherwise, it’s a fairly standard screen width.  Without going too far into what we talk about tomorrow, here’s a sneak peek at the system I use:

/* #Media Queries
================================================== */
/* Smaller than standard 960 (devices and browsers) */
@media only screen and (max-width: 959px) {}
/* Tablet Portrait size to standard 960 (devices and browsers) */
@media only screen and (min-width: 768px) and (max-width: 959px) {}
/* All Mobile Sizes (devices and browser) */
@media only screen and (max-width: 767px) {}
/* Mobile Landscape Size to Tablet Portrait (devices and browsers) */
@media only screen and (min-width: 480px) and (max-width: 767px) {}
/* Mobile Portrait Size to Mobile Landscape Size (devices and browsers) */
@media only screen and (max-width: 479px) {}

Notice how this allows you to have different CSS setups that tailor to the specific views.  It covers normal sizes, tablets, and landscape/portrait mobile phones.  Dropping this into your stylesheet will allow you to set up styles that are specific to those views.

However, setting up a specific media query for each site is cumbersome – it means that you have to basically design 5 different sites, and who has time for that?  What if there were a way to consolidate the different classes we need to automatically format themselves, and then use these values to tweak our existing design?

But I’m getting ahead of myself.  Tomorrow we’ll talk about why grid layouts are still important, and how we can marry the flexible and the rigid into something that works magically together.


One Web to Rule Them All: An Introduction to Responsive Design

This series is meant to be an in-depth look at Responsive Design.  It covers the history, the how-to, and best practices on responsive design, taken from the view of someone who hates fluid layouts and has found a (seemingly) better solution.  This session will be expounded upon in detail at BlogWorldExpo later this year.

According to the latest research, there are now 1.2 billion mobile Web users worldwide, with 25% of those users never even utilizing a desktop to view their Internet content.  Sure, there have been hacked together methods of displaying one page to your normal viewers and one for your mobile crowd, but for the most part it creates serious overhead for the organization (and serious confusion at times for your users).  What if there were one version of your website that you could serve up to readers, but instead of being shoehorned into a mobile app it would seamlessly mold and shape itself to be the perfect version of itself.  It would be one website on many platforms, instead of many versions of the same website. If you are looking for cleaning websites services, visit weblaunchlocal.com for more details.  This is called responsive design, and it’s a design trend that’s sweeping over the design community.

This idea of a reactive, or responsive design, is very new – less than two years old, in fact.  Ethan Marcotte coined the phrase in his article on “A List Apart” back in May of 2010.  He laid the foundation for a lot of the theories and practical ideas we use in a responsive design.  However, as the trend matured, one little problem kept arising.

Editors Note: This is where I’m supposed to tell you that this is my own opinion and all that stuff, so I guess that this next paragraph may be considered a bit… ranty.  You’ve been warned.

I hate fluid layouts.  Layouts that stretch and skew themselves to the entirety of the screen are awful, they’re ugly, and they are absolutely impossible to design for without a lot of thinking and planning.  For a web application, Gmail being an example, then a fluid layout is fantastic.  But for some reason trying to display brochure sites or blogs in a completely fluid layout usually ends up in a disaster.

Editors Note: End Rant 🙂

I am a grid designer.  I love using a system of classes that is predetermined to make the site bend and warp to my every will.  The 960 system has been my system of choice for years now and I was really reluctant to give it up, especially when I  knew that I was going to have to switch to a more fluid layout system, and I know a lot of other designers who are just as wary about switching.

When I see a fluid site, I think of a rubber band.  It’s nearly impossible to hold structure with a rubber band; the band actually takes on the structure of whatever it touches, and doesn’t allow you to plan for truly artistic designs, which the modern web is full of.

What if, instead of a rubber band, there was a studded band that would “snap” to various views, based on where you held it?  It would look like any normal website when done with a fullscreen view, but would immediately snap to the proper alignments when presented with a phone or tablet.  Turns out, there is a away to have a responsive design and a perfectly good looking normal website, all at the same time.

That is the new model I have adopted, and it’s one that will work for nearly any ground-up built design.

That said, stick with us, because here’s the roadmap for the week:

  • Monday: Introduction
  • Tuesday: What Are Media Queries
  • Wednesday: The Elastic Grid
  • Thursday: Best Practices for Responsive Design
  • Friday: Examples and Epilogue

I hope you’ll stick with me as I explore responsive design.  In the mean time, I’m curious to see your thoughts on the idea of responsive design.  Is it worth even doing?  Should we be focusing on this concept of “one web”, or still segregating our devices?

 


Add A Favicon; Because It’s The Little Things That Set You Apart

One thing I continually notice as I surf the web is that people tend to cut corners when it comes to getting their sites up.  They continually forget to drop in small, polishing elements that make a dull website sparkle.  Favicons seem to be the most ignored of the bunch, as I see sites quite often that have kept their hosting account’s favicon or (even worse) don’t have one at all.

All In One Favicon is my go-to plugin of choice for giving my site’s a favicon.  Not only can you specify a different icon for your front end and back end (if you have lots of users, this becomes handy!) but you can also set the Apple Touch icons.  All of the directions are included, and everything runs on the image uploader, so you don’t have to worry about specifying paths, etc.


CSS3: Fading Colors (A Quick Introduction)

It’s the little things, I’ve noticed, that really make a website design pop.  The layout may be good, the content may be worth reading, but it’s small, minor details that take a good design and turn it into a great one.  With the advent of CSS3 and HTML5, those details become even easier to bring in.  No longer do designers and coders have to “hack” in their favorite flourishes, but we can now simply enter one or two lines of code and get exactly what we need.

CSS3, for example, has a lot of animated characteristics built right in.  Everything from movement, fading, and even replacing current content can be done with just a few simple lines of code.  I wanted to introduce you to CSS3 with a four-line code snippit that can make any website just a bit more polished: a color transformation when you hover over a link.

The first thing we want to do is define our hyperlink colors.  We’ll start simple; I’m only going to change the default link color in the widget areas and the post content:

[code]

.post a, .widget a{
color: #09F;
text-decoration: none;
}

.post a:hover, .widget a:hover{
color: #F000FF;
}

[/code]

Nothing too unfamiliar, right?  We’re defining our hyperlink colors as blue in a resting state, and pink in a hover state.  Now, watch what happens when we add in the “transition” property (here’s a hint: if you want to see it in action, poke around the site a bit and try hovering over some links!)

[code]

.post a, .widget a{
color: #09F;
-webkit-transition:color .25s ease-in;
-moz-transition:color .25s ease-in;
-o-transition:color .25s ease-in;
transition:color .25s ease-in;
text-decoration: none;
}

.post a:hover, .widget a:hover{
color: #F000FF;
}

[/code]

Now, you may be asking why we’ve added 4 different versions of the same code?  Like its friend “border-radius” and all of the other CSS3 commands, all of the major browsers have different ways they interpret the code, and all have browser prefixes.  “Webkit” works on all Safari/Chrome browsers, “moz” on Firefox (and mozilla-based browsers), “o” is for opera, and the non-prefixed version is a catch-all should everything decide to standardize.

Now, without going too in-depth, here’s what that line is doing: the first value is the other property we’ll be affecting.  In this case, we’re going to be applying the transition to the “color” property.  But we can apply it to any other CSS property we want; color makes for a nice looking effect, so we’ll use it for our demo.  Next, is time.  the ‘s’ stands for seconds, so .25 is 1/4 of a second, or 2500 milliseconds.  And finally, ‘ease-in’ is the animation applied to the transition.

Hover over a link, and you’ll see a nice fade from blue to pink.  You can adjust the timing to make it faster (.15s) or slower (.5s), or change the colors.  This is a quick way to add a visual pop to nearly any website.  I’ll do a more in-depth look at CSS3 later, but for now, enjoy this handy little snippit.


A Few Amazing Sites That Can Be Built With WordPress

I always tell people that, in my mind, there’s no question that WordPress can take anything you throw at it.  I’ve been building websites on it for nearly 4 years now professionally and I’ve found quite a few fun little projects have come my way.  It’s always a challenge to make WordPress work in a way that is outside the box.  So, I thought I’d share a few of the projects I’ve had the privilege to work on over the years.

1. Church Websites

CCF Edmonds

The website I did for Community Christian Fellowship was definitely one of the more complex projects I’ve done.  It includes:

  • 4 Custom Taxonomies
  • 5 Custom Post Types
  • An event calendar built entirely out of custom posts
  • A customized podcast feed (also built out of custom post types)
  • Ministry pages that call data based on a matching taxonomy/page slug system

The event calendar was fun, mainly because it uses a little known WordPress function: meta comparison.  You can take custom field data and compare it against a variable to sort and display data that is greater than, less than, equal to, or NOT equal to a specific variable – it’s great for displaying top rated movies in a review database, for example.

2. Dating Website

Editor’s Note: Some pictures may be slightly NSFW – nothing fully exposed, but you may not want your boss seeing these. I wasn’t aware of content when I started the build, but it’s too technically awesome to not include. You’ve been warned.

Yes… a dating website – who knew, right?  Also built using custom post types and custom taxonomies, this allows the website owner to fill in data for his client’s profiles and tag them to a specific geographical location.  Since the service is invite only, specific user accounts are created for each member.  If a user is logged in, they see all the available profiles (and all of the data in that profile).  If they are not, they are redirected to a page to ask them to become a member, and are only shown a sample of the available clients.  (if you’re curious, the function is the is_user_logged_in() function).

3. Real Estate Site

Tennessee Valley Homes

Built again on WordPress, this has a testimonial section built on (surprise) custom post types.  The kicker, however, is the “Options Showroom” – which has javascript galleries built on top of the main WordPress photo gallery, as well as DSIdxPress running to pull in RealTracs user data.  Basically, any homes they have for sale that are in RealTracs are automatically updated on their site in real time.  We can limit the agent codes to just their office, however, since they are more focused on building.

These sites are only a sampling of what can be done with WordPress, some design knowhow, and a little time.  If you want specific information, or have questions, about replicating some of the functionality on a project you have in mind, or want to see what WordPress can do for you, then all you have to do is ask!


The Uncanny Valley: Applying Robotics Principles to your Interface/Web Design

This post is based on another article I stumbled upon from two years ago:

http://www.codinghorror.com/blog/2008/12/avoiding-the-uncanny-valley-of-user-interface.html

And it got  me thinking: back in 2008 the era of “cloud computing” and even “web desktop apps” (applications that simulate desktop applications, but are hosted online) have come a long way since then.  Google Apps is replacing Microsoft Office, we opt for cloud storage above external hard drives, and even our real life relationships are supplemented by contacts we make online.

As all of these changes take place, I wonder what this is doing to our perception of desktop apps.  Do we look at a web application meant to replace a desktop one and go “Wow, that’s fantastic”

…or do we cringe at the “cannot’s” and “won’t dos”.

There’s a principle in Robotics called the Uncanny Valley.  It states that the more lifelike a robot looks, acts, or seems, the more we pick out the unpolished, un-human bits, and focus on those.  If a robot seems toy-like, cheesy, or metallic, we are quick to write off the flaws.  However, get a robot that can’t be identified between a human, and we start to worry and show emotion.

Web designs are the same.  Not just between web applications and desktop applications, but between two web applications, we compare and contrast the perfections with the blemishes. 

The hard part about this is, it’s all based on perfection.  Your system of choice will always trump and be the mold for which all other applications are measured.

Take GMail, for example:

gmail

Anyone who uses Gmail may consider this the i-ching of simplistic design.  It’s well thought out, simple to use, and everything’s well labeled.

Look at a Live.com email account, on the other hand…

live

And you might say that everything is fairly similar… except for the huge ad on the right side! omg omg!!!1

OK you may not say it exactly like that, but considering that’s really one of the only differences between the two sites, you will zone in on that one giant change and maybe nothing else.  (FYI, I actually like Live’s color scheme and layout better, but use Google Apps because of the integration).

So you see, we’ve entered a spot in the design spectrum where the Uncanny Valley affects us all. However, it gets harder and harder to please everyone design-wise as the design pillars (Google, Twitter, etc) establish what they believe good design is. 

The trick: testing.  If you have the budget (and you should!) Hire a UX/UI consultant to come in and take a look at things.  Or, if you’re strapped, hire a few joe schmoes to surf through your site.  Give them a few clear goals, and watch what happens (don’t help them!).  If they are confused by too much information, take stuff away.  However, if they have to dig through nothingness to get to their data, put some back in.  It’s a fine line, but once you get out of the valley, you emerge onto something truly wonderful.


FLIR, Cufon, Typekit, or SFIR: Breaking Away From Web-Safe Fonts

If I had to subtitle this post, I would probably make some sort of a silly joke like “Georgia on my mind” or “Helvetica? I barely even know you” or something like that, but instead I want to jump right into the fun stuff.

Back when the web was young and you were “likely to be eaten by a grue” (ok, maybe not that far back, but back when the term “world wide web” had just been coined”) there was one font that reigned supreme: Terminal.  After graphics invaded our desktop machines, Microsoft created the “core fonts for the web” that allowed users to get the same fonts on every machine (allowing for at least some sort of consistency when you build a website).

The project flopped because of EULA problems, but it did give us a sort of standard font set that we use for the web:

  • Arial/Helvetica
  • Times New Roman
  • Georgia
  • Verdana
  • Tahoma

99% of websites have a combination of one or more of the fonts listed above.  There are others, but they are machine specific, such as Myriad Pro (Mac), but for the most part, until recently, you couldn’t branch out from those specified fonts.

Lately, however, a few services have appeared that allows you to take different fonts and use them at your will to replace boring, web-safe fonts with more exciting choices.

1. sIFR

Scalable Inman Flash Replacement was developed by web-pioneer Shaun Inman as a way to easily replace one font with another using a combination of Flash and JavaScript.  The first obvious drawback to sIFR is the word “flash”, which means that iPhones can’t view the text.  Flash blockers also have an issue with replaced text.  The other problem is a special sIFR font file must be generated/created to use with the script.  It’s a viable method, but may be outdated by other methods that have come along in recent times.

2. FLIR

FaceLift Image Replacement is meant as a JavaScript only replacement technique that takes the flaws from sIFR and removes them.  The upside is a fantastic font image that can be viewed on all devices.  It also uses real font files, not flash generations, to do its job.  The downside is that some fonts look jagged and pixilated, but most fonts look pretty good.

There’s a WordPress plug-in for FLIR you can download to make the process easier.

3. Typekit

Typekit is, by far, the easiest to set up.  You create an account, select the fonts you want to embed (and what CSS calls to use) and the one line of JavaScript takes care of the heavy lifting for you.  The downsides?  Limited font selection, and the better accounts cost money to get access to (not much mind you, and even font foundries have to get paid somehow).

4. Cufon

Cufon is my new favorite in the race to replace fonts.  Sure, it does require a generator file, like sIFR, but it’s not a flash file – it’s a JavaScript that runs.  The set up process is fairly easy: simply give the font a “font-family” attribute, generate the script, attach to a stylesheet, and then enter your CSS as normal, using the font family attribute to call the font.  Sizing, italics, weight; everything is taken care of by the JavaScript.

Also, the WordPress plug-in for Cufon makes it super easy to set things up effectively.

In conclusion…

Cufon is by far my favorite because it looks nice, is easy to use (if not a little harder to set up, but it’s a caveat I’m willing to live with), and does its job well.  Regardless, one thing to remember: only use fonts you have purchased the license to, because those guys work hard and deserve to be paid for their fantastic job.  Now, go out there and find some cool fonts to use!


Contact/Hire Mitch

Want to book Mitch for a speaking event at your business or church?

Or does your business or project need some amazing design / development muscle?

Use the form below!


Don’t worry - your information is safe with us! We dont’ sell it, and we don’t like people who do!

Please only contact Mitch related to speaking engagements, projects, or personal messages.

NO SPAM EMAILS, PLEASE!