dougv.com « Doug Vanderweide

This Web site is in sore need of a redesign — something cleaner, way prettier, brandable and unique — and it’s painfully obvious to me I’m not the guy to get that done.

So to all the ad agencies, creative houses, Web designers and graphic artists out there: I’m looking to trade my time and materials for your time and materials.

If you’ve got the skills to apply a brand to this site that kicks much ass, I’ve got the skills to hack your CMS, ride herd on your troublesome Web server, write you a WordPress plugin, fix your stove-up online store, clean up your messy database,  build you an ASP.NET / PHP site, do some Microsoft Office VBA, apply some jQuery or API code, and much more.

This site runs off WordPress and I’m pretty neurotic about making sure it’s the latest version. I have zero brand identity at the moment in terms of aesthetics, so you’ll have near total creative freedom. And since I’m in the business, you can be sure I’m not going to be one of those pains in the ass who expects the moon and stars for nothing, or who constantly asks for tweaks, needless gizmos or ridiculous “features.”

The only hard requirements on my end:

• The design must use WordPress coding standards and follow best practices (e.g., no hard-coding of menus / widgets on template pages; style hooks for unique divs / sections; no deprecated WordPress functions; page, index, archive, comment and other templates put in unique files; etc.)
• It must be XHTML 1 Transitional and CSS 2 compliant. I’d prefer if it was HTML 5 and CSS 3 compliant, but I’m not going to be pushy about that.
• No Flash or other animations.

Interested? Shoot me an email at dougvanderweide@gmail.com describing what you think would work here and what you’d like me to do in return.

Three weeks ago I decided to give Google Chrome a shot at replacing Mozilla Firefox as my primary browser. And believe me, it was a fair contest: I only called upon Firefox when I could not get Chrome to work.

Unfortunately, I had to call on Firefox at least once every other day. And while I still run across the occasional Web site that requires me to use Internet Explorer — mainly, Web sites that use some Microsoft technology, such as LiveMeeting or an ActiveX control of some sort — that’s maybe once or twice a month.

(And no, I have not given IE a chance to be my primary browser. When it truly embraces Web standards, then I will consider it. Internet Explorer is barely in the neighborhood of standards compliance right now, never mind on the same street. Safari? C’mon, man. Opera? Seriously, stop now, you’re embarrassing yourself.)

So I’ve made up my mind: Chrome gets sent back to the minors to work on its skills, and Firefox — older, fatter, slower, but far more dependable and experienced — is back as my ace starting pitcher.

Continue reading: Chrome Just Isn’t Up To Firefox’s Snuff »

After writing so much about the ASP.NET cryptographic padding oracle exploit, and the recommended workaround of a static error document, it dawned on me that I should probably make some custom error documents for my domains.

And then I decided I should share them. So, if you’re so inclined, you can download the custom error documents I use on this site. I release all code under the latest version of the GNU GPL.

I’ve created pages for 401 (unauthorized), 403 (forbidden), 404 (not found) and 500 (internal server) HTTP errors. Here’s how they look (click thumbnails for larger image):

I designed these to be valid XHTML 1.0; to appear well in all screen resolutions from 1024 x 768 and greater; and to appear the same on most Web browsers. (Of course, I exclude Internet Explorer prior to version 7 from that list.)

This little exercise also gave me a chance to play with the Google Font API. There aren’t a lot of fonts available yet, but using the API couldn’t be simpler.

Instructions on implementing custom error document on Apache can be found here. Microsoft documents how to add customError files to your ASP.NET web.config file here.

All links in this post on delicious: http://www.delicious.com/dougvdotcom/custom-errordocuments-available-for-download

Crowdsourcing is all the rage these days, and even if you’re not managing a social media Web site, sometimes it’s helpful to accept content from end users.

For example, one of my clients has a community calendar on its Web site. Since the inception of the calendar, staff time had been devoted to retyping e-mailed and snail-mailed items into that calendar’s back end.

That was almost entirely wasted time, which my client rightfully wanted applied to something more profitable. My client wanted to allow staff to approve, edit or delete calendar submissions before they appeared on the site, but asked me to shift the burden of actually adding items directly onto the shoulders of site visitors.

Thanks to ASP.NET’s built-in membership system, we can easily provide a simple system for allowing end users to provide content. Not only that, but thanks to the role-based permissions incorporated into membership, we can even presort content to specific sections of the site, based on who is submitting it; grant specific users or user groups the ability to bypass an approval process; throttle contribution allowances; basically, any permission or restriction you might want to use.

(Aside: We can similarly implement a model like this in PHP, but it does not have a built-in membership provider. I may, at some later date, describe building a PHP membership provider that is similar to the ASP.NET model, at least in terms of practical use, if not mechanically similar.)

I am going to make a simple cancellations notification system as my demo.

After all, everyone wants to know if school is closed, or whether the play is still on in spite of the weather. Because canceling school, play, etc. generally comes down to a single person’s decision — or, at most, a few people — we can easily provide a system to log in, select a few options or enter a bit of text, and save everyone the time and grief such notifications otherwise take.

The specific features I will demo, in this and upcoming blog entries, will be:

• an administrative interface to add, edit and delete memberships;
• another administrative interface to add, edit or delete membership roles (i.e., membership groups), and to assign members to those groups, as well as to assign users to specific schools, organizations, etc.;
• an administrative interface to approve, edit or delete cancellation notices;
• a private form to allow membership to post cancellations for the schools, organizations, etc. with which they have been associated;
• a public view of cancellations that have been approved for viewing.

Continue reading: An ASP.NET System To Allow Site Members To Contribute Content, Part 1: Overview »

A common challenge when working with ASP.NET master pages is how to dynamically add JavaScript that is relevant to a specific child page.

In other words, maybe your site has 10 child pages that share one master page / template. One of them is, let’s say, a contact us / directions page, and on that page, you want to display a map from one of the many mapping APIs out on the Web; for simplicity’s sake, let’s use the Google Maps API.

Proper implementation of the Google Maps API requires you to call, in the head section of your page’s HTML, the API library. So, you’re left with four options:

1. Import the library in the master page’s code for all child pages, and thus incur that overhead for every page using that master page / template;
2. Create a second version of the master page, containing the code, and apply that master to the child page that needs it;
3. Don’t use a master page for the page that needs the API; have that erstwhile “child” page contain all the HTML it needs; or
4. Figure out a way to add the needed code to the head of the master page for the child that needs it.

Option 1 seems reasonable, but it’s messy; although simply bringing in the Google Maps API for every page isn’t resource-intensive in this strong-computer, fast-bandwidth world, it’s sloppy at best and a potential security risk at worst (although the Google Maps API is pretty much safe to import, even if you’re not going to use it).

Option 2 leaves you with what is fundamentally two versions of the same thing, which is pretty much the dictionary definition of “inelegant.” Option 3 isn’t any better.

Option 4 is the best approach, and thankfully, there are a couple of ways to do it in ASP.NET. I’m going to describe the way to do it by dynamically adding HTML elements to the master page’s head, but first, a quick digression on using a PlaceHolder control.

Continue reading: Dynamically Adding JavaScript To Your ASP.NET Master Page From A Child Page »