Since I'm thinking about developing a website for a friend's band, I was wondering what do you guys think the best practices for doing it are. How do you usually do it? Do you photoshop the entire layout before actually create the html, or you just start coding immidiatelly? Do you like php, or you prefer an alternative language? Maybe you use XML over HTML? Windows, Linux or BSD Based hosting? MySQL or any other database? Can you offer some good tips?
Thanks in advance.

I use XHTML coded directly on text. WYSIWYG is evil. I have the layout in my head.

CSS is also a wise choice.

People seem to rave too much about W3C compliance. I'm not that anal. If it looks good on FireFox, IE and Opera, it's good enough™ for me.

For database, I would personally prefer PostgreSQL, but since the vast majority of hosts offer MySQL only, I would go with MySQL anyway.

Linux and BSD based hosting are all fine. I think it depends more on the host keeping an eye on security patches than the choice of *nix.

Regards;

Roberto.

1. Creating a mockup layout beforehand is always a good thing. Whether this is at the level of a diagram on the back of a napkin, or a full blown graphical layout in photoshop -- something is better than nothing. This can give you a good idea about how well a lot of ideas in your head will work when the whole thing is pulled together into an interface. This really goes for any sort of development by the way. If you don't know what kind of problem you're trying to solve (in this case, what kind of layout you need), you're going to waste a lot of time and probably make a lot more mistakes trying to figure it out along the way.

2. Implementation language, as far as a backend for dynamic features go, should probably depend mostly on how you can deploy the website. If it's going to be a very simple site that will need to run on almost any run of the mill webserver, then PHP is an understandable, albeit regrettable choice. I tend to think PHP is one of the crappiest "languages" ever to be thought up as a bad idea by someone who was probably confused and rather angry at the world, but I digress... If you have a choice to use something else, it's worth looking in that direction. Python and Ruby can serve pretty well for this through various libraries and web platforms.

3. Any website being created in this point in time really should be done in at least XHTML 1.0 Transitional. If you're up to it, use the most modern specification that you can, such as XHTML 1.1, possibly looking toward targetting certain XHTML 2.0 stuff even. You should absolutely use structural layout and CSS, and not go for the whole WYSIWYG HTML 4.0 with inline formatting tags. It doesn't work very well anymore, it's harder to maintain and to upgrade your layout later on if you use it, and it tends to lead to designs that render well in one or two browsers but not so well in others. Try not to go for a pixel precise layout either, but use something that is flexible and can accomodate different resolutions and feature sets for a given browser. This isn't as hard as people often tend to think.

4. Database stuff depends on the implementation language/platform. If you go with PHP, a probably rather natural choice is to go with MySQL. If you use a different language or platform, it may be the case that they come with a different database or database-like backend.

Don't use Flash/Java for things that can be done without them. If your friends desperatelly want to make intro in Flahs, make sure there's clearly visible "skip it". If they desperetelly want Flash logo at the top of the page with background music, make sure there's clearly visible "mute it"

You really need to sketch out the site beforehand, so that you can work out what pages you need, and how they'll link to each other.

Once you know what pages you need you can work out the menu system - for really complex sites you will need to work out how to acheive subnavigation - but I'm guessing that this is not the case here.

I would recommend XHTML with separate stylesheet (CSS).

I would recommend putting the design template either into includes (we often use header.inc and footer.inc), or a function if you use dynamic pages (such as PHP or ASP). By doing so you can make changes to the design template in one place and it will be visible in all the pages immediately. We use functions so that decisions can be made about how to render the page automatically (i.e.: "if in subfolder "/contact" do this...", "if session variable X exists do this...").

If you don't need dynamic content then I would recommend SHTML so that you can still use includes. SHTML is just a file extension so that the server knows to process the page - you can still use (X)HTML as the doctype with CSS. Include files are very useful.

I use ASP(X) with SQL Server because that's what my employer chooses - but I really would like to use PHP and MySQL. The hosting options are loads cheaper for PHP/MySQL, and there's more built in functionality (with ASP you need to utlise COM objects for file uploading, image resizing, etc.). Basically though if you are a VB person ASP will be easiest, if you are a Java(script)/C(++) person PHP will be easiest.

Using pre-processing such as PHP and ASP is very, very, useful, even for simple things like adapting navigation according to the page, or using functions to take the labour out of building new pages. I would expect that you could find PHP code or full systems (like Invision Power Board!) to do most things that you would need.

That said, I doubt your site is going to be huge and therefore will never be overwhelming to manage. If you don't need dynamic functionality or a database backend then don't bother. I would still recommend SHTML* but even that is not a big deal if you only have 10 pages.

NB: we do go for W3C/WAI compliance, but Roberto makes sense. It is good practise to use the TITLE tag on links, use ALT on images, etc. though.

* Your webspace provider may allow PHP at no extra cost - in which case you could just utilise the include functionality within PHP - i.e.: have PHP pages but only so that you can include the design from include files, e.g.:

Excellent suggestions, thank you.
About the static/dynamic questions, I'll definatelly choose a dynamic language. I'll probably give a few ones a try to make my mind, since I'll have to learn them (almost) from scratch and it'll probably be a time consuming task. I don't really wanna waste time learning an outdated flawed language. From my experience as a user, I get frustated everytime I need to go to an .ASP or .JSP website. ASP almost always is usable in IE only. Might be a coincidence, or something at the language level, but it's very frequent. On the other hand, with JSP (and I'm guessing these ones are java), I always have the feel the website is slow and bloated. So I'd say from my experience as a user, these two are to be avoided, although I don't really know what I'm talking about from a technical point of view.
PHP has always been nice to me, and given the numbers of hosts that offer php it may be the standard choice. However, I don't want rush my decision based on this, and after reading Dibrom's rant on php I'll consider the alternatives, mostly because I've already been playing around with Python and it's pretty cool and easy to get started. What's so wrong with php so that you refer it as a "language"?
About the layout, I'm gonna try and sketch it in Krita or GIMP, so I don't have to purchase any software. I'm guessing this will be the most difficult part cause I've never used an image editor for such a complex task. The includes Synthetic Soul suggested look like an intelligent way of doing things, and I'll try to use that scheme.
I don't really have an oppinion on databases, and since you guys don't seem to give it much importance I'll probably use whatever is available, which will probably be MySQL. I've read some opinions from users elsewhere who said "PostgreSQL is tEh BOMB!", although they generally admit MySQL is faster. I'll also be experiencing XHTML+CSS for the first time, and don't really know what to expect.

Edit: And by the way, what would be the linux alternative for dreamweaver, if any?

Edit2: Cool, just found Nvu. I guess i'm goona give it a try.

As I say, I think PHP may be a better solution for you - but I must clear this up.

Whether you use PHP or ASP the output can be identical. It doesn't matter what server-side language is used. I.e.: the server-side language is totally independant/irrelevant to the response that is receiveed by the browser.

This is not the same for ASPX.

Your experience may be based on software houses that are only interested in Microsoft, and therefore only test on IE. Don't know.

Good luck in your venture.

Very good advice that perfectly makes sense!


One would think that a commercially available program would be tested in most popular browsers, however what you've stated is a valid point. I've seen far too many times when a site doesn't work properly using "third-party" browsers such as Mozilla Suite/Netscape and Opera, which of course forces a site visitor to use MSIE.

At one point IE has a massive share of the browser market, after Netscape fell and before Firefox came out.

There's always lazy developers who figure that they can afford to lose 10% of the market for an easy life.

Edit: These stats may not be a good representation of general users*, but the increase in Mozilla users is interesting (though unsurprising) to see.

* General users are more likely to use IE as it comes with the PC, so I would expect to see IE's % around 90% for bbc.co.uk, disney.com, etc. in 2003/4.

Minor (but IMHO useful) info:

Instead of going with a full-blown CMS, for small sites (small as in "less than 30 pages"), you can also just package the layout into PHP-functions. I.e. a function which just prints out the pagehead, a function which prints a content-header(including optional parameters), a function which prints a content-section, etc. etc.

That way, you don't need to go with the full buerocracy of a CMS, yet still can have content, layout and design in seperate files. For large projects, a real CMS may be better, but for smaller projects, this approach is much more efficient.

As for browsers: this currently heavily depends on continent - in the US and asia IE still holds an iron grip on the market, while in europe non-IE browsers have a share of up to 20%(in germany).

I could probably write pages on this, but I'll try to summarize.

1. The single biggest reason is that the language is poorly designed from the get go. It has all the marks of being a toy language that has been extended in a kludge-like fashion over time, but without any serious thought going into long term design.

2. It has no formal semantic. This isn't always necessary for a powerful language (c and c++ didn't have one either), but it is usually necessary for a powerful, well-designed language that is easy to understand and to extend in a clean fashion (witness the ugliness of C++ mandated by adhering to previous C syntax, when C wasn't really designed for the type of things C++ does).

3. The syntax is overly verbose and often superfluous. Part of this comes from copying some of C's inferior syntax, and part of it comes from just adding more unnecessary stuff on top of that. Stuff like prefixing variables with $ is totally unnecessary, and is just one of many examples. In a language like Perl, where symbolic prefixes actually mean something, it's one thing, but in PHP it just reflects poor design once again.

4. Related to 3, PHP is pretty horribly inexpressive. There's very little in the way of syntactic sugar, and there's little support for functional programming. You have a few basic things like map, filter, and reduce defined for arrays, and a really ugly and hackish anonymous function facility (string based, rather than code based!), but they're setup in such a way that they wouldn't be very useful for anything really advanced. Beyond that, it doesn't have closures, currying, pattern matching, array/list comprehension, laziness, etc. This isn't even to mention other much more advanced features that most modern advanced languages might feature such as higher-order parametric polymorphism with quantified types, type classes, monads, arrows, uniqueness typing, implicit parameters, continuations, concurrency, lazy streams, constraints, etc., etc., etc.

5. Not scalable. PHP only recently even got OOP AFAIU. And on top of that, it's support for classes is very weak (not to mention quite slow) compared to something actually useful like in C++. OOP is by far not the only way (and possibly not the best even) to handle scalability, but what other non-OOP languages use to deal with this problem, PHP does not have either.

6. No metaprogramming. Nothing like C++ templates, LISP or Scheme Macros, or templates in Haskell, etc. This is a real shame because for the kinds of tasks PHP is used for, metaprogramming can tremendously cut down on boilerplate code, as well as improving efficiency, reducing errors, and improving maintainability.

7. Poorly designed integration with webpage content. PHP's cut and paste style integration with web pages might have been a good idea years ago when non-standard HTML code abounded and people weren't concerned so much with structural validity of code, or the ease of maintenance of such code and integration of it with other tools, but that is no longer true today. Something like Zope's Page Templates, which allow integration of python code into completely valid XML, is a much more elegant solution. Not only does it make page maintenance way easy, and allows for separation of concerns, but it also allows people to use the same tools for dynamic pages that they use for static pages. Yes, there is a sort of Page Template implementation in the 3rd party PHPTAL library, which basically copies the syntax and semantics of the Zope version, but since PHP was not built with this style of implementation in mind, it's a lot more limited than what you can get with Zope and Python.

8. Relatively weak development tools and environment. Due to the nature of the language, and the lack of a coherent runtime environment like you get with many alternatives to PHP, PHP just isn't very strong on this front. A lot of this has to do with the fact that PHP has no real non-webpage centric basis. Maybe there's something really good out there that I don't know about, but I've certainly never seen anything free or fairly cheap that is nearly as powerful as the tools I use for any other of the dozen or so languages I program with.

9. Slow. PHP just isn't very fast compared to most real languages. I don't think there's much else to say there.

I could go on, but that's probably enough. PHP is OK as a toy-like scripting language for very small projects that have no need for anything advanced whatsoever. But this doesn't really mean much insofar as making it a complete and powerful programming language. Sure, maybe it's Turing complete, but then so are Brainfuck and Unlambda.