I don’t like personal blogs.

No offense to people that do have blogs chronicling their lives, but I do not have the time or motivation to read personal blogs, even personal blogs that are written by my friends.

I probably wouldn’t even be able to maintain interest in reading the personal blog of a person that has a life more interesting than a James Bond movie. (Of course, I mean–such an autobiography would probably do better as a book or movie. Especially a movie.)

These above statements are assuming that FriendFeed, Twitter, and Facebook are not personal blogs for the users that use them. But assuming that those three social networks are personal blogging platforms, then my tune has to change–especially because of FriendFeed.

For the rest of this post, I will focus on the advancements that FriendFeed has brought to the personal blog; advancements that enable me to tolerate personal blogs.

1) Posts that are shorter, but not too short

Click on the above image to see it at full-size.

FriendFeed posts, by far, are shorter than long essays about one’s life. FriendFeed comments do have the capacity for quite long posts, but people generally keep FriendFeed messages short.

On the flip side, FriendFeed does not demand that an individual’s posts be insanely short–like Twitter posts. The advantage a decent message length is that one does not have to resort to hard-to-read shorthand  (“goin 2 library”–a very simple example) to get a message to fit in a brutally short character limit.

2) Hiding functionality

The problem with personal blogs is that if I read your blog, you decide what I see. This means that I either scroll through content that I may not like, or just not read the blog at all.

FriendFeed has a little “Hide” link next to entries. I can even use the “Hide” functionality to wipe out vast swaths of content.

To summarize, not only can I avoid seeing one of an individual’s tweets again–I can avoid seeing all of them again!

3) Lists

Let’s say that I want to keep track of all of my friends that live in a certain region, belong to a certain organization, or otherwise can somehow be categorized into one larger entity. FriendFeed’s lists allow me to mix all of their feeds into one page–while keeping their feeds separate from others.

Not only that, I can use the “Best of the day” feature in FriendFeed lists to make sure that I do not miss the FriendFeed posts that have attracted the most attention from other users.

4) Different user interfaces through the API

FriendFeed’s API means that developers can create their own custom user interfaces for the website. For example, I have previously covered on this blog the NoiseRiver interface for FriendFeed.

In addition, there is Benjamin Golub’s fftogo application–bringing FriendFeed to mobile phone browsers. Golub’s creation does not use Javascript at all, because many mobile phone browsers support it poorly. Phones w web browsers, such as the iPhone and Android browsers, can use the non-API-powered user interface at http://friendfeed.com/iphone.

RSS also enables such user interfaces, but the same RSS feed reader doesn’t usually provide all these interfaces and the opportunity to create more*. In addition, the different user interfaces sync instantly–simply given that all the user interfaces (third-party or not) rely on the same database at FriendFeed. I can add a subscription in the main interface, and expect to see that subscription’s post in fftogo.

*Google Reader comes close, though.

5) Saved Searches

Click on the above image to view it full-size.

The “hiding” functionality is good and all–but it isn’t very precise. I can hide a friend’s Twitter posts, but I can’t hide his Twitter posts that contain certain keywords–such as “iphone.”

FriendFeed saved searches is designed to fix that. One can use the advanced search interface–or type in search operators him or herself–to create complex views that exclude and include certain things.

---

So what happens when you take the above five reasons and add them together? You end up wtih a very powerful RSS reader that actually transforms personal blogging.

How powerful?

Well, powerful enough to convince a busy Unix geek like me to maintain a personal blog.

Update: Note that the thoughts I describe in this post ONLY apply to my blog posts. Three other authors have contributed to this blog.

Today is the one-year anniversary of my first post on this blog. Please do not read my first post, or any of the 136 other posts (not including this one), because you will be sorely disappointed.

A long time ago, I wanted to create a website where I could talk about some interesting tech-related ideas and see if anybody liked those ideas. Eventually, I registered a domain name for this blog and attached it to my web hosting account at Bluehost.

Was I successful?

Yes and no.

I’m a bit of a pessimist, so first I’m going to explain why I think I failed. My goal was to write many high quality blog posts centering around programming. The posts would include actual code examples. I’ve deviated far from my goal. With the difficulties I had with displaying code examples, I talked about other topics, such as blogging. (Although my posts on blogging and social media did get A-List blogger Louis Gray’s attention.)

I also took way too much time to develop certain consistencies, such as the capitalization in the title (Prepositions are not capitalized).

But, I did succeed beyond my wildest dreams.

Although I started the blog in December 2007, I only started tracking statistics in the middle of May 2008. By the end of the (not completely tracked) month, about 134 MB of my bandwidth had been used by non-bot visitors. I thought that this was a good start.

In June, I had used more than a gigabyte of bandwidth. Now, this had really excited me. Because all I post is text and some images, the fact that I had used up a whole gigabyte of bandwidth made me feel giddy.

June made me feel giddy, but July had me shocked. On the first day of July, I had nearly reached the total bandwidth used in the entire month of June. On the second day of July, I had used up eleven more gigabytes of bandwidth. A poorly written blog post of mine hit Digg, Reddit, LinuxToday, TuxMachines, and countless blogs in many languages.

Most of the hundreds of comments (spread across the websites listed above) that my post received were negative. I felt a little disappointed that my most viewed post of all time had to be one that made me look foolish. But then I stopped skimming over the comments and started reading and analyzing them. I discovered that I could learn a lot about the Linux community from the comments, and I decided that in the end, it was good that I had published the post.

In the end, I didn’t accomplish my original goal of having others see my brilliant ideas. Instead, I found the brilliant ideas of everybody else.

The web application in permanent beta is the latest fashion in today’s Internet world. Some folks believe that after several years of testing, that web applications ought to shed the beta tag and call themselves stable.

I disagree.

Open source desktop software is significantly more flexible than a closed source web application in terms of giving what users want. Desktop applications have extensibility through plugins, extensions, themes, and so forth. Web applications currently have only a weak extensibility through Greasemonkey.

Facebook Apps are closer to true extensibility, but Facebook remains in control over Facebook Apps, which results in rumors that Facebook is going to close down third party apps. Developers creating extensions of desktop applications usually do not have to worry about their extensions being wiped off the face of the Earth.

Also regarding Facebook, some users are not happy with Facebook’s transition to a new user interface. There is even a petition for the old user interface to return. I suggest you compare Facebook to WordPress. Nobody is going to force a blogger to upgrade to the latest version of WordPress, but there is little one can do if Facebook decides to switch to a different (and worse, in the mind of the user) UI.

Does my blog post ring a bell? Oh yeah, this blog post sounds roughly similar to Richard Stallman’s opinions on cloud computing. Stallman is dead right. One should only truly trust open source software on hardware within the ownership of the user.

So where does the whole “keep Web 2.0 apps in permanent beta” idea come into play? My point is that Web 2.0 apps ought to keep themselves in permanent beta as a reminder to users that no Web 2.0 app outside of the user’s control is as safe as an application within the user’s control.

Use Web 2.0 apps responsibly™.

Introduction

Adobe Flash, while it appears to be buggier on Linux, is a neat thing. I can watch animations and play games right through my web browser. Now, I would prefer that Adobe Flash not be put to the use of making entire websites, or even major parts of websites, such as a navigation menu.

Flash usability hasn’t had major improvements in eight years, as evident by Jakob Nielsen’s similar article on Flash and usability.

Why too much Flash is bad

1) The user interface is nonstandard.

Flash websites have a tendency to make their own (shinier) scroll bars to help me navigate large amounts of text.

A web designer creating his or her own scrollbar, and then refusing to let me use the browser’s scrollbar is like the web designer poking holes in my car’s tires and replacing the tires with cardboard boxes. Well, perhaps I’m being a bit dramatic with the metaphor.

Interaction with the user interface also totally gives the user unexpected surprises. Most Flash websites do not allow me to right-click*, middle-click, or use my web browser’s scroll bar.

*Whenever I say, “no right-click”, I mean that the user cannot access a context menu from right-clicking.

2) Flash websites often take longer to load.

Oftentimes, I want good ol’ fashioned text coming down the pipeline to my screen. I do not want:

• text animations.
• animations of somewhat related images.
• sound.
• a screen that tells me that the above three are loading.

3) Ctrl+F doesn’t work on Flash websites.

I cannot use text manipulation tools to edit or search the webpage. I cannot type Ctrl+F and then search the text of the page. Greasemonkey would not work well in all-Flash websites. Neither would bookmarklets or Firefox extensions that allow me to manipulate the page.

4) OS-specific Flash Player bugs

I recently visited a website that had a bug with an embedded Flash slideshow. The bug was only visible when using the Linux Flash Player. On Windows, even on Firefox, the Flash slideshow worked perfectly.

The bug was that the Javascript drop down navigation was being hidden under the Flash slideshow on Linux, which made most of the menu inaccessible.

Designers shouldn’t have to test on multiple operating systems, because the vast majority of designers probably do not have the time or resources to do so.

5) Redundancy

Plenty of website designers will provide a plain HTML version of the content on the website for users that do not have Adobe Flash. I just don’t understand why there needs two versions of a webpage, with one being flashier than the other.

The main usability issue here is that any text or link pointing to the HTML version is often in very small text and sometimes only visible to users that do not use Flash. Users that do have Flash and want to use the text version might have a hard time finding the text version.

6) Redundancy

Sorry, I couldn’t resist.

Conclusion

I would rather visit an ugly webpage full of HTML hacks that were inserted by a poorly coded WYSIWYG editor than an impressive looking (but completely unusable) Flash website.

Why?

Because in an HTML website, the defaults are more usable because defaults in HTML pages are what most users are used to. In an HTML page, developers would have to go out of their way to create some of the annoyances that are common on Flash websites.

The vast majority of people that create HTML pages don’t have an impulse to disable right-clicking in the browser, or to make their own scrollbar when the browser has a scrollbar that works just fine.

So, please. I beg you to start an HTML page with a DOCTYPE tag, end it with </html>, and make sure that the only uses of Flash in between are not for displaying text and images.

You know why I haven’t posted in a while? No, it is not because I’m really busy, but because the CodingExperiments team has been churning draft after draft and ping-ponging back and forth between them to make updates. The result is a massive amount of half-baked blog posts. Working on posts one at a time and not starting another post until you have finished or given up on an existing post is a good way to prevent a barrage of blog post drafts from raining down on you.

While plenty of people say that producing good content is more important than posting regularly, plenty of new bloggers, including me, feel guilty when they do not post regularly.

Now, there have to be exceptions to this rule. Bloggers that write mostly time-sensitive material, then following this rule could possibly hurt them by delaying the publishing of the posts. Taking a look at this blog’s archives will show that whenever I try to cover something time-sensitive, I always end up covering it a few days later.

Also, if you would like more extremely obvious (or extremely brilliant, depending on your perspective) tips on blogging, you might like reading some of this blog’s other posts covering bloggi–oh don’t bother, I know nothing on blogging.

Sorry I was unable to post for a while. I wasn’t busy, but wrote a bunch of drafts and decided I wouldn’t publish them.

I shouted to the Internet that I am unhappy with existing RSS readers. Now, let’s use our prediction skills to see what will happen next.

Hmm… Programmers like to solve problems. I appear to have a problem with RSS readers. The title also gives a hint that I’m making plans for an RSS reader. Considering all that evidence, it is pretty likely that I’m going to make an RSS reader, right?

Yup. You guessed correctly. I’m going to build an RSS reader.

Because I want to access my RSS reader from anywhere, I will be creating a web RSS reader.

Below is the list of features that I have planned for the RSS reader.

• Tagging of feeds as well as individual posts.
• A recommendation engine for posts.
• Integration with:
  • Google Reader
  • FriendFeed
  • Delicious
  • and possibly more
• The ability to experiment with possibly dozens of user interfaces.

Wait, “experiment with possibly dozens of user interfaces”? Now why would I want to do that? The main reason that I want to experiment with a large amount of user interfaces is because no user interface for an RSS reader (both desktop and web-based) have ever satisfied my need for large amounts of data to come down the pipeline and be displayed in a good looking manner.

I am also interested in getting feedback from users to see which user interface is the most easy to use.

Now all I have to decide is what language to write it in. I’m thinking of either writing it in PHP or Python. I’m leaning towards PHP, as I haven’t actually done any real web programming in Python. I might try Ruby on Rails, as I know a small amount of Ruby.

Because of my limited resources, my RSS reader would be restricted to private alpha, though making the RSS reader open source would allow other folks to try it out on their own servers.

Any comments and suggestions on my RSS reader? Comment below.

Note from possible248 (main author of CodingExperiments): freezewarp is a new author here. You won’t find much info on him by Googling his nick because he recently abandoned his old one. If you want to guest post on this website too, send me an email at possible248@gmail.com.

Intro

One advantage Firefox has in the web browser world is the large community of developers all contributing to Firefox by building extensions for it. Most of these developers post their extensions on Firefox’s official extension homepage. Here you will nearly 5,300 extensions, referred to as addons, though this is an unfair count. On the whole 600 are themes, 3,000 have no support for Firefox 3, and 600 do not work with linux. Though this means that some users will not be able to utilize all Firefox extensions, they will still be able to the best.

Best Addons

Adblock Plus

My Rating: 5/5

Community Rating: 5/5

Weekly Downloads: 480,000

Best Suited For: Pretty much anybody.

Last Updated: July 17, 2008 (Version .7.5.5)

Works with: 1.5 – 3.0.x (Older versions having support for Firefox versions as early as .7)

Summary: Adblock does one thing, and it does it better than anyone else, it blocks adds. Be it pop-ups, google adds, or the annoying flashy adds, it blocks them all.

Snapshots:

Video Download Helper

My Rating: 5/5

Community Rating: 5/5

Weekly Downloads: 390,000

Best Suited For: People who want their favorite content to go right with them.

Last Updated: July 22, 2008 (Version 3.2)

Works with: 1.5 – 3.0.x

Summary: Download Helper gives you the power to download embedded videos from almost any site. In more recent versions you even have to power of instant video conversion through FFMPEG or MEncoder. Using it on older versions of Firefox with little memory, however, can else be troublesome.

DownThemAll

My Rating: 5/5

Community Rating: 5/5

Weekly Downloads: 280,000

Best Suited For: People with a slow internet connection and those who download excessively.

Last Updated: June 07, 2008 (Version 1.0.3)

Works with: 2.0.8 – 3.0.x (Older versions having support for Firefox versions as early as 1.0)

Summary: DownloadThemAll is simply a download manager. It integrates directly into Firefox, allowing faster downloads in the default download manager in addition to many features in the newly existing one, such as page download and integrity checking with MD5Hashes.

Snapshots:

Better Gmail 2

My Rating: 5/5

Community Rating: 5/5

Weekly Downloads: 95,000

Best Suited for: People who use GMail online.

Last Updated: August 20, 2008 (Version 0.6.1)

Works with: Firefox Versions .8 – 3.0.x

Summary: Better Gmail 2 adds a better look to GMail that will make it sleeker and often easier to use. Functionality wise you won’t see a change.

Snapshots:

WOT

My Rating: 5/5

Community Rating: 5/5

Weekly Downloads: 80,000

Best Suited For: Pretty much anybody.

Last Updated: August 11, 2008 (Version 20080811)

Works with: 1.5 – 3.1a2pre

Summary: WOT is a relatively new extension to me, though so far I’ve founded it to be nothing but exceptionally good. In turn you are the one powering it as it ranks sites based on what users think of them. Anyone can rate a site on four aspects, trustworthiness, vendor reliability, privacy, and child safety. This means that you now can make important transactions and ensure your child is safe on the Internet rather easily. If in the case a site has poor reliability, it will bring up a warning screen questioning if you would like to continue to the site or go back. Here are some examples of sites that have been rated:

Site	Trustworthiness	Vendor Reliability	Privacy	Child Safety
Myspace	4	4	4	3
Yahoo	5	5	5	5
Google	5	5	5	5
Freedownloadscenter.com	2	2	2	2
KDE.org	5	5	5	5
CodingExperiments.com	5	NR	5	5

Snapshots:

Web Developer Toolbar

My Rating: 5/5

Community Rating: 5/5

Weekly Downloads: 70,000

Best Suited for: People who develop the web.

Last Updated: May 19, 2008 (version 1.1.6)

Works with: 1.0 – 3.0.x

Summary: The Web Developer Toolbar adds many great features for all users, though as the title would imply, it is best employed by web developers. You can easily gather information about a web page’s source, structure, style sheets, scripts, and other miscellaneous attributes of a page. Additionally, validation of a web page, from its HTML to its accessibility can be done instantly. If your a regular user you can also easily reap the benefits of showing hidden passwords, disabling images, styles, JavaScript, Java, and pop-up blockers, and magnifying the page.

Snapshots:

FireFTP

My Rating: 5/5

Community Rating: 5/5

Weekly Downloads: 55,000

Best Suited For: People who frequently use FTP.

Last Updated: August 15, 2008 (Version 1.0.2)

Works with: 3.0 – 3.0.x (old versions support Firefox versions as early as 1.5)

Summary: FireFTP integrates a mediocre FTP client directly into Firefox. I find it to be a good choice as its often easier to view the changes your making as you make them. It offers standard FTP access, though with the addition of SSL Encryption, SFTP, filtering, file hashing, and other features. None the less normal desktop FTP clients do tend to have more features, and so may be a better choice for people who want the most out of an FTP client..

Snapshots:

ScrapBook

My Rating: 5/5

Community Rating: 5/5

Weekly Downloads: 20,000

Best Suited For: People who want their favorite content to go right with them.

Last Updated: June 28, 2008 (Version 1.3.3.7)

Works with: 2.0 – 3.0.x (Older versions having support for Firefox versions as early as .9)

Summary: The Scrapbook extension has the general purpose of archiving web pages to your local computer. Though it lacks features it is great as what is does. Simply enter a number of links to spider and the content to store (images, CSS, JavaScript) and it will download every page it finds. Unfortunately large loads can do a computer in that lacks memory in.

Snapshots:

NoScript

My Rating: 4/5

Why I Rate It Lower: It can be very tiresome having to allow scripts for every site you go to.

Community Rating: 5/5

Weekly Downloads: 350,000

Best Suited For: People who prefer to be security conscious, such as those working for large companies.

Last Updated: July 15, 2008 (Version 1.7.7)

Works with: 1.5.0.4 – 3.1a1 (Older versions having support for Firefox versions as early as 0.7)

Summary: Noscript also ensures security like with WOT, however rather than simply warning you, it stops scripts, such as JavaScript, Flash, and Java cold, while still allowing you to view all the content of a page. Naturally this does come at a price, though. Since all it does is prevent scripts, harmless scripts are blocked just the same. Even worse you have to allow scripts for every site one by one. This means that on many sites you will have to click allow multiple times, once for the local site and the rest for embedded content. For many people who have constant problem or malware this is a small price to pay, but if you’ve never had to deal with malware then you probably don’t have much need for it.

All-in-One Sidebar

My Rating: 4/5

Why I Rate It Lower: AiOS often closes or opens unexpectedly, making it harder to use.

Community Rating: 5/5

Weekly Downloads: 130,000

Best Suited for: People who are often unorganized or those who find FireFox confusing.

Last Updated: June 24, 2008 (Version 0.7.6)

Works with: 2.0 – 3.0.x (Older versions having support for Firefox versions as early as 1.0)

Summary: All-in-One Sidebar is nothing greater than a sidebar that acts as a control panel for all of Firefox. By combining downloads, history, bookmarks, page info, add-ons, and more all in one place it makes Firefox much simpler, easier, and quicker to use.

Snapshots:

A few other good addons you may like if…

You are big on Internet Relay Chats: ChatZilla

You are big on Podcasts: FoxyTunes

You like to be in tuned to the weather: ForcastFox

You never type the URL right: URL Fixer

Recently I’ve been playing with Midori in the wake of being informed that it’s now an Xfce project.  A nice enough browser, albeit quite solidly still in the development stage.  However, on systems such as mine that lack GLib 2.16 (and therefore GIO), there is a compilation error.  Specifically, there are two problematic zones.  The first is a confusion in the macros that check for GLib 2.16 and GtkSourceView that result in a failed compile if you have an older version of GLib in combination with GtkSourceView. Secondly, Midori will attempt to use GLib 2.16 symbols without first checking if the user has GLib 2.16.

So I wrote a patch and submitted a bug report.  The bugs are now fixed in git master, but for the existing stable release (0.19), you can find my patch at the relevant bug report.  To apply it, move it into the Midori 0.19 directory and then run

cat midori-glib216.patch | patch -p1

UPDATE: If you saw the screenshots messed up in this post, it is now fixed.

1. Table of Contents

• 2. Introduction
• 3. Mobile screen resolutions
  • 3.1. Creating and designing mobile web pages
  • 3.2. Redirection to mobile webpages
    • 3.2.1. User agent detection
    • 3.2.2. Screen resolution detection
• 4. Desktop screen resolutions
  • 4.1. Creating more webpages for different screen resolutions
  • 4.2. Using fluid width designs
  • 4.3. Using limited fluid width designs
  • 4.4. Using narrow fixed width designs
  • 4.5. Intelligently using horizontal scrolling
  • 4.6. Having small desktop screens view the mobile pages
• 5. Conclusion

2. Introduction

Handling screen resolutions is a difficulty for web designers simply because there are so many screen resolutions. There are small screens on mobile devices and freakishly large and expensive screens now finding their way into the desktop market.

This post will give some guidelines which may make it easier for a web designer to deal with the vast differences in screen resolutions.

3. Mobile screen resolutions

It’s common to browse the Internet on a cell phone, especially now that the Apple iPhone (and other devices) make(s) it so easy. Many normal websites work fine or almost fine on iPhones, but for some mobile devices with different web browsers, web browsing can be a difficult task.

How can one web page be designed in such a way that it elegantly displays the content on mobile and large screens? It is possible for mobile and large screens to view the same webpage, but it is rather difficult for the content to be displayed elegantly.

3.1. Creating and designing mobile web pages

To solve this problem, a separate version of the webpage with the design tailored specifically for small screens can be created. Usually, the same content is displayed, unless the content is something that is currently problematic to display on mobile devices.

I believe that mobile web pages work best if they are fluid width, and do not strictly specify a font size. Towards the end of this post, you will see why I recommend this.

You might want to check out the W3C’s draft Mobile Web Application Best Practices“.

3.2. Redirection to mobile webpages

A problem with creating another webpage, or having server side scripting (such as PHP or Python) generate the mobile web page on the go, is that the user has to be aware of the mobile web page.

Redirection can help reduce the awareness problem. User agent and screen resolution detection can be used to redirect the users to the proper page for the user’s screen resolution.

3.2.1. User agent detection

This can be done either with client side scripting (Javascript) or server side scripting. The user agent of a mobile web browser is detected and is either redirected, or the same page is filled with different content.

3.2.2. Screen resolution detection

With screen resolution detection, only client side scripting can be used because the screen resolution is not passed to the server. Either the mobile users can be redirected, or the users with desktop screen resolutions.

I find it less reliable to rely on a mobile web browser’s Javascript capabilities, so I think it would be smarter to redirect the users with larger screen resolutions.

4. Desktop screen resolutions

Assuming that the mobile screen resolution problem has been solved, there still are a good variety of screen resolutions on the desktop market. The problem is that larger screens are being created and bought while some people can’t or don’t upgrade.

This results in screen resolutions from 800×600 (though 640×480 might still be seen) up to… Oh, I can’t give a top number. Somebody will point me to a place where larger screens are available.

Below are the various solutions for handling the differences in desktop screen resolutions.

4.1. Creating more webpages for different screen resolutions

Basically, use the techniques for mobile screen resolutions and use them again for desktop screen resolutions. This is not a very good solution, and is only used in the mobile situation because of the extremely small mobile screens.

4.2. Using fluid width designs

Because the size of desktop screens are pretty big, compared to mobile screens, a fluid-width layout might work. But if a fluid-width layout is not designed properly, problems can occur.

If the fluid with layout isn’t built with smaller screens in mind, the layout can look scrunched in smaller screens. Conversely, if the fluid with layout isn’t built with larger screens in mind, the layout can look overly spaced out (for the lack of a better term). Long lines of text, which can happen with fluid-width layouts on large screens, are hard to skim through.

Another problem with fluid width designs is that the content may contain fixed width elements, such as images. Should the fluid width container shrink to a size that is smaller than the fixed width container, the layout can get severely messed up.

4.3. Using limited fluid width designs

Cascading style sheets are quite powerful, and have the capability to limit the stretching and shrinking of fluid width designs.

The CSS properties min-width: and max-width: can be used to restrict the flexibility of a fluid width layout. But how can these properties be used in order to make webpages look good for large and small webpages?

Well, the use of max-width: can be used to prevent those long lines of text that was described earlier. The property min-width: can be used to force horizontal scrolling in the smaller screen resolutions. While horizontal scrolling is typically not a good thing, there is more below about how to intelligently use horizontal scrolling (not the style of scrolling seen at http://www.thehorizontalway.com/).

4.4. Using narrow fixed width designs

This is the solution that is, at the time of this writing, used by this blog’s template. This blog is neither scrunched up 800×600 nor does it have overly long lines. The major problem that this solution has is that fixed width content can mess up the layout. The fixed width content issue can be observed by looking at posts on this website that contain images that are wider than about 500 pixels will cause horizontal scrolling.

Also, due to the problem with fixed width content, the more columns that a design has, the narrower the fixed width content has to be in order for it to fit with the layout.

4.5. Intelligently using horizontal scrolling

This section is an extension of section 4.4, but modified slightly to allow for three or more columns with a decent width. Basically, use horizontal scrolling. As I said in section 4.3, I am not referring to the horizontal scrolling demonstrated at http://www.thehorizontalway.com/.

In my opinion, horizontal scrolling is a thing that should be avoided, but here I say that minimal horizontal scrolling should be okay for screens with small resolutions.

Basically, create a fixed width design for… perhaps 1024×768.  The goal is to get all of the main content (like the content of a blog post) visible on 800×600. Use somewhere from 700 to 750 pixels for the content. Don’t get too close to 800 pixels, because some space will be taken up by the scrollbar and you also want a portion of a sidebar or something displayed to show the user that horizontal scrolling is needed in case the user does not see the scrollbar at the bottom.

For more reading on horizontal scrolling, check out Jakob Nielsen’s alertbox on scrolling.

4.6. Having small desktop screens view the mobile pages

Section 4.1 talks about creating more pages for different screen resolutions, which is not optimal in most cases. But assuming a mobile page is already created, why not have users with small screen resolutions go to the mobile page?

To some of you, that might sound crazy, but look at my below demonstration.

Below is my FriendFeed page at 800×600 in Firefox 3.0.1.

Click on the above screenshot to view it full size.

The sidebar completely messes up the design. I would not want to use FriendFeed at such a low resolution.

Now, let’s see what Benjamin Golub’s FFToGo (a FriendFeed API app for mobile devices) looks like at 800×600 in Firefox 3.0.1.

Click on the above screenshot to view it full size.

Hey… not too shabby. It’s a clean and simple design that looks a whole lot better than the FriendFeed website.

Assuming that the mobile web page

• does not force a tiny font size,
• does not force a width,
• is not uglier than the main page,

it might be a good alternative for folks at 800×600. Of course, user agent detection will not work because there are very few people out there that are using a desktop browser with a mobile browser’s user agent. Screen resolution detection, or in the case of FFToGo, simple advertising will have to do.

5. Conclusion

None of these designs are for everybody. Designers creating a website for a very small audience might know what sort of hardware users would be using to access the webpage. The larger the audience, the more likely that the screen resolutions visiting the webpage will be more varied.

Psst. If you’re on dialup, you might as well disable images in your browser and then try loading this page. This page is going to take forever if you attempt to load all the images.

Introduction

When people think about search engines and privacy, the might think of incidents such as AOL publishing the searches of more than 650,000 users and the New York Times identifying a woman based on her AOL searches. Google isn’t well-known for privacy either. Privacy International did a study and gave Google a failing grade (PDF). Nowadays, Google seems to be getting itself into privacy troubles all the time with projects such as Google Street View.

What’s that? It’s a bird! No. It’s a plane! No. It’s Cuil! Cuil is a new search engine that was a major subject of discussion this week. Cuil claims to have indexed a whopping 121,617,892,992 webpages.

Cuil’s successes

1) Privacy

Not only does Cuil claim to have a massive index, Cuil also apparently does not keep logs of user search activity.

Cuil protects your privacy. Click on the photo to view the original image. Original image created by Flickr user dogseat. No I will not put an lolcat in every blog post.

2) The user interface

Cuil’s user interface brings something new to the table. Other search engine result pages (SERPs) are somewhat lacking in the type of fresh design that Cuil has.

Click on the above image to view it full-size.

3) Suggesting different keywords

Cuil, while it may or may not give you good results on the first query, will give you some example queries to narrow or expand your searches.

Of course, the feature has some flaws.

Click on the above image to view it full-size.

An interesting Cuil feature is that the links bring up tooltips that have more information about whatever the link is.

Click on the above image to view it full-size.

The tooltips appear to be the from first sentence from the word’s Wikipedia page.

4) Generating hype

Man, it seems like everybody is talking about Cuil. You can see a list of other blog posts and articles at the end of this post.

Cuil’s mistakes

1) Irrelevant images next to search results

Cuil puts what it thinks to be relevant images next to search results. This isn’t very accurate, as the below screenshot shows.

TechCrunch has more on this issue.

This is a huge problem, as other people are very upset when they see irrelevant images when searching for their own names.

Of course, Google News has had similar problems.

I found this above image on this Google Operating System post.

The wisest approach for Cuil would have been to only suggest images when Cuil is really sure that the images are relevant. Google will often display a few image results along with the standard web results if the algorithm believes that the images are very relevant.

2) A bad first day

On the first day that Cuil launched, Cuil went down. Given how important a user’s first impression of a website is, it’s rather unfortunate that it went down. Again, I’m going to link to TechCrunch, where there’s a post on Cuil’s downtime.
3) The name

I’m fine with the name Cuil, but some people have been very vocal about the name. Nobody can come up with a name to please everybody, but perhaps Cuil should have spent more time thinking about whether Cuil was a good name or not.

4) The result count for queries

While Cuil claims to have have the most pages indexed, some queries in Cuil give far fewer results than other leading search engines.

This isn’t absolute proof that Cuil has barely any pages indexed; it could be the algorithm filtering out results that appear in other search engines.

Regardless of what causes the fewer results, users are disappointed.

———-

On a side note, i80and continues displaying his interest in old browsers and tried out Cuil in Phoenix (Firefox) 0.3. The result is below.

Click on the image to view it full-size.

Above, I promised a list of blog posts and articles that have covered Cuil. I obviously cannot list them all, so the below are just the ones that I believe are the highest quality blog posts covering Cuil.

• Time Magazine — Why Cuil Is No Threat to Google
• ReadWriteWeb — Cuil: Good, But Not Great
• GigaOm –  Cuil Finally Gets Going
• Louis Gray — Can Cuil, Built for the Long-Term, Win the “Instant Analysis” Battle?
• Search Engine Land — Cuil Launches — Can This Search Start-Up Really Best Google?
• Bits (a New York Times blog) — No Bull, Cuil Had Problems
• Business Pundit — Cuil vs. Google? Not exactly.
• PC Magazine — The New Cuil Search Engine Sucks
• The Cool Cat Teacher Blog — Cool Cat Teacher’s Take on Cuil’s New Search Engine

Disclaimer: Cuil search result pages seem to change fast. Actual search results may vary. Do not submerge a computer with this blog post in water. Do not submerge any computer in water, unless it is waterproofed.