Design Tips for Building Tag Clouds
by Jim Bumgardner, author of Building Tag Clouds in Perl and PHP06/08/2006
Editor's note: In "Building Tag Clouds in Perl and PHP," author Jim Bumgardner says that to some, tag clouds would seem to be a fad. But as he demonstrates in this new, downloadable PDF from O'Reilly, the skills you learn in constructing your own tag clouds will also enable you to create other kinds of innovative, Web-2.0-style interfaces. To give you a sampling of what you'll find in the PDF, we've excerpted this section on tips for designing the most effective tag clouds.
Tag clouds can be used effectively, and provide real value to a web site, or they can be tacked on as an afterthought, simply because they look cool, or to make the site appear similar to other, better web sites that offer them. Ultimately, you need to keep in mind their dual function, both as a graph of current activity, and as a navigation aid. Here are some design and implementation tips:
Choose the Right Language
I like to write code in lots of different languages, and I believe in choosing the right language for a particular job (rather than using any one language for all jobs). I think higher-level scripting languages like Perl, PHP, Python, and Ruby are all good choices for making tag clouds. They tend to be supported on servers and they have associative lists (which make counting tags much easier). Lower-level languages that don't support associative arrays (such as C++ or Java) are not as good for implementing tag clouds, because you will end up writing considerably more code.
Make Your Tag Clouds Visible to Search Engines
You can make tag clouds fairly easily in Flash/ActionScript and JavaScript, and you can make them look much snazzier-flashier, even. However, I don't think these client-side languages are as good a choice as the server-based scripting languages. Why? Because you want search engines to see your tag clouds. Both of these technologies would effectively blind most search engines to the content of your tag clouds. If you do pursue a Flash or JavaScript solution for the interface, consider including the actual tags in a comment block in the HTML.
Frequency Sorting
You can, if you like, sort tag clouds by word frequency (Figure 19). Personally, I don't think it's a good idea. Not only does it reduce the "cloudy" nature of the word list, but it also denies your users an additional organizational axis. Most tag clouds use either random or alphabetic sorts. I prefer the alphabetic sort because it provides a quick way to eliminate or identify a particular tag.
Avoid Random Mappings
In Jim Flanagan's Zeitgeist plugin, the words are colored randomly, and the colors have no significance. While some people like this, I believe that if you desire clarity in the interface, you should try to make each mapping meaningful, and eliminate random information that adds no value. For example, you could associate color with time, or omit the color mapping entirely.
Make Tag Clouds Relevant to Your Users
Tag clouds are best when they are relevant to the user's particular interests. For example, a tag cloud that shows popular tags of the last few days is likely to be more interesting (to the breathing) than a tag cloud that shows popular tags "of all time." Also, if you filter for recent activity, the content of your tag clouds will change every day, rather than remaining static.
Tag clouds can also be used to accompany and annotate search results. When a user searches for a particular tag, you can display a cloud showing related tags. This result will be much more interesting to the user than a tag cloud showing only the most popular tags on the server.
Try Different Mappings
Tag clouds are only one, specific kind of weighted list. There are many kinds of mappings from visual features to underlying data that have not yet been exploited. How about trying some weighted lists that don't look like common tag clouds? For example, you could map font size to time, showing more recent tags in large sizes. Or, in a historical database, you could map font to decade or century, using progressively older- fashioned fonts for older data.
Jim Bumgardner started using computers while studying analog electronic music at CalArts in the early 80s. In the mid-90s, while making interactive multimedia CD-ROMs for Time Warner, Jim created The Palace, a pioneering avatar chat system. Today, Jim makes interactive TV software in Los Angeles and is an instructor at Art Center in Pasadena.
Return to ONLamp.com.
Showing messages 1 through 8 of 8.
-
interesting article
2010-02-14 13:30:43 devadvocate [View]
-
tags
2009-09-14 16:39:50 bearwoodbrown [View]
thanks abit confusing but useful
-
Correction
2006-06-13 23:22:31 dkrukovsky [View]
Jim,
Good article. It would be even better if you would know that both Java and C++ do support what you call associative arrays: http://en.wikipedia.org/wiki/Associative_array#Java
Denis Krukovsky
http://talkinghub.com/ -
Correction
2006-06-15 04:39:25 KristoferHoch [View]
Denis,
I believe the type of Associative array that Jim is speaking of, is a be more free than the Java generic.
Take the example you provided for instance. Thephonebookis a
Map Object that can only accept two arguments. Both arguments MUST be of the
Stringtype.
Map<String, String> phoneBook = new HashMap<String, String>();
phoneBook.put("Sally Smart", "555-9999");
phoneBook.put("John Doe", "555-1212");
phoneBook.put("J. Random Hacker", "555-1337");
In Perl, you can do all sorts of crazy things, for instance ...
use strict;
my %phonebook =
(
'Sally Smart' =>
{
name =>
{
'last' => 'Smart',
'first' => 'Sally',
'middle initial' => '',
'salutation' => [ qw(Ms. Lady) ],
'titles' => [ qw(PhD. Esquire M.D.) ],
}
'number' => '555-9999',
},
);
In this instance, I have associated Sally's full name to another associative array (really an anonymous associative array) which contains her full name and some more information.
If you wanted to do the same thing in Java you would, as Jim said, you will end up writing considerably more code.
-
Correction
2006-06-30 02:00:51 stephan.schmidt [View]
Yes you can't do that in Java, but on the other hand, most Java developers use object oriented development and have seldom the need to use structs anymore.
Syntactic sugar is nice to have for maps (see Groovy for an example of map sugar in the JVM) but usually in my applications maps are rather filled dynamically than statically.
-
Hashes
2006-06-15 08:15:43 Jim Bumgardner |
[View]
Yes, "considerably more code" was the point.
Certainly associative arrays are supported by C++ and Java, via libraries, but they are not built-in data types, as they are in Perl, PHP, Python and Ruby.
The code to construct and manipulate them is more ungainly in the lower-level languages. -
Correction
2006-06-15 04:17:53 KristoferHoch [View]
Dkrukovsky,
I believe the type of Associative array that Jim is speaking of, is a be more free than the Java generic.
Take the example you provided for instance. That Map can only take a String and Another String.
[snippet]
Map<String, String> phoneBook = new HashMap<String, String>();
phoneBook.put("J. Random Hacker", "555-1337");
[/snippet]
It cannot nest in more Maps because the phone book only accepts String objects. In Perl, you can do some crazy things like ...
[snippet]
%phonebook =
(
'name' =>
{'J. Random Hacker',
);
-
Correction
2006-06-15 04:40:46 KristoferHoch [View]
This was an unfinished post, sorry about that :-(











Dynamic versus static languages is a real holy war. I use both. I have to say though that from my experience, statically typed languages suffer from less run time errors because you catch things at compile time, and are infinitely easier to refactor, especially when dealing with massive codebases.
My $.02.