General

SEO: Dead? No. Different? Yes.

Fri, 04 May 2012 16:18:00 GMT

It's amazing how quickly the world of SEO changes. I was recently at an SEO seminar where I learned the basics of SEO, or traditional SEO. However, with Google and their constant updates, like Search plus your world or the new Penguin update, it seems like traditional SEO may be out the window.

This in no ways means SEO is dead, it’s just different. No longer is tracking your SERPs or spending weeks doing competitive keyword analysis the best way to boost your site traffic. Now, content really is king. There’s no denying it. Without great content, you’ll start to see your traffic decline. So, what does all this mean?

This means that you need to start creating content. And not just any run-of-the-mill content. It has to be good content. Something creative, engaging, informative. Something that people will learn from and want to share with others. This is new SEO.

Why is good content so important to the new SEO? Google is doing all that it can to make sure that you’re shown the most relevant search results when you enter a query into their site. This means that searches will be tailored to you (via your social graph) and sites that are spam (think keyword stuffing, link buying, etc.) will rank lower while quality sites will be higher. ‘Quality’ sites are those that are producing fresh, relevant content that Google sees is engaging and being shared in the social sphere.

Now, it’s still important to do some traditional SEO. You should still fill out your meta descriptions and make sure you have appropriate titles and headers. Keywords are still important (you’ll want to make sure you’re targeting the correct ones), but they are no longer the best way to implement your SEO strategy.

Remember, SEO is always evolving and it’s important to make sure that your site stays up-to-date or risk being left out of search.

Load Testing – What is “Design Load”?

Wed, 11 Apr 2012 15:04:00 GMT

In short, the Design Load for a website, or environment, is the total amount of traffic (or load) that the system is designed to support. This is the metric that describes the scalability of a system. Design load goes hand-and-hand with performance criteria as a key part of a solution’s technical requirements.

The term ‘Design Load’ is borrowed from more traditional engineering practices, in which it measures the amount of physical force that a component must be able to withstand. For example, when designing a new home or office building, the Design Load for floors and roofs will specify the minimum weight that the floors and roofs must be able to support.

Design Load Aggregates Multiple Considerations

The Design Load for a floor will incorporate a number of different elements, including the weight of furniture, equipment, people, and the weight of the floor itself. Each of these elements will vary depending of the planned usage, planned occupancy, and building materials. Similarly, a website’s Design Load includes a number of different elements:

The site’s current traffic – usually pulled analytics data
Organic growth (often 20% growth per year for 3-5 years)
Increased traffic due to the new site’s functionality or architecture (like new video streaming features or interactive polls or forums)

Factor of Safety

Back to our floor example, building codes typically require that the sum of the load elements be increased by some multiplier, or “factor of safety”. This multiplier helps to make sure the floor doesn’t collapse, even if there are minor materials defects or unplanned usage like an office party where everyone is jumping in unison to House of Pain’s “Jump Around” (OK, that’s never happened in any office party I’ve been to).

In the web world, we should also consider applying a factor of safety to protect against traffic spikes that can come from a variety of sources:

Ad campaign that goes viral
Media mention
Denial of Service (DoS) attack
Search engine indexing bots

The appropriate value for this factor of safety depends largely on the type of site and the perceived risk of traffic spikes. For a typical corporate brochure site, a multiplier of 3x is usually adequate. For a start-up, or a company actively engaged in marketing that is trying to create something viral, a multiplier of 5x might be more appropriate.

The Equation

Considering all of the ingredients listed above, the formula for calculating your Design Load might look something like the following:

DL = FS x (Current + New Features) x OG

Where:

DL = Design Load
FS = Factor of Safety (usually between 3 and 5)
Current = The site’s current traffic
New Features = Estimate of the new traffic that will result from new functionality or solution architecture
OG = Estimated organic growth (If planning for growth of 20% per year for 3 years, OG = 1.2³)

Specifying Design Load

Design Load for a website can be specified using a variety of different units and measures. For most sites, I recommend specifying the Design Load in Page Views per Second (a few exceptions are noted below). This metric is meaningful for most business stakeholders and translates well to analytics data, which is often Page Views per Day. The one challenge with this metric is that it doesn’t translate easily to most load testing tools, which are usually configured in terms of concurrent users.

Some alternative metrics that can be used to specify Design Load include:

Concurrent users - The number of users using the system at any one time. This isn’t very meaningful unless you also specify the “think time”, which is the delay from one user request to another. It also seems that every load testing tool treats concurrent users a little differently. Be sure you REALLY understand what your tool means by “concurrent users”. This metric often isn’t particularly meaningful to business types, and doesn’t translate well to analytics data.
Concurrent requests – The number of requests at any one time. This is more meaningful than concurrent users, but still needs further clarification. If the Design Load is five concurrent requests, does that mean five requests issued at exactly the same time, or does it mean five requests that are in various states of completion at any one time? Again, make sure you REALLY understand your load testing tool. Like concurrent users, concurrent requests isn’t meaningful in a business context and doesn’t translate well to analytics data.
Transactions per second – More appropriate for transactional systems where most of the systems resources are spent processing transactions rather than rendering pages.
MB per second (or GB per second) – More appropriate for systems that are heavy on video, audio, and/or images.

Design Load and Load Testing

As mentioned before, the Design Load typically helps define the success criteria for load testing. The ultimate goal of load testing is to validate that the system can support the specified Design Load while still satisfying the performance criteria. The statement this kind of technical requirement might look something like this:

“The site must be able to serve 50 page views per second, while maintaining a response time of no more than 2 seconds to serve a page’s HTML from the hosting environment to a client on the public internet.”

Load testing a site beyond the Design Load should NOT be a part of the success criteria or site acceptance, but in some cases it might provide some value for long term planning beyond the project’s planning horizon, or in case organic growth is faster than anticipated.

HTML5 Carousel with Video Player

Thu, 29 Mar 2012 16:18:00 GMT

Nowadays, many people are looking to add a rotating carousel to their homepage. Using a carousel or slider is a great way to make your site more dynamic and engaging.

Before starting you should first analyze what are your goals and in which devices you need the carousel and player to work. Deciding goals and devices first will help you avoid issues later on, especially with browser compatibility.

Why use HTML5 on your Carousel?

Better performance
Cleaner code that will be easy to maintain
No Flash plugin necessary to play your videos
Excellent for mobile devices

The main cons are related to browser compatibility, especially with older versions of Internet Explorer (IE6, IE7). These versions tend to ignore the HTML elements that they don’t understand meaning the, tag <video> will not be rendered (to get these tags to function, you either need to put an image or a text message instead or encourage your visitors to update their browsers to newest versions).

Choosing your jQuery Plugin

This is a crucial decision that will be reflected in the outcome of your carousel, especially if you have a video player included on your slides.

A very popular jQuery plugin that I usually use is Cycle Plugin; however, after including a video and testing it on all browsers I found that there is a critical issue with IE9: It doesn’t show the video player and there is no way to make it appear. This is unfortunate because Cycle Plugin is very flexible and easy to program, but I do not recommend it in this case.

The second option will be a plugin called Coda Slider. It is not as complete as Cycle plugin, but it solves the IE9 issue and it is easy to install on your site.

The disadvantage of this plugin is the lack of support and its poor flexibility when trying to build custom features. For instance, if you need to change the slide effect or to create play and resume functions, you might have to do them manually.

Installing Coda Slider Plugin on your site

Including HTML5 on you Carousel

You need to have a code similar as the following for each slide:

<h1>Slide Title</h1>

<p>Slide Description Text</p>

</video>

</article>

</div>

Let me know how this works when implementing an HTML5 carousel in your site.

References:

jquery.malsup.com/cycle/

www.ndoherty.biz/tag/coda-slider/

Useful tools for cross browser compatibility testing

Fri, 02 Mar 2012 21:10:00 GMT

In cross-browser compatibility testing, it is necessary to have several environments set. Although having virtual machines is a good choice, it often becomes a hassel to switch between environments. There are some helpful tools that can reduce all this configuration work.

1. Netrenderer

Netrenderer is a tool that allows you to check how a site is rendered in different versions of Internet Explorer. You don’t need to have an account or download a program. Just type in the URL to be tested, select the Internet Explorer version and the page will be rendered. This tool is recommended for testing specific sections of a page.

Pros
• It avoids the necessity of having a virtual machine to install the desired browser version
• Rendering takes seconds to be executed
• It lets you compare between browser versions (IE6 – IE7)

Cons
• Renders only one page at a time
• It doesn’t show the complete page, making it necessary to add a vertical offset value to see the content
• Incompatible with internal network sites

2. Browser shots

Browser Shots is an online tool that lets the user see screenshots of a desired page in different browsers and operating systems. It permits choosing the screen size, color depth, JavaScript, Java and Flash settings. It offers a trial version and as well as paid versions. To use, just insert the URL, choose the browsers, and set the options mentioned before. When the screenshots are done loading, it shows a report of uploaded, available and expired browsers. You can download them all in a zip file if needed.

Pros:
• There are a wide variety of browsers to choose from
• It is possible to choose the screen resolution and enable other options

Cons:
• Only supports Windows XP screenshots
• Sometimes sessions expire and some screenshots are missing
• The results are slow if you compare a lot of different browsers
• Very few options for Mac OS

3. CrossBrowserTesting

CrossBrowserTesting is a tool that offers many services:

• Interactive live testing: This lets you launch a browser, a screen resolution, an operating system and a platform on their server. Then you only have to enter the URL to test.

When the page is loaded, there are many options that the user can access, including: capture screenshots, record sessions and capture packets. For all of these options a report is generated and saved into a project.

• Run automated screenshots: Lets you choose the resolution of the selected operating systems/browsers/versions of the same URL. It loads the screenshots immediately.

• Local Connection: Makes it possible to test local files or websites behind a firewall. You only have to give permissions to an applet, choose the URL to be tested, select the platform and browser and you’ll see the site in their virtual machine. Any changes made will be automatically reflected.

• Bookmarklet: Just by dragging a button to the bookmarks bar you will have instant access to test any page.

Pros
• Easy to use. Instant access from the web browser.
• Lets you record the testing.
• Generates reports of screenshots and stress tests.
• Makes it possible to set up connection to test local files not yet uploaded to a server or internal web sites behind a firewall.

Cons
• Payment required

4. Browsera

Browsera is an online tool that analyzes a site completely and simultaneously in many browsers while identifying errors instead of just taking screenshots. When creating a new account, you will be prompted to add a project name, the baseline browser (the browser that you test most often), the URLs to be tested and the additional pages linked from the inserted URLs.

After the testing is done, you’ll get an email with a notification, a small report and a link to see the complete results. In the image below, the left section contains the URLs tested with errors and warnings found. On the right side, issues are better explained and a screenshot of each browser highlights the section that shows the error.

It also supports HTTP Basic authentication as well as application based logins, this is a critical feature when testing user profiles.

Pros:
• It shows errors found in each browser
• Creates a report of the results via an URL that can be shared.
• Takes screenshots of linked pages.

Cons:
• It is not possible to choose operating systems or devices; you can only choose the broswer.
• It doesn’t have the latest browsers versions (i.e. Chrome is only available until version

5. Microsoft Expression Web SuperView

This is a desktop tool that permits loading a page in all versions of Internet Explorer and the installed browsers. The user only has to add a baseline browser and the other required browsers to test and compare all of them at the same time. There’s an Overlay Layout option to see the differences between two browsers. It is also possible to upload a PSD file or an image to compare.

Pros
• You can see and compare all Internet Explorer versions
• It has the “remote browsers” option to test in uninstalled browsers

Cons
• It doesn’t support Linux platforms (In remote browsers)

These tools can help provide very useful information in your compatibility testing, depending on the testing platforms and the environments needed. Most of them offer screenshots, reports and results that are helpful to the process.

Browser Compatibility Testing: What to test, when to test, and other useful tips

Thu, 01 Mar 2012 19:12:00 GMT

When testing a site in different browsers, platforms, and devices, there are some details that QA testers may not take into account which can result in losing time due to retesting functionality or specific behaviors that they didn’t know would be different between environments.

Browser compatibility testing is a stage that needs special attention in the QA process. It is so important because results might be different depending on many variables (i.e. the platforms used, the time when tests are executed, the site’s sections tested, etc.)

(1) What to test

There are many elements that will not change across browsers (like images size, fonts color, texts padding and pages background). However, there are many other elements that will need more attention:

Font size and font style: some browsers overwrite these properties
Special characters with HTML character encoding
Controls alignment: bullets, radio buttons and checkboxes might not be correctly aligned
Information submitted to the database: if there are forms that interact with the database, it is necessary to verify that the information is correctly stored
HTML5 video format: users must be aware that depending on the player or plugin used, not all the browsers are able to play all the existing video formats. For example, Internet Explorer 9 will only play .mp4 videos and Firefox 9 will allow only .webm videos while Chrome will be more flexible (.mp4, .webm, .ogv and other video formats). This is an issue that should be taken care of by the development team and the QA team.
Text alignment: some dropdown items will look good in Internet Explorer while in Safari they might appear too close to the upper margin.
Plugins developed by external sites: some jQuery plugins might not work correctly, like print functionalities in IE8 or carousel rotation when playing videos.
CMS compatibility: be sure to know the browsers that the Content Management System supports and focus mostly on that browser verses other ones.

(2) When to test

As a best practice, it is useful to choose just one browser/platform and make all the testing on it during the development process. This browser should be the same as the one used by the development team. It is recommended that browser compatibility testing stage be executed at the end of the development process for two reasons:

Most of the development process will be finished, including resolved bugs. Consequently, there’s a major probability that some issues will not be related to a specific browser but to the site itself.

Work schedule is better structured. It will be easier to focus on testing a site using Chrome for Mac for 5 hours and then Internet Explorer 8 for Win7 for another 5 hours than to focus on testing one functionality in each platform every time a new module is released.

(3) What browser and platform should be tested?

The browser and platform selection should be specified during the Requirements Gathering process, this way the whole development team, QA team, and client will be aware of which browsers will be used from the beginning of the software development process. This is the time in the process where you should do research on the most used browsers in order to make a suggestion on which ones should be tested.

Here are the most used browsers in 2011:

2011	Internet Explorer	Firefox	Chrome	Safari	Opera
December	20.2 %	37.7 %	34.6 %	4.2 %	2.5 %
November	21.2 %	38.1 %	33.4 %	4.2 %	2.4 %
October	21.7 %	38.7 %	32.3 %	4.2 %	2.4 %
September	22.9 %	39.7 %	30.5 %	4.0 %	2.2 %
August	22.4 %	40.6 %	30.3 %	3.8 %	2.3 %
July	22.0 %	42.0 %	29.4 %	3.6 %	2.4 %
June	23.2 %	42.2 %	27.9 %	3.7 %	2.4 %
May	24.9 %	42.4 %	25.9 %	4.0 %	2.4 %
April	24.3 %	42.9 %	25.6 %	4.1 %	2.6 %
March	25.8 %	42.2 %	25.0 %	4.0 %	2.5 %
February	26.5 %	42.4 %	24.1 %	4.1 %	2.5 %
January	26.6 %	42.8 %	23.8 %	4.0 %	2.5 %

Here are the most commonly used Operating Systems in 2011:

2011	Win7	Vista	Win2003	WinXP	Linux	Mac	Mobile
December	46.1%	5.0%	0.7%	32.6%	4.9%	8.5%	1.2%
November	45.5%	5.2%	0.7%	32.8%	5.1%	8.8%	1.0%
October	44.7%	5.5%	0.7%	33.4%	5.0%	8.9%	1.0%
September	42.2%	5.6%	0.8%	36.2%	5.1%	8.6%	0.9%
August	40.4%	5.9%	0.8%	38.0%	5.2%	8.2%	0.9%
July	39.1%	6.3%	0.9%	39.1%	5.3%	7.8%	1.0%
June	37.8%	6.7%	0.9%	39.7%	5.2%	8.1%	0.9%
May	36.5%	7.1%	0.9%	40.7%	5.1%	8.3%	0.8%
April	35.9%	7.6%	0.9%	40.9%	5.1%	8.3%	0.8%
March	34.1%	7.9%	0.9%	42.9%	5.1%	8.0%	0.7%
February	32.2%	8.3%	1.0%	44.2%	5.1%	8.1%	0.7%
January	31.1%	8.6%	1.0%	45.3%	5.0%	7.8%	0.7%

Information from w3schools.com

(4) Set priorities

Depending on different aspects of the software process (like the number of developers working on the project and how much time is left on the project) there should be an analysis of the issues that are critical to the site versus the time needed to fix them and if they represent an obstacle to desired behaviors. This analysis is required to make sure critical issues are solved sooner than irrelevant bugs that might take more time to be fixed.

(5) Oshyn’s experience

The following graph shows the results of a cross-browser compatibility tests on a recent Oshyn project. Google Chrome for Mac seems to be the browser with the lowest amount of bugs, while Internet Explorer 8 for Windows Vista had the highest amount of issues. It is important to note that Internet Explorer 9 has not been added to this chart because the testing of the site was made using this browser.

Cross-browser compatibility testing is a critical stage in the QA process. It helps find unnoticed errors and gives you a chance to add improvements to the final product.

References:

Browser Statistics Month by Month, http://www.w3schools.com/browsers/browsers_stats.asp

OS Platform Statistics, http://www.w3schools.com/browsers/browsers_os.asp

Theming your jQuery Mobile site using ThemeRoller

Tue, 13 Mar 2012 15:07:00 GMT

The best way to theme your jQuery Mobile site is using ThemeRoller; an online app that allows you to create up to 26 theme "swatches" and download them for free.

Getting started

To access the app you need to go to http://jquerymobile.com/themeroller/

By default you will start with three swatches that look the same: A, B and C. You can add as many as 26 swatches, just by pressing the plus sign next to the letters on the left menu.

Theming

The easiest way to create your own color combinations is just drag one of the colors at the top to any element of a swatch.

Notice that you can adjust the "lightness" and "saturation" to get more color options. You can also use the Adobe Kuler swatches that provide coordinating color combinations.

Another great feature of ThemeRoller is the "Inspector". If you have used firebug or any of the browsers developer tools you will find this tool to be very familiar.

Turn the inspector "on" and select any element on the swatch you want to edit.

Once the element is selected, the related properties will be displayed on the left menu.

Here you can use more precise coloring with hexadecimal format and control shadows, borders, etc.

Notice that there are global styles for all swatches and custom styles for each one.

Exporting and Downloading

To export and download your newly created swatches, click the "Download Theme" button at the top left of the page.

Add whatever name you want and click on "Download Zip".

Inside the zip you will find the css file, as well as a minified version of the same file. You will also find a folder with the icons used by the theme. Follow the instructions to reference your new stylesheet and enjoy!

Note: You can edit your theme later using the "Import" button in the web app.

Getting started with jQuery Mobile

Fri, 10 Feb 2012 17:12:00 GMT

Most companies have already an established website, but are lacking a very important aspect. The number of smartphones and tablets on the market currently only continues to increase; this means that everyday more and more people are trying access your content on these devices. However, with such an increase in mobile visitors, there has not been as great of an increase in mobile-optimized sites, therefore, most webpages are just not meant to be viewed on smaller resolutions.

This is where jQuery Mobile kicks in! jQuery Mobile is a JavaScript framework that is touch-optimized, allowing developers to create a mobile version of a website in less time as well as presenting the complete functionality to the end user.

This tutorial will show you how to start using jQuery Mobile in just a few, easy steps and get something like this:

Requirements

To start using this powerful framework, you will need the following files:

jquery.mobile-1.0.1.min.css
jquery-1.6.4.min.js
jquery.mobile-1.0.1.min.js

The first file sets the basic styles for your website (I will show you how to customize the look and feel of your app using ThemeRoller in a future post).

The second file is the jQuery framework, this is the base of the mobile framework and it will need it to run properly.

The third and last one is the Mobile library. It contains all the necessary JavaScript for a great mobile experience.

You can download these files and host them yourself or add the recommended snippet that points to the files on the jQuery servers:

<link rel="stylesheet" href="http://code.jquery.com/mobile/1.0.1/jquery.mobile-1.0.1.min.css" />
<script src="http://code.jquery.com/jquery-1.6.4.min.js"></script>
<script src="http://code.jquery.com/mobile/1.0.1/jquery.mobile-1.0.1.min.js"></script>

Declaration

For this example I’m going to be hosting the files myself.

So, let’s start with the document declaration, it’s basically an HTML5 declaration with a <meta> tag that will control the layout and rendering for mobile devices, recognizing the device’s width and using it to rescale the display.

<!DOCTYPE html>
<html class="ui-mobile-rendering">
<head>
	<meta charset="utf-8">
	<meta name="viewport" content="width=device-width, initial-scale=1">
	<title>oshyn.com</title>   	
	<link rel="stylesheet" href="css/jquery.mobile.structure-1.0.1.min.css" />
	<link rel="stylesheet" href="css/oshyn.css" />
	<script src="js/jquery-1.6.4.min.js"></script>
	<script src="js/jquery.mobile-1.0.1.min.js"></script>
</head>

You’ll see that I’ve added my own stylesheet to tweak the look of the site a little bit.

Structure

One big advantage to exploit is that you can have several pages on one html document. This comes very handy for navigation purposes; you can have your entire navigation structure in a single html document and only create separate documents for content pages.

Technically you could build your entire site on one document, but I don’t recommend it because it could result in a heavy site to load the first time.

Here’s an example of two pages on the same document:

<body>
	<!---------------------------------------------------------------------->
	<!---------------------------Home Page---------------------------------->
	<!---------------------------------------------------------------------->
	<div data-role="page" data-theme="a" data-add-back-btn="true">
		<div data-role="header" data-theme="a">
			<h1><a href="index.html"><img src="images/logo.png" alt="oshyn.com" /></a></h1>
		</div>
		<div data-role="content"> 
			<ul data-role="listview" data-inset="true" data-theme="a" data-dividertheme="a">
				<li data-role="list-divider">home</li>
				<li><a href="expertise.html" data-transition="slide">expertise</a></li>
				<li><a href="#solutions" data-transition="slide">solutions</a></li>
				<li><a href="#work" data-transition="slide">work</a></li>
				<li><a href="#resources" data-transition="slide">resources</a></li>
				<li><a href="#partners" data-transition="slide">partners</a></li>
				<li><a href="#company" data-transition="slide">company</a></li>
			</ul>
			<br /><br />
			<ul data-role="listview" data-theme="b" data-dividertheme="a">
				<li><a href="contact.html" data-transition="slide">Contact Us</a></li>
				<li><a href="contact.html" data-transition="slide">Privacy Policy</a></li>
				<li><a href="contact.html" data-transition="slide">Terms of Use</a></li>        
			</ul>
		</div>
		<div data-role="footer">
			<h1>©oshyn.com</h1>
		</div>
	</div>	
	<!---------------------------------------------------------------------->
	<!-----------------------------solutions--------------------------------->
	<!---------------------------------------------------------------------->
	<div data-role="page" data-theme="a" id="solutions" data-add-back-btn="true">
		<div data-role="header" data-theme="a">
			<h1><a href="index.html"><img src="images/logo.png" alt="oshyn.com" /></a></h1>
		</div>
		<div data-role="content"> 
			<ul data-role="listview" data-inset="true" data-theme="a" data-dividertheme="a">
				<li data-role="list-divider">Solutions</li>
				<li><a href="sample.html" data-transition="slideup">Overview</a></li>
				<li><a href="sample.html" data-transition="slidedown">Content Management</a></li>
				<li><a href="sample.html" data-transition="pop">E-Commerce</a></li>
				<li><a href="sample.html" data-transition="flip">SOA</a></li>
				<li><a href="sample.html" data-transition="slideup">Portals & Collaboration</a></li>
				<li><a href="sample.html" data-transition="slidedown">Web Strategy</a></li>
				<li><a href="sample.html" data-transition="pop">Mobile Platforms</a></li>
				<li><a href="sample.html" data-transition="flip">Social Media</a></li>
			</ul>
			<br /><br />
			<ul data-role="listview" data-theme="b" data-dividertheme="a">
				<li><a href="contact.html" data-transition="slide">Contact Us</a></li>
				<li><a href="contact.html" data-transition="slide">Privacy Policy</a></li>
				<li><a href="contact.html" data-transition="slide">Terms of Use</a></li>        
			</ul>
		</div>
		<div data-role="footer">
			<h1>©oshyn.com</h1>
		</div>
	</div>
</body>

Attributes

Here are some of the most important attributes you'll use:

data-role

Notice that setting the data-role attribute to "page", it automatically defines that piece of html as a separate page, and it can have it's own header, content and footer.

This way you can access the different "pages" only using the page id.

If you set it to "listview" on a <ul> it will generate the typical navigation you find in mobile apps.
data-add-back-btn

Another attribute that is extremely useful is the "data-add-back-btn"; if set to true will automatically place a back button when needed.
data-theme

The "data-theme" attribute changes the theme of that specific piece of markup, there are several themes defined by default, just try changing the letters to a,b,c to change the colors.
data-transition

This attribute defines the effect that will be shown when changing from one page to another, the values can be: slide, slideup, slidedown, pop, fade and flip.

Example

To take a look at a live sample of Oshyn's mobile site or download the Oshyn mobilie site example.zip

The Importance of Compatibility Testing in a CMS Implementation

Wed, 22 Feb 2012 22:23:00 GMT

Compatibility Testing is one of the most important test types when performing Quality Assurance on a software development project. Web compatibility testing is when you test the site using a variety of different criteria on different browsers, operating systems (OS) and screens to verify if a site will work on all.

This means a compatible website should be able to run on different platforms with all the functionality and features working the same on each platform.

When testing for browser compatibility, pay special attention to:

Web browser: Which is the most used web browser that our clients (and their customers) use? (i.e. Firefox, Chrome, IE, etc. )

Operative systems: What operating system do they use? (i.e. Mac, Windows, Linux)

Screen resolution: Test the most common screen resolutions like, 800 x 600 pixels, 1024 x 768 pixels, 1280 x 800 pixels, etc.

Why is browser compatibility so important?

Nowadays, users have their choice of browser platforms and these platforms are constantly being updated with new releases., Sometimes, these releases are focused on user experiences, so the compatibility of the website is a big challenge for designers and developers.

The main thing to ensure is that all the functionality and features are working in the same, no matter which web browser, OS or screen resolution the site visitor is using. Web browser compatibility tests allow you to identify issues, like lost functionality on a particular browser, which may impact the user’s perception of quality.

As we know, there are a lot of web browsers and they release new versions all the time, testing all these web browsers would take too much time and a lots of effort.

But how necessary is to test the website in all this browsers?

The World Wide Web Consortium (W3C) is an international community where developing protocols and guidelines that ensure the long-term growth of the web¹. The W3C posts monthly reports that depict web browser, operative system and screen resolution are the most used.

W3C Web Browser Market Share (Jan. 2012):

Charts from www.w3counter.com

Based on these statistics, a QA team can decide which web browser, OS, and screen resolution we should use to test website.

So it is not necessary test all the web browsers we only need to define the trends on each section , as web browsers, OS, screen resolutions.

In this way we should use Chrome 16, IE8, firefox9, IE9 as top web browsers, also we should use win7, winXP, Apple OSx as OS, and 1024x768, 1366x768 as screen resolutions

There are also many apps (free and paid) that can be useful when you want to conduct web compatibility testing. The most used are: BrowserShots, NetRenderer, CrossBrowserTesting, BrowsrCamp, and Browsera.

SEO Basics for Your Site

Fri, 02 Mar 2012 22:30:00 GMT

Recently, I attended an SEO workshop by Search Engine Academy where I learned all about incorporating proper SEO into a site. The number one thing I took from the class was that SEO is complex and it can take a long time to see results; however, if done properly, you won’t have to worry about adjusting your strategy every time a search engine updates their algorithm.

Here are some steps to insure your site has the basics of SEO incorporated:

Do your keyword research. Who knows your industry better than you? Start with the words you know and build off of those. Just because you use a certain phrase in your industry doesn’t mean that your customers are using the phrase.

Tools like Wordtracker or Google Insights can help you find relevant keywords.

Use your keywords. Now that you know what your keywords are, use them. But make sure that you avoid keyword stuffing. Also, remember not to just use keywords in your copy, they should also be in your headlines, meta tags, image alt tags, etc.

Note: Write your content for humans! Write your copy for a human reader and then adjust to add keywords after. Read your copy out loud or have someone else review it to make sure it makes sense. If someone finds your site through search but can’t read it, you won’t get results.

Submit your pages for indexing. Now that you’ve made all of this amazing content, make sure search engines are finding it. It’s also a good idea to make sure you’re not forgetting about other search engines like Yahoo or Bing. Yes, Google is huge, but people still use other search engines so ignoring is the same as ignoring potential customers who use them.

Share! Remember, you can’t just rely on search engines to get your company found. You need to spread the word yourself! Utilize inbound marketing to draw people to your site through great content (white papers, blog posts, ebooks), share links on social media, and submit articles to other blogs or industry publications.

Set, test, tweak. Lastly, SEO is not a one-time thing. It takes time to see results and it takes on-going maintenance to make sure everything is working. You should be tracking your efforts on a regular basis (monthly, bi-monthly, quarterly, etc.) to see what efforts are working and what efforts are not. Maybe a keyword isn’t pulling in the types of visitors you are after or maybe your blog has a high bounce rate. Tweak these issues and track again.

SEO is not a set-it-and-forget-it feature. You need to keep an eye on it and tweak it, but if you follow these basic steps, your maintenance should be low and manageable.

Software Performance Tests: How to Know When to Stop

Fri, 03 Feb 2012 23:52:00 GMT

A common mistake during the performance testing process for a web application is not establishing clear, achievable, or realistic goals. Often, you’ll hear: “I want a fast response time application.” “How fast?” “Extremely fast!”

These types of questions usually receive non-descript, vague answers that often lead to endless performance test cycles. These endless performance test cycles then add up to higher costs and delays with the project.

As part of the performance test process, we have to guide and support to the customer through the appropriate and accurate questions that can predict and represent the application behavior on the production environment. This guidance and support is important because most customers do not have the knowledge required to define the performance criteria of the web application.

To be successful in this process, it is best to write a simple questionnaire (you may want to look at the application capacity planning for some question ideas). The main objective of this questionnaire is to determine the most common scenarios the application will face.

For example:

(1) What are the most common action/set of actions that the users will do in the application? (It is best to try not to exceed five.)

(2) How many actions/set of actions will be performed in a day?

(3) What is the time range for a peak transaction load? (E.g. From 9:00 am to 11:00 am (two hours).)

(4) How many actions/set of actions will be performed during the peak transaction rage time? (It can be defined as percentage of an entire day as well.)

(5) What is the acceptable response time (define a range) for each action/set of actions? (Consider the system/application response time (as click, page load, etc.). E.g. from 1 - 3 seconds.)

(6) Does the performance test environment have same features as the production environment (CPU, Memory, Disk, and Network)? (Note: This is one of the most important items to consider.)

It is very useful and desirable to match this information and ratify it against the old application statistics (if you have one), or collect extra information from other parallel systems that can provide valuable data to support and complement the gathered information.

This information, plus an adequate and careful analysis and its interpretation, will generate measurable and achievable performance criteria that will help you define the most important feature: realistic goals.

Introduction to Load Testing – Lessons from Journalism

Wed, 22 Feb 2012 19:00:00 GMT

Load test planning and journalism have some important similarities. Both activities need to answer the same core questions: Who? What? When? Where? How?

Who?

How many users do we need to simulate? This is a fundamental question when planning any load test, and one that is surprising difficult to answer. This parameter is also referred to as the Design Load of the system. I'll leave an in-depth discussion on this topic for another post, but the short answer is that the simulated user load should consider:

Current traffic
Addition traffic created by the ongoing project - Are we adding a mobile site? Better SEO?
Organic growth - a commonly used growth rate is 20% per year for 3 years (or whatever the planned time horizon is before a replatform, redesign, or hardware upgrade)
Traffic spikes – these short term bursts in traffic can be caused by a variety of events: ad campaign gone viral, media mention, Digg, etc.

What?

What aspects of the system are we trying to test? Are we trying to simulate transaction processing, test the system integration points, or simply pressure-test content delivery? Ultimately, the "what" question can be answered with a list of URL's, or a "script", that the simulated users will follow. Consider including the following:

High profile pages – prominent pages on the site that get a lot of traffic (think Home Page)
High impact pages – strategically important pages in user the experience, capture or conversion process
System integration points – are there pages that invoke back-end integration with other systems? These are often performance weak spots.
Transactions – are there transactional elements to the system? Maybe capturing a ContactUs form or processing a shopping cart?

When?

If the system to be tested resides in a shared environment with other live production sites, consider scheduling the load testing for an off-peak time to minimize the impact to live traffic.

Where?

From where should we run the load tests? This right answer here depends on what we said we wanted to test.

Internal testing - load testing from inside of our own network is the best option when we want to test specific elements of the system, like just the database, or just your new Web Content Management (WCM) system. Testing from an internal environment is also preferable if we are trying to establish precise benchmarks or do troubleshooting - it eliminates as many uncontrolled variables as possible.
External testing - load testing from outside of the production environment provides more of a "real-world" simulation and tests the entire system. Because external testing includes system elements like the network, load balancing hardware, and even our ISP, it gives us a more realistic picture of the response times our users will see. Unfortunately, these additional uncontrolled variables also make it more difficult to establish precise benchmarks or to pinpoint bottlenecks. With external testing, it is important to specify exactly where the load test software will be running, especially if we're defining technical performance requirements. For a site hosted in the U.S., network latency will be smaller from the Bay Area compared to Manila.

How?

If we've answered the first four questions, we're probably in a good position to start selecting the right load testing tool. Here are some additional considerations to think about before we begin the hunt:

What is our budget? (think in terms of time, effort and money)
Are we looking for a tool for one-time testing or to test on an ongoing basis? (load testing monthly releases)
Who will be using the tool? Some tools are intuitive enough to be used by any semi-technical individual; others require extensive training and/or developer skills
What types of analytics are we looking for?

Just the Facts

One final point of similarity between load testing and journalism is that both are most effective when focused on the most important facts. When answering the five questions above, it's crucial to focus intensely on just the most important functionality and pages. Without such a focus, load testing can become a black hole. It's very easy to go overboard and spend an endless amount of time and energy testing countless combinations and permutations of scenarios, pages, and benchmarks. Stick to the most critical points and time-box your load testing effort to avoid the black hole.

The Software Development Process: Scrum Projects

Fri, 10 Feb 2012 01:21:00 GMT

(This is Part II of a two-part piece. Click here for Part I) The scrum methodology offers flexible, results-oriented project structures with an emphasis on incorporating and embracing change throughout a project’s lifecycle. It’s an ideal framework for projects that evolve and change as much as software development projects do. Seriously, if I told you, “We can give you what you want and need, we can have something for you to test within a few weeks, and we can incorporate loads of changes as the progress progresses,” wouldn’t you say that sounds like a great plan?

Scrum is minimalistic, but not simple. It’s basic, but has the framework to handle the most complicated and evolving software projects. The fundamentals of Scrum keep everyone involved on the same page throughout the project’s entirety and ultimately results in a higher-quality product at the end of the project.

Basics of Scrum

To start, you have a Product Backlog – a list of features and functionality outlined in user stories that effectively communicates the goals of the site or software. User stories are carefully outlined to incorporate the different functionality that the users need to be able to do (i.e. Create a Username/Password to gain access to the site or the ability to save out a document and name it however they want). Each user story is then prioritized by the product owner, the person who is assuming the responsibility of determining the budget, direction, and overall final product. As the user stories are prioritized, the scrum master can then take each of the user stories that will fit into an iteration, or sprint, of no more than 3-4 weeks. The development team then tackles the user stories that have been assigned to that sprint, testing their work as they go. Throughout the sprint, the team (product owner, scrum master, and development team) meets daily to review the progress and in a meeting that should never last longer than 15 minutes, the team gives their status – what they did yesterday, what they’re going to do today, and any impediments that are standing in their way. At the end of the meeting, the development team breaks to take care of the day’s work while the scrum master focuses on getting the impediments out of the way so that the developers’ progress is not slowed.

This goes on for the duration of the sprint and, at the end the team has something that has been set up to be accepted by the product owner as software that’s performing as expected. While the product owner reviews and accepts the sprint’s work, the development team jumps into the next sprint’s activities, which were planned and prioritized by the scrum master and product owner while the previous sprint was being developed. This process goes on as long as there is work in the product backlog and funding from the product owner.

Benefits of Scrum

While the logistics of scrum seem fairly simple, the potential benefits to running a project this way can be monumental. From the high level of flexibility that allows for the inevitable changes to be incorporated to the highly increased speed to market, scrum offers benefits that make it difficult to ignore when starting a software development project.

Change, Change, and More Change

Every project is going to experience some level of change – whether it’s about building a car that can be driven on Mars or a piece of software that creates the CAD files that will aide in the design of the Martian rover, change is all but inevitable. By breaking the project down into small, digestible pieces and keeping everyone involved throughout the process, change is much easier to incorporate and encouraged to benefit the overall success of the project.

You Don’t Know What You Want Until You Interact with It

Oftentimes, you don’t know what you want until you interact with it. When you’re in the planning phases, you may think that one piece of functionality seems like the best idea anyone’s ever had, but once it’s built, you realize that you don’t need it at all. Approximately 64% of the features that are built into software projects are used "rarely" or "never"¹. So why are companies dumping their limited funds into a project where such a high percentage of the features and functionality will never be used? Because they’re trying to plan for everything they may need…and they don’t know what they will or will not need until they interact with it. Imagine prioritizing everything on your list from the most important to the least important and, as the project progresses, there are other features and functionality that come up that you may have overlooked in the initial planning phases.

Reducing the 64%

Because you have already determined which features are the most important, you can prioritize these changes in the queue with the other features and, as changes come up and new technologies, ideas, requirements come up, you can prioritize them in comparison with everything else in the queue and bump the lower priorities off the list, if necessary. Since you’re not locked in to any specific functionality outside of the current sprint, you have the flexibility to reassess requirements and reprioritize as necessary. You can even knock functionality out if you find that it’s not as important as it initially seemed, therefore eliminating features that may end up a part of the 64% that are rarely or never used.

Quicker to Market

Theoretically, at the end of each sprint, you have something that can be pushed up to a live environment and, since you’re prioritizing features and functionality as you go along, you’re always going to have the very most important things coming out of the early iterations. After a few sprints, you have a reasonably-sized site or piece of software that can be pushed out into the world, where it can begin collecting user data to incorporate changes and enhancements into future sprints.

Higher Satisfaction of the Final Product

Since the product owner has been involved throughout the process, the probability of acceptance at the end of each sprint is very high. This allows the development team to continue forward movement on a project rather than having to stop, go back, and do something over or make significant changes. However, even if changes are requested at the end of the sprint, it’s easy for the team to incorporate them into future sprint so that they don’t lose momentum. Ultimately, everyone from the product owner to the development team will experience a higher level of satisfaction on the overall project because everyone is working together to create the best product possible.

I think where scrum makes people uncomfortable is in its inherent flexibility and how encouraging it is of change. Many people, at some level, are uncomfortable with change and that’s totally normal – people like to know what the plan is so they have some reassurance that they’re headed in the right direction. They want to know what the outcome or final product will be. However, software development projects are always going to change, regardless of whether they’re run through a waterfall approach or with an agile methodology. Scrum simply provides a more accommodating environment for these all but inevitable changes, resulting in a more focused and successful solution.

PART II REFERENCES

1 - http://esj.com/articles/2009/02/10/agile-and-the-fine-art-of-gathering-application-requirements.aspx

The Software Development Process: Building a House or Building a Car for Mars?

Mon, 09 Jan 2012 21:07:00 GMT

Some say software development is like building a house. I disagree – a house doesn’t move, isn’t expected to perform outside of staying upright and weatherproof in a storm (which is very important, don’t get me wrong), and is built on a foundation of knowledge that has been evolving over centuries. I think software development is more like trying to build a car that will do 0 to 60 in under 2.3 seconds…on Mars.

Why would I say 0 to 60 in less time than a Bugatti Veyron or a Porsche 911 Turbo? When was the last time you started a substantial project with the mindset, “As long as it’s somewhere between sub-par and acceptable, that’s fine with me.” People want their software development projects to be amazing – the solution needs to be fast, high-quality, optimized for search engines, fully functional, and stable. And, of course it needs to be at the forefront of cutting edge technology because the second you start the project, the clock is ticking on that technical solution becoming outdated.

But why does it need to be built to be driven on Mars? Simple, while the technology behind building a car has been evolving for over a century, there are things that can be assumed with a fair amount of certainty about building a car to be driven on Earth – you know what components you’ll need, the effect of the Earth’s gravity, how the car will behave in the environment and weather conditions, etc.

However, if you’re building a car to be driven on Mars, there are many more factors to consider – the Martian terrain is going to be different from most driving conditions on Earth – your suspension will have to be completely different, the heating/cooling system will need to be pretty robust to keep the driver comfortable (…and alive), and you’re going to need some sort of system to supply breathable air to the driver. You’re also going to have to make assumptions on the environment (gravity, surface composition, etc.) based on research that has already been done and information that has already been gathered by those who’ve explored the environment ahead of you.

Building a House vs. Building a Martian Car
But the biggest difference between building a house on earth and building a car on Mars is that technology for building a Martian car is going to change rapidly as more is learned about the environment and new innovations are made. As soon as you start the project, you’ll be trying to hit a moving target while the overall goal remains the same – 0 to 60 in under 2.4 seconds and do it on Mars. While you can plan for changes to occur and set the project up to be able to handle the new information that comes in, you’re still going to have an ever-changing environment and list of requirements for building this car that wouldn’t be an issue if you were building the car to drive on Earth.

Much like a Martian car, building software is often like chasing a moving target. New technologies, enhancements to programming languages, and other developments are constantly bombarding the software industry. Since you want to incorporate the most up-to-date information and features into your solution, the scope and requirements are bound to change as the project progresses to ensure you end up with the very best possible product. You just need to structure your project in a manner that supports and allows for changes throughout the development cycle and the best way to do that is to break it down.

Break Up the Project
By breaking the project into smaller pieces, you’re giving yourself the opportunity to interact with individual pieces to test their feasibility in the bigger picture. You wouldn’t commit to driving a newly-built car on Mars without thoroughly testing each of the individual components, would you? If you’re going to be the one driving the car, you want to see that the heating/cooling system is functioning, the drivetrain is working, and the tires have been tested to ensure they will maintain traction over the Martian surface. You’re not going to put the car together, drive it through an off-road course one time, and load it onto a rocket – you will test each and every component before you even consider testing the final product. As you interact with each component, you may find that certain things you thought would work in the planning phase, won’t work in reality. By doing this, you’re finding issues early enough in the project to adjust course rather than finding out at the very end when changes are more difficult to make.

Scenarios like these come up all of the time in software development. As a project progresses, if it isn’t tested at regular intervals, the risk of finding something that doesn’t work the way you thought it would is much greater, regardless of how much time and consideration you put into the planning phase. To make matters worse, the effort to make a change late in the game is more difficult. By breaking the project down into smaller parts and testing each one, you’ve got a greater chance of seeing your project succeed because you can catch things early in this rapidly-changing environment.

Additionally, breaking the project down into smaller pieces allows for greater flexibility when it comes to incorporating new information, requirements, or other changes into the project. Since both software development and building a Martian car both carry a high likelihood that information and requirements will change, it’s ideal to have a more flexible project structure that can accommodate the inevitable curveballs. You can prioritize the information and features so that the most important things are tackled early and with enough time to test and make any necessary adjustments.

Ultimately, the best way to tackle a project with such high potential for change is to plan ahead for that change and set up the project to incorporate the inevitable adjustments. Perhaps this is why most development teams prefer to work under Scrum and Agile practices than any other form of project structure.

Jahia 6.5 vs Liferay 6.0 Part 2: Extensibility

Tue, 03 Jan 2012 18:15:00 GMT

This is part two of my comparison of Jahia and Liferay. As I mention in my post “Jahia 6.5 vs. Liferay 6.0 Part 1: Content Integration”, both products are excellent solutions for the implementation of Enterprise Web Applications. This post focuses on the Extensibility Model and the different ways that each product handles the need to implement custom functionality.

Extensibility Model

Both products present similar ways to add/extend functionality, but there are some differences.

Add/Extend Portable Functionality

Portlets are supported by and can be used in both products. The development effort in both cases is almost the same, but both systems provide to developers different tools for development. Liferay has the “Plugins SDK” tool in order to create portlet projects. In a similar way, Jahia has a maven archetype that can be used for this same purpose.

Jahia also can be extended via modules that are considered plugins. The advantage of modules over portlets is that they don’t need a Portal Sever and they are integrated directly into Jahia’s core gaining direct access to Jahia features. This means that developers using modules, apart from extending Jahia functionality, can add functionality to the default Jahia modules. Liferay doesn’t have this type of extensibility so I consider it an advantage of Jahia over Liferay.

Extend/Modify Core
Liferay has a very interesting method to overwrite files, beans, Struts Actions and properties in the core; it uses Hooks and Ext Plugins. This feature is based on the configuration of xml files that contain information about which files are going to be replaced. This feature does not exist on Jahia as those modules just can add new files but cannot replace core files.

I think that both products are excellent solutions and can work for any type of Enterprise Web Application. There are some differences, like in the Extensibility Model examples above, but in the end, both products can accomplish the same objectives (maintainability, usability, and portability). Also, the development time, effort and skills are similar because each product offers powerful tools, like Jahia Maven archetype and Liferay SDK to generate extensibility projects

Summary of Extensibility:

Extensibility
	Jahia	Liferay	Comments	Winner
Add/Extend Portable Functionality	Modules And Portlets	Portlets	Jahia Support Portlets but Liferay doesn’t support modules	Jahia
Extend/Modify the core	Modules	Hooks and Ext Plugin	Jahia doesn’t have the concept of file mapping replacements	Liferay

Improving Mobile User Experience with HTML5

Mon, 05 Dec 2011 22:55:00 GMT

Nowadays, people are constantly browsing the web via their mobile devices, there are 5.3 billion mobile subscribers in the world and the percentage of smart phones is growing exponentially. There are a few easy techniques using HTML5 that you can apply to your mobile apps and webpages that will improve user experience significantly.

Inputs

You've probably filled out a registration form from your phone, and it's not the nicest thing, screen needs resizing between reading labels and entering text and you also need to switch back and forward from the text keyboard, to the numeric and symbols keyboard.

Luckily HTML5 has several enhancements for input fields. And even if many browsers don't have full support for all these features, you can still add a lot of them without problems. Only browsers that support them will notice the difference, and older browsers will behave like they always do (HORRIBLE!).

HTML5 Input Techniques

Here's a list of all the input types available, you will notice that there are a lot more than most people are aware of:

button
checkbox
color
date
datetime
datetime-local
email
file
hidden
image
month
number
password
radio
range
reset
search
submit
tel
text
time
url
week

Though it’s nice to know there are so many options, keep in mind that not every one of them is going to work for your site. The most common and also the most supported new HTML5 elements are: email, number, tel, and URL. I'm sure you're already thinking on great uses for those!

Another great thing is that browser validation is already provided on some browsers, and my personal opinion is that all browsers will have that sooner or later, so we can see a future without JavaScript validations.

But let's get back to mobile devices and see the advantage of using the proper type of HTML5 input.

If your register form asks for an age or phone number, you’ll want to make sure that the user only enters numbers. To do this, use the input type = “number”. When you do this, the keyboard will automatically change to a numeric keyboard, and look something like this:

Pretty cool from a user's point of view, right? Now let's go through some pretty useful attributes that you can add to your input tags.

Input Attributes

autocomplete
autofocus
form
formaction
formenctype
formmethod
formnovalidate
formtarget
height
list
max
min
multiple
pattern
placeholder
required
step
width

These are all the "new" attributes according to http://www.w3schools.com. My favorite one is definitely the "placeholder" attribute. It puts a descriptive text on your input that clears on focus and shows on blur if you haven't typed anything. Classical behavior for which you needed to use JavaScript.

Other great attribute for mobile devices is the "autocapitalize". You can set it to "on" or "off" and it works perfectly for fields that should not contain capital letters, like URLs or for fields that should always begin with a capital letter, like names.

As you know, smart phones have dictionaries that correct spelling. The "autocorrect" attribute allows you to turn "on" or "off" this feature, to avoid annoying messages and underlines when you don't want them.

Anchors

Lastly, a great thing to have on all your "contact us" sections: Specialized Anchors.

Most developers know how to use “mailto:your@email.com”. You place that code inside your href attribute on any anchor tag and when a user clicks it, it opens your default email client and sends an email to the specified recipient.

Wouldn’t it be great if there was something like that for your mobile site that could place a call or send an SMS? There is and it's as simple as the mailto option! Just place it on your anchor tab.

Here's an example of each one:

	
		<a href="tel:1-555-123-1234">CALL PHONE</a>
		
		<a href="sms:1-555-666-7788">SEND SMS</a>

Hope you enjoyed!!