That said, I had an issue where I need to append any number of images to a Post. Sure, WordPress has its image gallery feature built into the editor, but I wasn’t looking for that. I didn’t want WordPress organizing and generating the content for me. It’s not that WordPress dumps out poor markup, it’s just that I was looking to build things by hand.

A number of hours later, Post Gallery emerged. According to the official WordPress Extend page, Post Gallery has been downloaded over 3,000 times. I continue to get a fair number of support requests for the plugin, and I’m really glad to have written it as it taught me quite a bit.

One of the biggest things it taught me was that it could have been written better. A lot better. So I did it, I took all of the shortcomings I saw with the plugin and completely reworked it from the ground up.

Post Gallery will officially be deprecated in favor of Attachments, a brand spankin’ new plugin that serves (in part) the same purpose.

What’s different about Attachments

As I continued to use Post Gallery on various projects, I began to wonder why the heck I decided to store the media in its own table, tucked away from the WordPress Media Library. That was the first bug under my skin. From there, technical issues with media storage snuck in by way of support emails. Then came the issue of wanting to use an image that was previously uploaded; you had to re-upload it. I was quick to decide that the rewrite would absolutely make direct use of WordPress’ Media Library. Not only does using the WordPress Media Library cut out reinventing the wheel, it allows users to recycle the same upload any number of times.

Another peeve I had with Post Gallery was the sorting I had implemented. Needless to say, you can drag and drop to reorder items in Attachments.

The official plugin home page

As of right now, I’m waiting for the WordPress team to officially add Attachments to the WordPress plugin repository. For the time being, if you’re interested in the plugin, you should first follow me on Twitter (@jchristopher) for updates, and then head over to the plugin home page as that will be home base until approval is granted.

In the meantime, if you’d like to check out a quick screencast overview of Attachments, here goes:

Suggestions more than welcome

Attachments will be my pet project for the next few months, as I’ve got a lot of ideas for handling the browse dialog. I realize that it could quickly become overwhelming with lots of media, so I’m going to begin scoping out some possible solutions. If you’ve got a use for Attachments and have any ideas for improvement, by all means let me know!

By far, the biggest hurdle for me is to make sure that WordPress is set up in such a way that it’s as easy as possible for clients to edit their content. That’s the whole point after all, right? Publicly facing, WordPress has a stigma of being a blog engine. I say stigma because being known as a blog engine does nothing to attribute to WordPress’ extensibility and rapid transformation into a full blown CMS. Besides the obvious solution of installing a CMS-facilitating plugin such as Pods, WordPress has plenty of functionality baked right in to bring your sites to the next level.

get_extended() and its unique place in WordPress

On a recent client project, I stumbled upon a feature of WordPress that seems to go unnoticed by many WordPress fans. WordPress has a built in “more” feature that allows content editors to flag a point within the copy of a Page or Post to bisect it. This flag is used by many templates, and comes into play when pulling excerpts of posts when the official excerpt field is left blank.

Since there’s an excerpt field built into every Page and Post, I’ll often suggest to clients that they should instead take a bit of a different approach to take advantage of these built in features. Excerpts are a great way to write very specific copy to be used only as an excerpt throughout the site, instead of adjusting the actual on-page copy to serve a dual purpose. While that handles the excerpt areas, it in part leaves the <!--more--> in an awkward place — how does that come in to play if the client is actively using the excerpt text area?

That’s where get_extended() comes into play. Checking out the Codex page on the function, we can see in the description that the function “gets extended entry info”. But what does that mean? Checking things out in a bit more detail, we can see that this function returns an array of post content. The first array value consists of the copy before the <!--more--> flag, and the second value holds everything after. This really opens up some doors by allowing your design to include different styles on each section of page content. For example:

<?php $pagecopy = get_extended( $post->post_content ); ?>
<div class="intro">
	<?=wpautop( $pagecopy['main'] )?>
</div>
<!-- /intro -->
<div class="entrycopy">
	<?=wpautop( $pagecopy['extended'] )?>
</div>
<!-- /entrycopy -->

Using that snippet allows us to wrap each part of the post copy in different elements, facilitating alternate styles for an ‘intro’ copy block. This came in really handy on a recent project that relied heavily on SEO, and taking this approach allowed for fine grained control over what copy appears where on the website when used in conjunction with the official excerpt text area for each page or post.

Why not just use…

The entire point of taking an approach such as this is for the benefit of the client. Sure, we could use a plugin (or even out of the box custom fields) to replicate this functionality, but we’re all designers & developers. Taking a passive angle here allows the client to understand why things are happening the way they are without having to understand how WordPress and PHP works.

On top of that, it gives the designer another level of control over the front end by including the_excerpt() or <?=wpautop($pagecopy['main'])?> at various places throughout the website.

One of the great things about WordPress is it’s ability to adapt to your needs in just about every circumstance. With that, though, comes numerous solutions to the same ‘problem’ — this is one of those cases. Please take it for what it is, but I hope it helps you on at least one of your future projects!

In the case of lightboxing, it came down to displaying images either by using target="_BLANK" or simply dealing with a full page refresh. For what? Clearly both the latency and resources involved were too taxing both for the user and her experience, even if she didn’t know it.

Lokesh recognized the problem and developed a very elegant solution that took the Web by storm. As with all great things on the Web, his implementation was first widely accepted, and then widely copied forked. The technique was applied to every JavaScript library and/or framework under the sun, in multiple cases, and the technique of lightboxing really took hold.

So what’s the problem with lightboxes, gramps?

Don’t get me wrong, I’m a huge fan of lightbox! To me, the trouble isn’t with lightbox as an entity or technique, the trouble surfaces when it’s put into production. I can’t remember a client project in which a lightbox variant was used where we didn’t need to take time to explain what it is and how it works.

That’s not to say that the lightbox used odd controls or was modified beyond recognition, no. It was simply because the average Web user doesn’t understand what’s going on. At all. Here’s where the problem comes up, and it’s a deal breaker. (Most) lightboxes break the Back button.

In every case of showing a client a development site using a lightbox, he would examine an image and disregard the controls put in place to return to the page, and always go for the Back button in his browser. Even after explaining the reasons we implemented lightbox for image viewing (user experience improvement, etc.) it was very apparent that the client was turned off by the technology.

A proposed fix

To our benefit, such technology exists to assist us with such problems. SWFAddress was written to tackle this problem specifically. Originally written for the benefit of full Flash websites, SWFAddress works wonders with JavaScript implementations as well.

Combining SWFAddress with your favorite lightbox variant would solve this very common problem with its use. A potential issue arises on a couple fronts. First, you’ll need to teach yourself how to use and implement SWFAddress. Beyond that, you’ll need to learn how to integrate SWFAddress with your lightbox.

As an example, I’ve taken those very steps and combined my choice lightbox implementation Shadowbox.js with SWFAddress and used jQuery to bridge the two.

Lightbox (Shadowbox) and SWFAddress integration demo

Please view the source for documentation.

You’ll notice that the Back/Forward browser buttons should retain expected functionality. Additionally, if you were to bookmark a SWFAddressed URL, hitting that URL should automatically invoke the Shadowbox and display the image. Users without JavaScript wouldn’t see the SWFAddress URLs at all, so it’s important to remember your alternative version for those users. But that was already in place, right?

Mind your audience, that’s the deciding factor

As per usual, the important thing here to consider when determining what technologies to use on your current project is to remember the target audience. Are they going to accept lightbox as an acceptable image display technique? Are you better off just doing things the old school way and firing a page refresh? Just be sure you’ve got reasoning (and fallbacks in place) when opting to go with such technologies.

I’m really thrilled to be able to announce the soft launch of SuggestRSS v1.0! If you happened to check out the site in its first incarnation, you may have thought it was neat, but you also must have thought id had a ways to go; it did.

Due to scalability issues, I was forced to take the site offline nearly eight months ago. I wish I could say that I’ve been working on it consistently since then, but that’s not the case. Instead, I took the experience for what it was worth in an educational sense, and let it sit for a short while. The project was always on my mind, but the limiting factor was actually limited experience.

I’ve worked with MySQL before. I’d be willing to wager that it would be quite uncommon to find a Web designer who hasn’t at least toyed around with the basics. When so much of our world revolves around a technology, it’s hard to keep your hands off.

What better way to learn?

Before writing the original release of SuggestRSS, my experience with MySQL was fairly limited. I understood the concepts for the most part, but advanced queries were out of my league. I wrote the first version by the seat of my pants and quickly realized the site wasn’t ready for prime time when it couldn’t scale past the initial user push.

I’ve heard a few designers mention it before, and I’m glad I’m not the only one who feels that sometimes the best way to learn something is to commit to a project outside your comfort zone. The first version of SuggestRSS was definitely outside my comfort zone, and I loved every minute of it.

It was really thrilling to me to have something I spent a significant amount of time on come crashing down within 72 hours of use. The knowledge I gained while writing the application the first time allowed me to instantly identify the multiple bottlenecks in the system. The downside, however, was my not having the knowledge to resolve the issues at hand.

Hit the books

I now had a detrimentally resource hogging application with what I see as quite a bit of potential, so I started researching how the heck I could make it work. I had a number of chats with my Overit Media cronies (lookin’ at you JR, Scott) and they offered some really useful suggestions that definitely got me thinking about what changes should be made, and fast.

With that jumpstart, a number of epiphanies quickly followed. You know, the ones that should have been in place from the get-go. Once the major bottleneck had been overcome, I instantly became determined to relaunch SuggestRSS. My only regret is it taking over six months for that inspiration to strike.

The latest SuggestRSS

The SuggestRSS you see today is a product of a couple moths work (I really wish I kept track of the hours, personal curiosity) and lots of reading. The underlying concept is the same: find some new feeds based on the feeds you currently subscribe to.

The biggest difference by far with version 1.0, besides the design, is that you now have the ability to ignore any suggestion you’d like. Many users the first time around said that while the suggestions made sense, they were mostly sites purposely ignored due to lack of interest or personal preference. You can now bring that omission to your SuggestRSS results.

Future plans

I’d really like to first see how this version scales. Pending any major disasters, I’ve got a boatload of small features and changes I’d like to make over time, but the biggest effort will be put into the suggestion algorithm itself. I’d really like to take as many factors into account as possible in an effort to focus on what I like to call targeted outliers, just so the site can point you in some directions that might otherwise go unnoticed.

I hope you take a minute to check out the new and (vastly) improved SuggestRSS! For the time being, I’ll be making any announcements or answering questions primarily through @SuggestRSS so certainly give a quick follow if you’re interested in any further updates coming down the pipe!

As a side note, with this soft launch I’ll again be able to focus on finishing a few of these articles and getting back on a more strict Monday By Noon schedule. Thanks so much for bearing with me while it’s been slightly quiet around here, I appreciate it.

I often challenge my own stance on handling IE6, and have found what I consider to be a happy medium between both sides of this argument. I can’t in good faith stand behind the abrasive method of completely blocking (or severely limiting) access to a site based on user agent. Another way of handling things is to serve a completely alternate stylesheet, or remove the styles altogether. I prefer that solution over a roadblock.

At the other end of the spectrum, designers will do anything and everything to make the best of the situation, including tracking and billing time specifically for IE6 support. These designers seem to be most irritable when it comes to IE6, and understandably so. There’s a better solution. There is middle ground.

Support IE6, but don’t cater to it

I (and my company) support IE6. We do it because we have a strong feeling about accessibility, and supporting IE6 is really not a big deal.

The biggest calling to roadblock IE6 is by far its CSS “support” — that’s what gives the biggest headaches and leaves everyone running for the hills. The thing to remember, though, is that you’re a professional. With each project, working with IE6 is going to get easier. You’ll remember the disaster happened last time, and you’re going to remember how you fixed it. You’re not going to be faced with that problem this time around, or ever again. Get a couple years of that under your belt and you’re on Easy Street.

I’m not saying that your fixes need to go above and beyond a level of reason for the sake of IE6. The markup and style we’re writing is solid, right? There’s no reason we can’t quickly gracefully degrade a document either out of the box or by force. If that drop shadow is giving you trouble, tell IE6 it’s not there and continue with the next task. This design uses a series of PNGs to bring it to the next level? Don’t bother with PNG fixes; use a choppy GIF or nothing at all. Next.

Another major reason for roadblocking IE6 is JavaScript support. Even though we’re working with superb JavaScript libraries, things sometimes just don’t work out the way we expect. Here’s the answer for that:

JavaScript enhances the document viewing experience by adding an additional behavioral level, right? We’re talented professionals who have already built a fallback version of this document to directly compensate for the absence of JavaScript, right? Our problem is solved: IE6? Don’t fire our JavaScript. If it’s going to be a headache, why bother? We have a perfectly good version of the document that was only progressively enhanced by the JavaScript. IE6 can’t hack it, so just shut it off. Deliver the reduced experience because your viewer, for one reason or another (it doesn’t really matter, does it?) is using a terrible browser.

My point is, that the frustration regarding IE6 comes from forgetting about the medium in which we work. Pixel perfection is a lost cause, and that not only deals with off-by-one-pixel situations, that expands to include the bigger picture including both design assets and behavior enhancements. Don’t try to replicate the beauty of the original design in IE6, just make it accessible and move on.

Aggressive Graceful Degradation

I’ve come to call this view of IE6 support Aggressive Graceful Degradation. Instead of relying on your implementation to fall back to a working version of something, you instead force the changes through gateways provided by IE6 itself.

My experience has taught me how to avoid any catastrophic issues as far as the box model (and therefore main document structure) is concerned, so the IE6 issues I deal with on every project are minimal at best. My IE6-specific stylesheets are mostly just a few declarations replacing PNGs with GIFs (or removing the image entirely) and li fixes that I already expected to implement.

There are a number of other tips that I’ve come to learn in my career that make IE6 less than a bleep on the radar on any project. I documented a number of these tips in Fear not. I have Conquered IE6, and You Can Too, hopefully there are some things that will help you out if you’re having a bit of trouble tackling IE6.

The other main factor to which I can attribute the success of Aggressive Graceful Degradation is that I employ conditional comments to target each version of Internet Explorer in such a way that my fixes are implemented quickly and directly with no side effect other than a few extra bytes of bandwidth for standards-based browsers.

Conditional comments is a subject by itself, one that has been discussed up down left and right, and I’m hard pressed to find a negative stance that really takes hold with me. I’m more than thankful that Microsoft implemented conditional comments so long ago, as it is the single most important enabling feature of Aggressive Graceful Degradation.

Preparing your clients

Taking an Aggressive Graceful Degradation stance is the easy part, the hardest part by far is conveying both the cause and effect of this decision to your client and what it means for his project. To tackle this issue directly, my company has started including an additional document with our contracts, explicitly stating our stance when it comes to Internet Explorer.

We try to teach our clients as much as we can from the kickoff meeting through (and beyond) a site launch. More often than not, a client will appreciate the fact that you’ve taken the time to share your knowledge, and explain it in such a way that the information is useful.

This extra document is referenced in the contract copy and the client is required to sign, acknowledging that he knows his website may in fact render in a very different way, but retain full accessibility. I’d like to extend this document to the community, in hopes that it helps you to take a stance of Aggressive Graceful Degradation when it comes to IE6 as opposed to taking on an abrasive solution such as roadblocking the project.

If you’d like to find out more information regarding the Internet Explorer Contract Addendum please feel free to review and use the addendum in your own contracts, it is released under a Creative Commons Attribution-Share Alike 3.0 United States License. Suggested revisions are encouraged. A formal area for suggestions has not yet been established, but please feel free to contact me directly and we can all work together to make the addendum commonplace in project contracts.

WordPress has had security breaches in the past, and there will be more in the future. That’s just the way it is. Attempting to classify any piece of software as completely void of security holes is a lost cause, and no software should be held to that standard. It’s up to the end user to take it upon himself to analyze the software and make an educated decision to use it. While it doesn’t remove responsibility completely, to WordPress’ credit, this most recent issue took hold only on outdated versions of WordPress. If you have been keeping your WordPress install(s) up to date, you were already covered when the incident first became widespread.

To me, the issue here lies with end users. WordPress is an extremely popular content platform. Millions of users happily publish their content to the world using the system, and that’s the extent to which they know about it. If I had to venture a guess, I would speculate that the majority of WordPress users have never actually installed the system, or are even aware if their version is the most current. Therein lies the problem, but that problem is in no way limited to WordPress itself. That is an issue with any piece of self-hosted software; there is an issue of responsibility on the owner himself.

There’s always a tradeoff

A larger segment of backlash directed toward WordPress revolves around the fact that it’s self hosted, that most of the end users wouldn’t know how to upgrade or even that it were possible. That’s not WordPress’ fault. That’s the fault of either the site owner, or the Web firm who set up his website. Someone needs to retain the responsibility of maintaining the install, it can’t be left to rust. If you’re handing over the keys to a client, you need to make him aware of the ramifications of your decision to use a self-hosted application. You’ll need to explain that the software will need to be maintained and kept up to date, if for nothing else, to avoid security issues. That puts the pressure on him. The other option is to make sure your client WordPress installs are kept up to date. That puts the pressure on you. One way or another, that decision needs to be made along with the original analysis regarding whether or not WordPress will effectively facilitate the project.

I use WordPress for the majority of my work. I know WordPress inside and out, I love the system, and I love the community. I know and expect there to be issues from time to time, and I take the time to make sure my WordPress installs are kept up to date. Not to toot a horn or anything, but I’ve never had a security issue with WordPress, and if that’s simply from keeping my installs up to date in reasonable intervals, I believe that’s a tribute to the WordPress team and community.

I realize that I’m running a risk by self-hosting my platform of choice, but there is no way I’ll ever return to a hosted solution simply because there are too many hoops to jump through. I prefer to hit the ground running, know what I’m doing, and get the job done in the fastest (most custom) way possible. Hosted solutions simply aren’t my choice solution, and as far as I can tell, it’s going to be some time before that’s the case (if ever). That’s a super opinionated statement, but I feel it’s important to convey that I do keep up to date on hosted solutions and consider each in comparison to WordPress as updates are rolled out.

Don’t be lazy

It’s tough to hear the integrity of WordPress be put in question because of lazy admins. To me, that’s what it comes down to after all. I’ve heard excuses left and right about why people don’t upgrade, right down to it being too time consuming, but it all comes down to laziness. The WordPress team has made the upgrade process a literal “click of a button” in the past year. It doesn’t get much easier than that. If your theme might break with a plugin upgrade or an upgrade to WordPress itself, write better themes. Your code should revolve around the fact that WordPress (and her plugins) are going to update, and it’s going to happen often. To moan about maintenance work is just a lazy excuse in my opinion.

I understand that there are other systems out there that don’t demand such care-taking, but I’m the type of person that wouldn’t simply let a version of software sit simply because I don’t take the few minutes to perform some maintenance. I would wonder why anyone would take such a stance to be honest with you, at least anyone in this industry for that matter. Why would you want to knowingly settle down with an expired piece of software?

Taking it for what it is

We know the issue of ‘Windows syndrome’. Crackers will spend most of their time and effort on the most popular system; you get the most bang for your buck. Not only is the software everywhere you look, it’s maintained by an exorbitant number of under qualified people. Unfortunately, WordPress fits quite snug in this classification, and that’s a major reason you’re seeing security issues get so much attention.

On top of that, WordPress is open source. Crackers have been given potential security issues arranged beautifully on a silver platter. More often than not, that works for the benefit of the community, and security issues are squashed before so much as a photon of light can provide exposure. In the eyes of security, this could be looked at as a con in comparison to a hosted solution. Without direct access to source code, malicious intent is much more difficult to bring to fruition. That’s why you aren’t seeing these security announcements from other self-hosted or hosted solutions, the access and desire just isn’t there.

I’m not trying to make excuses

Of course I would prefer to not read these security bulletins about Wordpress, but I take the responsibility associated with my decision to use WordPress and this comes with the territory. If you’re a WordPress user, just make sure you understand that this is part of the job, and if it’s not something you’re interested in, you should start examining other solutions. If you’re not a WordPress user, take the experience for what it’s worth, and give your application of choice another rundown solidifying your decision to use it.

I’m also not trying to start a flame war here, it’s just disconcerting to hear the instant dogging of a system that many of the nay-sayers aren’t even using. I suppose that’s the way of the Internet and will always be the case, I just hope that many people take the high ground and realize this, like everything else, is both a learning experience as well as a reminder.

Remain educated. Don’t take software for granted. Make sure your scheduled backup systems are in place, make sure your software is up to date, and don’t be a lazy Web designer.

This was before the days of the Gedit implementation of snippets so I did my best to replicate TextMate in SciTE. It was awesome. Incorporating snippets changed the way I worked by orders of magnitude, and the implementation found in TextMate is the bar to which I compare every other editor I’ve tried.

What’s great is that snippets seem to have hit the mainstream. Besides OS X specific editors such as Panic’s Coda and MacRabbit’s Espresso, platform independent editors and IDEs have their own implementations as well. Apart from E TextEditor on Windows, however, I haven’t seen an editor implement snippets to the full effect of TextMate.

The big deal about snippets

The deciding factor for me is the ability to have multiple stops per snippet. This gives you the ability to not only share snippets (through Bundles or otherwise) but also very easily write your own. Every designer/developer has his or her own set of tricks, and a generic bundle isn’t going to cover you 100%. The great thing about a solid implementation of snippets puts the power in your hand to finish the job and add the final touch of customization you need.

I’m always on the hunt for a newer, better editor. It’s a curse I’ve had for years and one that will never go away. To be brutally honest, snippets are the only thing holding me to TextMate at this point, as there are a number of strong contenders on the market now, targeted specifically toward Web developers. They’re also gorgeous to boot.

I was to the point where I was simply waiting for the various editors to publish a few dot releases including a solid snippets implementation a la TextMate. That is until I discovered zen-coding. My mind was blown all over again.

zen-coding takes snippets to a new level

zen-coding touts itself as a “set of plugins for HTML and CSS hi-speed coding” and my gosh it lives up to the name. The snippets implementation provided by zen-coding are based on specification drafts, and a heck of a lot has been included by default.

• HTML elements (based on the HTML5 draft spec)
• HTML selectors
• CSS properties (based on the CSS3 draft spec)

Instead of going over the documentation here, I’d just like to call a bit of attention to the HTML selectors linked above. This is truly what made my jaw drop.

The biggest calling point for zen-coding for me is its implementation of HTML selectors as snippet triggers. zen-coding includes an entirely new angle to writing markup, and it facilitates the feature by letting you write HTML based on CSS selectors. It’s so simple it’s confusing at first. I think it’s best explained by doing a quick before and after. If you were to type:

div#name.one.two

and follow that with the zen-coding plugin keystroke (CMD+E in TextMate), the plugin will reformat the line as:

<div id="name" class="one two"></div>

Let’s get a bit more advanced, typing:

ul#name>li.item

will result in:

<ul id="name">
    <li class="item"></li>
</ul>

Last, but not least:

p.one+p.two

will result in:

<p class="one"></p>
<p class="two"></p>

It doesn’t stop there. zen-coding has included an even more elaborate set of possibilities on top of valid CSS selectors.

Element multiplication and variables

A really fascinating feature of the CSS selector abilities comes from element multiplication. Perhaps one of the most tedious things to mark up (when not working from existing copy) is a list (or eight). zen-coding does its part to lighten the load, quite a bit:

ul#name>li.item*3

provides:

<ul id="name">
    <li class="item"></li>
    <li class="item"></li>
    <li class="item"></li>
</ul>

By including a multiplication modifier, you can control how many child elements are included in the snippet!

The other really interesting implementation deals with variables in snippet output, which is neat:

select>option#item-$*3

gives you:

<select>
    <option id="item-1"></option>
    <option id="item-2"></option>
    <option id="item-3"></option>
</select>

By including the dollar sign, you can include a reference to the index of the element you’re multiplying. Although really specific, it could (and probably will) come in very handy from time to time.

I mean if you’re not impressed yet, I just give up!

See it in action

There are a few screencasts referenced on the Google Code page for zen-coding which illustrate the above really well:

• Zen HTML features, 1.х branch, screencast
• Zen CSS features, 1.х branch, screencast
• Aptana Zen HTML features, 2.х branch, screencast

Definitely check them out if my explanation is still a bit foggy, as the screencast really helps display what this plugin is capable of.

Compatibility

One of the finer points of zen-coding is the fact that the developer(s) are taking the time and effort to publish this genius for multiple editors both for OS X and cross-platform. Currently, according to the Google Code page, the plugin has versions for:

• TextMate
• Aptana
• Coda
• NetBeans
• Espresso

Unfortunately, I didn’t find a download link to the Espresso Sugar, but I will keep my eyes open for that as well. Update: the lead developer, in his comment below, let us know that the Sugar is included by default in Espresso releases. I’ve checked out the plugin both in TextMate and Coda and I can say that this plugin alone makes Coda a true contender for more advanced developers looking for a better implementation of Clips (until Coda natively supports snippets (fingers crossed for 2.0 bigtime)).

Note: to fully install in TextMate, you’ll need to download three bundles. At the time of this writing, the three download links are titled as:

• Zen.Coding-TextMate.v0.3.zip (implements zen-coding)
• TextMate.Zen.HTML.1.3.zip (implements HTML functionality)
• TextMate.Zen.CSS.1.3.zip (implements CSS functionality)

Be sure to install each bundle you need!

Non OS X users may find a bit of luck in that the plugin is released for both Aptana and NetBeans, two very popular IDEs as of late. Windows users should be able to use the TextMate bundles in E as you’re accustomed. While there is definitely activity on the Google Code page, I’m not positive that other editors will be supported in future releases.

I love Web design.

This is the line of thinking that really gets me excited about what I do. zen-coding has again completely changed the way I approach writing code, and has raised the bar to a new height. What else is great is that this functionality was provided out of someone else’s love for the industry as well. Their great idea is now making my life even easier, and that cycle will definitely continue in the Web design community.

Monday By Noon was started as my primary method of becoming a part of the Web design community. There were (and still are) so many designers and developers I respect to the umpteenth degree from which I’ve learned everything I know. I’ll continue to hold the community in the highest regard both as a source for education as well as friendships, and that includes every reader of this publication.

The first post here was made on February 19th, 2006. I’ve written 171 articles since then, and you’ve provided 2,895 contributions via comments. Detail oriented readers will notice that from time to time, I’ve missed a scheduled posting. It’s been really tough for me to let slide, as I hadn’t missed a Monday publish date going on over two years strong. The rationalization, though, has been my not wanting to publish for the sake of following the Monday By Noon namesake and publishing for that reason alone. I do my best to think about applicable, useful, informational, worthwhile subjects about which to post, and to be brutally honest, sometimes the idea (or the energy) simply isn’t there.

It was great to read a recent article by one of, if not the, most respected names in Web design conveying the importance of only writing when inspired. I’ve learned many times that forcing yourself to do something is the quickest way to begin resenting it. I love publishing on Monday By Noon, and that’s the last thing I want to have happen. I hope to publish for many years to come, but that depends heavily on my ability to remain inspired. Unfortunately, becoming inspired is in no way an ability in the technical sense, so it’s not something I can actively refine. My inspiration comes directly from the community and the work I do, and I’m super lucky to be involved in a community consistently brewing with interesting changes, discussions, and updates.

Introductions aside, the entire meaning of this post is to extract any feedback from readers possible.

Monday By Noon: the schedule

My original intention with the Monday By Noon nomenclature was to combat a slight case of procrastination I had throughout my years of schooling. In college, I wasn’t the most proficient time keeper, and certain things tended to fall by the wayside and remain undone. Since then, I’ve done quite a bit to reverse that bad habit, and I like to think that I’ve become much better at getting things done, both personally and professionally. If you ask some people, though, they’ll be quick to tell you I’ve got a ways to go!

How do you feel about the posting schedule? I’m especially interested in hearing whether a missing post or two every few weeks is doing any sort of disservice to the site as a whole. Do you think publications made each week are with enough thought and effort to constitute a weekly schedule? In this age of design blogs pumping out ~2000 word articles every few hours, it’s sometimes hard to determine if readers are still gaining from what you write.

The content

I’ll be the first to tell you that Monday By Noon is one of the most improvisational projects I’ve ever had. While I do keep a running list of article ideas, I often come up with article topics at the last minute, something that happened within the past day or two, and I’ll want to write about the topic immediately, as I write best when I’ve got a stream — no, a flash flood — of consciousness to transcribe. It’s only once every few months I refer to the list of article topics I have floating around. Unfortunately, some ideas have been sitting on that list since the first few months of starting Monday By Noon, and no longer remain relevant or interesting.

Lately, however, I’ve been trying to force myself to plan more elaborate articles that people will find interesting. One of the more ambitious article types I’d like to seriously consider and evaluate are screencasts. I love screencasts. Not only do I love screencasts for the built in educational value, I feel like it’s that much more personal. One of the most gravitational aspects of the Web design community is the personality and lifestyle of other designers. I think that comes with any profession, being interested in the way other people do things (that is unless you hate your career).

That said, do you take the time to watch screencasts? If so, who makes your favorites? What screencasts would you love to see? I’ve had a few ideas rolling around, and would love to know if readers would enjoy watching such a thing:

• Design comp analyzation in prep for initial markup and style
• Initial front end development walkthrough
• WordPress development tips, tricks, techniques
• CSS troubleshooting techniques
• JavaScript tutorials

They’re just a few ideas I’ve had rolling around, thinking about what I’d like to watch a screencast discussing. Are screencasts overrated and I’m simply over-enthusiastic about them? If you’ve got any requests for screencast subject matter, anything you’ve been curious about but haven’t been able to find an article to help with, I would absolutely love to read about them!

I’d also be very interested to know if screencasts just aren’t your thing, so please take a second to comment below if you have a bit of free time!

Are there any up-and-coming topics you’d like to see covered in any amount of detail over the next few months? I’d really like to hear some suggestions directly from you, as I’m always worried that the same reader will become uninterested in article topics for many weeks in a row.

Changing it up

Continuing on the fact that I’ve never really had a plan or end goals in place for Monday By Noon, I’ve been considering taking the site to the next level as far as overall purpose is concerned. At first glance, and until now, Monday By Noon has served (and served well) as a weekly publication medium. With the site, though, that’s the one true calling to subscribe and/or visit. Sure, I’ll pull in some links from Delicious, my posts from Twitter, my public photos from Flickr, and even my most-listened albums of the month from last.fm, but the site is far from injected with personal content. For you, is that a pro or a con?

For me, I like to know about authors. Not that it has anything to do with the quality of work he or she does, it’s simply another aspect to check out and draw inspiration from. I’m considering making a few personal aspects a bit more apparent when it comes to the site, but also considering a complete abstraction and relocation to a different platform entirely. I’m having trouble finding a happy medium and would appreciate any thoughts you’ve got!

Personal information aside, I’ve had the itch to really beef up the way I include outside resources. Outside Reading has been the single area of Monday By Noon on site to include outside resources I find useful. Unfortunately, I’ve been posting resources more consistently to Twitter than Delicious, so a lot has been missed when it comes to Outside Reading. Truth be told, many people I’ve spoken to had no idea the links were there in the first place, which is the biggest problem of all!

How do you feel about outside resources and asides? Chances are very good that you’ve come across the links from other sources, but would you be opposed to other information taking a bigger responsibility when it comes to Monday By Noon? I’m considering a Tumblr style update to Outside Reading, turning it into a stream of resources both prominent on the site as well as included in the feed. Would that be too big of a change for you, or something totally welcomed?

I hope the deviation in topic matter wasn’t too much of a disruption, and if you’ve made it this far in the piece, I would truly appreciate any thoughts you’ve got. Monday By Noon’s readers are its most valuable asset, and I’d like to do everything I can to have them enjoy the site that much more, including responses to very specific requests. Hope to hear from you soon!

Follow me on Twitter to find out if you’ve won the book!