rowid,title,contents,year,author,author_slug,published,url,topic
150,"A Gift Idea For Your Users: Respect, Yo","If, indeed, it is the thought that counts, maybe we should pledge to make more thoughtful design decisions.  In addition to wowing people who use the Web sites we build with novel features, nuanced aesthetics and the new new thing, maybe we should also thread some subtle things throughout our work that let folks know:  hey, I’m feeling ya.  We’re simpatico.  I hear you loud and clear.

It’s not just holiday spirit that moves me to talk this way.  As good as people are, we need more than the horizon of karma to overcome that invisible demon, inertia.  Makers of the Web, respectful design practices aren’t just the right thing, they are good for business.  Even if your site is the one and only place to get experience x, y or zed, you don’t rub someone’s face in it.  You keep it free flowing, you honor the possible back and forth of a healthy transaction, you are Johnny Appleseed with the humane design cues.  You make it clear that you are in it for the long haul.

A peek back:



Think back to what search (and  strategy) was like before Google launched a super clean page with “I’m Feeling Lucky” button.  Aggregation was the order of the day (just go back and review all the ‘strategic alliances’ that were announced daily.)  Yet the GOOG comes along with this zen layout (nope, we’re not going to try to make you look at one of our media properties) and a bold, brash, teleport-me-straight-to-the-first-search-result button.  It could have been titled “We’re Feeling Cocky”.  These were radical design decisions that reset how people thought about search services.  Oh, you mean I can just find what I want and get on with it?

It’s maybe even more impressive today, after the GOOG has figured out how to monetize attention better than anyone.  “I’m Feeling Lucky” is still there.  No doubt, it costs the company millions.  But by leaving a little money on the table, they keep the basic bargain they started to strike in 1997.  We’re going to get you where you want to go as quickly as possible.

Where are the places we might make the same kind of impact in our work?  Here are a few ideas:

Respect People’s Time

As more services become more integrated with our lives, this will only become more important.  How can you make it clear that you respect the time a user has granted you?

User-Oriented Defaults

Default design may be the psionic tool in your belt.  Unseen, yet pow-er-ful.  Look at your defaults.  Who are they set up to benefit?  Are you depending on users not checking off boxes so you can feel ok about sending them email they really don’t want?  Are you depending on users not checking off boxes so you tilt privacy values in ways most beneficial for your SERPs?  Are you making it a little too easy for 3rd party applications to run buckwild through your system?

There’s being right and then there’s being awesome.  Design to the spirit of the agreement and not the letter.

See this?



Make sure that’s really the experience you think people want.  Whenever I see a service that defaults to not opting me in their newsletter just because I bought a t shirt from them, you can be sure that I trust them that much more.  And they are likely to see me again.

Reduce, Reuse

It’s likely that people using your service will have data and profile credentials elsewhere.  You should really think hard about how you can let them repurpose some of that work within your system.  Can you let them reduce the number of logins/passwords they have to manage by supporting OpenID?  Can you let them reuse profile information from another service by slurping in (or even subscribing) to hCards?  Can you give them a leg up by reusing a friends list they make available to you?  (Note:  please avoid the anti-pattern of inviting your user to upload all her credential data from 3rd party sites into your system.)

This is a much larger issue, and if you’d like to get involved, have a look at the wiki, and dive in.

Make it simple to leave

Oh, this drives me bonkers.  Again, the more simple you make it to increase or decrease involvement in your site, or to just opt-out altogether, the better.  This example from Basecamp is instructive:



At a glance, I can see what the implications are of choosing a different type of account.  I can also move between account levels with one click.  Finally, I can cancel the service easily.  No hoop jumping.  Also, it should be simple for users to take data with them or delete it.

Let Them Have Fun

Don’t overlook opportunities for pleasure.  Even the most mundane tasks can be made more enjoyable.  Check out one of my favorite pieces of interaction design from this past year:



Holy knob fiddling, Batman!  What a great way to get people to play with preference settings:  an equalizer metaphor.  Those of a certain age will recall how fun it was to make patterns with your uncle’s stereo EQ.  I think this is a delightful way to encourage people to optimize their own experience of the news feed feature.  Given the killer nature of this feature, it was important for Facebook to make it easy to fine tune.

I’d also point you to Flickr’s Talk Like A Pirate Day Easter egg as another example of design that delights.  What a huge amount of work for a one-off, totally optional way to experience the site.  And what fun.  And how true to its brand persona.  Brill.

Anti-hype

Don’t talk so much.  Rather, ship and sample.  Release code, tell the right users.  See what happens.   Make changes.  Extend the circle a bit by showing some other folks.  Repeat.

The more you hype coming features, the more you talk about what isn’t yet, the more you build unrealistic expectations.  Your genius can’t possibly match our collective dreaming.  Disappointment is inevitable.  Yet, if you craft the right melody and make it simple for people to hum your tune, it will spread.  Give it time.  Listen.

Speak the Language of the Tribe

It’s respectful to speak in a human way.  Not that you have to get all zOMGWTFBBQ!!1 in your messaging.  People respond when you speak to them in a way that sounds natural.  Natural will, of course, vary according to context.  Again, listen in and people will signal the speech that works in that group for those tasks.  Reveal those cues in your interface work and you’ll have powerful proof that actual people are working on your Web site.

This example of Pownce‘s gender selector is the kind of thing I’m talking about:



Now, this doesn’t mean you should mimic the lingo on some cool kidz site.  Your service doesn’t need to have a massage when it’s down.  Think about what works for you and your tribe.  Excellent advice here from Feedburner’s Dick Costolo on finding a voice for your service.  Also, Mule Design’s Erika Hall has an excellent talk on improving your word fu.

Pass the mic, yo

Here is a crazy idea:  you could ask your users what they want.  Maybe you could even use this input to figure out what they really want.  Tools abound.  Comments, wikis, forums, surveys.  Embed the sexy new Get Satisfaction widget and have a dynamic FAQ running.

The point is that you make it clear to people that they have a means of shaping the service with you.  And you must showcase in some way that you are listening, evaluating and taking action against some of that user input.

You get my drift.  There are any number of ways we can show respect to those who gift us with their time, data, feedback, attention, evangelism, money.  Big things are in the offing.  I can feel the love already.",2007,Brian Oberkirch,brianoberkirch,2007-12-23T00:00:00+00:00,https://24ways.org/2007/a-gift-idea-for-your-users-respect-yo/,ux
159,How Media Studies Can Massage Your Message,"A young web designer once told his teacher ‘just get to the meat already.’ He was frustrated with what he called the ‘history lessons and name-dropping’ aspects of his formal college course. He just wanted to learn how to build Web sites, not examine the reasons why.

Technique and theory are both integrated and necessary portions of a strong education. The student’s perspective has direct value, but also holds a distinct sorrow: Knowing the how without the why creates a serious problem. Without these surrounding insights we cannot tap into the influence of the history and evolved knowledge that came before. We cannot properly analyze, criticize, evaluate and innovate beyond the scope of technique.

History holds the key to transcending former mistakes. Philosophy encourages us to look at different points of view. Studying media and social history empowers us as Web workers by bringing together myriad aspects of humanity in direct relation to the environment of society and technology. Having an understanding of media, communities, communication arts as well as logic, language and computer savvy are all core skills of the best of web designers in today’s medium.

Controlling the Message


	‘The computer can’t tell you the emotional story. It can give you the exact mathematical design, but what’s missing is the eyebrows.’ – Frank Zappa


Media is meant to express an idea. The great media theorist Marshall McLuhan suggests that not only is media interesting because it’s about the expression of ideas, but that the media itself actually shapes the way a given idea is perceived.  This is what McLuhan meant when he uttered those famous words: ‘The medium is the message.’

If instead of actually serving a steak to a vegetarian friend, what might a painting of the steak mean instead? Or a sculpture of a cow? Depending upon the form of media in question, the message is altered.

Figure 1

Must we know the history of cows to appreciate the steak on our plate? Perhaps not, but if we begin to examine how that meat came to be on the plate, the social, cultural and ideological associations of that cow, we begin to understand the complexity of both medium and message. A piece of steak on my plate makes me happy. A vegetarian friend from India might disagree and even find that that serving her a steak was very insensitive.

Takeaway: Getting the message right involves understanding that message in order to direct it to your audience accordingly.

A Separate Piece

If we revisit the student who only wants technique, while he might become extremely adept at the rendering of an idea, without an understanding of the medium, how is he to have greater control over how that idea is perceived?  Ultimately, his creativity is limited and his perspective narrowed, and the teacher has done her student a disservice without challenging him, particularly in a scholastic environment, to think in liberal, creative and ultimately innovative terms.

For many years, web pundits including myself have promoted the idea of separation as a core concept within creating effective front-end media for the Web. By this, we’ve meant literal separation of the technologies and documents: Markup for content; CSS for presentation; DOM Scripting for behavior. While the message of separation was an important part of understanding and teaching best practices for manageable, scalable sites, that separation is really just a separation of pieces, not of entire disciplines.

For in fact, the medium of the Web is an integrated one. That means each part of the desired message must be supported by the media silos within a given site.  The visual designer must study the color, space, shape and placement of visual objects (including type) into a meaningful expression. The underlying markup is ideally written as semantically as possible, promote the meaning of the content it describes. Any interaction and functionality must make the process of the medium support, not take away from, the meaning of the site or Web application.  

Examination: The Glass Bead Game

Figure 2

Figure 2 shows two screenshots of CoreWave’s historic ‘Glass Bead Game.’ Fashioned after Herman Hesse’s novel of the same name, the game was an exploration of how ideas are connected to other ideas via multiple forms of media. It was created for the Web in 1996 using server-side randomization with .htmlx files in order to allow players to see how random associations are in fact not random at all.

Takeaway: We can use the medium itself to explore creative ideas, to link us from one idea to the next, and to help us better express those ideas to our audiences.

Computers and Human Interaction

Since our medium involves computers and human interaction, it does us well to look to foundations of computers and reason. Not long ago I was chatting with Jared Spool on IM about this and that, and he asked me ‘So how do you feel about that?’ This caused me no end of laughter and I instantly quipped back ‘It’s okay by me ELIZA.’ We both enjoyed the joke, but then I tried to share it with another dare I say younger colleague, and the reference was lost.

Raise your hand if you got the reference! Some of you will, but many people who come to the Web medium do not get the benefit of such historical references because we are not formally educated in them. Joseph Weizenbaum created the ELIZA program, which emulates a Rogerian Therapist, in 1966. It was an early study of computers and natural human language. I was a little over 2 years old, how about you?

Conversation with Eliza

There are fortunately a number of ELIZA emulators on the Web. I found one at http://www.chayden.net/eliza/Eliza.html that actually contains the source code (in Java) that makes up the ELIZA script.

Figure 3 shows a screen shot of the interaction. ELIZA first welcomes me, says ‘Hello, How do you do. Please state your problem’ and we continue in a short loop of conversation, the computer using cues from my answers to create new questions and leading fragments of conversation.

Figure 3

Albeit a very limited demonstration of how humans could interact with a computer in 1966, it’s amusing to play with now and compare it to something as richly interactive as the Microsoft Surface (Figure 4). Here, we see clear Lucite blocks that display projected video. Each side of the block has a different view of the video, so not only does one have to match up the images as they are moving, but do so in the proper directionality.

Figure 4

Takeway: the better we know our environment, the more we can alter it to emulate, expand and even supersede our message.

Leveraging Holiday Cheer

Since most of us at least have a few days off for the holidays now that Christmas is upon us, now’s a perfect time to reflect on ones’ environment and examine the messages within it. Convince your spouse to find you a few audio books for stocking stuffers. Find interactive games to play with your kids and observe them, and yourself, during the interaction. Pour a nice egg-nog and sit down with a copy of Marshall McLuhan’s ‘The Medium is the Massage.’ Leverage that holiday cheer and here’s to a prosperous, interactive new year.",2007,Molly Holzschlag,mollyholzschlag,2007-12-22T00:00:00+00:00,https://24ways.org/2007/how-media-studies-can-massage-your-message/,ux
160,Tracking Christmas Cheer with Google Charts,"A note from the editors:  Since this article was written Google has retired the Charts API.
                
                
                      
                Let’s get something out in the open: I love statistics. As an informatician I can’t get enough graphs, charts, and numbers. So you can imagine when Google released their Charts API I thought Christmas had come early. I immediately began to draw up graphs for the holiday season using the new API; and using my new found chart-making skills I’ll show you what you can and can’t do with Google Charts.

Mummy, it’s my first chart

The Google Charts API allows you to send data to Google; in return they give you back a nicely-rendered graph. All the hard work is done on Google’s servers — you need only reference an image in your HTML. You pass along the data — the numbers for the charts, axis labels, and so on — in the query string of the image’s URL. If you want to add charts to your blog or web site, there’s probably no quicker way to get started.

Here’s a simple example: if we add the following line to an HTML page:

<img src=""http://chart.apis.google.com/chart?cht=lc&chs=200x125&chd=s:ZreelPuevfgznf2008"" />

Then we’ll see the line graph in Figure 1 appear in our page. That graph is hosted on Google’s own server1: http://chart.apis.google.com/.

Figure 1: A simple example of a line graph created with Google Charts.

If you look at the URL used in the example you’ll notice we’re passing some parameters along in the query string (the bit after the question mark). The query string looks like this:

cht=lc&chs=200x125&chd=s:ZreelPuevfgznf2008

It’s contains everything Google Charts needs to draw the graph.  There are three parameters in the query string:


	cht; this specifies the type of chart Google Charts will generate (in this case, lc is a line chart).
	chs, the value of which is 200x125; this defines the chart’s size (200 pixels wide by 125 pixels high).
	chd, the value of which is s:ZreelPuevfgznf2008; this is the actual chart data, which we’ll discuss in more detail later.


These three parameters are the minimum you need to send to Google Charts in order to create a chart.  There are lots more parameters you can send too (giving you more choice over how a chart is displayed), but you have to include at least these three before a chart can be created. Using these three parameters you can create pie charts, scatter plots, Venn diagrams, bar charts (and more) up to 1,000 pixels wide or 1,000 pixels high (but no more than 300,000 pixels in total).

Christmas pie

After I discovered the option to create a pie chart I instantly thought of graphing all the types of food and beverages that I’ll consume at this year’s Christmas feast. I can represent each item as a percentage of all the food on a pie chart (just thinking about that makes me hungry).

By changing the value of the cht parameter in the image’s query string I can change the chart type from a line chart to a pie chart. Google Charts offers two different types of pie chart: a fancy three-dimensional version and a two-dimensional overhead version. I want to stick with the latter, so I need to change cht=lc to cht=p (the p telling Google Charts to create a pie chart; if you want the three-dimensional version, use cht=p3). As a pie chart is circular I also need to adjust the size of the chart to make it square. Finally, it would be nice to add a title to the graph. I can do this by adding the optional parameter, chtt, to the end of the image URL. I end up with the chart you see in Figure 2.

Figure 2: Pie chart with a title.

To add this chart to your own page, you include the following (notice that you can’t include spaces in URLs, so you need to encode them as plus-signs.):

<img src=""http://chart.apis.google.com/chart?chtt=Food+and+Drink+Consumed+Christmas+2007&cht=p&chs=300x300&chd=s:ZreelPuevfgznf2008"" />

Ok, that’s great, but there are still two things I want to do before I can call this pie chart complete. First I want to label each slice of the pie. And second I want to include the proper data (at the moment the slices are meaningless). If 2007 is anything like 2006, the break down will be roughly as follows:


		
			Egg nog
			10%
		
		
			Christmas Ham
			20%
		
		
			Milk (not including egg nog)
			8%
		
		
			Cookies
			25%
		
		
			Roasted Chestnuts
			5%
		
		
			Chocolate
			3%
		
		
			Various Other Beverages
			15%
		
		
			Various Other Foods
			9%
		
		
			Snacks
			5%
		


I have nine categories of food and drink to be tracked, so I need nine slice labels. To add these to the chart, I use the chl parameter. All nine labels are sent in one value; I use the vertical-pipe character, |,  to separate them. So I need to append the following to the query string:

chl=Egg+nog|Christmas+Ham|Milk+(not+including+egg+nog)|Cookies|Roast+Chestnuts|Chocolate|Various+Other+Beverages|Various+Other+Foods|Snacks

Next I need to add the corresponding percentage values to the chart labels. Encoding the chart data is the trickiest part of the Google Charts API — but by no means complicated. There are three different ways to encode your data on a chart. As I’m only dealing with small numbers, I’m going to use what Google calls simple encoding.

Simple encoding offers a sixty-two value spectrum in which to represent data. Remember the mandatory option, chd, from the first example? The value for this is split into two parts: the type of encoding and the graph data itself.  These two parts are separated with a colon.  To use simple encoding, the first character of the chd option must be a lower case s. Follow this with a colon and everything after it is considered data for the graph.

In simple encoding, you have sixty-two values to represent your data. These values are lowercase and uppercase letters from the Latin alphabet (fifty-two characters in total) and the digits 0 to 9. Each letter of the alphabet represents a single number: A equals 0, B equals 1, and so on up to Z, which equals 25; a equals 26, b equals 27, and so on up to z, which equals 51. The ten digits represent the numbers 52 to 61: 0 equals 52, 1 equals 53, and 9 equals 61.

In the previous two examples we used the string ZreelPuevfgznf2008 as our chart data; the Z is equal to 25, the r is equal to 42, the e is equal to 30, and so on. I want to encode the percentage values 10, 20, 8, 25, 5, 3, 15, 9 and 5, so in simple encoding I would use the string KUIZFDPJF.

If you think figuring this out for each chart may make your head explode, don’t worry: help is out there.

Do you remember I said I needed to change the image dimensions to be square, to accommodate the pie chart? Well now I’m including labels I need even more room. And as I’m in a Christmassy mood I’m going to add some festive colours too.

The optional chco parameter is used to change the chart color. You set this using the same hexadecimal (“hex”) notation found in CSS. So let’s make our pie chart green by adding chco=00AF33 (don’t start it with a hash character as in CSS) to the image URL. If we only specify one hex colour for the pie chart Google Charts will use shades of that colour for each of the slices. To choose your own colours, pass a comma separated list of colours. The “Milk” and “Cookies” slices were consumed together, so we can make those two slices more of a redish colour.  I’ll use shades of green for the other slices. My chco parameter now looks like this:

chco=00AF33,4BB74C,EE2C2C,CC3232,33FF33,66FF66,9AFF9A,C1FFC1,CCFFCC.

After all this, I’m left with the following URL:

http://chart.apis.google.com/chart?chco=00AF33,4BB74C,EE2C2C,CC3232,33FF33,66FF66,9AFF9A,C1FFC1,CCFFCC&chl=Egg+nog|Christmas+Ham|Milk+(not+including+egg+nog)|Cookies|Roast+Chestnuts|Chocolate|Various+Other+Beverages|Various+Other+Foods|Snacks&chtt=Food+and+Drink+Consumed+Christmas+2007&cht=p&chs=600x300&chd=s:KUIZFDPJF

What does that give us?  I’m glad you asked.  I have the rather beautiful 600-pixel wide pie chart you see in Figure 3.

Figure 3: A Christmassy pie chart with labels.

But I don’t like pie charts

The pie chart was invented by the Scottish polymath William Playfair in 1801.  But not everyone is as excited by pie charts as wee Billy, so if you’re an anti-pie-chartist, what can you do?

You can easily reuse the same data but display it as a bar graph in a snap. The first thing we need to do is change the value of the cht parameter from p to bhg. This creates a horizontal bar graph (you can request a vertical bar graph using bvg). The data and labels all remain the same, but we need to decide where the labels will appear. I’ll talk more about how to do all this in the next section. 

In Figure 4 you’ll see the newly-converted bar graph. The URL for the graph is:

http://chart.apis.google.com/chart?cht=bhg&chs=600x300&chd=s:KUIZFDPJF&chxt=x,y&chtt=Food+and+Drink+Consumed+Christmas+2007&chxl=1:|Egg+nog|Christmas+Ham|Milk+(not+including+egg+nog)|Cookies|Roast+Chestnuts|Chocolate|Various+Other+Beverages|Various+Other+Foods|Snacks&chco=00AF33

Figure 4: The pie chart from Figure 3 represented as a bar chart.

Two lines, one graph

Pie charts and bar charts are interesting, but what if I want to compare last year’s Christmas cheer with this year’s? That sounds like I’ll need two lines on one graph.

The code is much the same as the previous examples; the most obvious difference is I need to set up the chart as a line graph. Creating some dummy values for the required parameters, I end up with:

<img src=""http://chart.apis.google.com/chart?chs=800x300&cht=lxy&chd=t:0,100|0,100"" />

The chs=800x300 sets the dimensions of the new chart, while cht=lxy describes the type of chart we are using (in this case a line chart with x and y co-ordinates). For the chart data I’m going to demostrate a different encoding, text encoding. To use this I start the value of the chd parameter with “t:”  instead of “s:”, and follow it with a list of x coordinates, a vertical pipe, |, and a list of y coordinates. Given the URL above, Google Charts will render the chart shown in Figure 5.

Figure 5: A simple line graph with x and y co-ordinates.

To make this graph a little more pleasing to the eye, I can add much the same as I did to the pie chart. I’ll add a chart title. Maybe something like “Projected Christmas Cheer for 2007”. Just as before I would add a chtt parameter to the image URL:

&chtt=Projected+Christmas+Cheer+for+2007

Next, let’s add some labels on the y axis to represent a scale from 0 to 100. On the x axis let’s label for the most important days of December. To do this I need to use the chart axis type parameter, chxt. This allows us to specify the axes and associate some labels with them. As I’m only interested in the y-axis (to the left of the chart) and the x-axis (below the chart), we add chxt=x,y to our image URL.

Now I need my label data. This is slightly more tricky because I want the data evenly spaced without labelling every item. The parameter for labels is chxl, the chart axis label. You match a label to an axis by using a number. So 0:Label1 is the zero index of chxt — in this case the x-axis. 1:Label2 is the first index of chxt — the y-axis. The order of these parameters or labels doesn’t matter as long as you associate them to their chxt correctly.

The next thing to know about chxl is that you can add an empty label. Labels are separated by vertical pipe; if you don’t put any text in a label, you just leave the two vertical pipes empty (“||”) and Google Charts will allocate space but no label.

For our vertical y axis, we want to label only 50% and 100% on the graph and plot them in their respective places. Since the y-axis is the second item, 1: (remember to start counting at zero), we add ten spaces to our image URL, chxl=1:||||||50|||||100 This will output the 50 halfway and the 100 at the top; all the other spaces will be empty.

We can do the same thing to get specific dates along the x-axis as well. Let’s add the 1st of December, St. Nick’s Day (the 6th), Christmas Day, Boxing Day (a holiday common in the UK and the Commonwealth, on the 26th), and the final day of the month, the 31st.  Since this is the x-axis I’ll use 0: as a reference in the chxt parameter tell Google Charts which axis to label. In full, the chxl parameter now looks like:

chxl=1:||||||50|||||100|0:|Dec+1st|||||6th||||10th|||||15th|||||20th|||||25th|26th|||||Dec+31st

That’s pretty.

Before we begin to graph our data, I’ll do one last thing: add some grid lines to the chart so to better connect the data to the labels. The parameter for this is chg, short for chart grid lines. The parameter takes four comma-separated arguments. The first is the x-axis spacing for the grid. I have thirty-one days, so I need thirty vertical lines. The chart is 100% wide, so 3.33 (100 divided by 30) is the required spacing.

As for the y-axis: the axis goes up to 100% but we probably only need to have a horizontal line every 10%, so the required spacing is 10 (100 divided by 10). That is the second argument.

The last two arguments control the dash-style of the grid-lines. The first number is the length of the line dash and the second is the space between the dashes. So 6,3 would mean a six-unit dash with a three-unit space. I like a ratio of 1,3 but you can change this as you wish. Now that I have the four arguments, the chg parameter looks like:

chg=3.333,10,1,3

If I add that to the chart URL I end up with:

http://chart.apis.google.com/chart?chs=800x300&cht=lxy&chd=t:0,100|0,100&chtt=Projected+Christmas+Cheer+for+2007&chxt=x,y&chxl=0:|Dec+1st|||||6th|||||||||||||||||||25th|26th|||||Dec+31st|1:||||||50|||||100&chg=3.3333,10,1,3

Which results in the chart shown in Figure 6.

Figure 6: Chart ready to receive the Christmas cheer values.

Real data

Now the chart is ready I can add historical data from 2006 and current data from 2007.

Having a look at last year’s cheer levels we find some highs and lows through-out the month:


		
			Dec 1st
			Advent starts; life is good
			30%
		
		
			Dec 6th
			St. Nick’s Day, awake to find good things in my shoes
			45%
		
		
			Dec 8th
			Went Christmas carolling, nearly froze
			20%
		
		
			Dec 10th
			Christmas party at work, very nice dinner
			50%
		
		
			Dec 18th
			Panic Christmas shopping, hate rude people
			15%
		
		
			Dec 23rd
			Off Work, home eating holiday food
			80%
		
		
			Dec 25th
			Opened presents, good year, but got socks again from Grandma
			60%
		
		
			Dec 26th
			Boxing Day; we’re off and no one knows why
			70%
		
		
			Dec 28th
			Third day of left overs
			40%
		
		
			Dec 29th
			Procured some fireworks for new years
			55%
		
		
			Dec 31st
			New Year’s Eve
			80%
		


Since I’m plotting data for 2006 and 2007 on the same graph I’ll need two different colours — one for each year’s line — and a key to denote what each colour represents. The key is controlled by the chdl (chart data legend) parameter. Again, each part of the parameter is separated by a vertical pipe, so for two labels I’ll use chdl=2006|2007. I also want to colour-code them, so I’ll need to add the chco as I did for the pie chart. I want a red line and a green line, so I’ll use chco=458B00,CD2626 and add this to the image URL.

Let’s begin to plot the 2006 data on the Chart, replacing our dummy data of chd=t:0,100|0,100 with the correct information. The chd works by first listing all the x coordinates (each separated by a comma), then a vertical pipe, and then all the y coordinates (also comma-separated). The chart is 100% wide, so I need to convert the days into a percentage of the month.

The 1st of December is 0 and the 31st is 100. Everything else is somewhere in between. Our formula is:

(d – 1) × 100 ÷ (31 – 1)

Where d is the day of the month. The formula states that each day will be printed every 3.333 units; so the 6th of December will be printed at 16.665 units. I can repeat the process for the other dates listed to get the following x coordinates: 0,16.7,23.3,33.3,60,76.7,83.3,86.7,93.3,96.7. The y axis coordinates are easy because our scale is 100%, just like our rating, so we can simply copy them across as 30,45,20,50,15,80,60,70,40,55,80. This gives us a final chd value of:

chd=t:0,16.7,23.3,33.3,60,76.7,83.3,86.7,93.3,96.7,100|30,45,20,50,15,80,60,70,40,55,80

Onto 2007: I can put the data for the month so far to see how we are trending.


		
			Dec 1st
			Christmas shopping finished already
			50%
		
		
			Dec 4th
			Computer hard disk drive crashed (not Christmas related accident, but put me in a bad mood)
			10%
		
		
			Dec 6th
			Missed St. Nick’s Day completely due to travelling
			30%
		
		
			Dec 9th
			Dinner with friends before they travel
			55%
		
		
			Dec 11th
			24ways article goes live
			60%
		


Using the same system we did for 2006, I can take the five data points and plot them on the chart. The new x axis values will be 0,10,16.7,26.7 and the new y axis 50,10,30,65. We incorporate those into the image URL by appending these values onto the chd parameter we already have, which then becomes:

chd=t:0,16.7,23.3,33.3,60,76.7,83.3,86.7,93.3,96.7,100|30,45,20,50,15,80,60,70,40,55,80|0,10,16.7,26.7,33.3|50,10,30,55,60

Passing this to Google Charts results in Figure 7.

http://chart.apis.google.com/chart?chs=800x300&cht=lxy&chd=t:0,100|0,100&chtt=Projected+Christmas+Cheer+for+2007&chxt=x,y&chxl=0:|Dec+1st|||||6th|||||||||||||||||||25th|26th|||||Dec+31st|1:||||||50|||||100&chg=3.3333,10,1,3&chd=t:0,16.7,23.3,33.3,60,76.7,83.3,86.7,93.3,96.7,100|30,45,20,50,15,80,60,70,40,55,80|0,10,16.7,26.7,33.3|50,10,30,55,60&chco=458B00,CD2626&chdl=2006|2007

Figure 7: Projected Christmas cheer for 2006 and 2007.

Did someone mention Edward Tufte?

Google Charts are a robust set of chart types that you can create easily and freely using their API. As you can see, you can graph just about anything you want using the line graph, bar charts, scatter plots, venn diagrams and pie charts. One type of chart conspicuously missing from the API is sparklines.  Sparklines were proposed by Edward Tufte as “small, high resolution graphics embedded in a context of words, numbers, images”.  They can be extremely useful, but can you create them in Google Charts?

The answer is: “Yes, but it’s an undocumented feature”. (The usual disclaimer about undocumented features applies.)

If we take our original line graph example, and change the value of the cht parameter from lc (line chart) to lfi (financial line chart) the axis-lines are removed. This allows you to make a chart — a sparkline — small enough to fit into a sentence. Google uses the lfi type all throughout the their financial site, but it’s not yet part of the official API.


		
			MerryChristmas
			
			http://chart.apis.google.com/chart?cht=lfi&chs=100x15&chd=s:MerryChristmas
		
		
			24ways
			
			http://chart.apis.google.com/chart?cht=lfi&chs=100x15&chd=s:24ways&chco=999999
		
		
			HappyHolidays
			
			http://chart.apis.google.com/chart?cht=lfi&chs=100x15&chd=s:HappyHolidays&chco=ff0000
		
		
			HappyNewYear
			
			http://chart.apis.google.com/chart?cht=lfi&chs=100x15&chd=s:HappyNewYear&chco=0000ff
		


Summary

The new Google Charts API is a powerful method for creating charts and graphs of all types. If you apply a little bit of technical skill you can create pie charts, bar graphs, and even sparklines as and when you need them. Now you’ve finished ready the article I hope you waste no more time: go forth and chart!

Further reading


	Google Charts API
	More on Google Charts
	How to handle negative numbers
	12 Days of Christmas Pie Chart


1 In order to remain within the 50,000 requests a day limit the Google Charts API imposes, chart images on this page have been cached and are being served from our own servers. But the URLs work – try them!",2007,Brian Suda,briansuda,2007-12-11T00:00:00+00:00,https://24ways.org/2007/tracking-christmas-cheer-with-google-charts/,ux
166,Performance On A Shoe String,"Back in the summer, I happened to notice the official Wimbledon All England Tennis Club site had jumped to the top of Alexa’s Movers & Shakers list — a list that tracks sites that have had the biggest upturn or downturn in traffic. The lawn tennis championships were underway, and so traffic had leapt from almost nothing to crazy-busy in a no time at all. 

Many sites have similar peaks in traffic, especially when they’re based around scheduled events. No one cares about the site for most of the year, and then all of a sudden – wham! – things start getting warm in the data centre. Whilst the thought of chestnuts roasting on an open server has a certain appeal, it’s less attractive if you care about your site being available to visitors. Take a look at this Alexa traffic graph showing traffic patterns for superbowl.com at the beginning of each year, and wimbledon.org in the month of July.

Traffic graph from Alexa.com 

Whilst not on the same scale or with such dramatic peaks, we have a similar pattern of traffic here at 24ways.org. Over the last three years we’ve seen a dramatic pick up in traffic over the month of December (as would be expected) and then a much lower, although steady load throughout the year. What we do have, however, is the luxury of knowing when the peaks will be. For a normal site, be that a blog, small scale web app, or even a small corporate site, you often just cannot predict when you might get slashdotted, end up on the front page of Digg or linked to from a similarly high-profile site. You just don’t know when the peaks will be.

If you’re a big commercial enterprise like the Super Bowl, scaling up for that traffic is simply a cost of doing business. But for most of us, we can’t afford to have massive capacity sat there unused for 90% of the year. What you have to do instead is work out how to deal with as much traffic as possible with the modest resources you have.

In this article I’m going to talk about some of the things we’ve learned about keeping 24 ways running throughout December, whilst not spending a fortune on hosting we don’t need for 11 months of each year. We’ve not always got it right, but we’ve learned a lot along the way.

The Problem

To know how to deal with high traffic, you need to have a basic idea of what happens when a request comes into a web server. 24 ways is hosted on a single small virtual dedicated server with a great little hosting company in the UK. We run Apache with PHP and MySQL all on that one server. When a request comes in a new Apache process is started to deal with the request (or assigned if there’s one available not doing anything). Each process takes a bunch of memory, so there’s a finite number of processes that you can run, and therefore a finite number of pages you can serve at once before your server runs out of memory.

With our budget based on whatever is left over after beer, we need to get best performance we can out of the resources available. As the goal is to serve as many pages as quickly as possible, there are several approaches we can take:


	Reducing the amount of memory needed by each Apache process
	Reducing the amount of time each process is needed
	Reducing the number of requests made to the server


Yahoo! have published some information on what they call Exceptional Performance, which is well worth reading, and compliments many of my examples here. The Yahoo! guidelines very much look at things from a user perspective, which is always important.

Server tweaking

If you’re in the position of being able to change your server configuration (our set-up gives us root access to what is effectively a virtual machine) there are some basic steps you can take to maximise the available memory and reduce the memory footprint. Without getting too boring and technical (whole books have been written on this) there are a couple of things to watch out for.

Firstly, check what processes you have running that you might not need. Every megabyte of memory that you free up might equate to several thousand extra requests being served each day, so take a look at top and see what’s using up your resources. Quite often a machine configured as a web server will have some kind of mail server running by default. If your site doesn’t use mail (ours doesn’t) make sure it’s shut down and not using resources.

Secondly, have a look at your Apache configuration and particularly what modules are loaded. The method for doing this varies between versions of Apache, but again, every module loaded increases the amount of memory that each Apache process requires and therefore limits the number of simultaneous requests you can deal with.

The final thing to check is that Apache isn’t configured to start more servers than you have memory for. This is usually done by setting the MaxClients directive. When that limit is reached, your site is going to stop responding to further requests. However, if all else goes well that threshold won’t be reached, and if it does it will at least stop the weight of the traffic taking the entire server down to a point where you can’t even log in to sort it out.

Those are the main tidbits I’ve found useful for this site, although it’s worth repeating that entire books have been written on this subject alone.

Caching

Although the site is generated with PHP and MySQL, the majority of pages served don’t come from the database. The process of compiling a page on-the-fly involves quite a few trips to the database for content, templates, configuration settings and so on, and so can be slow and require a lot of CPU. Unless a new article or comment is published, the site doesn’t actually change between requests and so it makes sense to generate each page once, save it to a file and then just serve all following requests from that file.

We use QuickCache (or rather a plugin based on it) for this. The plugin integrates with our publishing system (Textpattern) to make sure the cache is cleared when something on the site changes. A similar plugin called WP-Cache is available for WordPress, but of course this could be done any number of ways, and with any back-end technology.

The important principal here is to reduce the time it takes to serve a page by compiling the page once and serving that cached result to subsequent visitors. Keep away from your database if you can.

Outsource your feeds

We get around 36,000 requests for our feed each day. That really only works out at about 7,000 subscribers averaging five-and-a-bit requests a day, but it’s still 36,000 requests we could easily do without. Each request uses resources and particularly during December, all those requests can add up. 

The simple solution here was to switch our feed over to using FeedBurner. We publish the address of the FeedBurner version of our feed here, so those 36,000 requests a day hit FeedBurner’s servers rather than ours. In addition, we get pretty graphs showing how the subscriber-base is building.



Off-load big files

Larger files like images or downloads pose a problem not in bandwidth, but in the time it takes them to transfer. A typical page request is very quick, a few seconds at the most, resulting in the connection being freed up promptly. Anything that keeps a connection open for a long time is going to start killing performance very quickly.

This year, we started serving most of the images for articles from a subdomain – media.24ways.org. Rather than pointing to our own server, this subdomain points to an Amazon S3 account where the files are held. It’s easy to pigeon-hole S3 as merely an online backup solution, and whilst not a fully fledged CDN, S3 works very nicely for serving larger media files. The roughly 20GB of files served this month have cost around $5 in Amazon S3 charges. That’s so affordable it may not be worth even taking the files back off S3 once December has passed.

I found this article on Scalable Media Hosting with Amazon S3 to be really useful in getting started. I upload the files via a Firefox plugin (mentioned in the article) and then edit the ACL to allow public access to the files. The way S3 enables you to point DNS directly at it means that you’re not tied to always using the service, and that it can be transparent to your users.

If your site uses photographs, consider uploading them to a service like Flickr and serving them directly from there. Many photo sharing sites are happy for you to link to images in this way, but do check the acceptable use policies in case you need to provide a credit or link back.

Off-load small files

You’ll have noticed the pattern by now – get rid of as much traffic as possible. When an article has a lot of comments and each of those comments has an avatar along with it, a great many requests are needed to fetch each of those images. In 2006 we started using Gravatar for avatars, but their servers were slow and were holding up page loads. To get around this we started caching the images on our server, but along with that came the burden of furnishing all the image requests.

Earlier this year Gravatar changed hands and is now run by the same team behind WordPress.com. Those guys clearly know what they’re doing when it comes to high performance, so this year we went back to serving avatars directly from them.

If your site uses avatars, it really makes sense to use a service like Gravatar where your users probably already have an account, and where the image requests are going to be dealt with for you. 

Know what you’re paying for

The server account we use for 24 ways was opened in November 2005. When we first hit the front page of Digg in December of that year, we upgraded the server with a bit more memory, but other than that we were still running on that 2005 spec for two years. Of course, the world of technology has moved on in those years, prices have dropped and specs have improved. For the same amount we were paying for that 2005 spec server, we could have an account with twice the CPU, memory and disk space.

So in November of this year I took out a new account and transferred the site from the old server to the new. In that single step we were prepared for dealing with twice the amount of traffic, and because of a special offer at the time I didn’t even have to pay the setup cost on the new server. So it really pays to know what you’re paying for and keep an eye out of ways you can make improvements without needing to spend more money.

Further steps

There’s nearly always more that can be done. For example, there are some media files (particularly for older articles) that are not on S3. We also serve our CSS directly and it’s not minified or compressed. But by tackling the big problems first we’ve managed to reduce load on the server and at the same time make sure that the load being placed on the server can be dealt with in the most frugal way.

Over the last 24 days we’ve served up articles to more than 350,000 visitors without breaking a sweat. On a busy day, that’s been nearly 20,000 visitors in just 24 hours. While in the grand scheme of things that’s not a huge amount of traffic, it can be a lot if you’re not prepared for it. However, with a little planning for the peaks you can help ensure that when the traffic arrives you’re ready to capitalise on it.

Of course, people only visit 24 ways for the wealth of knowledge and experience that’s tied up in the articles here. Therefore I’d like to take the opportunity to thank all our authors this year who have given their time as a gift to the community, and to wish you all a very happy Christmas.",2007,Drew McLellan,drewmclellan,2007-12-24T00:00:00+00:00,https://24ways.org/2007/performance-on-a-shoe-string/,ux