Category Archives: Uncategorized

Website Development

Working in website development not only means constantly learning new languages and knowing when to use them, but, it also means learning more about marketing, requirements gathering and human-computer interaction. Website development has transitioned from simple HTML-driven sites to fully interactive informational and ecommerce portals. HTML5, jQuery and node.js didn’t even exist a few years ago. Now they are a part of every project I do.

It has always been my goal to share web programming tutorials and offer suggestions on proper web design here on Web Development Blog. You’ll find articles on eCommerce Solutions, Google Services, jQuery Code, PHP Scripts and a variety of other topics.

What you’ll find in this section are conversations and ideas on website development that do not easily fit in one of the existing categories. We’ll talk about website design as a whole, website development tools, usability and running a website development company. As new technologies and programming languages emerge, we’ll talk about them here first. Contact us for more information

Mobile Application Development

Mobile Application Development

It is crystal clear that the demand of mobile apps has escalated in all businesses. To cope with that, we become your accelerator to design and develop brilliant mobile applications. Snehasoft is a top-notch mobile app development company offering mobile application development services for iPhone, iPad and Android.

Our team of mobile app developers is creative and knowledgeable to accomplish your individual demands as well as your business needs. With advanced tools and technology our mobile apps developers are able to create highly customized mobile applications for consumer needs and enterprises. Our experience and past work are the showcase of our brilliance in mobile applications development.

Why Should You Choose Us?

  • bullet
    Experienced Personnel
  • bullet
    Profound knowledge of frameworks and mobile technologies.
  • bullet
    High Quality app development process
  • bullet
    Time bound delivery and cost effective services
  • bullet
    Reputed and Recognized for developing robust mobile apps
  • bullet
    Provide dynamic services to various platforms
 When mobile meets the right application, miracles happen! Contactus for your Mobile Apps Needs.

Improving Your Web Design with 13 Simple Tips

Want to ensure that none of your visitors will exit your website almost immediately after landing there? Be sure to make it difficult for them to find what it is they are looking for. Want to get people to stay on your website longer and click on or buy stuff?

Follow these 13 Web design tips.

Web design
How to rebuild your career after a layoff
There is life after the layoff. Take these 6 steps to engineer your own comeback.

1. Have a polished, professional logo–and link it to your home page. “Your logo is an important part of your brand, so make sure it’s located prominently on your site,” says Tiffany Monhollon, senior content marketing manager at online marketer ReachLocal. “Use a high-resolution image and feature it in the upper left corner of each of your pages,” she advises. “Also, it’s a good rule of thumb to link your logo back to your home page so that visitors can easily navigate to it.”

2.Use intuitive navigation. “Primary navigation options are typically deployed in a horizontal [menu] bar along the top of the site,” says Brian Gatti, a partner with Inspire Business Concepts, a digital marketing company. Provide “secondary navigation options underneath the primary navigation bar, or in the [left-hand] margin of the site, known as the sidebar.”

Why is intuitive navigation so important? “Confusing navigation layouts will result in people quitting a page rather than trying to figure it out,” Gatti says. So instead of putting links to less important pages–that detract from your call to action or primary information–at the top of your home or landing pages, put “less important links or pieces of information at the bottom of a page in the footer.”

[Related: 6 Ways to Add Social Media to Your Web Design]
3. Get rid of clutter. “It’s very easy these days to be visually overloaded with images, to the point where our brains stop processing information when confronted with too many options,” explains Paolo Vidali, senior digital marketing strategist, DragonSearch, a digital marketing agency.

To keep visitors on your site, “make sure pages do not have competing calls to action or visual clutter [e.g., lots of graphics, photographs or animated gifs that would draw the visitor’s eyes away from the most important part of the page.” To further keep clutter down on landing pages, “consider limiting the links and options in the header and footer to narrow the focus even further,” he says.

Another tip to streamlining pages: “Keep paragraphs short,” says Ian Lurie, CEO of internet marketing company Portent, Inc. “On most Web sites, a single paragraph should be no more than five to six lines.”

4. Give visitors breathing room. “Create enough space between your paragraphs and images so the viewer has space to breathe and is more able to absorb all of the features your site and business have to offer,” says Hannah Spencer, graphic designer, Coalition Technologies, a Web design and online marketing agency.

“Controlling white space through layout will keep users focused on the content and control user flow,” adds Paul Novoa, founder and CEO at Novoa Media. “With a lot of visual competition taking place on the Web and on mobile, less is more. Controlling white space will improve user experience, increasing returns from the website.”

5. Use color strategically. Using “a mostly neutral color palette can help your site project an elegant, clean and modern appearance,” says Mark Hoben, the head of Web design at Egencia, the business travel division of the Expedia group, who is also a believer in using color wisely. “Employing small dashes of color–for headlines or key graphics–helps guide visitors to your most important content,” he explains.
It is also important to use a color palette that complements your logo and is consistent with your other marketing materials.

6. Invest in good, professional photography. “Website visitors can sniff out generic photos in a second–and they’ll be left with a generic impression of your company,” warns Zane Schwarzlose, community relations director, Fahrenheit Marketing. “Your company isn’t generic. So show your visitors that by investing in professional photography.”

“We strongly recommend that our clients invest in professional photography or purchase professional stock photos,” says Gatti. Good photographs “draw the eye, providing an emotional connection to the written content.” Poor quality photographs or photographs that have nothing to do with your message, on the other hand, are worse than having no photographs.

Bonus photography tip: “If you want to draw attention to a particular piece of content or a signup button, include a photo of a person looking at the content,” suggests Elie Khoury, cofounder and CEO of Woopra, which provides real-time customer and visitor analytics. “We are immediately drawn to faces of other humans–and when we see that face looking’ at something, our eyes are instinctively drawn there as well.”

7. Choose fonts that are easy to read across devices and browsers. When choosing fonts, keep in mind that people will be looking at your website not just on a laptop but on mobile devices. “Some large-scaled fonts may read well on [a computer monitor], but not scale or render well on mobile, losing the desired look and feel,” explains Novoa. So he advises using a universal font.

“Pick a typeface that can be easily read and size it no less than 11pt,” says Ethan Giffin, CEO, Groove Commerce. “If you’re using Web fonts, try to use no more than two font families in order to ensure fast load times,” he says.

“If you’re using a fixed-width design, use a font size that allows a maximum of 15 to 20 words per line,” adds Lurie. “If you’re using a fluid design, use a font size that allows 15 to 20 words per line at 900 to 1000 pixels wide.”

8. Design every page as a landing page. “Most websites have a design that assumes a user enters through the home page and navigates into the site,” says Michael Freeman, senior manager, Search & Analytics, ShoreTel, Inc., which provides hosted VoIP, cloud PBX service and business phone systems. “The reality, though, is that the majority of visits for most sites begin on a page that is not the home page,” he says. Therefore, you need to design the site in such a way that whatever page a visitor lands on, key information is there.

9. Respect the fold. When asked for their top design tips, almost all the Web designers queried immediately said: Put your call to action in the upper portion of your website, along with your phone number and/or email address (if you want customers to call or email you). Regarding home page images, “I recommend going against full-width sliders and encourage sliders or set images that cover two-thirds of the width allowing for a contact form to be above the fold,” says Aaron Watters, director, Leadhub, a website design and SEO company.

10. Use responsive design–that automatically adapts to how the site is being viewed. “Rather than developing a site for each device, a responsive site is designed to adapt to the browser size,” making for a better user experience, says Jayme Pretzloff, online marketing director, Wixon Jewelers. And a better user experience typically translates into more time spent on your site and higher conversion rates.

11. Forget Flash. “Thanks in part to the ongoing dispute between Adobe and Apple, the days of Flash as an Internet standard are slowly coming to a close, so why stay on the bandwagon when there are other options that are much more Web and user friendly?” asks Darrell Benatar, CEO of Instead, use HTML5, he says. “HTML5 is gaining more support on the Web, with search-engine friendly text and the ability to function on many of the popular mobile operating systems without requiring a plug-in. The same can’t be said for Flash.”

12. Don’t forget about buttons “The ‘Submit’ or ‘Send’ button at the bottom of a Web form can be the ugliest part of a website,” says Watters. So he encourages designers to make form submission buttons “so appealing visitors can’t help themselves. They just have to click it.” In addition, “when a visitor hovers over your submit button, it should change color, gradient, opacity or font treatment,” he says.

13. Test your design. “Whether you are trying different placements for a call to action or even testing different shades of a color, website optimization can make a big impact to your bottom line,” states Lindsey Marshall, production director, Red Clay Interactive, an Atlanta-based interactive marketing agency. “A user experience manager at Bing once remarked that Microsoft generated an additional $80 million in annual revenue just by testing and implementing a specific shade of blue!” We how it better, Wanna Get in Touch With us for your Web designing work

Responsive Web Design – What It Is And How To Use It?

Almost every new client these days wants a mobile version of their website. It’s practically essential after all: one design for the BlackBerry, another for the iPhone, the iPad, netbook, Kindle — and all screen resolutions must be compatible, too. In the next five years, we’ll likely need to design for a number of additional inventions. When will the madness stop? It won’t, of course.

In the field of Web design and development, we’re quickly getting to the point of being unable to keep up with the endless new resolutions and devices. For many websites, creating a website version for each resolution and new device would be impossible, or at least impractical. Should we just suffer the consequences of losing visitors from one device, for the benefit of gaining visitors from another? Or is there another option?

Responsive Web design is the approach that suggests that design and development should respond to the user’s behavior and environment based on screen size, platform and orientation. The practice consists of a mix of flexible grids and layouts, images and an intelligent use of CSS media queries. As the user switches from their laptop to iPad, the website should automatically switch to accommodate for resolution, image size and scripting abilities. In other words, the website should have the technology to automatically respond to the user’s preferences. This would eliminate the need for a different design and development phase for each new gadget on the market.

The Concept Of Responsive Web Design Link

Ethan Marcotte wrote an introductory article about the approach, “Responsive Web Design,” for A List Apart. It stems from the notion of responsive architectural design, whereby a room or space automatically adjusts to the number and flow of people within it:

“Recently, an emergent discipline called “responsive architecture” has begun asking how physical spaces can respond to the presence of people passing through them. Through a combination of embedded robotics and tensile materials, architects are experimenting with art installations and wall structures that bend, flex, and expand as crowds approach them. Motion sensors can be paired with climate control systems to adjust a room’s temperature and ambient lighting as it fills with people. Companies have already produced “smart glass technology” that can automatically become opaque when a room’s occupants reach a certain density threshold, giving them an additional layer of privacy.”

Transplant this discipline onto Web design, and we have a similar yet whole new idea. Why should we create a custom Web design for each group of users; after all, architects don’t design a building for each group size and type that passes through it? Like responsive architecture, Web design should automatically adjust. It shouldn’t require countless custom-made solutions for each new category of users.

Obviously, we can’t use motion sensors and robotics to accomplish this the way a building would. Responsive Web design requires a more abstract way of thinking. However, some ideas are already being practiced: fluid layouts, media queries and scripts that can reformat Web pages and mark-up effortlessly (or automatically).

But responsive Web design is not only about adjustable screen resolutions and automatically resizable images, but rather about a whole new way of thinking about design. Let’s talk about all of these features, plus additional ideas in the making.

Adjusting Screen Resolution Link

With more devices come varying screen resolutions, definitions and orientations. New devices with new screen sizes are being developed every day, and each of these devices may be able to handle variations in size, functionality and even color. Some are in landscape, others in portrait, still others even completely square. As we know from the rising popularity of the iPhone, iPad and advanced smartphones, many new devices are able to switch from portrait to landscape at the user’s whim. How is one to design for these situations?

Portrait Landscape

In addition to designing for both landscape and portrait (and enabling those orientations to possibly switch in an instant upon page load), we must consider the hundreds of different screen sizes. Yes, it is possible to group them into major categories, design for each of them, and make each design as flexible as necessary. But that can be overwhelming, and who knows what the usage figures will be in five years? Besides, many users do not maximize their browsers, which itself leaves far too much room for variety among screen sizes.

Morten Hjerde and a few of his colleagues identified statistics on about 400 devices sold between 2005 and 2008. Below are some of the most common:


Since then even more devices have come out. It’s obvious that we can’t keep creating custom solutions for each one. So, how do we deal with the situation?


A few years ago, when flexible layouts were almost a “luxury” for websites, the only things that were flexible in a design were the layout columns (structural elements) and the text. Images could easily break layouts, and even flexible structural elements broke a layout’s form when pushed enough. Flexible designs weren’t really that flexible; they could give or take a few hundred pixels, but they often couldn’t adjust from a large computer screen to a netbook.

Now we can make things more flexible. Images can be automatically adjusted, and we have workarounds so that layouts never break (although they may become squished and illegible in the process). While it’s not a complete fix, the solution gives us far more options. It’s perfect for devices that switch from portrait orientation to landscape in an instant or for when users switch from a large computer screen to an iPad.

In Ethan Marcotte’s article, he created a sample Web design that features this better flexible layout:

More Flexible

The entire design is a lovely mix of fluid grids, fluid images and smart mark-up where needed. Creating fluid grids is fairly common practice, and there are a number of techniques for creating fluid images:

  • Hiding and Revealing Portions of Images
  • Creating Sliding Composite Images
  • Foreground Images That Scale With the Layout

For more information on creating fluid websites, be sure to look at the book “Flexible Web Design: Creating Liquid and Elastic Layouts with CSS” by Zoe Mickley Gillenwater, and download the sample chapter “Creating Flexible Images.” In addition, Zoe provides the following extensive list of tutorials, resources, inspiration and best practices on creating flexible grids and layouts: “Essential Resources for Creating Liquid and Elastic Layouts.”

While from a technical perspective this is all easily possible, it’s not just about plugging these features in and being done. Look at the logo in this design, for example:

Cropping Logo

If resized too small, the image would appear to be of low quality, but keeping the name of the website visible and not cropping it off was important. So, the image is divided into two: one (of the illustration) set as a background, to be cropped and to maintain its size, and the other (of the name) resized proportionally.

<h1 id="logo"><a href="#"><img src="site/logo.png" alt="The Baker Street Inquirer" /></a></h1>

Above, the h1 element holds the illustration as a background, and the image is aligned according to the container’s background (the heading).

This is just one example of the kind of thinking that makes responsive Web design truly effective. But even with smart fixes like this, a layout can become too narrow or short to look right. In the logo example above (although it works), the ideal situation would be to not crop half of the illustration or to keep the logo from being so small that it becomes illegible and “floats” up.

Flexible Images Link

One major problem that needs to be solved with responsive Web design is working with images. There are a number of techniques to resize images proportionately, and many are easily done. The most popular option, noted in Ethan Marcotte’s article on fluid images but first experimented with by Richard Rutter, is to use CSS’s max-width for an easy fix.

img { max-width: 100%; }

As long as no other width-based image styles override this rule, every image will load in its original size, unless the viewing area becomes narrower than the image’s original width. The maximum width of the image is set to 100% of the screen or browser width, so when that 100% becomes narrower, so does the image. Essentially, as Jason Grigsby noted, “The idea behind fluid images is that you deliver images at the maximum size they will be used at. You don’t declare the height and width in your code, but instead let the browser resize the images as needed while using CSS to guide their relative size”. It’s a great and simple technique to resize images beautifully.

Note that max-width is not supported in IE, but a good use of width: 100%would solve the problem neatly in an IE-specific style sheet. One more issue is that when an image is resized too small in some older browsers in Windows, the rendering isn’t as clear as it ought to be. There is a JavaScript to fix this issue, though, found in Ethan Marcotte’s article.

While the above is a great quick fix and good start to responsive images, image resolution and download times should be the primary considerations. While resizing an image for mobile devices can be very simple, if the original image size is meant for large devices, it could significantly slow download times and take up space unnecessarily.


This technique, presented by the Filament Group, takes this issue into consideration and not only resizes images proportionately, but shrinks image resolution on smaller devices, so very large images don’t waste space unnecessarily on small screens. Check out the demo page here.

Filament Group Image Resizing

This technique requires a few files, all of which are available on Github. First, a JavaScript file (rwd-images.js), the .htaccess file and an image file (rwd.gif). Then, we can use just a bit of HTML to reference both the larger and smaller resolution images: first, the small image, with an .r prefix to clarify that it should be responsive, and then a reference to the bigger image using data-fullsrc.

<img src="smallRes.jpg" data-fullsrc="largeRes.jpg">

The data-fullsrc is a custom HTML5 attribute, defined in the files linked to above. For any screen that is wider than 480 pixels, the larger-resolution image (largeRes.jpg) will load; smaller screens wouldn’t need to load the bigger image, and so the smaller image (smallRes.jpg) will load.

The JavaScript file inserts a base element that allows the page to separate responsive images from others and redirects them as necessary. When the page loads, all files are rewritten to their original forms, and only the large or small images are loaded as necessary. With other techniques, all higher-resolution images would have had to be downloaded, even if the larger versions would never be used. Particularly for websites with a lot of images, this technique can be a great saver of bandwidth and loading time.

This technique is fully supported in modern browsers, such as IE8+, Safari, Chrome and Opera, as well as mobile devices that use these same browsers (iPad, iPhone, etc.). Older browsers and Firefox degrade nicely and still resize as one would expect of a responsive image, except that both resolutions are downloaded together, so the end benefit of saving space with this technique is void.


One nice thing about the iPhone and iPod Touch is that Web designs automatically rescale to fit the tiny screen. A full-sized design, unless specified otherwise, would just shrink proportionally for the tiny browser, with no need for scrolling or a mobile version. Then, the user could easily zoom in and out as necessary.

There was, however, one issue this simulator created. When responsive Web design took off, many noticed that images were still changing proportionally with the page even if they were specifically made for (or could otherwise fit) the tiny screen. This in turn scaled down text and other elements.

iPhone Scale(Image: Think Vitamin | Website referenced: 8 FacesBecause this works only with Apple’s simulator, we can use an Apple-specific meta tag to fix the problem, placing it below the website’s <head> section. Thanks to Think Vitamin’s article on image resizing, we have the meta tag below:

<meta name="viewport" content="width=device-width; initial-scale=1.0">

Setting the initial-scale to 1 overrides the default to resize images proportionally, while leaving them as is if their width is the same as the device’s width (in either portrait or lanscape mode). Apple’s documentation has a lot more information on the viewport meta tag.

Custom Layout Structure Link

For extreme size changes, we may want to change the layout altogether, either through a separate style sheet or, more efficiently, through a CSS media query. This does not have to be troublesome; most of the styles can remain the same, while specific style sheets can inherit these styles and move elements around with floats, widths, heights and so on.

For example, we could have one main style sheet (which would also be the default) that would define all of the main structural elements, such as#wrapper, #content, #sidebar, #nav, along with colors, backgrounds and typography. Default flexible widths and floats could also be defined.

If a style sheet made the layout too narrow, short, wide or tall, we could then detect that and switch to a new style sheet. This new child style sheet would adopt everything from the default style sheet and then just redefine the layout’s structure.

Here is the style.css (default) content:

/* Default styles that will carry to the child style sheet */


p, blockquote, pre, code, ol, ul{}

/* Structural elements */
  width: 80%;
  margin: 0 auto;

  background: #fff;
  padding: 20px;

  width: 54%;
  float: left;
  margin-right: 3%;

  width: 20%;
  float: left;
  margin-right: 3%;

  width: 20%;
  float: left;

Here is the mobile.css (child) content:

  width: 90%;

  width: 100%;

  width: 100%;
  clear: both;

  /* Additional styling for our new layout */
  border-top: 1px solid #ccc;
  margin-top: 20px;

  width: 100%;
  clear: both;

  /* Additional styling for our new layout */
  border-top: 1px solid #ccc;
  margin-top: 20px;
Moving Content


CSS3 supports all of the same media types as CSS 2.1, such as screen, printand handheld, but has added dozens of new media features, including max-width, device-width, orientation and color. New devices made after the release of CSS3 (such as the iPad and Android devices) will definitely support media features. So, calling a media query using CSS3 features to target these devices would work just fine, and it will be ignored if accessed by an older computer browser that does not support CSS3.

In Ethan Marcotte’s article, we see an example of a media query in action:

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

This media query is fairly self-explanatory: if the browser displays this page on a screen (rather than print, etc.), and if the width of the screen (not necessarily the viewport) is 480 pixels or less, then load shetland.css.

New CSS3 features also include orientation (portrait vs. landscape), device-width, min-device-width and more. Look at “The Orientation Media Query” for more information on setting and restricting widths based on these media query features.

One can create multiple style sheets, as well as basic layout alterations defined to fit ranges of widths — even for landscape vs. portrait orientations. Be sure to look at the section of Ethan Marcotte’s article entitled “Meet the media query” for more examples and a more thorough explanation.

Multiple media queries can also be dropped right into a single style sheet, which is the most efficient option when used:

/* Smartphones (portrait and landscape) ----------- */
@media only screen
and (min-device-width : 320px)
and (max-device-width : 480px) {
/* Styles */

/* Smartphones (landscape) ----------- */
@media only screen
and (min-width : 321px) {
/* Styles */

/* Smartphones (portrait) ----------- */
@media only screen
and (max-width : 320px) {
/* Styles */

The code above is from a free template for multiple media queries between popular devices by Andy Clark. See the differences between this approach and including different style sheet files in the mark-up as described in his book “Hardboiled Web Design.”


Above are a few examples of how media queries, both from CSS 2.1 and CSS3 could work. Let’s now look at some specific how-to’s for using CSS3 media queries to create responsive Web designs. Many of these uses are relevant today, and all will definitely be usable in the near future.

The min-width and max-width properties do exactly what they suggest. Themin-width property sets a minimum browser or screen width that a certain set of styles (or separate style sheet) would apply to. If anything is below this limit, the style sheet link or styles will be ignored. The max-width property does just the opposite. Anything above the maximum browser or screen width specified would not apply to the respective media query.

Note in the examples below that we’re using the syntax for media queries that could be used all in one style sheet. As mentioned above, the most efficient way to use media queries is to place them all in one CSS style sheet, with the rest of the styles for the website. This way, multiple requests don’t have to be made for multiple style sheets.

@media screen and (min-width: 600px) {
     .hereIsMyClass {
          width: 30%;
          float: right;

The class specified in the media query above (hereIsMyClass) will work only if the browser or screen width is above 600 pixels. In other words, this media query will run only if the minimum width is 600 pixels (therefore, 600 pixels or wider).

@media screen and (max-width: 600px) {
     .aClassforSmallScreens {
          clear: both;
      font-size: 1.3em;

Now, with the use of max-width, this media query will apply only to browser or screen widths with a maximum width of 600 pixels or narrower.

While the above min-width and max-width can apply to either screen size or browser width, sometimes we’d like a media query that is relevant to device width specifically. This means that even if a browser or other viewing area is minimized to something smaller, the media query would still apply to the size of the actual device. The min-device-width and max-device-width media query properties are great for targeting certain devices with set dimensions, without applying the same styles to other screen sizes in a browser that mimics the device’s size.

@media screen and (max-device-width: 480px) {
     .classForiPhoneDisplay {
          font-size: 1.2em;
@media screen and (min-device-width: 768px) {
     .minimumiPadWidth {
          clear: both;
      margin-bottom: 2px solid #ccc;

For the iPad specifically, there is also a media query property calledorientation. The value can be either landscape (horizontal orientation) or portrait (vertical orientation).

@media screen and (orientation: landscape) {
     .iPadLandscape {
          width: 30%;
      float: right;
@media screen and (orientation: portrait) {
     .iPadPortrait {
          clear: both;

Unfortunately, this property works only on the iPad. When determining the orientation for the iPhone and other devices, the use of max-device-width andmin-device-width should do the trick.

There are also many media queries that make sense when combined. For example, the min-width and max-width media queries are combined all the time to set a style specific to a certain range.

@media screen and (min-width: 800px) and (max-width: 1200px) {
     .classForaMediumScreen {
          background: #cc0000;
          width: 30%;
          float: right;

The above code in this media query applies only to screen and browser widths between 800 and 1200 pixels. A good use of this technique is to show certain content or entire sidebars in a layout depending on how much horizontal space is available.

Some designers would also prefer to link to a separate style sheet for certain media queries, which is perfectly fine if the organizational benefits outweigh the efficiency lost. For devices that do not switch orientation or for screens whose browser width cannot be changed manually, using a separate style sheet should be fine.

You might want, for example, to place media queries all in one style sheet (as above) for devices like the iPad. Because such a device can switch from portrait to landscape in an instant, if these two media queries were placed in separate style sheets, the website would have to call each style sheet file every time the user switched orientations. Placing a media query for both the horizontal and vertical orientations of the iPad in the same style sheet file would be far more efficient.

Another example is a flexible design meant for a standard computer screen with a resizable browser. If the browser can be manually resized, placing all variable media queries in one style sheet would be best.

Nevertheless, organization can be key, and a designer may wish to define media queries in a standard HTML link tag:

<link rel="stylesheet" media="screen and (max-width: 600px)" href="small.css" />
<link rel="stylesheet" media="screen and (min-width: 600px)" href="large.css" />
<link rel="stylesheet" media="print" href="print.css" />


Another method that can be used is JavaScript, especially as a back-up to devices that don’t support all of the CSS3 media query options. Fortunately, there is already a pre-made JavaScript library that makes older browsers (IE 5+, Firefox 1+, Safari 2) support CSS3 media queries. If you’re already using these queries, just grab a copy of the library, and include it in the mark-up:css3-mediaqueries.js.

In addition, below is a sample jQuery snippet that detects browser width and changes the style sheet accordingly — if one prefers a more hands-on approach:

<script type="text/javascript" src=""></script>

<script type="text/javascript">
    $(window).bind("resize", resizeWindow);
    function resizeWindow(e){
      var newWindowWidth = $(window).width();

      // If width width is below 600px, switch to the mobile stylesheet
      if(newWindowWidth < 600){        $("link[rel=stylesheet]").attr({href : "mobile.css"});        }       // Else if width is above 600px, switch to the large stylesheet       else if(newWindowWidth > 600){
        $("link[rel=stylesheet]").attr({href : "style.css"});

There are many solutions for pairing up JavaScript with CSS media queries. Remember that media queries are not an absolute answer, but rather are fantastic options for responsive Web design when it comes to pure CSS-based solutions. With the addition of JavaScript, we can accomodate far more variations. For detailed information on using JavaScript to mimic or work with media queries, look at “Combining Media Queries and JavaScript.”

Showing or Hiding Content Link

It is possible to shrink things proportionally and rearrange elements as necessary to make everything fit (reasonably well) as a screen gets smaller. It’s great that that’s possible, but making every piece of content from a large screen available on a smaller screen or mobile device isn’t always the best answer. We have best practices for mobile environments: simpler navigation, more focused content, lists or rows instead of multiple columns.

Digg Mobile

Responsive Web design shouldn’t be just about how to create a flexible layout on a wide range of platforms and screen sizes. It should also be about the user being able to pick and choose content. Fortunately, CSS has been allowing us to show and hide content with ease for years!

display: none;

Either declare display: none for the HTML block element that needs to be hidden in a specific style sheet or detect the browser width and do it through JavaScript. In addition to hiding content on smaller screens, we can also hide content in our default style sheet (for bigger screens) that should be available only in mobile versions or on smaller devices. For example, as we hide major pieces of content, we could replace them with navigation to that content, or with a different navigation structure altogether.

Note that we haven’t used visibility: hidden here; this just hides the content (although it is still there), whereas the display property gets rid of it altogether. For smaller devices, there is no need to keep the mark-up on the page — it just takes up resources and might even cause unnecessary scrolling or break the layout.

Showing Hiding Content

Here is our mark-up:

<p class="sidebar-nav"><a href="#">Left Sidebar Content</a> | <a href="#">Right Sidebar Content</a></p>

<div id="content">
  <h2>Main Content</h2>

<div id="sidebar-left">
  <h2>A Left Sidebar</h2>


<div id="sidebar-right">
  <h2>A Right Sidebar</h2>

In our default style sheet below, we have hidden the links to the sidebar content. Because our screen is large enough, we can display this content on page load.

Here is the style.css (default) content:

  width: 54%;
  float: left;
  margin-right: 3%;

  width: 20%;
  float: left;
  margin-right: 3%;

  width: 20%;
  float: left;
.sidebar-nav{display: none;}

Now, we hide the two sidebars (below) and show the links to these pieces of content. As an alternative, the links could call to JavaScript to just cancel out the display: none when clicked, and the sidebars could be realigned in the CSS to float below the content (or in another reasonable way).

Here is the mobile.css (simpler) content:

  width: 100%;

  display: none;

  display: none;
.sidebar-nav{display: inline;}

With the ability to easily show and hide content, rearrange layout elements and automatically resize images, form elements and more, a design can be transformed to fit a huge variety of screen sizes and device types. As the screen gets smaller, rearrange elements to fit mobile guidelines; for example, use a script or alternate style sheet to increase white space or to replace image navigation sources on mobile devices for better usability (icons would be more beneficial on smaller screens).

Below are a couple of relevant resources:

  • Mobile Web Design Trends For 2009
  • 7 Usability Guidelines for Websites on Mobile Devices


Touchscreens are becoming increasingly popular. Assuming that smaller devices are more likely to be given touchscreen functionality is easy, but don’t be so quick. Right now touchscreens are mainly on smaller devices, but many laptops and desktops on the market also have touchscreen capability. For example, the HP Touchsmart tm2t is a basic touchscreen laptop with traditional keyboard and mouse that can transform into a tablet.


Touchscreens obviously come with different design guidelines than purely cursor-based interaction, and the two have different capabilities as well. Fortunately, making a design work for both doesn’t take a lot of effort. Touchscreens have no capability to display CSS hovers because there is no cursor; once the user touches the screen, they click. So, don’t rely on CSS hovers for link definition; they should be considered an additional feature only for cursor-based devices.

Look at the article “Designing for Touchscreen” for more ideas. Many of the design suggestions in it are best for touchscreens, but they would not necessarily impair cursor-based usability either. For example, sub-navigation on the right side of the page would be more user-friendly for touchscreen users, because most people are right-handed; they would therefore not bump or brush the navigation accidentally when holding the device in their left hand. This would make no difference to cursor users, so we might as well follow the touchscreen design guideline in this instance. Many more guidelines of this kind can be drawn from touchscreen-based usability.

A Showcase Of Responsive Web Design Link

Below we have a few examples of responsive Web design in practice today. For many of these websites, there is more variation in structure and style than is shown in the pairs of screenshots provided. Many have several solutions for a variety of browsers, and some even adjust elements dynamically in size without the need for specific browser dimensions. Visit each of these, and adjust your browser size or change devices to see them in action.

Art Equals Work
Art Equals Work is a simple yet great example of responsive Web design. The first screenshot below is the view from a standard computer screen dimension. The website is flexible with browser widths by traditional standars, but once the browser gets too narrow or is otherwise switched to a device with a smaller screen, then the layout switches to a more readable and user-friendly format. The sidebar disappears, navigation goes to the top, and text is enlarged for easy and simple vertical reading.

Art Equals Work
Art Equals Work

Think Vitamin
With Think Vitamin, we see a similar approach. When on a smaller screen or browser, the sidebar and top bar are removed, the navigation simplifies and moves directly above the content, as does the logo. The logo keeps its general look yet is modified for a more vertical orientation, with the tagline below the main icon. The white space around the content on larger screens is also more spacious and interesting, whereas it is simplified for practical purposes on smaller screens.

Think Vitamin
Think Vitamin

8 Faces
8 Faces’ website design is flexible, right down to a standard netbook or tablet device, and expands in content quantity and layout width when viewed on wider screens or expanded browsers. When viewed on narrower screens, the featured issue on the right is cut out, and the content below is shortened and rearranged in layout, leaving only the essential information.

8 Faces
8 Faces

The Hicksdesign website has three columns when viewed on a conventional computer screen with a maximized browser. When minimized in width, the design takes on a new layout: the third column to the right is rearranged above the second, and the logo moves next to the introductory text. Thus, no content needs to be removed for the smaller size. For even narrower screens and browser widths, the side content is removed completely and a simplified version is moved up top. Finally, the font size changes with the screen and browser width; as the browser gets narrower, the font size throughout gets smaller and remains proportional.


Information Architects
Here is a great example of a flexible image. The image in this design automatically resizes after certain “break” points, but in between those width changes, only the side margins and excess white space are altered. On smaller screens and minimized browsers, the navigation simplifies and the columns of navigation at the top fall off. At the design’s smallest version, the navigation simplifies to just a drop-down menu, perfect for saving space without sacrificing critical navigation links.

Information Architects
Information Architects

Garret Keizer
The website for Garret Keizer is fully flexible in wider browsers and on larger screens: the photo, logo and other images resize proportionally, as do the headings and block areas for text. At a few points, some pieces of text change in font size and get smaller as the screen or browser gets narrower. After a certain break point, the layout transforms into what we see in the second screenshot below, with a simple logo, introductory text and a simple vertical structure for the remaining content.

Garrent Keizer
Garrent Keizer

Simon Collison
With four relatively content-heavy columns, it’s easy to see how the content here could easily be squished when viewed on smaller devices. Because of the easy organized columns, though, we can also collapse them quite simply when needed, and we can stack them vertically when the space doesn’t allow for a reasonable horizontal span. When the browser is minimized or the user is on a smaller device, the columns first collapse into two and then into one. Likewise, the horizontal lines for break points also change in width, without changing the size or style of each line’s title text.

Simon Collison
Simon Collison

CSS Tricks
On the CSS Tricks website, like many other collapsible Web designs, the sidebars with excess content are the first to fall off when the screen or browser gets too narrow. On this particular website, the middle column or first sidebar to the left was the first to disappear; and the sidebar with the ads and website extras did the same when the browser got even narrower. Eventually, the design leaves the posts, uses less white space around the navigation and logo and moves the search bar to below the navigation. The remaining layout and design is as flexible as can be because of its simplicity.

CSS Tricks
CSS Tricks

Tee Gallery
As one can see, the main navigation here is the simple layout of t-shirt designs, spanning both vertically and horizontally across the screen. As the browser or screen gets smaller, the columns collapse and move below. This happens at each break point when the layout is stressed, but in between the break points, the images just change proportionally in size. This maintains balance in the design, while ensuring that any images (which are essential to the website) don’t get so small that they become unusable.

Tee Gallery
Tee Gallery

Ten by Twenty
Ten by Twenty is another design that does not resort to changing layout structure at all after certain break points, but rather simplifies responsive Web design by making everything fully flexible and automatically resizing, no matter what the screen or browser width. After a while, the design does stress a bit and could benefit from some rearrangement of content. But overall, the image resizing and flexible content spaces allow for a fairly simple solution that accommodates a wide range of screen sizes.

Ten by Twenty
Ten by Twenty

Hardboiled Web Design
On wide screens and browsers, all of the content on this simply designed website is well organized into columns, sidebar and simple navigation up top. It’s a fairly standard and efficient layout. On smaller screens, the sidebar is the first to drop off, and its content is moved below the book previews and essential information. Being limited in space, this design preserves its important hierarchy. Whereas on a wider screen we’d look left to right, on a narrower screen we’d tend to look from top to bottom. Content on the right is moved below content that would appear on the left on a wider screen. Eventually, when the horizontal space is fully limited, the navigation is simplified and stacked vertically, and some repeated or inessential elements are removed.

Hard Boiled
Hard Boiled

This design features a complex layout that looks inspired by a print style. When viewed on a standard wide computer screen, more portfolio pieces are featured and spanned horizontally across the page. As one moves down the page, more graphics and imagery span the space. On a smaller screen, the portfolio piece is cut down to one, and then eventually left out altogether for very small screens and narrow browsers. The visualizations below collapse into fewer columns and more rows, and again, some drop off entirely for very small screens. This design shows a creative and intelligent way to make a not-so-common layout work responsively.


Stephen Caver
This design has three main stages at which the design and layout collapse into a more user-friendly form, depending on how wide the screen or browser is. The main image (featuring type) is scaled proportionally via a flexible image method. Each “layout structure” is fully flexible until it reaches a breaking point, at which point the layout switches to something more usable with less horizontal space. The bottom four columns eventually collapse into two, the logo moves above the navigation, and the columns of navigation below are moved on top or below each other. At the design’s narrowest stage, the navigation is super-simplified, and some inessential content is cut out altogether.

Sephen Caver
Stephen Caver

Unstoppable Robot Ninja
This layout does not change at all; no content is dropped or rearranged; and the text size does not change either. Instead, this design keeps its original form, no matter what the change in horizontal and vertical space. Instead, it automatically resizes the header image and the images for the navigation. The white space, margins and padding are also flexible, giving more room as the design expands and shrinks.

Unstoppable Robot Ninja
Unstoppable Robot Ninja

This is perhaps the simplest example of a responsive Web design in this showcase, but also one of the most versatile. The only piece in the layout that changes with the browser width is the blog post’s date, which moves above the post’s title or to the side, depending on how much horizontal space is available. Beyond this, the only thing that changes is the width of the content area and the margin space on the left and right. Everything is centered, so a sense of balance is maintained whatever the screen or browser width. Because of this design’s simplicity, switching between browser and screen widths is quick and easy.


CSS Wizardry
Harry Roberts shows that responsive design can also have quite humble uses. If the user has a large viewport, the website displays three columns with a navigation menu floating on the left. For users with a viewport between 481px and 800px, a narrow version is displayed: the navigation jumps to the top of the site leaving the area for the content column and the sidebar. Finally, the iPhone view displays the sidebar under the content area. Harry also wrote a detailed article about the CSS styles he added to the stylesheet in his article “Media queries, handier than you think“. A nice example of how a couple of simple CSS adjustments can improve the website’s appearance across various devices.

CSS Wizardry
CSS Wizardry

Bryan James
This last design by Bryan James shows that responsive Web design need not apply only to static HTML and CSS websites. Done in Flash, this one features a full-sized background image and is flexible up to a certain width and height. As a result of the design style, on screens that are too small, the background image gets mostly hidden and the content can become illegible and squished. Instead of just letting it be, though, a message pops up informing the user that the screen is too small to adequately view the website. It then prompts the user to switch to a bigger screen. One can discuss if the design solution is good or bad in terms of usability, but the example shows that Flash websites can respond to user’s viewport, too.

Bryan James
Bryan James

Conclusion Link

We are indeed entering a new age of Web design and development. Far too many options are available now, and there will be far too many in the future to continue adjusting and creating custom solutions for each screen size, device and advancement in technology. We should rather start a new era today: creating websites that are future-ready right now. Understanding how to make a design responsive to the user doesn’t require too much learning, and it can definitely be a lot less stressful and more productive than learning how to design and code properly for every single device available.

Responsive Web design and the techniques discussed above are not the final answer to the ever-changing mobile world. Responsive Web design is a mere concept that when implemented correctly can improve the user experience, but not completely solve it for every user, device and platform. We will need to constantly work with new devices, resolutions and technologies to continually improve the user experience as technology evolves in the coming years.

Besides saving us from frustration, responsive Web design is also best for the user. Every custom solution makes for a better user experience. With responsive Web design, we can create custom solutions for a wider range of users, on a wider range of devices. A website can be tailored as well for someone on an old laptop or device as it can for the vast majority of people on the trendiest gadgets around, and likewise as much for the few users who own the most advanced gadgets now and in the years to come. Responsive Web design creates a great custom experience for everyone. As Web designers, we all strive for that every day on every project anyway, right?. want to get your website design contact us

Now Is The Time For Responsive Design

Beginning April 21, Google will use mobile-friendliness as a ranking signal in search results, rewarding websites that are fully optimized for mobile platforms.

Most modifications to the all-important Google Search Algorithm have only a low-weight impact on search results, however Google says the effect of this change will be profound. It is very important for any business owner with a website to respond accordingly.

Effective immediately, Google will also factor content from mobile apps (a feature called App Indexing) when rendering mobile search results. Android users who are signed into their Google account will begin to see apps more prominently in search listings.

These changes will make it easier for mobile users to find relevant, high-quality search results that are optimized for their devices, creating a better search experience. Google provides very clear recommendations on what you can do to make your website mobile-friendly. If your business website as not yet adopted responsive design, want to know more

Google’s Accelerated Mobile Pages to Make Their Way to Search Results

In February this year, Google introduced its Accelerated Mobile Pages (AMP) project with the aim to reduce the loading times for mobile webpages. Now these sped-up versions of mobile pages will soon make their to all of Google’s search results instead of being limited to just the Top Stories carousel in search results.

The main idea behind Google’s AMP initiative was to deliver news and other articles from publishers to mobile users in as less time as possible. Interestingly, the adoption for AMP has gone past just news industry and now includes e-commerce, entertainment, travel, recipe sites, the official blog for the project says.

On Tuesday, Google shared an early preview (for users, developers, and sites) of this expanded support across entire search results page. Mobile search results outside of the Top Stories carousel that have corresponding AMP pages will now feature a lightning symbol next to the word AMP as a label – similar to how Google shows mobile-friendly webpages.

In the blog, Google has clarified that this new change will not result in ranking change for the websites and is only meant to provide mobile users with faster browsing experience. Google’s ranking system does prioritise small load times and page speed, however, Google VP of Engineering David Besbrisexplained to Search Engine Land that if there are two identical pages – one mobile friendly and the other AMP-powered – it will show the AMP one.

According to the official blog, Google has more than 150 million AMP articles in its index, with over 4 million new ones being added every week.

You can also check out how the sped-up webpages work by heading to AMP’s demo page on your mobile device and searching for “something like ‘french toast recipe’ or music lyrics by your favourite artist to experience how AMP can provide a speedier reading experience on the mobile web,” the search giant said in its blog.

In April, Accelerated Mobile Pages came to all of Google’s platforms including its news app for Android and Apple devices. Get in touch with us for more information

Storyboarding in the Software Design Process

Using storyboards in software design can be difficult because of some common challenges and drawbacks to the tools we have. The good news is that there’s a new, free tool that tries to address many of these issues. But before I get into that, let’s revisit the value of using storyboards (and stories in general) in software design.

Using stories in some form or another is a well-established practice in software design, so much so that there are many meanings of the term “stories.” For instance, in agile processes, there is a concept of “user stories,” which are very basic units of expressing functional requirements: “As a user, I want to receive notifications when new applications are submitted.”

In user experience design, these stories take on more life through the incorporation of richer user and usage contexts and personas: real people in real places doing real things, not just some abstract, feature-oriented description of functionality that clothes itself in a generic “user.”

In their book, Storytelling for User Experience, Whitney Quesenbery and Kevin Brooks offer these benefits of using stories in software design:

  • They help us gather and share information about users, tasks, and goals.
  • They put a human face on analytic data.
  • They can spark new design concepts and encourage collaboration and innovation.
  • They are a way to share ideas and create a sense of shared history and purpose.
  • They help us understand the world by giving us insight into people who are not just like us.
  • They can even persuade others of the value of our contribution.

Whatever they’re called, stories are an effective and inexpensive way to capture, relate, and explore experiences in the design process. We look for talking with you

Web Design Vs. Web Development: What’s the Difference?

“By day, I’m a designer and developer hybrid working on client projects, a two-person, design studio his wife began two years ago,” he says. “We take on a wide range of work including web design and development, user experience design for apps and mobile as well as many other design projects.”

When he is not working on contract projects he teaches web development and graphic design classes as an adjunct instructor at the CDIA.

In high school, Haney tried “every programming language he could get his hands on,” and so, naturally, he enrolled as a computer science major in college. It wasn’t long before he realized that he needed a balance of web development and design and changed majors.

“My first few jobs out of college were development focused, and while I really enjoyed what I was doing, I felt it was lacking something,” he says. “Eventually, as I began to write more HTML and CSS, I realized that the design side of the web was really intriguing. The ability to make something work, but then to make it enjoyable to use, that’s where I found my passion.”

web design langages HTML CSS JavaScrift

A good web designer must know HTML, CSS, and JavaScript.

Patrick is one of an increasing number of people who consider themselves a designer and developer hybrid, which makes sense in a world where clients lump web design and web development together as if they were the same thing.

“What’s on their screen is ‘designed,’ and they might not understand the mechanics and complex system under the hood,” Oliveira says. “It’s probably simpler for those people to just pick one and go with it; just like when you call a tissue a Kleenex or folks in the south who call any and all sodas Coke.”

These “unicorns,” or people who are great designers and developers, are fairly rare and incredibly sought after in today’s market. The difference in the number of jobs available for designers versus developers is drastic.

web developer vs web designer

Job demand is heavily skewed in favor of web developers.

So why does one get paid so much more than the other if they’re both working together to produce the same outcome: a beautiful and functional website or an application?

Web designers are architects of the web. They focus on the look and feel of the website; and so, they should be visual arts experts, who are skilled in color scheming, graphic design and information flow. Designers are typically more in tune with their right brain hemisphere, utilizing their creativity, intuition and imagination, to design amazing user experiences.

designer developer right brain left brain

Development is for left-brained people; Design is better suited for the right-brain.

The education requirement of a web designer is debatable. While a  degree may not be needed, a full portfolio of your past work is a must. Of course others would argue that a degree from a university is just as important. Also, you should be skilled in software such as Adobe Illustrator, Photoshop and Dreamweaver.

web development certification worthless

The education required for web designers is less than that of web developers.

Amanda Cheung, lead interaction developer at DockYard, works with designers and other developers to create great experiences on the computer and mobile web. She creates and reviews Cascading Style Sheets (CSS), ensuring the code is clean, maintainable, user-friendly and responsive.

Cheung actually began as a designer and had a natural progression into web development because like Haney, she felt something was missing. “I studied fine arts in school, concentrating in painting and graphic design,” she says. “Once I graduated I started working as a graphic designer, but the job I was doing wasn’t too fulfilling for me so I took an introduction to web design and web programming classes at night. I was able to get several freelance gigs, realized how fun it was and made the transition into web development full-time.”

Kyle Bradshaw is the senior front-end developer at Digitas, and he classifies himself as solely a web developer.

“I went to an engineering school so I enjoy programming. I was never very interested in the design aspect of it. I lack artistic talent,” he says. “I could always remix other designers’ designs if it came down to it. I enjoyed the development part more.”

Oliveira is a developer as well. He enjoys how there is always an answer in code and that computer science and programming filled the proverbial creative void.

“There is always an answer – true or false, 1 or 0, works or crashes, but the means by which you could get to that answer were limitless,” he says. “How liberating! The space in between fascinated me. How efficient could I be? How fast? How cute? How confusing? How clear? The journey to finding the answer to a problem has been the reason I’ve stayed in the field to this day.”

Most developers would agree with Joel because programmers tend to think with the left side of their brain, which is the logical, linear thinking and technical side.

If web designers are the architects of the web then developers are the builders. Without coders, the plans would never come to life. They work with designers in making semantic mark-up languages like XHTML and CSS and transform static PSDs into interactive working web browser pages. Typically, programmers are skilled in programming languages such as PHP, ASP, Ruby on Rails, Python, HTML, CSS and more depending on what they specialize in and their experience level. The nice thing about being a good developer is that since their skills are in such a high demand then any programmer with a good portfolio can easily get a coding job.

back end vs front end web development languages

Web developers speak a different language (or more than one) than front-end designers.

No matter how different or not different being a designer and/or a developer may be, the two occupations do seem to come with the same pros and cons.

Flexible work hours and ability to work from anywhere seem to be the biggest perks aside from doing something these people love to do.

Oliveira says the ability to work from anywhere can also be a huge con.

“Because I have my laptop with me almost all day and night I can and will work. It’s a constant struggle to be mindful of my work/life balance. I enjoy what I do immensely (obviously a perk), but the possibility of burnout is a very real thing,” . We would be happy to help you get your ideas on web development, please Contact US for any information.

You Don’t Need a DevOps Team: You Need a Tools Team

Lately the job boards have been filled with ads that look something like this:

Seeking Senior DevOps Engineer

* Must be able to debug all databases created since 1980

* Be a core contributor to at least 10 open source projects

* Have experience with Go, Java, Python, Ruby, and C#

* Understand the kernel and be able to debug panics at 3AM

* Be willing to participate in the on-call rotation

* Insert some other absurd skill here!

Am I the only one who thinks this is a joke? Hiring one person isn’t going to make a DevOps implementation successful. DevOps is a shift in how work is flowed to various parts of your orginization, and who should take responsibility when certain actions occur. It is the next evolution of the cross-functional team.

Why is it so difficult to have success with an idea that seems so simple? At Rally we’ve found that it stems from two issues:

  • Development teams are asked to own their services in production, but lack the neccessary access to resolve problems.
  • Operations teams are very interrupt-driven, so asking them to build tools and systems for other people is never their top priority.

It’s taken us some time to find the right solution to these two problems above, and while our solution may not be right for everyone it’s worth consideration in most engineering organizations.

Iteration 1: Embed a Core Ops Member on a Dev Team

A few years ago, when we started moving towards a Service Oriented Architecture (SOA,) the decision was made that development teams should “own” the code they put in production and therefore should be “on-call” in case an outage occurred. Great idea, right? Systems administration isn’t going to know how to fix a problem that keeps happening every night at 2 AM, but the developer who wrote that code will. So let them get the alerts and provide them with the mechanisms to help debug issues as they occur in production.

However, due to orginizational constraints, we did not give the developers production access. So we effectively tied their hands behind their back while asking them to tread water in the open ocean. There was no way this would ever work. We needed to provide certain tools that would help the developer understand what was happening with their application. So we increased our metrics-gathering and logging capabilities and thought all would be well with the world.

At the same time, the team building this first service needed to spin up new hosts and get them configured in the same way as our other production hosts; another task they could not complete. Furthermore, our operations team was busy handling other support cases for our main application (ALM) which was more important than spinning up new hosts for some new service (that wasn’t even production-ready yet.)

So our engineering leadership made the decision that a core operations member would go and work with this service team and provide them with the needed system administrator skills to get their application into production. He would help bring up new hosts, get them configured (which was done by hand at the time,) set up deployment pipelines, and help debug issues that occurred in production while the application was being dark-launched. This approach worked well. The team found they had a lot more throughput and could experiment without having to bother several other teams to get the work done.

But ultimately this iteration wasn’t tenable. We couldn’t scale having an operations team member embedded on every service team we created. Plus, those teams were focused on delivering features, not solving the real problem at hand: automation and lack of tooling for production.

Iteration 2: Tooling Team, Take One

So we formed a new team that would work on speeding up the delivery lifecycle for the engineering orginization. The thought was that by giving this team a very specific goal, they would be less likely to be interrupted by other tasks.

We couldn’t have been more wrong. In fact, this team found that 80% of the work done was interrupt-driven, and therefore we could never accomplish the task we set out to do.

You’re probably wondering: Why was this team interrupted so often if it had such a specific task to perform? Well, part of it was the team make-up. One member of our team was the sole person responsible for maintianing our build infrastructure (the machines where our CI jobs were executed.) This meant most of his time was spent debugging issues around that system, instead of helping the team. In hindsight we should have found someone else to own that infrastructure (which we’ve now done) but when we were doing this it was hard to justify pulling someone off another team to maintain the machines when we already had someone.

Another reason we were interrupted was that we pushed out the first iteration of our configuration management solution way too early, and the teams that chose to use it were constantly finding problems. We’d have to drop everything and rush to fix their pipelines, so they could get their builds out to production. This sometimes took days or weeks, depending on the sitution. We also spent a ton of time trying to automate the configuration of systems that really didn’t need to be automated in the first place.

Iteration 3: Devops Team, aka SysAdmin for Hire

During the iteration 2 experiment, we also hired several system adminstrators in our remote offices to help facilitate the production tasks for the service teams. They worked outside of the core operations team and were often divided among multiple teams (unlike our iteration 1 experiment.) This was really unfortunate for the team whose work needed to be performed in production, but whose “DevOps” person was working with another team. Since their tooling support was incomplete, the iteration 2 team often felt blocked.

This had an unintended consequence: there was automation support for their service, in a silo very specific to their stack. Their “DevOps” person would help them operationalize that tool, so when they needed to perform a specific task they’d just run a Jenkins job or execute some CLI task. This was great for them but made it hard to reuse the scripts for other teams.

The “DevOps” team members were unable to spend their time buiding generic tools for their teams (or other teams for that matter) because they were now the point of interrupt for production outages and other tasks. Fighting fires became their fulltime job.

Iteration 4: Merge the Tooling Team with Ops

Eventually we realized that the tooling team from iteration 2 was building many of the things that our core operations team had wanted to build for years. So we did what every other engineering department would do: we merged them, and created a new team called Infrastructure Engineering. This team’s goal was to build reproducible infrastructure using tools like Chef and Docker, facilitating the goal of delivering services to production faster. It would ensure that all tasks were automated and had sensible UIs for developer interaction (whether CLI or web.)

But here, all we did was take two teams that were already experiencing high interrupt rates and physically relocate them next to each other in the office. We did nothing to address the interrupt-driven lifestyle that had become commonplace among both teams. The utopia they thought would occur as a result of the merger was quickly diminishing. After several developers left the team for various reasons, it was time to reevaluate the problems.

The Problems

  • Our core operations team is specifically an interrupt-driven team. They fight the fires that other teams cannot on their own.
  • Developers were being alerted or paged when their applications failed in production but didn’t have appropriate access to fix the problems, which caused more interrupts for the core ops team.
  • Compliance requirements were going to eat up even more of the core operations team time.
  • More and more services were coming online and we did not have the correct automation in place to make this easier (spinning up new VMs, for instance.)

Iteration 5: The Hard Decision

During our Q1 PSI planning at the beginning of this year, our engineering leadership made a very hard decision. We would divide the Infrastructure Engineering team into three parts: a tooling/platform team, a compliance team, and an interrupt/fire-fighting team. Siloing the interrupt work would allow the other two teams to actually complete the work that was needed by the end of the quarter.

Building a tooling team free of interrupts, and with a focused product (our first iteration of a Platform as a Service, or PaaS,) meant we were able to accurately predict and prioritze work in our quarterly PSI planning. We broke down our customer needs and set goals for each iteration on things we wanted to deliver. This brought a renewed sense of passion to the team and we’ve been crushing it ever since.

Now: Why do I feel this is the proper implentation of DevOps, vs. what we were doing before?

Our Developers Are More Efficient

The goal of every engineering orginization should be to make its developers more efficient. We did this years ago with the advent of TDD and automated testing. While you may still manual test your applications, the coverage required of your QA personel is drastically reduced because of the automation I hope you have in place. This makes your entire team more efficient, allowing them to increase their throughput.

Now ask yourself: Are there other areas of automation you wish you had in place that could make your development teams more efficient? This is why you need a tools team. There’s not enough time in the day for your developers to both create the tools they need and crank out features. So you have to decide: which would you rather have?

Your Ops Team Has Other Problems to Solve

Your operations team is a fountain of knowledge that’s been shaped and molded over years of midnight pages and one-too-many weekend alerts. They possess crucial information about the state of your infrastructure, and ideas to make it better. Tap into that knowledge and allow your tooling team to build operation tools that help them automate their day-to-day workflow so they can focus on building you a better system.

Your Ops and Development Teams Should Already Be Communicating

These teams should be focused on real problems: How can I effectively scale my application? Do we have enough bandwidth for a given service? What happens when this service increases the database load? While tooling can solve some of the problems your development teams face, it’s often not enough. Your development teams should be working closely with operations to solve application and system problems that are occuring in your environments. This is the value you want them delivering.

Now What?

There are probably people on your development and operations teams who are passionate about building these tools. Talk with them and find out what they would do to help your orginization, because I bet they go home at night and think about these problems. You should be harnessing this energy, and this is how you get started. Find a few things you can do quickly that will provide immediate value to your teams, and let them work on these. Then watch how the effect cascades and how those tools speed up other areas of your development cycle.

Over fifty fake call centres in Delhi-NCR duping job seekers, says Delhi Police

NEW DELHI: As Delhi and NCR has turned into a major educational hub, the region has also become the den of fraudsters duping job seekers of their hard-earned money on the pretext of getting them placed in multinational companies.

Investigations in this connection by Delhi Police and UPSTF reveal that at least 50 such call centers and job portals are running in the region. Similar frauds are being committed by some Nigerian nationals through phishing emails.

On March 25, UPSTF arrested two persons for allegedly running a fake call centre by taking data of job seekers from famous job portals, which unearthed the network of scamsters.

This case is just the tip of an iceberg and the police estimate that over 50 such fake call centers are operating in Delhi, Noida and Gurgaon.

Victims of such fraud are spread across India who are initially asked to make a payment of Rs 10,000 to Rs 25,000 for job in IT giants and MNCs.

Recently, an FIR was registered by the Delhi police against unidentified fraudsters after a complaint by Tata that several job seekers were duped on the pretext of getting them placed in it.

The youths were duped to the tune of Rs 8,000 to Rs 10,000 in the name of application and processing fee, police said.

While this case is being investigated by Economic Offence Wing of the Delhi Police, the wing formed to probe financial crimes had earlier unearthed a similar fraud in which gullible job seekers across the country were duped in the name of Maruti Suzuki India.

“Many of these gangs download resumes from job websites and then target people in faraway cities so that once duped they refrain from travelling to Delhi and registering complaints. We have also seen a case where people were duped in the name of getting them jobs in Delhi Metro Rail Corporation,” said a senior official in EOW.

Explaining the modus-operandi, UPSTF’s Additional Superintendent of Police Triveni Singh said, “Conmen first buy data of job seekers from famous job portals for Rs 25,000-Rs 40,000. Then they make a fake placement website which sounds similar to existing famous portals. They make calls to job seekers that their resume has been selected for a job in leading IT, banking and international companies and then demand money.”

Data of most of the job portals are compromised as they are not following stringent process to keep their data secured, a senior police officer said.

The police claim it becomes difficult to bust these gangs as their bank account, payment gateway and domain names are taken on fake identifies and many a times the servers are based abroad.

“Payment gate does not do physical verification of their client and allows payment against their commission. Similarly, domain registrar and server do not follow stringent rules and register customers on incomplete details,” Singh said.

As per police claims, in order to sound professional, gangs hire English speaking call centre executives and rent an office space at a plush commercial building.

“Job seekers are communicated in proper English through internet calling so that their number becomes difficult to track. In the name of registration and interview they extract Rs 20,000-50,000 from a candidate. All mobile SIMs, mobile phones and bank account are activated on fake documents,” Singh said.

According to cyber crime experts, most people in the scam are below 30 years of age and target fresh graduates who are desperate for jobs.

“Educational institutes have mushroomed in Delhi and NCR. These scamsters target unemployed fresh graduates. Most of these conmen have worked with job portals and call centers so they know how to exploit the loopholes.

“The initial payment they charge from each candidate is low so a complainant hesitates to approach police and even cops do not take these cases seriously. But criminals keep minting money and after running the racket from one place for a few months they change their location and other details,” Cyber Crime expert, Kislay Chaudhary said.