Actually the analogy above doesn’t really work because I want to talk about the responsibility of hosting rather than choosing a supplier. Hosting is one of those awkward requirements of the web industry that doesn’t get the attention it needs. It’s a necessity, without web-hosting we wouldn’t be able to put our websites online, every website has to be hosted somewhere. It’s an incredibly important aspect of our industry and if you are involved in the creation and deployment of web media, you should have a strategy in place to deal with it.

The problem is, it’s an area with a few potholes. Often a client will have absolutely no idea of what hosting is or why they need it. This is fine and understandable, I wouldn’t expect them to any more than a plumber would expect me to know what sort of valve connects my boiler to my water supply. We could just include the hosting costs along with any other build and support costs, but, I believe that a greater degree of transparency is required. With hosting (and certain other support requiring services) identification of responsibility must be clarified up front.

There are sometimes issues with hosting, sometimes minor problems, sometimes major outages. This is where you need to have identified clearly to your client what hosting is, where your responsibilities lie with regards their hosting and ensured that their expectations with regards level of service are reasonable. Without these concepts clearly agreed between you and the client, things have the opportunity to get pretty messy.

Reseller Accounts

A nice simple solution is to set yourself up a reseller account with a hosting company, that way you can supply hosting neatly bundled up with your branding. All lovely if you have the resources to manage this properly. Depending on your supplier’s set up you may have to deal with every support request from your clients and in some cases handle assorted administration tasks as well. I’m uncomfortable working on this basis, with the best will in the world, no amount of small print T&Cs are going to convince an irate client that their hosting going down is outside of our control if their control panel comes with our branding.

Client Managed Hosting

Handing the responsibility for their hosting back to the client can be considered. Yes, there’s the positive that you won’t have to deal with support calls, it’s up to the client to sort out the billing and, worst case scenario if everything falls over it’s someone else’s problem. The cons far outweigh the pros. Primarily it’s just unprofessional, I like to think a client can come to us for a web solution and we can make the process as simple as feasibly possible for them. Sending them off to set up an account they may have not even been expecting to require is just going to make the process frustrating. There are some technically savvy clients out there but the majority are not (and nor should they need to be). Realistically you are going to either spend half your life detailing what sort of package they need to purchase, or trying to work with a hosting package that’s not quite fit for purpose. The issue I have run into most with this approach in the past is that hosting companies tend not to have the flexible billing practices of a freelancer or agency (for understandable reasons) and often a client will just forget to pay their hosting, at which point their website ceases to exist (worse still with domain names).

My Approach

With Shinytastic, by default we organise the hosting for the client and try to be as transparent as possible. We make clear that our responsibility is to ensure the hosting account is paid up to date and continues to exist, but the responsibility for the servers themselves lie with the actual hosting company. We always tell the client who the hosting company is and give them a copy of any sign up emails, agreements, logins or anything relevant to their account for their own records. We do add a markup to any hosting we purchase to cover administration costs, but we make the client aware of this and will give them the costs of setting up the account directly themselves should they wish to. I believe we’ve only ever had one client opt to purchase the hosting themselves, most are happy to not have to deal with it.

We do give clients the option to choose their own hosting company if they prefer, although there are certain hosts (who I shall not name) who if the client wishes to use we will insist they purchase the account directly and indicate that they understand they are opting for a ‘cheap’ solution which may cause problems down the line. We have run into problems in the past when a client has opted for the cheapest hosting solution they can find, which has caused us substantial additional work.

The hosting company (EvoHosting) we use are set up such that we can purchase multiple hosting accounts under a single client account. This massively simplifies the management of multiple hosting accounts without resorting to a reseller account. This is also set up so that should a client decide to part company with us, we can quickly release their hosting account to another agency preventing them needing to set up new hosting to move away. We don’t hold accounts hostage and do not charge a release fee, the only stipulation we have is that a client must have all invoices up to date before we will release their account.

We use EvoHosting as our preferred hosting provider. As a full disclosure, I’m good friends with the directors of the company, but my decision to use them is based on the reliability and quality of their service.

Let me know your thoughts, how do you deal with hosting?

You must be based in the Maidenhead/Reading/Slough/Wycombe area and have the following skills:

• PHP (must have a good understanding of OOP)
• jQuery (must be able to build plugins)
• MySQL
• HTML & CSS
• WordPress Plugins

Preferred, but not required:

• Symfony 2
• Joomla
• OpenCart

If this sounds like the right position for you, then drop us a line! bob@shinytastic.com

We’re currently looking for freelancer developers, but we will be able to offer full-time employment to the right people in the future.

Looking for more artwork (we have a lot of wall space), there’s currently a selection of prints and posters by Tara McPherson, Jeph Jacques (Questionable Content) and The Oatmeal. Any suggestions on artists and illustrators that might brighten up our working day would be welcomed.

I’ve listened to the feedback from the last incarnation, which was mostly “I fell asleep about page 8″ and “does it really need THAT much detail”. We’ve tried to give a good overview of the service without going into more detail than is necessary. We are here to answer any questions that are not covered in the brochure.

The brochure does include a price guide, which was the other most requested aspect. It’s not a hard and fast menu but it should give an idea of costs, and what you will get for your money.

Any feedback is welcome — bob@shinytastic.com, or leave a comment below. Let me know what we’ve missed and if any of it reads like marketing speak, the intention is for it to be as intelligible as possible.

We put together a very Christmas project for our lovely client Ex-Mil Recruitment, they wanted something to entertain their clients and candidates over the Xmas period. We’ve created a simple advent calendar which you can view on their homepage, when you click on a window you’ll get something to (hopefully) make you laugh. As with traditional calendars you can only open each window once that day has arrived so hopefully we’ll get a few return visits. We managed the layout and functionality while JC and Annette at Ex-Mil are supplying the content of the windows (they know their audience better than us!).

We’ve also added some social media elements with Facebook social plugins. You can like and share the calendar on their website and we’ve added it as a tab on their facebook page.

A quick demo of using jQuery for parallax. This example just creates a nice visual effect but it could easily be converted for more constructive purposes but I’ll leave that up to you.

Parallax (for the sake of this post) is the effect whereby things at different distances move at different rates, for example looking out of a train window the closer items are the faster they move past you. This is as horribly simplified and inaccurate description but will suffice for the sake of this example.

I’ve used three transparent PNGs for this but you can use as many layers as you like or easily replace the PNGs with div tags containing whatever content you need.

View the demo.
View the javascript source.

The HTML

This is very simple. The html you need is as follows:

See, told you it was simple. The div is the outer container into which the layers belong. Add the images in order of the bottom one (smallest) first. Job done.

The Images (or layers)

The images (or layers) you use should each be a different size, the bigger the image the more movement. Each image must be at least as big as the viewer, if you set one side of it to be the same size as the viewer and another to be larger it will only move on that axis, which is a nice effect in itself. So if your image is the same height as the viewer but wider it will only move horizontally.

This may be stating the obvious, but I’ve used transparent pngs, you must be able to see the lower images through the upper ones. To create them I used a photoshop file with a group for each image. This meant I could check how they would look before I output them. You can view the three images here:

• Top
• Middle
• Bottom

The CSS

You can view the entire CSS file here. The important parts are as follows.

The background color can be whatever you fancy. Bear in mind that if all your layers are transparencies the background color will show through. Of course you could make the bottom layer fully colored, patterned or whatever you fancy. You could also give the #Parallax div a background image if you wanted.

The width and height are important, remember your images should all the same dimensions or bigger than this div. Overflow must be set to hidden to ensure that tags within this div will not cause it to change it’s size and will not poke out of the sides.

The relative position is required as we will be setting the tags within the div to absolute and we want them to be positioned relatively to this div, not to the document.

Each of the images within the div (or whatever you use for layers) must be set to use absolute positioning so that we can move them around with jQuery. I’ve set their initial positions to the top left corner but you can set them to wherever suits.

The Javascript

This uses jQuery for the heavy lifting. It could be converted into a handy little jQuery plugin but I wanted to keep it as simple as possible for the sake of the example, plus others have already done that.

What this does is whenever the mouse is moved over the viewer (#Parallax div) it calculates it’s position over the div (as percentages) then moves each of the inner images by that same percent of their overflow.

Firstly work out the xPos and yPos. To do this we subtract the viewers x and y offset from the x and y mouse position. This is because the mouse positions returned are relative to the document not to the viewer. The offset values give us the viewers position relative to the document.

Next, work out the horizontal and vertical position of the mouse pointer as a percentage (0 = the top of the viewer, 100 = the bottom).

Loop through each image, for each one work out the difference in width and height between the image and the viewer. The image’s new position for each axis is the percentage calculated earlier for that axis of the difference for that axis. So if the mouse is dead center on the viewer the horizontal position is 50% of the difference between the image width and the viewer width.

Finally, we create an object containing the new CSS settings and apply it via a very short animation which gives the effect a nice smooth finish. You can just jump to the new position but it looks a little too rough for my tastes.

Links

• jQuery
• View the demo
• View the javascript source
• View the CSS source

There are two types (at the time of writing) of Facebook ‘Like’ buttons you can add to your website, the difference caused a little confusion at first but it’s simple enough. The first type is a general purpose Like button which you can stick on any page anywhere to allow users to like that page, when they do it creates a link on their facebook feed which links back to the page they liked. This is great for a blog or any website where you might want users to be able to like specific pages or pieces of information. The other type (which we have used) is a like box which is linked to a Facebook Page (for a business, entertainer, etc). When a user clicks a like box button it adds an entry to their feed which links back to the Facebook Page the button is associated with. This is better if you want to point people at your organisations Facebook Page and not at specific articles or pieces of information. The implementation is pretty much identical.

There are two ways you can add a like button (either of them) to your website, the easy way using an iframe which I’m not going to cover as facebook generates all the code you need for you and the more complicated but much more flexible manner using XFBML. I wanted to use XFBML because you have a lot more control over how it looks and integrates with your site, plus it was a challenge. Although all the documentation needed is out there (mostly on the Facebook Developers site) it’s a little scattered so here’s the steps involved in as straight-forward a manner as I can put them. I’ll try not to be too verbose with the supporting notes.

Namespaces, Doctypes and Validity

The first thing you need to do to your page to run XFBML is add the Facebook and Open Graph namespaces. Find your root html tag which will look something like this:

Add the Open Graph and Facebook namespaces as follows

The Facebook namespace is so that you can use the XFBML tags the Open Graph is so that you can use the Open Graph meta tags which I’ll come to in a moment. First off though there’s a bit of a problem to overcome. As a rule I stick to XHTML 1.0 Transitional but HORROR if you use XFBML tags with that Doctype your page will not validate, now this is not an issue for everyone but it’s a serious problem for me. The solution is you need to use the RDFa version instead, which I’m afraid kids means you need to write strict xhtml (unless you’re using HTML5 already in which case check out this handy link). This is not the time for a full explanation, the short of it is you’ll need to change your doctype to this (assuming you are using XHTML 1.0 otherwise just have a little google for whichever HTML version you are using + RDFa):

Our site still doesn’t actually validate 100%, we have some errors referencing the XFBML tags, but I can deal with that (for now) as the code was supplied by Facebook. That’s the hard part out of the way.

Adding the Javascript SDK

Use of the XFBML tags for like buttons requires the Facebook Javascript SDK. This is simply a case of going here to the Facebook SDK page, cutting and pasting the supplied code into your page. Stick it just above the closing body tag. Job done.

Add the XFBML tag

Facebook supplies handy generators for you here. You’ll need a different tag depending on your preference.

Like Buttons (articles, specific web-pages, etc)

Click here to go to the Facebook page to generate the tag. You can pretty much leave the form as it is. You should be given some code a bit like this:

Yup, that’s it. That’s all you need. You can add attributes for specific layout and control features like this if you fancy, see the Facebook documentation for specific info:

Like Boxes

Like boxes are the slightly more advanced siblings to the Like buttons. They are tied to a Facebook page. Quickest way to get the code is to visit your Facebook page (you must be logged in), click Get Started then click Add Like Box. This will take you to the generator page with all your details pre-filled. Set the settings how you fancy them and click Get Code and you shall receive something like this:

Stick your supplied tag wherever in the page you want it to go then configure your Open Graph Meta tags…

Open Graph Meta Tags

You can read all about the Open Graph Protocol here. For the sake of this article the Open Graph tags are additional meta tags you can add to your document to add specific information about the document which will be used by Facebook. There’s some information on the Facebook Like page on how to use them. Add the meta tags to the head section of your document, they should look a little like this (with your information in, not ours obviosuly):

title, email, phone_number, url and site_name are pretty obvious. type must be one of a very specific list available on the Open Graph website. image image is more important than you expect, I intially didn’t specify it assuming Facebook would either not use an image or would use the first image on the page. Nope, it used one of our clients logos so anyone who liked our page ended up with a confusing link to our website using our client’s logo. Facebook explain the image as follows:

The URL to an image that represents the entity. Images must be at least 50 pixels by 50 pixels. Square images work best, but you are allowed to use images up to three times as wide as they are tall.

Final item of importance is the fb:admins entry. This must contain a comma seperated list of user id’s who are responsible for this page. To get your Facebook id go to your profile and look at the url, your id is the part after the ?id=. My profile is http://www.facebook.com/profile.php?id=100001073515935 so my id is 100001073515935.

To get the like button working one of the users listed in fb:admins must visit the page and click the like button.

That’s it. It’s pretty simple really. I’ve only covered very basic integration here, there’s loads more you can do with a bit of research. Let me know how you get on.

Those Links Again

• Facebook Javascript SDK
• Open Graph Protocol
• Facebook for Websites
• Facebook Like Button
• Facebook Like Box

Here’s a few shaky cameraphone pics…

The file browser makes it so much easier to browse and select images (and other files) when you are editing pages of your website through the CMS. Files can be viewed as thumbnails or as a list of filenames available, with additional information on each file available as a popup, image previews and filtering.

You can view a demo of the new browser here, do bear in mind this is a first release and as such we are still bug-fixing and making improvements. We’re just about to start planning version 2

For the technically intrigued amongst you, this was written in Adobe Flash Actionscript 3 and it integrates with our in-house CMS system via XML, the CMS was written in PHP5 and MySQL with a dash of Javascript.

We’ll be posting up information on current Shinytastic projects where we can and giving a bit more in-depth information that we would on our official portfolio site.

As well as commentary on our own work we’ll be inviting our regular associates to comment and contribute with their own viewpoints on the industry covering design, PR, hosting and other aspects of this marvellous industry we work in.