Privacy policies are actually a big deal. They’re the EULA of websites and often go ignored, resulting in outrage from user bases who never read it in the first place and are infuriated that the company behind the site followed through on what was outlined.

Perhaps an even bigger deal is the alteration of an existing privacy policy. Google appears to be going about that in the right way, and that’s great.

If you use Google products as much as I do, you should be aware of their goals as a company, which are outlined to an extent in their privacy policy. It’s important to understand the changes taking place to evaluate whether or not you’d like to continue using said products.

Additionally, let Google’s action be an example: are you maintaining an effective privacy policy on your properties? 37signals recently went through quite a bit of PR surrounding this issue, something to take note of.

Advertise here with BSA

Bookmarklets are handy, Google Chrome Extensions are handy. This neat little tool allows you to easily convert your extra-heavily-used bookmarklets into Chrome Extensions. Timely for a small project I’m working on. Awesome.

Advertise here with BSA

Google is improving their page layout algorithm to better handle the content-supersaturated pages we end up finding all too often.

As stated in the writeup, the algorithm change affects less than 1% of searches globally, but that seems odd to me. I search quite a bit, and it feels like I’ve ended up on these types of pages more than 1% of the time. I realize, though, that I’m far from the majority and am glad a change is in the works!

If we continue to do our jobs by designing and building sites of high quality, this algorithm change should help us and our clients rise in the ranks.

Advertise here with BSA

This whole story is kind of weird. I’ve only been watching on the periphery, but the background gist is this:

From what I understand, it all starts here, an article outlining an example of Google violating it’s own guidelines against paid link listings. The usual result for this action is either a time-based penalty or outright banning.

Yesterday, a follow-up post was published illustrating that yes, Chrome was in fact undergoing various changes regarding where it would show up for certain search queries.

Long story short: searches for “Chrome” resulted in links pointing toward the support docs on support.google.com and searches for “browser” found links to Chrome falling as low as the 73rd result. Very interesting.

A short time later, Matt Cutts provided a more official response to the situation explaining a bit more from behind the scenes, and also divulging that http://www.google.com/chrome will be demoted for at least 60 days.

Weird stuff, man.

Advertise here with BSA

PayPal has it’s pros and cons, but Google’s flopping of products basically forever has prevented me from suggesting it’s use to clients. This makes me glad I did that.

I’m putting some hope into Stripe.

Advertise here with BSA

A neat look at what Google+ is doing to keep itself secure, and even takes a comparative look at what Facebook is(n’t) doing.

Advertise here with BSA

This article is rightfully making the rounds, it’s really important that you read it. For those not familiar with hash-bangs, it’s the newfangled “solution” (from Google) to create AJAX-crawlable websites. The best real-life example you’ve likely seen is the URL structure of New (is it still considered “New”?) Twitter, e.g. http://twitter.com/#!/jchristopher

That #! doohicky is a hash-bang, and it’s causing a ruckus, recently very much so for Gawker and it’s recent massive redesign. Definitely give the article a read, it’s worth it.

Advertise here with BSA

I watched a screencast the other day, focused on experiencing Twitter through a screen reader. If you’ve got a spare 3 minutes, check it out:

The Screenreader Experience Part One from NAPCS on Vimeo.

I was gritting my teeth not only at the frustrating user experience, but at the fact that I know I’ve unconsciously let a few best practices slip when working on recent projects. As stated in the screencast, I’m not trying to pick on Twitter, as I think we can all agree that accessibility sometimes takes a back seat in favor of new hotness.

Accessibility is more than standards

Watching that screencast brought me back to an internal debate I’ve been having for some time. It seems as though advanced interactions on the Web — JavaScript, HTML5, and otherwise — becoming more prevalent may have us a bit blinded to the underlying importance of making our sites accessible.

If I had to venture a guess, I’d say that the majority of us have never had a one-on-one experience with a screen reader. The leading software is pricey and it runs on Windows. It therefore has a general barrier to entry for the majority of us. There are alternatives, but we as designers realize the importance of using a piece of software in its natural environment. We test in more browsers than we would ever want to, but we do it because we’re professionals and we take pride in our work. That said, we should be testing assistive technology as well, but we don’t.

Is the world moving on, again?

There are more inaccessible, downright bad documents floating around the Web than I care to think about, some created very recently too. I’m hopeful that the world hasn’t forgotten about accessibility, but things like Google pushing the capability to crawl AJAX applications really facilitates bad practice, in my opinion.

I’m not trying to knock Google for doing what it does, but in all honesty the fact that Google didn’t index AJAX-powered applications was one of the last remaining reasons for developers to take accessibility seriously. That’s not to say that AJAX-powered applications can’t be accessible, it just opens the doors to leave the principle on a back burner.

Accessibility received a ton of attention during the ‘original’ standards movement, and I look upon that very fondly. I learned a lot during that era, but unfortunately I’ve forgotten to retain those best practices from time to time. That’s something I’m going to focus on quite heavily in an effort to retrain myself, maybe you can too.

Advertise here with BSA

Back when standards were standards if you were building anything that didn’t have a fall back plan in place for a lack of JavaScript, you were doing it wrong. Yes it took more time and it took better planning but that’s the point. When you’re a professional you’re supposed to be doing it right, right?

The rise of (my) Web standards

Back when JavaScript was reborn, when its use began transforming into what we know and love today, the rules were still being written. I remember thinking about how I should approach learning this skill I knew would soon be essential. My first stop when teaching myself something is Google. Of course back in the day Google was still polluted with DHTML tutorial sites and wretched implementations. After reading countless tutorials comprised mostly of “copy and paste this snippet here and that snippet there” I knew it was time to hit the books.

It took about four seconds of poking around to realize that there was more than meets the eye when it came to JavaScript for me. I needed to learn about the DOM before I tried to manipulate it. If there’s one thing that drives me batty it’s the notion of ’learning the framework instead of the language’ and this is no exception. JavaScript though, has a completely new layer to work with.

I won’t detail the issues I have behind learning a framework or platform as opposed to the language here, but it can be applied to every programming language, every markup language, CSS, and JavaScript as well. To sum it up: learning the framework gives the language a bad name. We’ll leave it at that and the rest for another article.

I grabbed myself a copy of DOM Scripting by Jeremy Keith and to this day I’m glad I did. DOM Scripting was instantaneously followed by Bulletproof Ajax, also published by Mr. Keith. If I had to choose two books as a suggestion to someone looking to learn proper JavaScript I think these two are it. There are of course subsequent, more advanced books that I’d also suggest, but these two works will help you to realize which blog posts are junk and which are gold.

The theory behind writing JavaScript, as I took it, can be taken from DOM Scripting:

Separate behavior from structure using unobtrusive JavaScript. Add dynamic effects with progressive enhancement. Ensure backwards-compatibility through graceful degradation.

I lived by those rules. I still do. But am I stuck in the past while everyone is moving forward?

The new Web

Has building a proper Web stack become old school? What I’ve been curious about lately surrounds the trend that requiring JavaScript for your Web app is something we hardly blink at. MobileMe has just recently relaunched with a new look:

Looks really great, but if you hit the page with a JavaScript-incapable browser it’s a bit different:

Back in the day we’d all have scoffed at such a thing, comparing it to a “This site looks best in IE6″ badge straight out of the 1990s. What’s changed since then? Why is this now an acceptable practice? I understand that Apple is a progressive company, bringing the web in its best form to the largest population possible, and making it look great, but that’s my point. Is this new school of thought going to transform itself into common practice?

The entire point behind breaking away from closed platforms such as Flash (yes, it’s a closed platform no matter how much marketing gets put behind it) is to build a universally accessible Web. Devices are advancing, yes. Browsers are advancing, yes. But does that give us the liberty to put the fruits of our labor on a back burner now that we’ve reached some sort of plateau in the evolution of the browser?

I’m not dogging Apple

Apple isn’t the only one producing Web applications that show similar messages if you’re using a JavaScript incapable browser. In fact, other more popular platforms are doing it even worse:

There was a time, if I remember correctly, where Google Docs gave a notification similar to MobileMe as opposed to loading a non working pseudo interface that does nothing but confuse a visitor. Gmail still retains its fully functional JavaScript-less implementation, albeit behind a quick message notifying you what you’re in for:

Depending on your choice, you can end up at a really well put together version of Gmail:

To me, Gmail remains to be one of the best implemented modern Web applications because of this very attribute.

Where are we headed, really?

I’ve tried to wrap my head around these poorly implemented Web applications to find out the real inspiration behind them. Are companies rushing JavaScript dependent platforms out the door simply to get things live before the competition? Are metrics showing that supporting JavaScript simply doesn’t make fiscal sense? Are we to a point where leading Web companies care more about dollars and cents than users?

What about the Web applications themselves? We’re working with the most rich implementations of JavaScript we’ve ever seen. Many times, it doesn’t even make sense to offer a degraded version of an application simply because the desired feature is built within JavaScript from the ground up; there’s nothing else to show. This is not a bad thing. I’m concerned in particular for those applications that could in fact have a decent degraded version. Does it change the opinion we have behind the modern Web though? I’m speaking from a front end developer point of view here, a conversation between us professionals, not as users.

Do we need to move beyond this self-imposed requirement of providing a gracefully degraded version of our application? If so, would it not be a (short) matter of time before that school of thought trickles all the way down to the Coda Slider we plan to implement? In essence, what’s the difference? We’d all be thrilled if we could just make that AJAX request and call it a day without having to first build an alternate version, but is it the right thing to do as professionals?

The groundwork has been laid by some of the best thinkers in our industry, and neglecting to build a proper stack, to me, pushes all of that hard work aside in favor of (too) rapid deployment. If your metrics show a 99% JavaScript enabled audience, are you willing to forsake that 1%?

I’m not only concerned about that 1%, I’m (perhaps) more concerned about how it affects the overall implementation. Working from your degraded version is going to result in a much more stable environment upon which to build your behavioral layer. Skipping that valuable step can and probably will result in a less structurally sound document.

I have a tendency to remain loyal to influential circumstances that have shaped me as a professional, but I’m curious how (if?) these events are affecting other designers and developers, if at all. Do you continue to be curious about degraded versions of modern Web applications? I could be way off base in even thinking about things to this level, and if that’s it by all means feel free to call me out on it, but there’s something under my skin about what’s going on. Thoughts?

Advertise here with BSA

I think this is great. Typekit is really making an impact with the service provided, and Google hopping on board is a really great thing for the both of them… and all of us.

We’re happy to announce that we’ve teamed up with Google to make webfonts ubiquitous and more accessible. Starting today, we’re making our Typekit font events an open source project called WebFont Loader. Now you can have complete control over how fonts are loaded and what happens when they’re rendered. You can download the code and use it however you like, or link directly to the latest version via the Google Ajax APIs.

Over the past few weeks, we’ve worked very closely with developers from Google to ensure the code is as broadly usable as possible. You can use WebFont Loader with fonts on your own server, links to the just-announced Google Webfont API, or any Typekit account. We’ve also made sure the code is modular, so other font hosting services can add to it in the future. You’ll find full documentation, examples, and information on how you can contribute at our GitHub repository.

There’s even a collection of open source webfonts that you can use right now provided via Googles CDN. I’ll be shopping around to see if anything suits Monday By Noon over the next few weeks.

Type is a big deal to us all. Projects like this help make beautiful type more accessible and usable and I really welcome it. I also keep in mind, however, that a (completely supported) native implementation is something I’ll continually be waiting for. Until then, keep rocking it, Typekit (and Google).

Advertise here with BSA