Archive for the ‘Technology’ Category

Responsive Design

September 9th, 2011 by

In the modern age, there is a lot of emphasis on making websites and applications more accessible for a variety of devices. No longer are we developing websites just for a desktop experience, we also need to think about users on handheld devices, iPads, and netbooks. With so many different resolutions to contend with, it is simply not reasonable to create a separate version of your website for each experience.

This is where responsive design comes into play. Responsive design is building your website with every user in mind. You want to make sure that your website will resize properly when viewed in a different viewport.

There are many different ways to achieve this but I’m going to focus on Fluid Design and CSS3 media queries.

Fluid Design

First, I would go ahead and download the Fluid 960 Grid System. This comes in a 12-column or 16-column grid and is percentage-based so that it resizes as the browser does.

Working with a fluid grid should handle most of what you’re looking for, but what about images and divs that need to flow with each other when the screen shrinks? That’s when we use the CSS3 media queries.

CSS3 Media Queries

If you’ve ever built a websites with print in mind, then you’ll understand this concept. This reminds me of a blog post I made about cross-browser compatibility where we talked about the many different ways to design your website with many browsers in mind. Responsive web design takes it a step further where we start thinking not only about IE, Firefox, and Chrome, but also Android, BlackBerry, and Safari mobile.

The way a CSS3 media query works is that if a certain test is passed then you push forward styles that you have developed for a particular resolution or type.

For example, in order to create a test that only serves styles based on a max width of 480px (e.g. the width of the landscape mode of an iPhone), you would create the following query:

@media screen and (max-device-width: 480px) {
img { max-width: 100%; }
}

  • @media declares the media query.
  • screen lets the browser know that this is primarily for color computer screens (CSS2 specification)
  • The part within the parentheses is the actual query. max-device-width looks at the width of the screen and says that if the width is less than or equal to 480px than to use the following styles.

There are other ways of achieving this. You can also use the link element that will serve a separate stylesheet altogether if certain conditions are met.

<link rel=”stylesheet” type=”text/css” media=”screen and (max-device-width: 480px)” href=”alternate.css” />

This will serve alternate.css for devices with a max screen width of 480px.

You can even use @import within your stylesheet:

@import url(“alternate.css”) screen and (max-device-width: 480px);

Conclusion

This should be enough to whet your appetite for responsive web design. There are a lot of great articles out there that talk about responsive web design in more detail than I have here:

Thanks for stopping by and keep learning!

Nick Beranek is a Web / Graphic Designer for Interactive Financial Marketing Group.

Code Evolution

July 22nd, 2011 by

Web Design and Development are constantly evolving, proving to be quite a challenge for those that use associated technologies. Not only are the technologies changing, but also the way that we do things. There are lots of templates and methods and it’s difficult to figure out which ones will work the best.

Technologies

There are three technologies that I’d like to focus on: HTML, CSS, and Javascript. Before people were paying a lot of attention to CSS, websites were mainly built using tables. Tables are terribly constrictive so the web fell way to div-based layouts, providing a more fluid architecture. Divs are also a lot easier to style using CSS as there are fewer restrictions to the layout. So HTML started to evolve when more and more people were using these techniques. As HTML grew, CSS did as well. Now we have a pretty robust library of elements and attributes that we can style. Now with HTML5, we have elements like header, footer, section, and article that can be styled independently, and make websites more readable by search engines. It’s important to note, however, that to use these new elements, you’ll need to have them added to the DOM. I recommend using Modernizr.js for this. It allows you to use HTML5 and CSS3 elements and have them be cross-browser compatible. There is also a new element in HTML5 called canvas which allows you to use Javascript to build rich browser-based applications without the need for Flash. I’ll talk about that in a future post.

CSS3 has brought about a lot of changes to the web. There are so many things you can do without the aid of images including gradients, rounded corners, box and text shadow, and much more. You can even rotate and skew elements and images, pretty neat stuff. Fortunately, many of these new elements are already supported by Mozilla and Webkit browsers, including Chrome and Firefox. Safari and Opera are also on board. The culprit is Internet Explorer. Even the latest version, IE 9, is struggling with some things, only scoring 141 out of 450 in The HTML5 Test. Where it really suffers is with the new form field types, like input type=tel, url, and date. It does not support these. Back to CSS3, I recommend learning these new styles now and start using them. IE 8 may not support them, but Modernizr.js is able to recreate these effects using Javascript, so cross-browser compatibility is no longer as much of an issue. I do hope that each browser gets on board, because for many of these to work you have to prepend the type of browser to the style (e.g. –webkit-border-radius instead of simply border-radius). I believe Opera is already accepting the latter.

Javascript has made some leaps and bounds, as well, with libraries like jQuery, knockout js, and YUI (Yahoo! UI Library) taking the center stage. These libraries make things exponentially easier for designers and developers alike, offering so many cool functions. They are also extremely cross-browser compatible, as well. We have also been utilizing better practices when it comes to writing our code. For instance, take the following example:


var names = [‘zero’, ‘one’, ‘two’, ‘three’, ‘four’, ‘five’, ‘six’, ‘seven’, ‘eight’, ‘nine’];
var digit_name = function(n) {
return names[n];
};
alert(digit_name(3)); // ‘three’

This is what’s called a Global function, meaning that it variables are accessible to other functions. The problem here is that if you have another function that uses the same variable name, it is going to get overwritten. The better way of doing it is using a closure statement. This ensures that the function’s variables can only be used by this function:


var digit_name = function(){
var names = [‘zero’, ‘one’, ‘two’, ‘three’, ‘four’, ‘five’, ‘six’, ‘seven’, ‘eight’, ‘nine’];
return function(n) {
return names[n];
};

}();

Take a moment and explore the options available to you in HTML5, CSS3, and Javascript. They are powerful technologies that can help you make the web a friendlier place.

Nick Beranek is a Web / Graphic Designer for Interactive Financial Marketing Group.

Why use Model View viewModel?

April 29th, 2011 by

viewModelWhat is it?

“The essence of a Presentation Model is of a fully self-contained class that represents all the data and behavior of the UI window, but without any of the controls used to render that UI on the screen.”, Martin Fowler.

The viewModel is a model for a view.  It allows UX developer to use the model without having to know back-end logic which is not their job.  It helps to think of it as Model represents or binds to the database and viewModel binds to the view.

Why use Model view viewModel (MVVM) architectural pattern?

Represent the state and behavior of the presentation independently of the GUI controls used in the interface “, Fowler.   Having a true dynamic representation of UI instead of following a strict model from the database schema is great way to develop for UI developer and for back-end developer.

Many times UX developers need to add entities time to time that are not part of the database model in order to aid users to interact with your application better.  This is a great way to program on domain driven development (DDD) environments like asp.net MVC, WPF, ruby on rails, php, and java version of MVC.

When to use it

If you are in DDD environment then it makes sense to use it all the time or most of the time.   But this pattern can be helpful for all other scenarios since this is a great way to practice separation of concern architectural model.  This design model makes sense when you need to have a multiple views or objects for a single class or data model.

Example

The modelView makes sense on registration page where you need to have different UI/view based on age.

///If you are age under 13 then display under age view else display adult view.

Public class AdultRegistration

{

public string Username { get; set; }

public string Address { get; set; }  //only in adult model

}

Public class ChildRegistration

{

public string Username { get; set; }

public bool HasConsent { get; set; }  //not in database model

}

This allows back-end developers to practice separation of concerns and strongly typed model.    It also helps UI developer to work with model that represent the view and only the entities that are necessary to them.

Will Lee is a Web Developer for Interactive Financial Marketing Group.

Web Services and Caching

December 8th, 2010 by

Over the past few months we at IFMG, have frequently stumbled across a recurring problem – one or more of our web servers belonging to the load balanced environment gets pegged resulting  in non-responsive applications costing us revenue and customer/consumer dissatisfaction.  Such server downtimes or outages tend to have a negative impact on the business and taking proactive measures to prevent such events is one of our main priorities.

In an environment that is rendering several different applications & web services, we narrowed down to one of the most frequently used web service as a suspect. There are at least two factors that contribute to the performance, or lack thereof, in web services:

  • Network transaction time: How long it takes client to make a request to remote web service?
  • The time the service itself takes to execute: This piece is often the major culprit in ill performing services. It is easy to forget that useful code can take some time to perform its function.

What if you enabled caching? What and where can you cache?

What if we tried some setting changes? Have an idea, need to experiment it – make the change, observe the impact, commit or rollback.  Repeat until we have a winner.

After integrating and building applications that leverage and exploit web services, you may have heard many times that you cannot have simplicity without sacrificing efficiency.  That being said, we experimented with enabling caching on one of our highly used web service to only discover a dramatic improvement in performance of our servers, without compromising its efficiency – A simple change with a big impact.

Caching can be a useful tool in any application. In web services, you get to leverage the cache more often, as repetitive and high load queries are many times the nature of the game. The question then arises if the responses can be cached? There lies the opportunity – identifying the processes that are repetitive and the caching the responses. The next step would be identifying how long you keep these cached items around? This can be determined by the frequency with which the parameters involved in computing change, lower the frequency longer the cache interval could be maintained.

Below is the graphical representation of the CPU utilization before and after caching enabled, SWEET!!

Dinesh Prakashchand is a Senior Web Developer at Interactive Financial Marketing Group.

So what is A/B Testing, anyway?

November 12th, 2010 by

Whether your background is marketing, sales, management, information technology (or any combination of these), you probably have your own ideas and opinions about how websites should look and function. Perhaps you’ve participated in the redesign of your company’s website. And if you haven’t, maybe you went to your company’s website one day and noticed that it was completely overhauled with a brand-new layout, images, content, banner ads, etc.

For most of us, giving a website that looks old and dated a fresh new look is a no-brainer. But if your website’s main goal is to drive some kind of conversion–e.g, selling a product, adding newsletter subscribers, getting visitors to download a trial version of your product, etc–things aren’t so simple. Whether you’re considering a complete redesign of your website or a few tweaks to the site’s homepage, you need to be aware of the possible impact of these actions on your conversion rates. While it might seem intuitive to believe that aesthetic improvements to a website or web page will improve–or at least not worsen–your conversion rates, you won’t know unless you test these kinds of changes.

This is where A/B testing comes in. In an A/B test, you are comparing the performance of two elements A and B. A is usually referred to as the control; the control is the original version of whatever it is you are changing. B is the new element that is meant to replace A. For a simple example, imagine you are replacing a button (the A version) on your website’s homepage. The button you are replacing is orange, has rounded corners, and the text “Sign up for our FREE newsletter!” You are replacing it with a blue button (the B version) that has square corners and the text “Sign up for our newsletter today!”

So let’s imagine that you are making this change because someone thought it was a good idea. The next step, then, is to do a side-by-side comparison of A and B. What this means is that you will not simply replace the orange button with the blue one. Instead, with the help of an A/B testing tool (two popular tools are Google Website Optimizer and Adobe Omniture Test & Target), you can direct half of your site visitors to the A version and the other half to the B version. You will then, over time, compare conversion rates for the two versions and eventually declare a winner (the version that drives a higher conversion rate).

In this kind of testing environment, decisions such as changing a button on a homepage are no longer driven by an individuals subjective opinions (“I’ve never liked rounded corners”; “I don’t like orange, it’s too loud”) but by statistical data that can usually (but not always) tell you whether your proposed change performs better or worse than your original version. If conversion rates on your website can be affected by this change, you should always, whenever possible, test first.

Kevin Boylan is a Senior Web Developer here at Interactive Financial Marketing Group.

Kevin Boylan is a Senior Web Developer here at Interactive Financial Marketing Group.