I've tripped, stumbled, and clawed my way through creating an actual Web application. I have set up an events system that allows you to run 4 separate events, with the ability to dynamically alter the configuration, records and e-mail confirmations sent per event. Once the event is over, each of the systems can be wiped for Round 2. Mind you, it could be polished, but I think I've done an awesome job.

I am finally grasping how to code in ASP and absolutely loving it. I originally posted the SQL form awhile ago, and since then, it has become such a beast. I think this is the funnest and most stressful months work I've done in quite awhile.

I may post a documented toned down version sometime soon.

Features:

Dynamically Generate E-mail Distrobution List from Registrants.

Remove duplicates in case a user register's twice under the same e-mail address.

Ability to run 4 simultaneous events, ability to add more if you really do that much.

Add/Edit/Delete user registrations on the fly.

Download the data to a CSV file.

Data is completely sortable.

The forms are dynamically generated based on the configuration you set up.

I've been working with CMSs for roughly a month (hardcore, that is) and I'm slowly becoming a large advocate in my own mind towards using them. I know why they are used and can be used quite well, but I'm starting to realize that some of the clients that inevitably seek out design services don't have a long-term plan in place to uphold the work we've done. They don't have tech guys and usually farm the work out to a receptionist or somebody who has the most knowledge of managing a Web site, and that could be something as small as having their own blog.

When I code and send off a final design, it's validated, the code is clean, etc. When the toss off happens with a CMS, it's up to the user on their end to piece together what we've done, and odds are, they will horribly forego anything we've done and screw it up. I've had tons of success with a bunch of CMSs, but at the end of the day, if they are the ones changing the content, validation and cleanliness sort of go out the door. And I realize that it's not necessarily my responsibility at this point, but I do think about it more and more.

The first CMS put in place here was handed over and they've yet to use the system, which makes for a big waste of time when you consider the amount of programming work that went into customizing the CMS to match their Web site needs. But they needed it, they proclaimed.....

I've started to create little guidelines in my head on this topic to figure out when a CMS is viable at all:

1) When the site owner will be doing constant updating to all of the site's content. If the only thing they will be changing are the events, install a system for events and customize it.

2) Validate as much as possible and if you use specific CSS styling for an element or new page worth of content, make sure it's documented and ready to pass on when the transfer happens.

3) Think in terms of simple styling when you hand it over. Most likely they won't be classing out their own content. Code the basic tags as simple as possible.

Code :

<p>
<ul>
<li>
<hr>
<h1-h6>
<blockquote>

4) Not installing a CMS provides reoccurring monetary work on your end. The hand off with a CMS implies that you will no longer be involved with a site. If that is your intention, discover their needs and determine if the CMS is worth it, or proclaim at the top of your longues that they need to hire somebody to maintain the content.

I've developed a firm belief that skinning is an art form. It allows you to hone quite a few skills with little time involved. You can track down code faster, edit templates, re-code it entirely, and lambaste it away with a impressive CSS-backed design.

The last two weeks I've been commissioned to come up with a comparison between a couple content management systems, namely Community Server and DotNetNuke. My task proved a little more involved when my host had issues installing either of the two. Both will have to be set up as a virtual server, and therefore editing the code will be out of the question, but I at least know that it's a possible solution once either of the two have been installed onto the main server (and will ultimately work).

From the DNN code. I've extracted out a default template and used that to create my skin. The skinning part on DNN is relatively easy, however, a little time consuming to grasp early on without access to the code. Once you've edited a basic template, CSS is the only tricky part, and CSS once mastered becomes a playground. That's where I'm at so far, and I'll assume it'll take just as long to get this far with Community Server. The main difference between the two is a comprehensive manual wide. Community Server blows away DNN when it comes to documentation. Creating a skin pack ought to bring some joy away to the easiness of editing a template in DNN.

Occasionally, if you are starting out in the CSS world, you'll come across issues that'll waste a good portion of your day. I mentioned this in another post, and one struck me tonight that I had to look up originally to fix a Internet Explorer issue that a previous designer couldn't figure out and was left broken.

The design was set up like two note cards, one on top of the other, the top overlapping the edge by roughly 10 pixels. In Fire Fox, Sea Monkey, Netscape, and Opera, it displayed correctly. In Internet Explorer however, it ignored the CSS coding.

NOTE: Internet Explorer ignores negative margins unless your "position" is set.

Code :

#content {
position: relative;
margin: -10px 0 0 -10px;
}

Without the "position: relative;", Internet Explorer would ignore the negative margin attribute. It would honor the right and bottom values. Using negative margins could open the door to a wide range of techniques to you, whether it be a floating menu, background floats, etc.

Over the last 2 months, I've had the pleasure of mentoring a learning disabled intern in the joys of XHTML and CSS. Where he learns the most is anything through repetition, and coding is just that.

His HTML knowledge was sub par, but minor knowledge to grasp hold of what I was teaching him. I moved directly into XHTML, standards-compliant mind you. XHTML is cleaner and easier to explain, and although he wasn't an expert with HTML, XHTML was easy to pick up. I've been using it for 6 months now, and finally I'm at the point where I feel comfortable marking up a page and feel guilty using multiple DIVs (Divitus) instead of lists. However, he has a solid foundation in front of him to code a basic Web site. With only 2 days a week to do it, it's quite an impressive accomplishment. My goal was to get him to Step 5 and I've done that 2 weeks before his internship is up. If you have any inkling to dabble in XHTML/CSS, here's a quick 5 step process to get you very familiar and coding Web standards friendly Web sites.

1. Start with XHTML markup, using Web standards - validate constantly to learn the needs for validation.

2. Start with inline styles.

Code :

<div style="float:right; margin: 0; padding: 5px;">This is floating text</div>
<span style="color: #000; text-decoration: underline;">This is black underlined text</span>

Inline styles pave the roadway for implementing a style sheet. It also gives you a chance to learn all of the properties associated with CSS. I recommend Cascading Style Sheets: The Definitive Guide by Eric. A. Meyer. Eric is pioneer for the industry and it's only best if you start out your curiosity with him. This also gives you a chance to differentiate the difference between needing an inline style and a parent style that affects the whole document.

3. Start in on Classes and IDs and place the CSS inside of your header - inline document styling. IDs are meant to be used once within a page, and classes throughout a page. In terms of site use, I treat classes as reoccurring items. At this point though, I've got markup down to where I don't need many classes. IDs should be used for structure, defining the document as a whole. The header goes here, because I say so.

Code :

<head>
<style type="text/css" media="all" />
body {
background: #fff url(whitespace.jpg) top center;
}
</style>
</head>

4. Strip your inline styling completely and use a separate style sheet altogether. Decide on the various ways to include your style sheet, the importance of your decision regarding browser compatibility.

Note: The @import feature is good for certain browser to hide your main style sheet from CSS incompatible browsers, but is your markup good enough so that they can effectively use your site without a style sheet?

5. Learning how to manipulate and troubleshoot CSS. Have all the important browsers ready to test your code with your handy F5 key ready. Troubleshooting an issue could waste an entire day. I dread fixing pixel issues related to Mozilla Sea Monkey.

We are currently in stage 5 and progressing slowly. Part of the problem we have right now is the lack of repetition that troubleshooting has. It could be anything. I have five different browsers installed for this reason. A float element that isn't cleared might appear perfectly on Internet Explorer and could be fixed rather easily. But since this isn't always the case, the repetition is lacking. Border-bottom is ALWAYS a problem in Fire Fox, always. These are things you just pick up occasionally, but don't fret, Google is your friend. There are tons of developer's out there who are or were just as frustrated as you are that are kind enough to write something up on the Web about it. Search it and ye will find.