seige

Please, please please try and use the fonts given as 'standard'. There's only any real need to style headers, but the tricks used are a bit 'hacky' and still the nicest designs for web pages need to respect simple markup etc. There's some quite nice display styles available 'out of the box'... Georgia is a beautiful header serif font, and Impact makes a total contrast for 'newspaper' style headlines.

Sometimes, one has to respect that the web is becoming more and more 'accessible', and at some point aesthetics have to go out of the window. In this case, there's another trick which is to change focus using Javascript of the current element. If I find the snippet, I'll add more info!

So many toys, so little time ...

Am I right in thinking this is a kind of pseudo-screensaver?

It's not fair to 'slate' wordpress for being a single-blog machine... have you not seen WordpressMU ??? I think the price for EE would be a charge-on, so it's not really an issue.

I've been following the progress of this, and I must say that it looks set to be high on my list of 2008 'must-do'. As stated, the documentation and support are outstanding.

Go get XAJAX. PHP and JS start talking interactively. The important distinctions to make: 1. PHP is parsed and written SERVER SIDE 2. JS is parsed and used CLIENT SIDE XAJAX bridges the gap (as does AJAX), and is a great framework.

We had a client requiring this facility, and used Amazon's service (the one used to thumbnail sites in Alexa.com). Try: http://www.amazon.com/gp/browse.html?node=236156011

Don't make errors Nah, seriously, set up a test folder and leave the live site alone until the test site works. Otherwise, if a search engine or client chooses *that* moment to view, they will get gobbledeguk. You *can* suppress errors, but the easiest way is to test separately.

Spot on advice for above. CSS 'floats' will go to the screen edge if an enclosing outer div isn't specified. By creating an outer DIV with width but no height specified and the 'inherit' property used, it can be invisible, but is then set to 'hold' your floating elements. Designing with pure CSS is tricky if you're not accustomed to it. But generally, think of it like old-school 'tables', and apply the logic similarly, i.e. a TABLE contains CELLS, and each CELL is governed by the bounds of the TABLE. CSS is similar in that each DIV can be controlled by the DIV which surrounds it. Nesting elements inside a container is the only real way (without using specific absolute measurements) that you can control your layout. Always start by mapping your design out on paper or in a graphics app such as Photoshop, and then work out the positioning. It's a long, hard task if you try to do it blind, unless you are fluent!

What PHP version are you using? Foreach has been around since version 4. You may be able to subsitute a "while/each" loop for the foreach.

Serialzing data for MYSQL is great. We use this method for forms. Here's how you can get your data out... I'll comment it so you know what is going on... $query="SELECT * FROM colours"; // change the 'colours' to the table you have your array in $result=mysql_query($query); // perform the query $numrows=mysql_num_rows($result); // count how many results returned... if($numrows>0) // and if there's anything in the table, process it { while($colours_list=mysql_fetch_array($result)) // This loop checks for multiple sets of colours { $colours_set=unserialize($colours_list['colours']); // Unserailize the 'set' of colours foreach($colours_set as $single_colour) // This loop sorts one at a time each colour from the unserialized array { print $single_colour.', '; // prints the colour name, followed by a comma. } // end of 'for each' loop } // end of 'while' loop } // end of 'if numrows>0' loop if it's true else { print 'That table's empty!'; // Display a message that the table is empty } // end of 'if numrows>0' loop if it was false Hope that makes sense!

Depending on your server setup, most packages come with a CGI bin and a load of useful script. Alas, many don't support PHP. However, there's usually a FORMMAIL script in the CGI bin from Matts Scripts archive. Let us know more about your server details, and we'll guide you best. PHP is simple and quick, but CGI works perfectly well too. Also, it's more than possible to get a simple form sent via mailto, although there's no 'field required' control. But it makes sending a form simple, and sends literally a copy of all the form fields to email. That's 3 options so far available. But you *do* need to let us know what scripting is available to help any further.

You need to be very careful with statistics. RESOLUTION doesn't mean the page width... it means the display width. Subtract toolbars, navbars, scroll bars and the likes, and you'll realise that aiming for 1024 resolution means that ideally your site PAGE WIDTH should be around 800-900 pixels wide. Ergo, RESOLUTION does NOT equal visible page area. Now—also consider that most folk don't even REALISE they can change resolution from the usually default 800x600... and you start to realise that resolution needs a bit more thought than just 'averaging the population's settings'. Go carefully

There's a little room for improvement, but they're not all THAT bad... (hang on, need to put glasses on...)

Hey, I didn't mean to come across 'too strong' but, there's no point patronising people

1. 'design' is a term you're abusing... it's a skill, not a 'given' 2. Frontpage ain't going to do you any favours... learn some basic HTML first 3. We can't even see the site you mention, so we're not able to comment 4. See point 1... it's THAT important 5. See point 4. Being able to 'design' is something you are gifted with, or have learned. You should use the term 'build' 6. Liquid layouts/testing at various resolutions is a pre-requisite of the 'design' process. Learn the basics before attempting to even START to build a page/site 7. In continuation from 6... ALWAYS work out the content as a pencil/paper sketch first, before applying to page. Then work to a resolution that's currently common, such as 1024x768, and bear in mind the desire of the public to add toolbars, gizmos and gimmicks to their browser... pretty soon you'll realise that YOUR desktop real-estate doesn't equal the available space used by the masses. 8. TRY AND UNDERSTAND that not everyone has a 22" widescreen display. Lots and lots of people browse the web on 15" laptops.

Here's the advice you may find useful... 1. Make sure your document 'image size' is showing the image as being 72ppi 2. NEVER scale images in your browser... make them the correct size BEFORE export 3. A PNG file has no compression options, but making them the CORRECT SIZE (both dimensionally and resolution) will ensure that only the image which needs displaying is loaded. If you, for instance, have a 1200x1200 PNG file in PS, and scale it to 300x300px on the page layout, the browser is STILL LOADING the 1200x1200 file to re-scale it. 4. Determine which file type suits the image best: solid colours or just text is better saved as an optimised GIF, wheras pictures or graphics save better as a JPG or PNG. 5. Try and use the 'Save for Web' command in Photoshop, and keep an eye on the 'filesize' area. This will tell you how big the final image is going to be. For instance, an 850px x 120px top header will ideally be less than 70kb. Anything bigger is just crazy.

As a ballpark, we usually quote 2 hours per-client for mainenance on non-CMS, static sites. Breaking it down for them allows them to see what/why it's important... 1. Backup of site, database and user settings This is done automatically, as a cron job on our servers. We do a 3 day rotational backup for every client. 2. Checking for dead links, out of date items This is done once a month, by hand, and involves trawling the site for known pages containing links or chronologically dependent data 3. Minor amends If the client has nips and tucks, such as word changes etc. which fall into a 'five minute job' category, these are inclusive What ISN'T included, and is charged extra... 1. Updates and new pages 2. Adding features or facilities We also make a separate charge for optimisation and SEO, and ANOTHER separate charge for 'human friendly' stats reports. We write the stats reports by hand, and they are based on not only the server stats, but a comparison on the previous month's performance and general trend. The report also includes search engine performance vs. the previous months for the given keywords a client wants to target. This alone can take 2-3 hours, and is therefore a separate charge entirely. Once a client sees the benefits of reports, backups etc. they get used to the monthly charge, and find great pleasure in seeing how well their site is performing. But make sure it's charged for!

As with most scripts, you can make it as accessibility-compliant or not, depending on use. Because it's JS based, any changes to elements are *not* seen in the source code, therefore it is wise to populate elements in the body, and only *change* them when required. This can also cause havoc if the browser back button is used! Another caveat is when writing for assistive technologies in mind, such as braille readers etc. As with all these things, it's a good thing to write your pages *without* bells and whistles and make sure they are as compliant as you want them... THEN determine how to make them all-singing, all-dancing, and remain as compliant as possible. XAJAX is unfortunately no more accessibility friendly than any DOM scripting exercise, so you need to 'design' your pages very well to enable them to be universal.

Just a quick heads-up to anyone interested in really simple AJAX... Search Google for 'xajax'. We started a couple of projects using it last year, and it has made a WHOLE HEAP of lovliness possible, including an interactive Google Maps interface for a client of ours. Not much brainwork either... very simple constructs... imagine being able to have one single page loaded in a browser, and let client side/server side scripts interact to manipulate data on-the-page? For instance, having the results of a page form DYNAMICALLY call from a database and insert the result into the page, without a submit, without a reload? Yep... this is AJAX folks. Being using the AJAX power for a while, but XAJAX really has sped up development here. One great usage we're currently developing with XAJAX is a shopping cart system which allows the shopping cart to auto-update on the page, on the fly, when selections/options are made. Even the shipping charge is calculated on the fly. All this is done without a submit, without a reload. Sounds simple? Well, yeah... the *effect* is simple, but the actual speed which this is achieved is breathtaking. Havent' had so much fun since I coded my first game on the ZX81

Dizi has hit the nail on the head... For an obscure reason known only to webbies since the dawn of netdom, there's a 'border' attribute which defaults at an ugly blue line in Explorer when an image is made into a link (href). What seems to be happening is the tables/cells are restricted to the size of the images. By making an image a link, the border attribute kicks in and throws the whole thing into disarray. There's no reason you'd want to have a border on an image for style purposes when used as a link, so use the css Dizi recommends to 'catch-all' remove it. Another thing to watch is that your ready-coded import to dreamweaver doesn't have lots of ugly 'td width=' and 'td height=' tags. It's very good practice to go through the auto-generated code and try to move everything you can to CSS, and avoid inline styles wherever possible... this makes the overall semantics compliant, plus has the advantage of giving you control from a single CSS sheet—one less butt to kick when things go wrong. The problem you're having used to be what we called 'the curse of ImageReady Slices'... and you'll find as time goes on that sure, it's a quick way to get a PS file sliced up into HTML... but it has TOO MANY flaws for real-world use. And don't get me started on over-coded ImageReady rollover exports... yeuch!

Glad to see someone finally touching on typography... I'm pig sick of seeing bad use of letterforms and typestyles! I started my career in design when Letraset and Linotype were still being used, and boy did that teach you some valuable lessons about typography! In fact, I do believe typography was a part of my coursework way back in the day!

REMEMBER: some browsers/users have JS disabled, so you need a totally compliant form in order to make sure it works with non-JS browsers. Always do a quick test with JS switched OFF in order to make the form work for all! My own practice is to make the form work properly first with all browsers, then slip back to it and tweak it for 'gadgets', leaving a fully functioning version available for those people who love to mess with their browser settings

The 'html.' and 'html body' hack for IE browsers is invaluable. Another point to note whilst testing recently is control over forms... when in a space/design crucial layout, try assigning a monospace font for form fields etc. You'll find things MUCH nicer, and IE complies with the length setting of simple text and password fields a lot better too.