Archive for the ‘User Experience’ Category

Opting Out Of Advertising Cookies

Wednesday, January 4th, 2012

The internet is a creepy place, if you haven’t noticed… The majority of people are oblivious to what really goes on behind the scenes. Companies buy and sell information about you more than you could imagine, and they spend a lot of money on it. One of the most common pieces of information about you is your browser history. Advertising companies set cookies in your browser when you visit certain websites, and then they use that information to target additional advertising toward you after you’ve left those sites. Let’s run through an example scenario.

You open up your browser to your homepage of Google and do a search for laptops. Google keeps track of this for their future advertising usage. You click on a link to Best Buy. Now you have another cookie indicating you went to that website to look at laptops. Then say you click on an ad while looking at laptops for a Wii. Now another advertising network knows you are interested in buying a Wii or other video gaming system. So with just a few pageviews, several ad networks know you want a laptop, video game system, wii, and that you were thinking about buying one at Best Buy.

Now, the next hour, the next day, the next week, the next month, you will see ads now targeting those exact things, Best Buy, Wii, laptops. Some people consider this a convenience and prefer that ad networks know these things about you. I however, along with many others, consider this an invasion of my privacy. I will do my own research, and I don’t need some cheap ad on the internet to tell me what to read and what to buy. That’s why I’ve opted out of advertising cookies. It is a legal requirement of advertising networks actually, which shows you how sleazy what they are doing really is. If you want to opt out of every advertising network out there, there is a fantastic non-profit resource available to you. Check out the Network Advertising Initiative to get rid of all those ad networks on your computer so they can leave you alone!

Safe browsing…

Server And Client Side: What’s the Difference?

Monday, November 7th, 2011

It’s a pretty simple question if you know how the web works, but if you don’t, it is very complicated. To succeed working in the web world, you’ve got to have a firm grasp on the difference between server-side and client-side interactions. If you want the quick answer, here you go:

Server-Side: Server-side interactions require sending data to a server and the server sending data back to you, the client.

Client-Side: Client-side interactions don’t need a server, and data is exchanged or altered on your own computer browser without sending any information to a server.

Now if you need the longer explanation, you’ll first need a little background on how the internet works. The internet is just a mapping of connections between millions of computers around the world. When you type in a web address–such as http://www.google.com/–your computer knows that means go find the computer somewhere in the world that has the website for Google on it (I’m really simplifying things here if you can’t tell). The computer that has Google on it is called a "server". Servers aren’t typical computers. They don’t necessarily have any screens to view anything on, and for sites like Google, thousands of servers are collectively used to house the website.

So now that you understand the web (at least in a basic sense), we can start to learn about what server-side and client-side means with a more indepth explanation. So say you are on Google’s homepage. As a user (consumer) of Google, you can interact with their homepage in a multitude of ways. To understand each type of interaction, I’ll give an example using the Google homepage.

Client-Side: When you rollover a link in the navigation bar at the top and its display changes, you’ve just triggered the most basic client-side interaction, the pseudo class :hover in CSS. For a slightly more complex client-side interaction, by clicking on the "more" link in the navigation bar, a menu expands with more options. This is a very typical client-side interaction using simple javascript to hide and show something on your screen. In addition to CSS and Javascript being client-side languages, you should also include HTML, the basis of all displays in the web. Without HTML, the internet would be completely different from what we know it as today, and all three of those languages are interpreted on your own computer within your own browser, needing no interaction or data transfer from a server.

Server-Side: Now, after you’ve typed a search phrase into the search bar, when you click the "Search Google" button or click enter, you’ve now triggered a server-side interaction. Your computer doesn’t have the information it needs to conduct the search you are requesting, so it must send your search across a series of connections to a Google server somewhere in the world, that then sends back the results that it found for you. This is the basic concept behind server-side interactions. Typical server-side scripting languages include Perl, PHP, Java, and ASP.NET (I could keep going, but who is it really helping?). The key to identifying a server-side interaction is noting when your browser page reloads. Server-side interactions require reloading the browser window to show the results that were found. There is one exception to this rule.

A Combination Of Both: It is possible to conduct a server-side interaction without reloading the browser window. This requires a combination of both server-side and client-side interactions. Using a subset of Javascript called AJAX, we can send requests to a server, and then load those results into the client browser without a page reload. An example of this on the Google homepage is the suggested search phrases that change as you start typing. You type in a few characters, Google sends those characters to their server which then looks at frequent searches conducted by other people to make suggestions, and then sends them back and fills in the drop down menu for you to make a selection.

Now hopefully you’ve got a firm understanding of the difference between server and client side interactions and languages. If you’ve got any questions, don’t hesitate to ask.

Javascript: Creating a Text Watermark

Friday, January 7th, 2011

UPDATE: Read about the JQuery version of this text watermark.

This post is in response to a request to see how to create a textbox watermark using only text instead of an image. In a previous post, I explained how to use an image for a textbox watermark. Textbox watermarks are fantastic tools you can use to improve the usability of a website, as they give the user guidance on what to enter into the textbox. If you don’t want to use an image as my other post describes, here is how to create a simple watermark using javascript. Before we begin though, see exactly what you are making:

So either in an external Javascript file (which is called the same way as an external CSS file), or in the head of your HTML inside a <script> tag, include the following javascript:

The Javascript:

function watermark(inputId,text){
  var inputBox = document.getElementById(inputId);
    if (inputBox.value.length > 0){
      if (inputBox.value == text)
        inputBox.value = '';
    }
    else
      inputBox.value = text;
}

This javascript function checks if the textbox text isn’t empty, and then determines whether to clear the text or not. It also will put the watermark text back in if the user deletes what they entered or doesn’t enter anything. The function needs to be called in both the onblur and onfocus events of the textbox, which is explained below.

Here is the HTML that goes with the JS:

<input id="inputTextboxId" type="text" value="type here" onfocus="watermark('inputTextboxId','type here');" onblur="watermark('inputTextboxId','type here');" />

That’s all you need! And if you have any questions, don’t hesitate to ask! A question on my image watermark post lead to this post, so you never know!

AJAX: Wait Here Just A Minute

Sunday, September 12th, 2010

The best thing about Ajax is you can get brand new content on a page without having to reload it. The worst thing about ajax is people aren’t entirely used to waiting for content if they don’t see a page reload. Well, there is a quick and easy solution for that problem: animated gifs! In the beginnings of the web, animated gifs were used to make flashing titles that somehow everyone thought were the bee’s knees. Now that those are thankfully out of fashion, we can use animated gifs as an indicator that the website is “thinking”. The average web user won’t understand what all this AJAX stuff is doing in the background, all they need is something to tell them to wait just a little bit. Here are a few examples that I created using an awesome AJAX loading gif generator:

Oooh, that’s pretty. But maybe something more simple?

I like the simplicity, but it is too circly. Fix it designer!

And here’s a bar that could be used to indicate more of a “progress” concept instead of a “loading” concept:

I can guarantee that you’ve seen these types of images all over the web, and now you know why. It is possible people will implement these animated gifs for other purposes, but mostly, you’ll just experience them because of AJAX. Now go have fun making your own!

AJAX: What The Heck Is It?

Monday, August 16th, 2010

Ajax is the new web 2.0 fad, and it is probably here to stay for quite some time. AJAX, or Asynchronous Javascript and XML, is a method used to communicate with the server and load new content in a website without having to reload the page. You’ve probably seen it all over the web, but possibly without necessarily thinking about what it is. The minor difference makes a huge positive impact on users, and a pretty negative impact on page impressions.

So what type of things would AJAX come in handy for? Well a very common implementation is for search tools. Say you are on a site looking for houses and there are tons of criteria you can enter in to narrow down your search. It is really helpful to see how each change in your criteria affects your results. To offer constant feedback, web developers need to use AJAX to bring back search results each time you change criteria. If they didn’t use AJAX, you’d be staring at a page reload every time, and that’d be mindbogglingly annoying…

A great example is a search tool I worked on at my company, College Prowler. The tool is meant for high school students trying to find colleges that fit their criteria of where they want to attend a college. Test it out and see for yourself here. The telltale sign of AJAX by the way is one of those circling gifs to indicate something is loading, so keep an eye out for that as you browse the web.

So now maybe you understand the benefits of AJAX. It makes for a much more fun and usable experience for users as they traverse your website. The serious downside is a decrease in your pageviews. Every time you make an AJAX call, you lose what would have been a new page load and thus a new pageview. With each pageview (if you know what’s good for you AND have a highly trafficked website), you gain ad income. Now you could argue that with the improved user experience, you’ll make up for the lost pageviews in your AJAX tool with more devoted users (an argument I agree with), but that doesn’t cut it for everyone.

So make the choice to go with AJAX. In an upcoming post, I’ll write about the basics of AJAX and how to implement it.
Cheerio!