Showing blog entries 41-45 of 60.
There has been a change on google.co.uk. Their Suggest functionality has gone from lab to mainstream. So what is Google Suggest? Simply start typing in the search box and suggestions of relevant search terms will automatically display. The green number next to each suggested query represents the approximate number of results that would return if you select the query.
So what does this mean to us in terms of SEO?. I see this effecting long-tail keyword searches mainly, these are typically searches for 4-6 keywords in length, eg. print design high wycombe. Google is now helping the user make its search decisions and focuses the end user far more on highly competitive and short-tail key phrases.
We will be keeping a close eye on search terms and key phrases used for our clients to see the real impact of this change.
Whenever I start a new CSS build, I use a pre-made stylesheet and add to it, rather than create one from scratch. There are a few reasons for this:
- HTML elements have default browser-inherited properties: for example, unstyled text usually display as 16px times new roman.
- Different browsers may apply slightly different default values. In interner explorer, the h1 tag displays at 300% in relation to its parent element font-size, where as firefox displays at 200%.
- Re-declaring these values ensures all browsers are using the correct styles and are displaying uniformly and as intended.
Good practise for font-size declarations is to set the size in the body tag using em's or a percentage (not pixels), so a user can over-ride the values using the browser's 'increase text-size' functions. All other font-size declarations should then be made relative to this.
We want to have a font-size of 12px for the body text and h1 tags of 24px:
note: The browser's default font-size setting is 16px, so 75% amounts to 12px.
font-family: arial, helvetica, sans-serif;
There are other values and properties which require attention, most notably element margins of block elements, but the best way to find out what CSS works best for you is thorough mulit-browser testing and a passion for web design and self-improvement :)
Last night I went down to the student bar at BCUC (the Bucks uni) to check out 'idle hands', a team of street artists and illustrators - one of which is a friend, hence how I ended up there. The setup of the evening involved 6 guys tricking out some 8 x 4 canvases (well, white-washed MDF actually) as envious spectators drank and gawped at their work as it developed, and wow, was I impressed.
One of the artists especially impressed me, going by the name dirty thirty. Below is a picture of his board.
The event had a real positive and creative atmosphere, and I managed to have a chat with a few of the artists as they were working. It just shows what great talent is emerging locally, and I look forward to networking with idle hands more - and hopefully collaborating with them on projects in the not too distant future.
One of the most unenjoyable tasks I often have to undertake is the creation of forms - simple web-to-email forms. Therefore, I've decided to create a little wizard-like application to allow non-webbies to create them, so I don't have to. A few points to consider for anyone doing this are as follows:
- The PHP page which will process the form will need to be generic, and able to handle any input type thrown at it - a checkbox group is read as an array, where as radio button values are simply strings.
- The PHP proccessing page will need to recognise which fields are marked as required fields.
- If required fields are left blank, the PHP processing page will need to send the user back to the form, with values the user has already inputted preserved.
- Inputted values will run through a PHP regular expressions function which will allow only white-listed characters. This security measure will prevent form hi-jacking.
- The PHP processing page will need to verify it is receiving data from its own website. This is done by checking the $_SERVER['HTTP_REFERER'] variable.
- The recipients email address will be cross-referenced in a database table by a unique ID. This ID is what will be specified on the form page. This security measure means a hacker can't alter the recipient email address.
- The form will need to specify a redirect page the user will be sent to upon successful submission.
The creation of the form itself will be wizard-like - WYSIWYG almost, with the user specifying which type of input, its possible values, required fields, etc. Each form and its contents will be stored in a mySQL database table.
This will be a fun little mini-project for me to work on, and when its done it will either be attached onto Arena (our custom CMS) and/or sold here on our website!
I'm coming across more and more websites using this technique, buzzwordly-named IFR (Inman Flash Replacement)
IFR is displaying text through flash - dynamically feeding a text string into a SWF file, which in turn displays the string in a font style specified by the SWF. Doing this ensures text is always displayed in a smooth anti-aliased fashion, and allows for non-web fonts to be used on web pages.
The most desirable application of the IFR technique is for text in header tags (h1, h2, h3, etc), but these tags are very important to search engine spiders and contribute quite heavily to how the page is read, so replacing them with flash files is a big no-no. Search engine's don't read text within flash (or images for that matter).
- h1, h2, h3, etc. tags are set to display: none by default.
- The original text is then wrapped in a span tag.
- The h1, h2, h3, etc tags are set to display: block, and span tags within these tags are set to display: none;
Thats how I think I'd do it anyway... although setting h1 tags to display: none by default scares me a little, perhaps visibility: hidden would be better. There would also need to be flash detection at stage 2...
Example - http://www.yourstreet.com/ - Uses IFR quite extensively on the homepage, but select 'no styles' and you'll see the text as normal web text - readable to us and search engines.
Personally, I'm not too keen on this technique although I can see its purpose. I'd prefer to use PHP's GD library and the freetype library because I feel dynamic content should be handled and processed at the server, not the client. Doing this eliminates the need to test the client machine environment for flash, activeX, browser, etc...
Showing blog entries 41-45 of 60.