Posts Tagged 'Layout'

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.

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)

Expanded main navigation menus at the top of each page

A new lower-order navigation system on the left of all content pages

[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.

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!

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!

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).

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.