AdSense Videos Not Necessarily Good

In my last post, I "introduced" AdSense's new Video Units. I also railed against the size requirements a little bit in that post.

Now. Taking a step back, let me ask a question. What is the purpose of ads (AdSense ads in particular)? For most legitimate cases, the purpose is to enhance a page's content with topic-relevant alternative links, with the main incentive of earning a few cents per click. Note the word enhance, meaning "to add value to". You put ads on your site in the hopes that the links provided will provide enough potential quality that the user will click through. Now, another question: what do videos, the marketing tool of the Information Age, do by their very nature? They grab your attention, and they grab it hard! Have you ever found one specific video on YouTube, watched it, and immediately been pulled in to the "related videos" journey? Mm-hm. Guilty as charged :) . The "traditional" (if I may use the word here) ad system is to place a text block (which is easily skimmable, by the way!) within our content, where it sits quietly by in the hopes that some user may grace it with a mouse click. This new version? GRAB the user's attention away from the main content, and perhaps they might click the overlay ads in the process. These video ads, as big as they are, will steal the limelight from your content, if not placed appropriately. Really, I don't think the current sizes have an "appropriate" placement. You can either place them intrusively up front where they steal from your content, or you can place them out-of-the-way (long after your content) where they'll hardly be noticed.

Now, you'd think that's great, right? Grab their attention straight to the ad unit itself, no trouble? Well, it might be, if the overlay ads themselves were noticeable. I just added the mini player to my blog and played the first video on it, and the overlay ad was so annoying and detracting from my video experience so badly that I quickly hid it. That's right, there's a "close overlay ad" button. It reduces the entire money-making mechanism to a little "show ad" button in the bottom-right corner of the player. Now, how many people do you think, after having hidden the ad that was so darned annoying, will re-open that same ad to see if they want to click it? Certainly not me. I have more content to look through, and better things to do with my time.

Come to think of it, I might not even press the play button.

Circular Menus and Usability

Circular menus. Ever heard of them? I'm not sure if they have an "official" or "common" name, but this name is pretty descriptive.

Circular menus are superior in usability to the typical rectangular slide-out menu. Why? Because, ideally, each menu item is the same distance from the initial pointer position as each other item. Look at the iPod buttons, for example. Play/Pause, the most common function, is in the middle, and the other functions are equal distances from there.

Also check out the SecondLife context "spin menu". The pie pops up surrounding the cursor, and all the available options are an equal twitch away from the center.

Submenus? Just expand the circle. For example, here's a quick mockup I made converting much of my current FireFox context menu into a pie menu:

But how feasible would such menus be inside a website? WebToolkit.info has a mostly-working demo that uses images exclusively. I tried substituting text for the images, but the menu simply disappeared.

Credit for image: iPod image and SecondLife image

Do we really need the br element?

Do we really need the lowly <br/> element? Apparently the W3C thinks so, with HTML5 containing the element. I mean, seriously, what does it do that a span styled with display:block; can't?

The last two times I've seen it used were in articles about creating a tableless photo gallery and making a CSS block nav menu. In both instances, the br was used to drop down the descriptive text to the next line. In both instances, a span surrounding the descriptive text, and with its display set to block, does the exact same thing.

I suppose an argument could be made about users with CSS turned off. In my opinion, though, if you have CSS turned off, you're willing to deal with a few minor inconveniences. If you're that worried about them, throw in a space before the span for readability. And if you really insist on giving them the extra lines of text -- there's always the naturally-block-level <div>.

And what about screenreaders? I doubt they'd be affected either way (it is whitespace, after all -- right?), but I really have no clue. Perhaps someone who uses a screenreader could tell me, after chewing me out about my own blog's (actually Blogger's) screenreader-friendliness. :o

Web 3.0: Are We There Yet?

Quick disclaimer: this article is simply something that I wrote up on a whim, meant to provoke thought. By no means do I claim to be an expert on the history of the web, the intricacies of "Web 2.0" et al, or anything else. This is, simply put, a brainstorm.

Since its inception, the web has been evolving.

In the beginning, there were marked-up files, with the sole purpose of spreading information. Files linked to each other using hyperlinks. Pages were made up of static HTML -- with a strong emphasis on "static". Websites were merely a collection of rarely-changing information. Rarely-changing because...well...because, put simply, they were static.

Enter Server-Side Scripting. Wonder of wonders! Intelligent pages, able to adapt, to learn, to store and retrieve information! Pages could be made easier to update, easier to maintain, and easier to modify. Website owners and visitors alike could create accounts, and later log back in to those accounts to retrieve information they had saved on previous visits.

The world of static pages, difficult maintenance, and ad-hoc special effects has been dubbed the "Web 1.0 era". The focus of the web was information, and information was served.

As dynamic server-side languages gained popularity, people created websites that slowly evolved into communities. Web 2.0, we called it. The focus shifted to the people, and the people were served.

And now where are we? "Well, nothing revolutionary has come along, so we must still be in Web 2.0". I would disagree. In a recent article on IndustryInteractive.net entitled "Facebook has failed us", the author states:

1. Facebook is great at connecting people. [...] I was able to find people I went to elementary school with, identify them, and connect.
2. Facebook sucks at playing well with others. There are Facebook Apps to integrate things like Flickr and del.icio.us, but they really blow, and why isn’t Facebook building that functionality right in anyways? [...]

While I won't say how great or how horrible Facebook is, it seems the focus of the web is shifting -- or already has shifted -- away from people, and more towards services. With "web applications" like Google Docs, Flickr, Netvouz, GMail, and Google Reader, web-based computing may not be that far off. Already, most of the functions we perform on our computers can already be done through our favorite web browsers -- even BitTorrent downloading!

People don't expect information or community anymore -- those are a given for any good website. What people expect in this new day and age is integration of services. Can I inject my Del.icio.us bookmarks into my blog feed? Can Google Docs post this document to my Blogger blog? Can I integrate my Flickr pics into my Facebook profile?

With the shift of focus to services, it's possible we may already be in a kind of Web 3.0. Or perhaps not -- perhaps we are only in Web 2.5, the middle grounds between people-focus and service-focus. After all, there was a Web 1.5: the middle grounds between information-focus and people-focus, when those good ol' dynamic web languages were still picking up support.

Web App ideas: QuickMail

I was thinking the other day, I want to build a web app. Yeah. Right after I finish Physics homework, build an AI program, and take finals. Good grief.

What the heck, I can still come up with ideas, right? Google didn't turn up much inspiration, so I started thinking on my own. Here's what I came up with.

QuickMail, a lightweight mail app, designed for those who don't have time to deal with bulky webmail interfaces (am I right, AOL users??). It should support as many mainstream mail services as possible. It should have a clean, simple interface, with little or no bells or whistles. It should be built for speed (both runtime and download time).

Upon entering the site, the user is presented with a login panel, which contains a dropdown with available services, username and password fields, and out-of-the-way links to an about page and other pages that might be accessed before "logging in" (perhaps a "donate" page to pay for hosting, maintenance, etc). Ideally, this panel will be presented as a blackbox-style overlay, to prevent the need to wait for an extra page refresh after logging in.

Once "logged in", mail will be fetched from the user's account (probably through AJAX) and displayed (unread mail only? both read/unread? will there be options?). No registration is required for QuickMail, only the login credentials for the specific service are needed. The user should be able to choose whether or not the app autochecks for new mail (for slower computers, to avoid the constant background JS that would be required), and there should be a button for checking for new mail, regardless of whether autocheck is on or off.

Credentials should be kept only on a per-session basis; the user should be able to simply exit their browser without fear of being "hacked". Most likely, this will involve avoiding cookies, probably keeping the credentials as JS variables.

A mail search function would be nice, though it would be an extra feature, to be implemented after the core functionality is stable.

With this kind of setup, you could type "qm.com" or similar in your url, choose your service, enter your credentials, and read your email, all in the 15min between classes :D ok, maybe not that snappy, but close enough. Once you're done, just exit the browser (or tab) and don't worry about logging out (since you were never really "logged in" to begin with).

So, what do you think? Would you use this? Is it feasible? Anything I missed?

If you think you can implement it, fine, but I'd love to be in on it. If not, feel free to leave suggestions in the comments :)