So you want to be a web developer?

[tiggerai]

I've been asked a few times by people asking how to go about being a web developer. So here goes!

1, Languages. What are the best languages to learn?

To be a web developer, either an Interfacer (as I am, making things pretty) or an application developer (making things work) you need to have a good grasp on how HTML and CSS works.
"OLD" HTML has gone through a lot of changes over the last few years. Brush up on your xHTML and external, inline and embedded CSS. W3Schools Online Web Tutorials is a very good reference site.

After you've mastered that, then move onto making your pages funky and "doing stuff" with Javascript. I've recently got really into this, as AJAX is taking off massively. Check out some of the Javascript libraries that make funky stuff easy, such as script.aculo.us, JQuery and Adobe Flex (I think)

2. Standards. Read up on your standards. The W3C guidelines for accessbility are imperative, ensuring that your website is accessible to as many people as possible. The RNIB web centre is a good read.

3. Layouts. If you're still using tables to lay out your sites, then please please consider using DIVs and tableless layouts. Tables bloat your code and are a nightmare to style with CSS.

So that's a start, I'll add some more at some point

[aidanjt]

*cough*noframes*cough*

Good summery though. Another point is looking at server side scripting techniques, as they often go hand in hand with AJAX, or otherwise make websites extraordinarily powerful.

[Vini]

Can I just add...

"Don't expect it to be easy"

I get people at work asking me to teach them how to 'do websites'... As far as I'm aware making website's is not something that can be taught/learnt in a few hours. It's taken me what, about 10 years, to be able to even grasp the basics.

Whilst I don't do it everyday, I don't believe you can just inherit the ability to create complex websites in just a few months, unless you're technically minded (which colleagues that ask, simply aren't)

[tiggerai]

Can I just add...

"Don't expect it to be easy"

I get people at work asking me to teach them how to 'do websites'... As far as I'm aware making website's is not something that can be taught/learnt in a few hours. It's taken me what, about 10 years, to be able to even grasp the basics.

Whilst I don't do it everyday, I don't believe you can just inherit the ability to create complex websites in just a few months, unless you're technically minded (which colleagues that ask, simply aren't)

Both good points above...

Before tables there were frames... they're horrible and non-accessible.

and no, it's not easy. I've been doing this 5 years and there is still stuff I'm finding out every day!

AND don't start mastering the server side things (ASP, PHP AJAX etc) without having a VERY GOOD GROUNDING in the basics. And I mean being able to code a page from scratch, in notepad++ or dreamweaver.

People who "do websites" but then you find that they have used a dreamweaver template really let the side down. Heck, even my mum can do that.

Code a site from scratch including CSS and I'll be impressed.

[Disturbedguy]

Good points tigs and thanks again.

I prefer coding by hand if I have the time, it allows more freedom and imo..makes me feel better knowing i've done it by hand.

[aidanjt]

Vim ftw!.. Yeah, there's a lot to be said about hand coding, *especially* in the case of server-side, very often 'wysiwyg' editors like dreamweaver which automatically inject SSI code into pages, the framework is beyond awful, and when you come back to updating/fixing things you end up dumping the lot and starting from scratch because there's no actual coding design thought out ahead. In production, the only real use dreamweaver has is rapid prototyping of sites.

[Saracen]

.....

People who "do websites" but then you find that they have used a dreamweaver template really let the side down. Heck, even my mum can do that.

I don't disagree with anything you've said, but I would present a perspective on that.

That perspective is ..... it depends what the customer wants. If they want an all-singing website using the latest technology, then you're dead-on.

But .... what about the local running group that wants a quick website, a small number of static pages? And they want it by Wednesday.

Or I'll give another example. I know of a company that wanted a private website for staff use ONLY. I don't just mean it wasn't intended for the public, I mean it HAD to have means of keeping anyone other than staff out. So it needs password entry. Then, it needed about a dozen different levels of access. Some people could see everything, others could see very restricted amounts, and then there were half a dozen areas that groups of people needed access to, but access varied widely - and some of them needed read-only access, but some needed read-write to add content.

Oh, and it needed the ability to distribute company confidential documents to all staff. And there was a Health & Safety section, and a section for contract discussions with commercial managers. And a section for board meeting minutes. And so on.

Now, someone could have sat down, coded that from scratch and spend months doing it. And what would that have cost?

I installed vBulletin. It took longer discussing and agreeing things like user access levels, who can see and do what, etc, than it did to install. Oh, and I tweaked a few templates for one or two particular needs.

Do I "do" websites? Depends what's needed. I'm sure as hell not any form of web developer, though. But .... if need be, I can cobble together something that does the job IF that matches what the customer wants and needs, perhaps by using or adapting a template, or by using existing tools like vBulletin and a bit of lateral thinking. So I'll "do" websites, if the needs are right. There's a lot of jobs I personally wouldn't even consider attempting, though.

My point .... sometimes the quick and cheap method is all that's needed .... or wanted.

[Stoo]

Some days I do ask the question of myself

Oh, and coding websites for mates etc is a *very* different beast to large scale commercial websites, especially when you get stuck in all the corporate politics..

[aidanjt]

I don't disagree with anything you've said, but I would present a perspective on that.

That perspective is ..... <snip>

Absolutely, the other part of being any kind of commercial developer, web or no, is recognizing when a set of off-the-shelf components will do the same job.

[TheAnimus]

the problem with server side technology is people seam to have a religious belonging to one technology. In saracen's case he used a commercial project, but at &#163;85 its hardly a concern, yet there are many (nuke for instance) free projects which are more designed to the sectioned intranet.

I've never been impressed with the vast, vast, vast majority of backend web devs, purely because they only know one tool, and assume it to be best, defending with ignorance. Pearl programmers did this against PHP, PHP does this against Ruby. Rails and non Rails people do the same. Then throw in ASP people. And worst of all LAMP advocates.

I lay the blame for this fully with far too many polys's and 6th forms churning out "web courses" which cover none of the basics of programming languages, as such people get trained, rather than educated, and settle on one technology. This is bad because it means they get left behind with the new developements.

An easy example of this is two similar juinor dev roles, one of my friends does this in manchester for &#163;18k, Ruby on Rails shop. Another does this in London on &#163;40k in practically everything m0n0rail, php, asp.Net. Location rates asside, the main difference is one is multi skilled, and when says "this is a good cost effective way of doing it" its a rounded opion, and actually worth something. Vrs the always picking what they know.

I die a little inside when someone always recomends something, just because they know it, even thou its grossly in-appropreate, knowing that often the time for them to train in the appropreate tech would be minimal.

[Saracen]

the problem with server side technology is people seam to have a religious belonging to one technology. In saracen's case he used a commercial project, but at £85 its hardly a concern, yet there are many (nuke for instance) free projects which are more designed to the sectioned intranet.

Absolutely right. The reason I picked vBulletin is largely that I know it well, and already had a licence I could use to slap up a demo. That company MD was very impressed when I showed him a mockup of my proposed solution a few hours after he outlined the problem.

Sure, there are other (free) solutions. But the cost of the licence was negligible, and the increased cost of my time using a less familiar product for what, really, was a modestly priced job, would not have been. When put against time costs, £385 doesn't go far.

Besides, I was going to be running the system on an on-going basis, and familiarity with vBulletin paid back me and the company even more then, since I can do most things I need to do with vBulletin in my sleep.

[tiggerai]

But .... what about the local running group that wants a quick website, a small number of static pages? And they want it by Wednesday.

My point being that it should still be accessible, written to standard and designed well.

You can't do this without having a good understanding of what you're doing and how things work. Heck I can churn that kinda thing out in 4 hours, but just because someone wants it done quickly doesn't mean you should scrimp on quality AND especially usabiliy and accessibility.

And to be honest, I haven't written this for those of you who do this as a "hobby" I'm writing this for people who DO want to make a career out of it.

And yes, by all means, use and adapt templates (it's exactly what I do, apart from they're usually templates written by me) as why invent the wheel?

And the quick and cheap method you describe is usually the one where it's been done properly by someone who knows what they're doing... otherwise it'll only cost more money down the line. Swings and Roundabouts.

I find that flexibility is the name of the game, don't always stick to the same framework as Animus says. I've dabbled in ASP, JAVA, ORACLE, .NET, PHP (joomla, Mambo, CMSMS) and all sorts of other things (about to have a look at Rails at some point), and I find this beneficial as it makes it a lot easier to pick things up on the fly. And yes, being multi-skilled is the name of the game. I've recenly been playing about with flash and actionscript, which is something that I hadn't done before, but I gave it a go anyway.

This thread was personal opinion from my experiences as a commercial web developer, to give those wanting to get into web development an idea of what's involved. I have had PM's on the subject so thought I would expand it for the benefit of the community.
I wasn't really talking about the small scale hobbyists. It didn't really need a perspective, but thanks for yours all the same Saracen.

[yamangman]

You can't do this without having a good understanding of what you're doing and how things work. Heck I can churn that kinda thing out in 4 hours, but just because someone wants it done quickly doesn't mean you should scrimp on quality AND especially usabiliy and accessibility.

I agree to some extent with this also. I would also consider ease of modification as a factor. Small sites do grow.

[Saracen]

.....

This thread was personal opinion from my experiences as a commercial web developer, to give those wanting to get into web development an idea of what's involved. I have had PM's on the subject so thought I would expand it for the benefit of the community.
I wasn't really talking about the small scale hobbyists. It didn't really need a perspective, but thanks for yours all the same Saracen.

I understand that, which is why I said I didn't disagree with anything you'd said.

The perspective is that while it's right and proper to have standards compliance, a pure design ethos and accessibility as laudable objectives, that ALL has to be tempered by the practicality of what the client wants.

As an example, there are other things that a company ought to be considering in relation to what it commissions for it's website, such as the requirements of the Companies Acts. Those requirements aren't about good design practice, or about expandability (as yamangman mentioned), or which technology to use, but mandatory legal requirements the ignoring of which could land the company in court and acquire them a fine.

Yet there was one occasion where I pointed out those requirements to a company that had commissioned a small website, and provided the exact text, page by page, they wanted on it. Their response to my pointing out they'd be committing an offence by ignoring those requirements was to ask me if I knew how many offences a company could be committing (I did), and to point out that if they worried about every one of those possible offences, they'd spend so much time worrying about the law that they wouldn't have a business. So will I please just do as I've been asked and produce what I'm told?

The point - it's all very well have high ideals about what to do and how you want to do it, as a commercial designer. But listen to what the client wants you to do, too. And I don't mean you personally, but the people you're aiming this thread at. If they want to be successful at this, then the pragmatics of listening to the client is crucial, and supersedes showing off their technical or design skills.

I don't design websites for a living, though as I said, I've knocked up a few. But I've been involved in commissioning some, and other IT projects, and it's astonishing how often enthusiastic young IT pro's are so enthusiastic about the fact that they can do this or that with technology that they lose sight of the client's wishes. And that's a good way to lose clients. That's the perspective I mentioned - bear in mind the designer needs to produce what the client wants, not what the designer would like to do. Because if one designer/developer doesn't give the client what he wants, there's another out there that will.

Use the tips you've given by all means. They're all very good practice. But keep it firmly in line with client requirements. And if that means a cheap and cheerful job because that's what he wants, there's no point designing him a Rolls Royce version. And sometimes, that is all he wants.

[aidanjt]

I agree with what you're trying to say Saracen, 90&#37; of the time a client will come to you with only basic requirements. But, and there is a but, 50% or more of the time they'll come back in a month or two asking for more features or pages to be added.

Now the good thing is most web dev shops often have their own framework/library that they have already developed and actively maintain, and use it as a template which nearly automatically gives them a website, that almost resembles a content management system, and they only need to fill in the blanks to fulfill the clients requirements, and they have a central base of code that is applicable to all their clients, so when a problem is found, it's easy to apply to all their clients sites. This way they avoid the headache of working around feature creeps in a design that wasn't extendable or realistically maintainable because it was a fast/cheap solution, and at the same time it'll help them stay on schedule and budget during development of the production system.

[Saracen]

I agree with what you're trying to say Saracen, 90% of the time a client will come to you with only basic requirements. But, and there is a but, 50% or more of the time they'll come back in a month or two asking for more features or pages to be added.

Oh, yes.

Two types of client from hell :-

1) Knows exactly what he wants, down to the last dot and comma (but usually can't explain it or specify it coherently).

2) Hasn't a clue what he wants, but will moan like he if you don't deliver it exactly.



Dealing successfully with either can be an art form.

And your second point is why I, personally, work to a written spec, with a quote that details what additional work will cost.