The Basics Articles

"Should I use Dreamweaver to code websites?" my short answer is, no - you should learn to use an editor that was made with coders as the main focus.

"But doesn't Dreamweaver have a code editor build into it?"

Yes, Dreamweaver contains a code editor. But my answer to why a coder should not use it goes back to the original intent of the application. The intent of Dreamweaver was to give people who don't know how to code websites the power to build websites. Today, Dreamweaver has changed quite a bit, giving coders some more tools to work with, but it hasn't lost it's original intent.

Adobe's focus with Dreamweaver is to create a website development tool that reaches the widest audience possible; which in-turn increases sales. Because of this goal, Dreamweaver has everything and the kitchen sink in it. Dreamweaver (in my opinion) suffers from feature bloat because it has such a wide target audience and the program is not 100% focused on the coder's needs.

Hats down to the Adobe Dreamweaver team for making a tool that reaches such a wide audience, but I will never use it because it doesn't have me (the coder) as the main focus. My advise for coders is to find a tool that is solely focused on you, the developer and leave the design / hybrid software behind.

After years of working with developers and observing motivations - it seems I've generalized people into a few categories.

Please don't balk if they aren't 100% accurate, since everyone is different it is hard to generalize - but this shows the general trends I see of paths people follow when devleoping for the web.

Type A: Developers for Developers

The core of the coding world.  They have philosophical debates about code with each other.  From this group of people came all the programming languages ( C++, PHP, Java, Ruby, etc ). If they have any people skills at all you will see them leading conferences and in the lime-light.  Otherwise you can find them in password protected MIRC channels and in the deep dark caverns of corporations where no business person has ever step foot.

Type B: Developers for Client-Developers

They build plugins, frameworks and tools for themselves and fellow developers.  The focus is on developing bits of reusable code to accomplish client work more efficiently.  In the marketplace some are self-employeed, yet most of these people occupying full-time positions as team leads (or normal developers who exceed employer expectations). Their philisophical debates are found to be mostly around what are the best tools to use, but also on how to write the best code.  Community activity is high - as most have blogs, comment regularly on blogs and attend conferences.

Type C: Client-Developers

These developers use out-of-the-box software packages and slightly modifies them to get client work done. Their focus is on doing what the boss or client tells them for the day. May listen to podcasts, or participate in community lightly via blog comments or in-frequently posted to blog hosted at Blogger.com.  Will only attend a conference if it is local and 100% paid for.  In the marketplace you will find them working 40 hour weeks.  Prime motivating factor is family and job security.

Type D: Developers for Money

These people are hack'n'mash, "developers".  You will find them grabbing dreamweaver or any WYSWYG tool to, "make a million" via affiliate programs and any idea they can get their hands on to make money.  Visit their sites and see all types of ads - link ads, popup ads, pop-under ads (though some are finding smarter methods). Products are being sold because they understand the human condition and feed desire into a sale (conversion).

What type of devleoper are you? I am definitely type B.

I desperately need and am looking for a solid way to upload and attach photos to my web applications.  I have no problem coding uploading one at a time - that is simple - but what about uploading and managing multiple photos?  SWFUpload has been my uploader of choice, but I have found it to be fairly shaky at times. Is there something better than SWFUpload, or is it the best?

Please keep in mind that I use PHP as my server-side technology, if that matters.

I'm giving away $10 via PayPal to the best answer.

Update: I'm looking for any method to upload images to web applications.  This could be picasa, flickr, air application, normal forms with ajax ... whatever is easiest for people to get their pictures on web applications.  Even though your ideas may not work for every case, I (and the community) need to hear your ideas and any methods used for uploading images.

Update August 1: This is a broad question - and broad questions deserve broad answers.  If I need in-depth information about a specific analytics need, I will follow up with another question and reward.

I've used Mint, BLVD and Google Analytics - but I still want to know what the best software is for gathering data.

Please explain why the software is the best in as little as a few sentences, and as much as a few paragraphs.  I don't mind long answers if you want to take the time, but this is meant for myself and others to get a general flavor of what people think regarding analytics packages.

I tried to give $5 to Bernd for his thought-provoking answer, but he denied it.

Thanks for all your answers, the answers are now public.

Imagine how many user accounts you have. If you use Firefox to save your login information, go to preferences -> security -> show passwords... You will see a glimpse of how many user accounts you have on the internet - I have well over 200 accounts. With your personal accounts, usually a person has a set of a few passwords and probably won't have a hard time getting in. However, the companies we work for have a healthy set of logins as well, and are most likely poorly documented.

Document Company Passwords!

Please, take some time this week to document the passwords on behalf of your company. Show them this article, get some time in to do this. This is a simple thing that can really smooth things out for all of us. It is also a great thing to document is the contact for each system. Hosting accounts, routers, web accounts, email, etc should all be documented. It is a silly thing to waste time fetching passwords when you want to get something accomplished.

Open Id

On the note of user accounts, there is a system called Open ID that many of you either know of or are using. Open ID lets you tie your identity to a domain, allowing you to use your one user account across multiple websites. As of May 1st, 2008 myopenid.com reported that 13196 websites support the Open ID protocol. This means that if you have an open id account you no longer have to register with each of the 13,000+ websites.

Open ID is a ways from becoming a ubiquitous platform, but it certainly can help slim down that user account list. Until then, we are left in a sea of accounts and passwords where documentation is our best navigation.

As masters of semantic markup, front-end (HTML/CSS) coders can get downright anal when it comes to writing clean, search engine friendly code. Yes, you should always strive for quality and meaningful markup! But, I'm afraid that more and more people are wasting their time (in my opinion) for a bit less markup in their code.

Trust me, a couple of extra divs will not hurt anyone - I promise! I have wasted hundreds of hours re-coding and fixing bugs in IE6, Safari and Firefox when I could have saved that time with an extra div or two. Besides, I doubt you are going to see the fruit of your labor unless you are showing off to other developers.

Rounded Corners, the Front-End Developer's Black Hole

Designers love adding rounded corners everywhere these days. Unfortunately, rounded corners can be the death of a front-end developer if designers cannot design consistent templates (sometimes this is out of their control).

There are many projects I've seen and been on where the developer has to cut new sized rounded corner tops and bottoms of the same style, while making them work in all browsers - this takes a lot of time. Even worse, when the templates are handed off and implemented, many browser inconsistencies show up. This is a painful process to fix and make these types of boxes work cross-browser across all landscapes.

The development team has to spend countless hours fixing boxes with rounded corners and drop shadows - a black hole of time and energy to keep the markup clean and consistent. So how do we fix this?

Stop Wasting Time with a Few Extra Divs

At work, we have saved countless hours with a solution based on schillmania's rounded corners template. With 5 (or a few more) divs, we have saved all that time and frustration! With this solution we only have only one image, as opposed to 10 different box tops and bottoms of the same style.

Make sure you think about what is the best solution for your employer, their clients and your sanity. If you have an abundance of time than go ahead and strip those divs out of your code. But, if you want lightning fast results and want to become a very valuable front-end developer, pick your battles wisely and strive to make each keystroke more valuable. Clean markup is good, but fast and solid (semi-clean) markup that works in all browsers is almost always better.

Don't be fooled by, "the standard"

One more note of advice, don't implement "the standard" just because someone tells you to. Make sure you understand why it is the standard. I've seen people use css sprites because it is the proper thing to do, while they totally messed up executing the technique because they didn't have an understanding why it exists. They could have done much better with what they know.

Standard practices are difficult to master. You should only use them when you understand them. Get books like, "CSS Mastery":

Read a lot of books and articles online - research until your mind gets heavy. You will find out why standards exist and learn when it is appropriate and when it is simply a waste of time. Web standards and semantic markup are great, but please only implement them if you understand why you are doing it. You will save yourself and your employer a lot of trouble.

Don't feel so pressured by web standards. Standards are great, but learn them at a pace where you don't break things. Eventually you will become a respected ninja warrior, I mean HTML/CSS master.

Should you offer your website to those without JavaScript? - or should you simply require it to make sure your website works how you intended? Where do you draw the line in the sand between functionality and accessibility?

The Simple Answer

Do not require JavaScript in any public areas of your website.

If your website is public-facing, then you should not require JavaScript. It is bad for search engines and accessibility. The search engines will not be able to parse all of your website, leaving you with bad search rankings. And most obviously people without JavaScript turned on will not be able to view your hard work.

The non-public facing parts of your site varies. You may be able to tell ahead of time whether or not your administrators (non-public users) use JavaScript, which is usually the case. I think it is fine to require JavaScript for admin interfaces so long as they are not open to just anyone.

The Stark Reality

There are cases in which you simply cannot build websites to accommodate JavaScript on or off. This is life. Requiring JavaScript then boils down to three basic factors: requirements, timeline, and dedication.

Requirements

First, is a non-JavaScript of the website required? If not then you can't base your decision to build a non-JavaScript version based on the requirements. You then have to factor in the next two variables.

Timeline

Do you have time built into the project for building a non-JavaScript version of the website? If you aren't required to build your website without JavaScript, then what is the timeline like? Does it allow you to go the extra mile for your users? If you have the time on your hands, then it comes down to the last factor.

Dedication

Lastly, are you dedicated enough to develop that perfect website that works without requiring JavaScript? We front-end developers sometimes aren't dedicated enough to build a websites that gracefully degrade.

To be fair, there is usually not a lot of pressure on us to go this far with our work - so why do it? The client usually doesn't care and neither do your coworkers. Requiring JavaScript is a personal choice, but soon enough it won't be. You will be forced to develop websites that don't require JavaScript in the future, so why not learn now? Target was sued and soon enough businesses will realize that this is important.

One Final Note to Business Owners and Business Analysts

If you are a business owner or business analyst reading this, then please realize this: building websites that have great features and yet works without JavaScript can be a difficult task. Don't pressure web developers to do this without paying them the proper time and resources to accomplish the task. Time is valuable and money talks.

1. Create a solid foundation.

When you release a piece of code to the open source world, make sure it is commented and nicely formatted. I was under the impression that I would release a piece of code and people will just use it. Not so, they actually interact with your code and modify it to their needs. When you release code to the public, if you comment it well and make it easily extendable you will be amazed at how other developers augment it.

2. Treat your community well and watch your project grow.

Make sure you give users a platform to speak off of. I did this with comments on the demo page. In open source, the community you are a part of is the lifeline to a better project. If you respond to users and fellow developers, they will help you out a lot. jQuery calendar went from having a basic feature set, to having 25+ customizable options and 10+ languages. Could I have done that alone? No, and thats the beauty of open source. I can release something and if I have a solid foundation and a community to fuel it then it will grow.

3. If your code becomes popular, prepare for tons of bugs and feature requests.

At first, it was really cool to get any response at all on my code. I was instantly fixing, updating and supporting my users. After a few months the code became more and more popular. I eventually got overwhelmed with emails and comments. Now I could literally spend three full work weeks tracking down and catching up on the comments on my jQuery Calendar plugin alone. I decided I need to shut down my comments and direct all traffic to jQuery's bug tracking tool. At least now it will be categorized, organized and more efficient. I think comments were a really great starting point because people could make comments without having to register or go to a new location to comment. But at some point I need to have a life and that involves making things easier for me, the developer.

4. Test your code in browsers you don't care about.

Make sure your code is tested in Safari, IE6+, FireFox and Opera or else you will never hear the end of it. Maybe you don't care about one of those browsers but I guarantee someone will complain because they use it as their primary browser. Use something like Firebug Lite to debug your code in non-firefox browsers.

5. Don't expect money, you'll get paid in other ways.

I've talked to open source gurus and they don't get many donations, so you probably won't either. You will get paid in other ways. Sometimes you need to do things because you are passionate about it rather than expecting to get rich. There is more to life than being rich.

If you ever program in the Microsoft ASP.NET framework, you have to choose whether to program in VB.NET or C#. Recently I've had to work on a project where the client wanted a website in VB.NET because that is what their programmers knew how to maintain. Needless to say my experience with VB.NET has been painful, yet my experience with C# went just fine.

What was the difference? The community, answers and examples I found were all using C#. I couldn't find the proper VB.NET code or answer any time I looked. I ended up going line by line translating VB.NET to C# to figure out how to make it work. Jeff Atwood summed up my feelings with this excerpt from his article, C# and the Compilation Tax:

Most of the community has settled on C# as the de-facto standard, so you're in for a rough slog of code translation if you want to stick with VB and cleanly integrate commonly available source code libraries into your codebase. And if you want to understand the code you're absorbing into your application (note: this isn't really optional in my experience), you better learn how to read it without a bunch of mental translation gymnastics. And once you've learned how to read and write the language well enough to integrate it, you've come full circle. Like me, you'll be left wondering why you didn't just cut out the translation penalty entirely and stick with one language in the first place.

He points out exactly my frustration with VB.NET. The bulk of the community has settled on C# and if you want to do anything complex in VB.NET be prepared to translate C# code over to VB. So the moral of the story is stick with what people use the most - C#.