Posts Tagged 'Design'

September 26, 2012

Tips and Tricks - jQuery Lazy Load Plugin

In the late 90's, web pages presented their information in a relatively structured fashion, with little concern on how "pretty" the content looked. To a certain extent, that was a result of available technology and resources being a little more limited, but much of the reason was probably because we had no idea what was possible. We've come a long way, my friend. These days, it's tough to spend an hour online without coming across a gorgeous web site with huge animations, a pallet of every color possible, full-width backgrounds and high definition detail.

Those sites may be aesthetically pleasing, but they can be a big pain from a developer's perspective.

How much load does all of that stuff put on the server every time that web page is visited? As developers, it's our job to think about both what the visitor sees AND the visitor's experience in seeing it. Even the most beautiful sites will be ignored if a page takes too long to load. We spend hours optimizing every detail so users can fluidly browse without having to wait. It was in one of these optimization sessions that I discovered "lazy load."

To be honest, I wasn't too fond of the word "lazy" in the name, and I especially wasn't fond of having to explain to my boss that *I* wasn't being lazy ... The jQuery plugin is *named* "Lazy Load." Lazy Load effectively allows large pieces of content to stay in the backlog until they're needed. To give you an example of what that looks like, let's say you have a website with three humungous images, but they're all in different locations. Instead of pushing the entire load onto the user when they first land on your page, we can break them up and have them load only when the user goes to view them. We're not reducing the size of the web page; we're merely helping it work smarter.

Without Lazy Load, a normal web page loads each item when its page is visited. If a website has videos, music, images and some neat user interactivity applications, each of those items will load at the same time:

Lazy Load Illustration

If you take into consideration how large each of those items are, you can sense the problem. The user only has so much bandwidth to load these items, and something's gotta give. Usually, it means long loading times. We can't control how fast each user's ISP is, but we can reorder our items and let Lazy Load help us prioritize items and load the page more efficiently.

After we snag Lazy Load on Github (jquery.lazyload.js), we put our jQuery scripts in the <head> of our page:

<script src="jquery.js" type="text/javascript"></script> 
<script src="jquery.lazyload.js" type="text/javascript"></script>

Now that the plugin is available to us, we need to determine what we want to load lazily. Images are probably one of the most bothersome page elements, so let's apply Lazy Load to the images we load in the belazy class. In the <head> of your page (or in the footer if you prefer your JavaScript entries there), you'll add:

<script type="text/javascript">$("img.belazy").lazyload();</script>

As a result of that function, all image tags with a class of belazy will have Lazy Load run on them. This helps us ensure that we're not loading ALL of our images lazily. Now we need to choose which images we want to apply Lazy Load to.

Let's say the image tag of the largest image on one of our page looks like this:

<img src="bighonkingimage.png"/>

To have the lazyload function apply to it, we just have to make a couple tweaks:

<img class="belazy" src="bighonkingimage.png" data-original="bighonkingimage.png"/>

We added class="belazy" to trigger the lazyload function, and we added data-original="bighonkingimage.png" to line up with the formatting required by the newest version of Lazy Load (it's simply a repeat of the source).

When a user visits our page, bighonkingimage.png will load only when it's needed!

Pretty neat, eh?

-Cassandra

September 6, 2012

Tips and Tricks - jQuery equalHeights Plugin

Last month, I posted a blog about dynamically resizing divs with jQuery, and we received a lot of positive feedback about it. My quest to avoid iframes proved to be helpful, so I thought I'd share a few more esoteric jQuery tips and tricks that may be of use to the developers and designers in the audience. As I thought back about other challenges I've faced as a coder, a great example came to mind: Making divs equal height, regardless of the amount of content inside.

I haven't seen many elegant div-based solutions for that relatively simple (and common) task, so I've noticed that many people struggle with it. Often, developers will turn back to the "Dark Side" of using tables to format the content since all columns would have the same height as the tallest column by default:

JQuery Tutorial

It was easy theme table columns and to achieve the coveted 100% height that many designers seek, but emulating that functionality with divs proves to be much more difficult. A div is like the Superman of HTML elements (faster-loading, more flexible, more dynamic, etc.), and while it has super powers, it also has its own Kryptonite-like weaknesses ... The one relevant to this blog post being that floating three div elements next to each other isn't going to give you the look of a table:

JQuery Tutorial

Each of the three divs has its own height, so if you're doing something as simple as applying background colors, you're going to wind up with an aesthetically unpleasing result: It's going to look funky.

You could get into some nifty HTML/CSS workarounds, but many frustrated theme creators and designers will tell you that if your parent elements don't have a height of a 100%, you're just wasting coding lines. Some complex solutions create the illusion of all three divs being the same height (which is arguably better than setting fixed heights), but that complexity can be difficult to scale and repeat if you need to perform similar tasks throughout your site or your application. The easiest way to get the functionality you want and the simplicity you need: The jQuery equalHeights plugin!

With a few class declarations in your existing HTML, you get the results you want, and with equalHeights, you can also specify the minimum and maximum parameters so it will create scrollable divs if the tallest element happens to be higher than your specified maximum.

How to Use jQuery equalHeights

First and foremost, include your JQuery lirbraries in the <HEAD> of your document:

<script src="//ajax.googleapis.com/ajax/libs/jquery/1.8.0/jquery.min.js"></script>
<script language="javascript" type="text/javascript" src="jquery.equalheights.js"></script>

The equalHeights plugin is not a hosted library, so you have to host the file on your server (here's the link again).

With the required libraries called in our document, it's time to make the magic happen in your HTML.

Create Your Divs

<div class="divHeight">This DIV is medium sized, not too big and not too small, but just right.</div>
<div class="divHeight">This DIV has a lot of useful content and media that the user can interact with, thus it's very tall.</div>
<div class="divHeight">This DIV is tiny. Period.</div>

To have them line up next to each other, you'd have them float:left; in your CSS, and now you need to apply the equalHeights function.

Call the equalHeights Plugin
In order for the script to recognize the height of the tallest element, you'd need to call $(document).ready just before the </body> tag on your page. This will ensure that the page loads before the function runs.

The call looks like this:

<script type="text/javascript">$(document).ready(function() {
$(".divHeight").equalHeights();
});</script>

If you want to specify a minimum and maximum (i.e. The div should be at least this tall and should be no taller than [adds scrollbar if the div size exceeds] the maximum), just add the parameters:

<script type="text/javascript">$(document).ready(function() {
$(".divHeight").equalHeights(300, 600);
});</script>

The initial call does not change the appearance of the divs, but the time it takes to do the resizing is so miniscule that users will never notice. After that call is made and the height is returned, each div with the class of divHeight will inherit the the same height, and your divs will be nice and pretty:

JQuery Tutorial

This trick saved me a lot of headache and frustration, so hopefully it will do the same for you too!

-Cassandra

June 5, 2012

New SoftLayer.com Design: Build the Future

If you've been reading the SoftLayer Blog via an RSS feed or if you find yourself navigating directly to the portal to manage your SoftLayer account, you might not have noticed that the our main website has been updated again — and in dramatic fashion. Last fall we gave the site a slight refresh ... This time, we did a total rework.

We took the site in a new visual direction, with graphics and messaging to complement our mantra of customers using our platform to create their vision — to build the future.

SoftLayer Homepage

The new look — referred to as "SoftLayer at Night" by my fellow SoftLayer developer friend, Seth Thornberry — was designed to reflect our core identity, and it retires the faithful red, white and grey theme that has served us well for more than three years. The new style has received rave reviews from customers, partners and employees, and even if there has been some criticism — everyone has an opinion nowadays — we can generally chalk it up to people simply not liking change.

Highlights of the Redesign:

  • A dramatic new home page design, including visually rich "hero images" (where you see "The InnerLayer" heading if you're reading this on the SoftLayer Blog)
    SoftLayer Homepage Hero Image
  • Expanded main navigation menus at the top of each page
    SoftLayer Homepage Top Nav
  • A new lower-order navigation system on the left of all content pages
  • SoftLayer Homepage Side Nav

  • [For typographically inclined] The new design also leverages web fonts functionality to incorporate "Benton Sans," the corporate font used in print, interactive and other marketing communications.
    SoftLayer Homepage Side Nav

The new design was executed in-house, and our workflow was pretty traditional ... We like to roll up our sleeves. Page templates were created as PSD files and then hand-coded in HTML, PHP, JavaScript and CSS on top of the same framework we use for the SoftLayer Customer Portal.

During the development process, we used our new GIT code repository to facilitate the merging of all of our code onto our staging server. Since it was our first time to use GIT in a major way, there was a bit of a learning curve. The first few merges had to be reworked after finding a few errors in commit messages, but after we got a little practice, the subsequent merges went off without a hitch. The final staging merge was a breeze, and given the struggles we've had with SVN in past projects, this was a huge relief.

When it came time for the design's official launch, we ran into a hiccup related to our automatic regression testing system and problems with cached CSS files, but these issues were quickly resolved, and the new-look SoftLayer.com went live.

It took a lot of hard work from (and a lot of caffeine for) a number of people to get the new site out the door, so I'd like to make sure credit goes where it's due. Our lead designer Carlos ("Los") Ruiz did a majority of the design work, and the implementation of that design fell to Dennis Dolliver (Website Developer), Charles King (SEO Manager) and me. I should also send a shout-out to the entire marketing team who jumped in to help to proof content, test pages and keep everyone sane.

What do you think of the new design? Stay tuned for more website improvements and additions!

-Brad

March 13, 2012

Web Development - CSS - Highlight Selection

I immediately fell in love with CSS when we were introduced in late 2000. The ability to style a whole site outside the HTML was a fantastic concept and probably my first true introduction to separation of style and content. Put your words over here, and put how you display those words over there. So simple! Since then I have always been an advocate of cascading style sheets. Today's tip will involve an effortless addition that will have your readers say, "Ooooh. That's a clever little change."

I find that when I read articles and blogs online, I not only read with my eyes, I scan the page with my mouse. Especially if it's a wordy article or not styled in smaller columns, I highlight the text by clicking and dragging to help me maintain my focus. Up until recently, whenever you selected text that way in your browser, your operating system would choose the color of the background highlight. For Windows, this is generally blue. For OS X, this is whatever you've set your preferences to (which is light blue by default).

For those of you that use a newer version of Webkit (Chrome or Safari) or Gecko (Firefox), the site designer can determine what color to highlight your selection of text, and CSS has made it easy.

/* Webkit */
::selection {
    background: #972F2C;
    color: #FFF;
}
/* Gecko/Mozilla */
::-moz-selection {
    background: #972F2C;
    color: #FFF;
}

As of today, Webkit browsers are the only ones that support ::selection without browser prefixing. Firefox requires the -moz- prefix. Here we have set the highlight background color to "SoftLayer Red" (#972F2C) and made the text color white (#FFF). It should be noted that earlier versions of Webkit and Gecko did not support anything but the background property. There is still limited support for which CSS properties are allowed during selection. You are unable to change font-style, font-size, text-decoration and many other properties, but we can hope support for most of the properties will be available in the future.

This is pretty cool so far, but we can take it one small step further. Just like other selectors, we can apply the ::selection selector to other elements and style each one differently.

h2::selection {
    background: #B72E33;
    color: #FFF;
}
p::selection {
    background: #ACEFB2;
}
div::selection {
    background: #E4DB80;
}
span::selection {
    background: #C780E4;
    color: #FFF;
}

This produces the following:

Highlighting Example

Surprise your readers and give them some highlight goodness.

Happy coding!

-Philip

February 10, 2012

Amsterdam Data Center (AMS01): Does it Measure Up?

SoftLayer data centers are designed in a "pod" concept: Every facility in every location is laid out similarly, and you'll find the same network and server hardware connected to the same network. The idea behind it is that this design makes it easier for us to build out new locations quickly, we can have identical operational processes and procedures in each facility, and customers can expect the exact same hosting experience regardless of data center location. When you've got several data centers in one state, that uniformity is easy to execute. When you open facilities on opposite sides of the country, it seems a little more difficult. Open a facility in another country (and introduce the challenge of getting all of that uniformity across an ocean), and you're looking at a pretty daunting task.

Last month, I hopped on a plane from Houston to London to attend Cloud Expo Europe. Because I was more or less "in the neighborhood" of our newest data center in Amsterdam, I was able to take a short flight to The Netherlands to do some investigatory journalism ... err ... "to visit the AMS01 team."

Is AMS01 worthy of the SoftLayer name? ... How does it differ from our US facilities? ... Why is everything written in Dutch at the Amsterdam airport?

The answers to my hard-hitting questions were pretty clear: SoftLayer's Amsterdam facility is absolutely deserving of the SoftLayer name ... The only noticeable differences between AMS01 and DAL05 are the cities they're located in ... Everything's written in Dutch because the airport happens to be in The Netherlands, and people speak Dutch in The Netherlands (that last question didn't get incorporated into the video, but I thought you might be curious).

Nearly every aspect of the data center mirrors what you see in WDC, SEA, HOU, SJC and DAL. The only differences I really noticed were what the PDUs looked like, what kind of power adapter was used on the crash carts, and what language was used on the AMS facility's floor map. One of the most interesting observations: All of the servers and power strips on the racks used US power plugs ... This characteristic was particularly impressive to me because every gadget I brought with me seemed to need its own power converter to recharge.

When you see us talking about the facilities being "the same," that's not a loosely used general term ... We could pull a server from its rack in DAL05, buckle it into an airplane seat for a 10-hour flight, bring it to AMS01 (via any of the unique modes of Amsterdam transportation you saw at the beginning of the video), and slide it into a rack in Amsterdam where we could simply plug it in. It'd be back online and accessible over the public and private networks as though nothing changed ... Though with Flex Images making it so easy to replicate cloud and dedicated instances in any facility, you'll just have to take our word for it when it comes to the whole "send a server over to another data center on a plane" thing.

While I was visiting AMS01, Jonathan Wisler took a few minutes out of his day to give a full tour of the data center's server room, and we've got video and pictures to share with more shots of our beautiful servers in their European home. If there's anything in particular you want to see from AMS01, let us know, and we'll do our best to share it!

-@khazard

P.S. Shout out to the SLayers in the Amsterdam office who offered their linguistic expertise to add a little flair to the start of the video ... From the four employees who happened to be in the office when I was asking for help, we had six fluent-language contributions: English, Italian, French, Dutch, Polish and German!

**UPDATE** After posting this video, I learned that the "US" server power plugs I referred to are actually a worldwide computer standard called C13 (male) and C14 (female).

July 1, 2011

PHIL's DC: Fine-Tuning the Idea

When Lance opened the floor for SoftLayer employees to present their ideas for "innovative" approaches to the Internet, I put together a pretty ambitious proposal. As it turns out, the idea wasn't as fully baked as I may have wanted it to be, but I came to the decision to change gears a little and take a different approach.

Completely unrelated to that personal decision to adjust the direction of the project, I had a nice little chat with Lance on the phone. We decided that the world was underready for a revolution and that a more traditional nontraditional approach was in order:

The Internet needs data centers to hold all of your pictures. SoftLayer does a great job at being a data center, but I feel like there's still an opportunity for a revolution in data center design. I have a few ideas about how the world of web hosting can be completely redefined, and with the unique resources Lance has put at my disposal, I'm fairly confident that I'll be able to create a stellar hosting platform with an unbeatable discount price structure. PHIL's DC is the future of web hosting.

- PHIL

June 28, 2011

Modern Website Design: Layout

There have been many books written about website design, and I am not about to take on the challenge of disputing any of them or trying to explain every facet of design. In this short blog, I want to explain what I have come to understand as the modern layout of websites. The term "layout" may have many different definitions, but for this article I am talking about the basic structure of your website, meaning separation of concerns, data transfer from host to client, how to handle changes in data, and when to change your page structure.

Separation of Concerns

It is important when sitting down for the first time to build a website to come up with an outline. Start by making a list of the parts of your website and the functions of those parts. I always start at the base of my web structure and work from there. HTML is always the foundation of a website; it defines the structure and outlines how you will display your data – plain and simple. It doesn't have to include data or styles, nor does it need to be dynamic ... At its essence, it's a static file that browsers can cache.

Client-side scripting languages like JavaScript will take care of client-side animations and data dispersal, while cascading style sheets (CSS) take care of style and presentation, and server-side scripting languages like PHP or Perl can take care of data retrieval and formatting.

Data Transfer

Where is your data going to come from, and what format it will be in when the client receives it? Try to use a data format that is the most compatible with your scripting languages. I use JavaScript as my primary client side scripting program, so I try to use JSON as my data format, but that's not always possible when dealing with APIs and transferring data from remote computers. JSON is quickly becoming a standard data format, but XML* is the most widely accepted format.

I prefer to use REST APIs as much as possible, because they sends the information directly on the client, rather than using the server as a proxy. However, if a REST API is not available or if there is a security risk involved, you get the advantage of being able to format the data on the server before pushing it to the client. Try to parse and format data as little as possible on the client side of things, the client should be concerned with placing data.

Changes in Data

In the past, websites were made from multiple HTML documents, each one containing different data. The structure of the pages were the same though, so the data changed, but the code was nearly identical. Later, using server side scripting programs, websites became more dynamic, displaying different data based on variables passed in the URL. Now, using AJAX or script injection, we can load new data into a static webpage without reloading. This means less redundant code, less load on the client, and better overall performance.

Page Structure

It is important when displaying data to understand when to change the structure of the page. I start by creating a structure for my home page - it needs to be very open and unrestricting so I can add pictures and text to build the site. Once the overall loose structure is established, I create a structure for displaying products (this will be more restrictive, containing tables and ordering tools). The idea is to have as few HTML structures as possible, but if you find that your data doesn't fit or if you spend a lot of time positioning your data, then it might be time to create a new structure.

The Impact of a Modern Layout

Following these steps will lead to quicker, more efficient websites. This is (of course) not a new subject, and further understanding of web layout can be found in Model-View-Controller frameworks. If you find that you spend too much time writing code to interface with databases or place data, then frameworks are for you.

-Kevin

*If you have to deal with XML, make sure to include JavaScript libraries that make it easier to parse, like JQuery.

June 16, 2011

An Exercise in Innovation

Some of the best ideas come from people who think "outside of the box." SoftLayer was born in a living room six years ago when we decided to look at the staid hosting industry from a new perspective. We said, "We don't want to build a company to meet customers' current needs. We want to build a company to meet the needs our customers don't even know they have yet," and that's one of the biggest reasons the SoftLayer platform has IPv6, KVM over IP, private network, out-of-band management and standardized pod-based data centers.

Only people with a certain level of "crazy" can recognize opportunities for innovation, and because SoftLayer's motto is "Innovate or Die," to incubate innovation, we have to create an environment that enables employees to take their "crazy" and run with it. Speaking of "crazy," meet Phil.

Phil plays guitar, tests software in non-standard ways, and has a bobble-head of himself. Some would say he marches to the beat of a different drummer – a drummer that may or may not be overdosing on caffeine.

Phil was tasked with a 12-week project: If SoftLayer is built for what our customers are going to need tomorrow, figure out what customers will need after "tomorrow." He'd have access to people and resources up and down the organization to build his idea, and the experiment is set up to incubate his innovation:

  1. Because there are no bad ideas in brainstorming, anyone helping Phil should do so without questioning the logic or "sanity" of what he asking for help with.
  2. Phil can spend up to 20% of his work hours building his idea.
  3. Anyone who helps Phil can spend up to 10% of his/her work hours to build his idea.
  4. Phil can have space in H2 to build his idea.
  5. Regardless of apparent success or failure, the project will conclude at the end of 12 weeks. From there, we'll evaluate the "good" and "not as good" ideas from the experiment.

It'd be impossible to guarantee the success of any kind of project like this because it's a little like catching lightning in a bottle, but I was interested to see what kinds of operational changes he came up with over the course of the three months. We might see the evolution of the next brilliant idea in hosting, or we'd see a lot of hilariously terrible ideas.

Then I saw his first installment:

By the time I got to "circumstantiate," I had the phone in my hand to call off the project. What I didn't expect was Phil's tearful pleading to take the idea down a different path. They say you don't get a second chance to make a first impression, and despite the fact that this first impression was pretty awful, I decided to give him another shot (with a much more limited scope):

  1. Apparently there are bad ideas in brainstorming, but anyone who helps Phil on his "new path" should try to be supportive.
  2. Phil can spend up to 5% of his work hours building his idea.
  3. Phil can't take anyone else from SoftLayer away from their jobs during work hours.
  4. Phil can have space in the Houston office to build his idea.
  5. The project is scheduled to run for 12 weeks. There's no guarantee that it'll make it through next week.

If you have ideas for Phil, feel free to contribute. He'd probably appreciate the help.

-@lavosby

Subscribe to design