Meet an AdSense Publisher: Tim Carter

Google AdSense Steps to Success

Google Adsense Pin Without Pin

As you may know, we'll send you a Personal Identification Number (PIN) by standard mail when your account first reaches $10 in earnings. This PIN is used to help verify publisher accounts and addresses for security purposes. We often receive messages from publishers concerned about what to look for in the mail, and when they can expect to receive it. In response, we've created the short video below which we hope will help address these issues. It might not be a Hollywood production but hey...even the greats started small ;)


If you don't receive your first PIN, you can still request up to two more. Please note that aside from verifying your PIN, other holds may apply to your account -- you'll need to remove all holds and generate $100 in earnings before a payment can take place.

Google Ad Sense Earnings/Reports

The report of these link units is not exaggerated

I don't know about you, but I'm a big fan of data. I look at my own reports frequently and use channels to track the performance of individual pages and ad units so I can optimize my AdSense experience.

I'm also a fan of AdSense for content link units. As we've mentioned before, these units pack a big punch while conserving your screen real estate and can be a great addition to a page that's already using one of our many other products. We've also been doing a lot of work lately to improve the targeting of link units.

This is why I'm happy to announce that my two loves are now coming together. As of today, we've enhanced your reports so that you can view the performance of link units separately from your other AdSense for content units. Even better, the link unit-specific reports contain more information about your link units. A lot of publishers have been asking us for more statistics on their link units, such as the per-link CTR and the number of click-throughs to the link units results page.

To view your new, improved reports, visit the Advanced Reports page under your Reports tab and select AdSense for content. You'll notice a new option to customize your reports -- 'Choose Units'. A 'Combined' report will look just like the data you're used to seeing in your AdSense for content reports, while choosing 'Ad Units' or 'Link Units' will help you look at things with more granularity.


Please note that data is only available dating back to May 2007. Right now, we're having a little issue where, if you generate a report with a date range starting any earlier than May 2007, our report won't show any data, even if there is data after May 2007. Rest assured that our engineers are aware of the issue and are working to display all available data even if the date range starts before May 2007.

Remember, you're allowed to put up to three link units on any given page in addition to your three regular ad units. With better reporting and improved performance, now is the perfect time to start using link units if you aren't already.

Western Union Payment Method for AdSense

Western Union Payment Method for AdSense

Google Adsense offering a new payment method for some countries. Publishers who located in Argentina, Chile, China (Mainland), Colombia, Malaysia, Pakistan, Peru, the Philippines, or Romania, may change the payment method to Western Union Quick Cash. Western Union is a new form of payment that lets publisher receive the AdSense payments in cash using the worldwide Western Union money transfer service. According to Google AdSense normal payment schedule, payments for publishers will be available for pickup at the local Western Union agent the day after they are issued.

AdSense payments with Western Union is totally free. With this new payment method, publishers will no longer need to wait for a check to arrive in the postal mail. This new payment method can also cut down on bank fees and long clearing times associated with depositing checks.
However, I wonder why Google didn’t make this payment method for worldwide. If they really care about their publisher, they should make it available worldwide.

To exchange the payment method, publisher should keep these important points in mind:

Western Union Quick Cash is only available in Argentina, Chile, China (Mainland), Colombia, Malaysia, Pakistan, Peru, the Philippines, and Romania as mentioned above.

Unfortunately, Google doesn’t support this payment method for business account. This new payment method is currently only available to individual payee names.

To pick up the payment, publisher will need to bring the government-issued ID that will be used to validate the payee name in adsense with the ID.

The payments must be picked up within 35 days of issuance or they will expire. If this case happened, a payment hold will be placed on AdSense account and the payment will be credited back to publisher’s account.

All payments will be made in US dollars, but they may be picked up in your local currency, depending on local Western Union agent that being used by publishers

So, to begin receiving AdSense payments by Western Union Quick Cash, publishers just follow these instructions. What are you waiting for?

Stop using Ajax!

Introduction

A while back I got into a forum discussion over the accessibility of CAPTCHA systems. That isn't what this article is about (in fact it wasn't what the thread was about either, but I soon changed that!). I only mention it because one comment in particular stood out as symptomatic of an attitude I come across time and time again:

"I am very much in favour of making the web more accessible to everyone, but ..."

As I said in that thread, to be "very much in favour" is a cop-out if you're not prepared to follow that through to its conclusion; it only pays lip-service to the idea of accessibility, without being prepared to do what it actually takes. I stewed on that thought for a few days, and eventually followed it up with a rant on my own site: Technology is the last, best hope for accessibility. In that post I railed against developers who can't be bothered to care:

"Server-side programmers who hide on the server and deny that the client-side matters; client-side programmers so obsessed with the latest cool thing, that they're quite happy to leave groups of people behind in the name of what's cutting-edge and sexy."

See, the web already was accessible to everyone. Tim Berners-Lee’s original vision for the web was all about universal access; and the technologies involved – such as HTTP and HTML – were designed to be platform and device agnostic; it shouldn’t matter what kind of technology you use to access the web.

But commercial interests got in the way, and the desire for branding overtook the need for open, standardised solutions; in effect, we tried to run before we could walk, because the huge commercial uptake of the internet far outstripped its early capabilities. And so we got things like browser wars, browser-specific DHTML, and table-based layouts. These were things that got in the way of the original vision, because people wanted rich content when the technology wasn’t ready. And now it’s happening again.

Of course to the majority of people this is all irrelevant – if it works, and it looks good, where’s the problem? Well the problem unfortunately is that there’s a victim, and the victim is accessibility. What I’m suggesting in this article is that it’s not acceptable to have a victim – especially when it’s a group of people who are already suffering disproportionately - and if what we’re doing creates that, then what we’re doing is wrong. I'll look at the argument in detail, get to a conclusion, and along the way I'll suggest how we can find non-Ajax solutions to a lot of the web functionality that Ajax is commonly used for.

"most" doesn't need to be enough

Ajax is a sound and useful idea. But every idea comes down to a practical implementation - a technology that makes it happen - and in this case the technology is immature, because it leaves groups of users behind. Most notable and greatly affected are those using assistive technologies, but also those using less capable browsers that don't support the necessary scripting objects, or don't support scripting at all.

It might be reasonable to say that JavaScript support is not an accessibility issue, if it's a user choice - if a person switches off JavaScript deliberately then shouldn't they take responsibility for that choice? Well, yes, they should, but that's not the real issue here; the real problem is more complicated, and isn't a user choice.

Screen readers like JAWS, Window-Eyes and Hal are script-capable devices (since they sit on top of a script-capable browser, usually Internet Explorer), yet their ability to handle JavaScript applications is nothing like equivalent. We can't rely on non-script fallbacks, nor on a scripted interface - these devices fall through the net of progressive enhancement.

Now that probably won't come as a surprise. The fact that assistive technologies have problems dealing with asynchronous updates to the DOM is fairly well known by now (for a summary of the state of play, check out Improving accessibility for today's Ajax at Access Matters; I'd also recommend a recent ALA article, Accessible Web 2.0 Applications with WAI-ARIA, which looks at one promising solution to this issue).

You could also say – and quite fairly – that this is the screenreaders’ problem, that the technology is broken and needs to be fixed. Yeah fine, but that really doesn’t help. The simple fact is that there are people using the web right now, using technology that’s increasingly failing to cope, and they don’t have the option of using something better, because there isn’t anything better.

(Let's look at this using an analogy – suppose you could speak English and Spanish, and you’re talking to someone who only speaks English. Do you continue to speak to them in Spanish just because you think it sounds nicer? Do you complain that it’s their fault for failing to understand you?)

So let’s take the situation as read and move on to an interim conclusion: this problem has not been solved, and in my opinion, until such time as it is, Ajax techniques should not be considered suitable for widespread use.

It's really not okay to leave groups of people behind, simply because they no longer fit your model of what a user is. Still, I appreciate that neither is it palatable to delay useful progress and development, if other groups of people can benefit from it.

But I don't believe it's necessary to do either - we can have our cake and eat it too, if we remember this simple observation:

New innovations often inspire us to do things that we don't really need the new technology for, it's simply that the change in approach and easy capability inspires new ideas.

In other words, the emergence of Ajax techniques has inspired a whole new wave of applications, but in many (if not most) cases, these applications don’t actually need Ajax to work - it’s simply that we hadn’t thought of them before. It’s easy to assume that the evolution of ideas follows an unbroken chain of cause and effect, but this isn’t really the case; evolution is as random as it is deterministic, and we can cherry-pick the best ideas – we can build Web 2.0 applications without using Ajax.

Web 2.0 != Ajax

One of the darlings of Web 2.0 is the photo-sharing site, Flickr. I really love Flickr, and am certainly not suggesting it’s a terrible web site, but Flickr uses Ajax gratuitously, and arguably unnecessarily. None of Flickr's core functionality requires asynchronous updates to the page; all of it could be achieved in the "traditional" Web 1.0 way. If it were done like that it would be a whole lot more accessible and arguably a lot more usable.

To illustrate, here's something I whipped up earlier. Thinking about how Flickr could be made without using any Ajax, I hit upon the idea of an editable page, similar to a wiki, on which everything that's user-editable can be modified all at once. So it's either read-only like a regular page, or it's editable like a form. You can download the full example files here.

This distinction makes for better accessibility because the technology baseline is lower; and I also think it makes for better usability because there's no mystery-meat to the interface anymore, no clicking things to see if it's edit-in-place. You have output elements, and input elements, and never the twain need meet.

This demo is not perfect by any means (it's missing a couple of features, and it could look prettier!), but it should serve to illustrate the point - we don't actually need Ajax to provide an editable interface. The page is constructed as a single form, and all editable parameters are fields in that form (editable parameters are indicated with a yellow box). The whole thing makes a POST request when submitted (rather than using GET data, which is inappropriate for some kinds of action); and of course, it all works without JavaScript.

It's also semantic XHTML throughout, with no tables for layout!

Now to me, that's far more useable than the original interface, because it's obvious what everything is - there are no form actions disguised as links, or links disguised as buttons - it does what it says on the tin. But I know that the usability thing is debatable - you might look at that and think it's far less useable than the slick, micro-update, edit-in-place format of the current site. Usability is, after all, one of the main touted benefits of Ajax, and if we can design interfaces that are more self-contained and versatile, then isn't that a good thing? (Would Flickr even be Flickr - would it have been so successful at all - without that "progressive" user experience?)

But posting forms and page refreshes are norms of current web behaviour. They're part of a set of expectations that all Internet users share by now - everybody knows how that works. Is it really a good thing to ride roughshod through these expectations so soon, simply because we think it's better another way? (What is that "yellow fade" thing all about, other than re-creating status functionality that the browser already had?)

Striving for better things is not good enough, if in the process we lose some of our users completely. I think of progressive enhancement like a hierarchy of objectives: where accessibility is the highest, most important thing, followed by usability, followed by aesthetics. Ideally we want all three, but if achieving one of the lower levels means sacrificing one of the higher ones, then it's simply not justifiable, in my mind.

Good usability or not, the pure accessibility issue is pretty much undeniable, I think. All browsers and all assistive technologies know how to deal with forms. You don't need JavaScript, or a mouse, or stylesheets, or even color to make that work!

"And the men and women ... well, the men ... who went to the moon - they did it with no mouse, and a black-and-white text-only screen, and 32 kilobytes of RAM!"

But Ajax allows for applications that are otherwise impossible...

How could Google maps possibly work without asynchronous updates? And what about Meebo, the online messaging service, which similarly couldn't be done without Ajax (or an excessive and highly unfriendly stream of constant page refreshes!)?

Meebo and Google Maps need Ajax to work, and so I have no real criticism of them, and accept that the pure accessibility issues are (as far as I can think) unsolvable for now. I'm not a puritan, and if it comes down to a division between, "do X for the majority", or, "don't do X at all for anyone", I'll usually side with the former.

Twitter I'm not so sure about - it could be done without Ajax, because its periodic updates are relatively infrequent. Twitter could work by refreshing the whole page, or an iframe containing just the message list, say, every minute or two; but automatic page refreshes have their own accessibility issue quite apart from this (because most user-agents don't allow control over page refreshes, and to reload a page without user intervention is equally rude and intrusive). So again, if Ajax is what it takes, and it's that or nothing at all, then you won't hear me complaining too loudly about gratuity or lack of forethought.

Indeed, a client of mine has a successful web-development division that recently did some work that could only have been done with Ajax. They were asked to make improvements to the usability of a legacy system, their client having already been told by other developers that such improvements were impossible, since the system was so entrenched and nightmarish to edit. But Ajax allowed improvements to be made by injecting new UI components directly into the interface, without having to touch the back-end at all! And that's great - and their client was very pleased!

But all of these examples are really edge cases - circumstances that seldom apply. Most of us, most of the time, are working on applications that don't really need Ajax, and which don't significantly benefit from using it. So much Ajax is pointless, used purely for its own sake, or for the sake of being trendy.

I recently went to see a company who were developing a complex, entirely Ajax-driven application; to me Ajax really didn't seem necessary for what they were trying to build. I wanted to give them a fair go, but I was pretty sure in advance that I was going to hit a brick wall when it came to accessibility. And I did. And their arguments were reasonable in purely financial terms - if we can achieve 90% penetration using this technology, why should we care about that other 10%?

But what if everyone thought like that? What would happen to that 10% who suddenly found the web to be a place in which they're no longer welcome? Who found that technology - the ultimate enabler - had become just another barrier?

It's happening right now, and it's really not okay. This headlong rush toward Rich Internet Applications is happening without due care and attention.

To boldly stay

In 2293, in his opening speech to the peace conference at Camp Khitomer, the Federation president spoke these insightful words:

"Let us redefine progress, to mean that just because we can do a thing, it does not necessarily follow that we must do that thing."

Jesse James-Garrett may have started a revolution, but I'm sure that was not his intention. He had the freedom to use a technique in which accessibility didn't matter, and universality was not an issue. But most of the time, for most of what we do, we don't have that kind of luxury; so let's not be so quick to abandon what works.

Stop being so infatuated, and take time to do things properly.

And anyway ... the really good ideas in this evolution of the web are conceptual, not technological - social networking, tagging / folksonomy, user-generated content - and we don't need Ajax to make any of that work.