Photo courtesy of Jen Loves Kev

I’m going to take the next few weeks off to focus on the best thing that’s happened to me since ever; marriage. I’m getting married to Carrie in just a few short days and I’d like to take time to enjoy that and make sure I’m able to remember as many details as possible for the rest of my life.

I plan on getting a lot done with my wife and I also plan on spending as much time with her as possible, even when it’s sitting in the back yard. We’ve been so off the wall busy planning, planning, and planning, we haven’t had nearly enough time to spend together in the past number of months. It’s officially time to remedy that.

That said, Monday By Noon is going to take a back seat for the month of July.

I’m nowhere near done, though, fear not! I’ll be back with a vengeance as I’ve got more articles drafted than I’ve ever had and I can’t wait to get back into the swing of things.

Thank you so much for keeping Monday By Noon within sight, reading, and commenting. See you in August!

I believe having a consistent desire to improve ones self on a professional level is a curse for many in our industry. It is at least a curse for those that care about the work and not just making a buck.

That said, this curse is a curse. Consistently discovering new and better ways to do things can have significant effects on the way you take on and see through a project. With the day-to-day being so extremely variable, everything is likely to change with the wind, and that can be disastrous for some people. Personally, I love it.

One Sure-Fire Way to Improve Your Coding could have very well been written by some guy who was shadowing me for the past 3 years, spying on my every move. I practice nearly everything mentioned in the piece and I really hope you do the same.

I love the detail this piece goes into, not only describing methods of improving yourself, but also some really solid guidelines on how to make the most of your time.

I love that the take home message, though, is that one of the best things you can do to improve your code is to read someone else’s. The next time you’re impressed by something, do what you can to crack it open and figure out how problems were solved on an intimate level.

If you’re impressed by a website, try to see what the designer saw. If you’re impressed by a plugin, open it in your code editor and figure out just how they did it. $10 says you’ll learn something and implement it at your next opportunity.

As our relationship with HTML5 progresses and grows deeper, I’m excited to see direct comparisons between ‘old and busted’ and ‘the new hotness’ on a one-to-one scale.

William Malone literally holds our hand as he walks us through the replication of an icon in both JavaScript (via canvas) and Flash (via ActionScript 3). I find it really interesting to compare both the differences as well as the similarities found within the common ground known as ECMAScript.

This is honestly a thing of beauty. Supported currently by Safari, WebKit Nightlies, Chrom, and even Firefox by default, text-rendering:optimizeLegibility automagically handles kerning pairs and ligatures.

How sweet is that?!

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 you’re 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?

I like to step back and examine things from the ground up from time to time, on every level of Web design, right down to the single line styles I write. I prefer to keep my mind sharp, and feel that there’s no better way than to consistently question the methods I’ve become comfortable with. The Web moves at a mile a minute, and sticking with something because you’re comfortable with it will more than likely leave you in the dust quite promptly.

That said, I’ve been thinking a lot about Suckerfish Dropdowns lately.

The root of Suckerfish Dropdowns

I wasn’t even front ending a site when I started thinking about Suckerfish Dropdowns, but once I started I couldn’t stop. Where the heck did they come from? Suckerfish Dropdowns themselves are basically a proper implementation of something rooted back in the days of DHTML dropdown menus. DHTML dropdown menus more than likely came from a ‘this is pretty neat, and it moves!’ epiphany, and that’s where I started to be puzzled.

I’m not really much a fan of inventing completely new interactions on the Web. The Web is still a very scary place to lots of people and I feel it’s our duty to tackle that directly. Surprising someone new to the web with a completely unconventional method of interaction isn’t going to help anybody.

I tried to find another area of computer interaction, aside from the Web, where something resembling Suckerfish Dropdowns appeared; I couldn’t find one. Every other menu system we work with requires a click from our mouse.

That started to make more sense to me. If I were moving around in various applications throughout the day, and simply moving my mouse pointer from one area to the next resulted in a number of Suckerfish Dropdowns activating momentarily only to retreat back to an original position would drive me crazy. I then became annoyed with Suckerfish Dropdowns on the Web.

At the same time, however, I can see why they exist: Suckerfish Dropdowns help organize an entire site in a neat little package, waiting for some interaction. We can’tshouldn’t require a click action because that’s JavaScript dependent and we’d get in big trouble if we were to do that. So where do we go from here?

What’s the alternative?

Perhaps we’re not thinking through our navigation systems thoroughly enough. Maybe we’re just defaulting to Suckerfish Dropdowns because they’ve been put in place so consistently they are a founding interaction on the Web, regardless of their absence elsewhere.

Is bombarding a user with every option under the sun really the best solution? Would we be better off simply going with high (single) level navigation systems and better structuring our secondary navigation elements? Or is it at that point we’re instilling a sense of ‘venturing to the unknown’ for our user? Perhaps we need to develop better copy for the top level navigation in that case?

I have a lot of questions on this and before I delve into it further and drive myself nuts, I’d really like to hear some feedback as to whether anyone even sees this interaction pattern as a detriment for user experience. Thoughts?

What are Custom Post Types?

First and foremost we need to understand what Custom Post Types are. I’ll try to do my best to sum them up as quickly and as easily as possible in my own words.

Custom Post Types defines our new ability to better organize more advanced content structures within our WordPress sites. That is to say, using Custom Post Types will allow us to create groups of content in addition to the stock Posts and Pages. Subsequently, we’re also able to define the data fields used in each group. Further, we’re able to take advantage of many standard features built into WordPress such as creating custom taxonomies (used for categorization among other things) and more.

If I had to label one final stake in the ground that WordPress is fantastically stating that it is no longer a “blogging” platform and instead a content platform, it would be Custom Post Types.

Custom Post Types have got a ton of attention lately, and as such deserves it. I can’t emphasize how much of a game changer this is on a platform level not only for WordPress developers, but for users as well. We’re going to see a lot of changes on the theme level which in turn will spread the word about WordPress’ adaptiveness.

Where does Pods fit in?

Custom Post Types sound great, but what about Pods? If you want the short version: I love Pods and I don’t see it going anywhere anytime soon as a result of Custom Post Types.

Now for the extended version.

Pods and Custom Post Types, although they have some overlapping functionality, don’t directly compete with one another top to bottom. Custom Post Types open a lot of doors, and I plan on using those doors as often as possible. Pods, however, is functionally superior to Custom Post Types in ways that I’ve been taking advantage of on nearly every project in recent memory.

The superiority lies in the fact that instead of being a new group of Custom Posts or Pages, Pods focuses on the relationship factor by keeping the doors wide open when it comes to how the data is displayed, how users interact with it, and how you use it. Additionally, the Pods developers are super focused on performance. That’s not to say that I’ve noticed a performance problem with WordPress, but it’s great to read that they’re focused on speed and integrity to the level of creating one-off database tables every time Pods needs one for your content types.

Pods takes a different approach entirely when it comes to the database level. WordPress Custom Post Types simply append your new content groups to the Posts table and under the hood are using Custom Fields to take care of your custom data. This is nowhere near magic to anyone who has written a plugin before that accomplishes the same thing. Attachments, for example, uses that philosophy to function.

Don’t take me wrong, I don’t think that’s wrong to do, not by any means. I always try to KISS and I think Custom Post Types do the same thing. I also appreciate, though, that Pods focuses on performance at its root.

Pods also offers more when it comes to functionality offered. Custom Post Types leave things pretty open-ended for you to get done what you’d like, but I’m not sure how easy it will be to relate one Post to another, or multiple for that matter in that group. What about relating that Post to a Post from a completely different group? What if you want to limit that list of available Posts to include a certain number of Posts from one group, and more from another? Pods has you covered out of the box.

I’ve also become addicted to the way Pods UI lets you present the Pods you’ve created. You’re able to organize and group your content types in such a way that it makes perfect sense when your client needs to hop in the driver’s seat. Pods UI is founded on built-in WordPress functions and I’m not sure to what extent it can be replicated with Custom Post Types at this stage, but I’m smitten with Pods UI and hopefully that functionality can eventually find its way to Custom Post Types.

I’ve become very comfortable with the advanced features offered by Pods, especially when Pods UI comes into play, and I won’t backtrack at this point just to take advantage of built-in functionality (my personal preference by default). I think Pods still stands on its own two feet by a long shot.

Will they blend?

That said, I plan on using a combination of Custom Post Types and Pods until a new catalyst enters which will cause me to reevaluate the situation at that point. I have a set of rules that help me build sites on top of WordPress and incorporate Pods all to make things as easy as possible for my clients to use and I will continue with that school of thought now that Custom Post Types are here.

I’ve got a lot to learn about Custom Post Types and what’s technically functional, possible, and stable. You can be sure I’ll be posting my findings along the way. I feel that Pods and Custom Post Types make a good team and will continue to do so beyond the launch of WordPress 3.0.

Should the project include it, we’ll work with clients to finalize their content strategy from top to bottom and work with them to finalize copy, imagery, and other assets. The part that comes with some internal divide in my office, however, is that pesky population part. Who does it, and when?

We should do it, we provide a service

One side of the office argues that we should provide content entry as part of the development process. While final content shouldn’t hold up development in any way, this camp feels that once content has been finalized, it should be provided from the client in its native form and it’s our job as the service provider to enter it all. I see the positive, customer service aspect of that solution, but I also see a ton of red flags.

First and foremost, have you ever received photo gallery content (read: photos) in a Word doc? Yeah, I have too. Last week in fact. Although it’s labeled as final, much of the content is still missing and much of what’s there isn’t organized in such a way that makes much sense to the developer or production manager that actually has to input everything.

By far, though, the worst offense that I can see is that it’s delaying a completely necessary part of the project. The part where you hand over the keys to your client and they actually use the content management system you spent 3 months setting up for them.

We provide extensive documentation in conjunction with a site staging environment, and the tools in place exist for the client to use. Why would we delay that and take it upon ourselves to use the tools for them? We would do it because content entry is not fun, it’s very tedious. We’d also do it to make sure it’s done on time and in such a way where we can take advantage of the little tips and tricks we’ve come up with can be fully taken advantage of. But is it for naught?

While the initial content population might be top to bottom perfection if done in house, at some point you’re going to have to relinquish control to the client and they’re going to do everything in their power to make that text centered, bold, capitalized, and “a red that pops” once a new promotion begins. I guess what I’m saying is, why wait until the site is live to try and sway your client in the right direction as opposed to when it’s on the staging server, hidden from public view? If the client is populating all of the content, you can monitor how they are using the CMS and educate accordingly.

The client should do it, it’s their site

The other camp at the office feels that it’s the job of the client to populate their own content on their website once it’s to a stage where the CMS will facilitate the additions. This camp feels that in addition to the documentation we provide, the client needs working knowledge of the website, because chances are they didn’t read the documentation anyway, and won’t until an emergency edit needs to be made at a later date.

While we do work with clients on a consistent basis to finalize content, the only one to have it truly and absolutely organized is the client, and often times it’s very difficult to have a client transfer the assets in such a way where it makes as much sense on our end. Why cloud the waters? Why not just let the client enter the content in the exact way it’s organized in their head?

Many times when we’re entering content we’ll see that the wrong assets are incomplete or categorized improperly, which causes a certain amount of additional back and forth with the client to number one make it clear which page we’re talking about and number two explain what was wrong and what the client needs to do to make it right. This is often a very circular, frustrating process that we’d rather avoid altogether. If the client is entering their own content, it’s a moot point because they plainly see the exact problem at hand.

The major argument against the client entering their own content is customer service. Is content entry putting your client to work? I try to put myself in the shoes of the client, having just gone through this extensive process of working with a company to build my dream website. I might not be the most computer savvy person, but I went with this company because they showed me that managing my website isn’t as scary and impossible as I was once told. I want to get my hands dirty, I don’t want to be scared of making updates to the site in the future, once I’m on my own.

What’s my take?

I know I can’t help my bias of actually building these websites and thinking about how much a client willshould love working with the content management system the way I’m setting it up. I try to be objective with this situation, as I do with all client situations. I feel that it helps me do my job that much better, but I see both sides with this argument.

I do have a formulated an opinion on the subject, though. I’d prefer to hold off in saying it outright in an effort to hopefully spark some conversation in the comment thread, but at some point soon I’ll plead my case in line with one of the camps above.

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).

I somehow missed the cruise liner that is BlackBerry buying a mobile WebKit company and things are finially coming together.

Truth be told I’m not the least excited about BlackBerry OS 6.0 in general, but if it is true to fact based on WebKit, the mobile Web just got that much better for us all.

MobileSafari is without a doubt the top tier platform for the mobile Web. If BlackBerry sucked it up, admitted that, and adopted it, I think that says a lot for WebKit really setting the bar (and retaining it) as we grow into this unavoidable, giant segment of the Web.