Procedures

Here are the procedures and languages that I use when developing a site.

All my sites are developed using the following:

Client Side (What is sent to the Web Browser).

  • HTML5 (Hyper Text Markup Language ver 5) - A massive improvement on the old HTML4 and XHTML versions - you can do so much more "magic" in HTML5 - this language is about what is displayed on the page.
  • CSS3 (Cascading Style Sheets ver 3) - A massive improvement on the old CSS2 version - this language is about how the content is displayed, the colors, spacing, decorations (underlining, boldness etc)
  • Javescript and JQuery - these are programming languages (JQuery is written in Javascript) that are executed in the browser and can do things like check that a form is correct before submission, rotate image displays and so much more.

Server Side (Languages use on the server to generate the page):

  • This depends on your hosting company and may be a Microsoft OS (Operating System) but more commonly is one or other version of UNIX (Linux being the most common one)
  • The actual web server is normally Apache (on Unix/Linux) or IIS (on Microsoft)
  • PHP is the language that I use. It comes standard on Apache and id by far the most commonly used. IIS has difficulty running PHP so I steer clear of such servers personally as there may be much "heartache" involved.
  • My database engine of choice is MySQL - again, this is standard on Apache. IIS normally use MSSQL (the Microsoft database) and again, I steer clear of this due to the "heartache" issue.

How I develop a website:

  • The process begins with an image (PSD, jpg etc) which I use to develop the site template object. All pages on the site use the same template (the "Common Template" method), this practice makes changing the look of the site able to happen in a single script, not a script for each page.
  • Next I do the default CSS script. This script dictates the sizes, colors, positioning of everything and is used on every page.
  • The menu object is next. It contains all the navigation links, used CSS to control the colors and positioning of the links and if necessary, drop down menus.
  • The site header object (the bit at the top which normally contains the site name/logo image and maybe some other stuff like Facebook Like buttons etc) is done with any CSS or JQuery enhancements required.
  • If the site is going to have a side column, I create that object.
  • All sites normally have a footer so I create that as well.
  • A dummy "home" script is created. (I do the actual content of all the pages at a later stage)
  • Then its the .htaccess scripts turn. This script enables the use of "Friendly URL's" which the search engines love - I would strongly advise that all sites use them.
  • Let the fun start! The Index script actually generates the entire page based on the parameters it receives.
    It works like this:
    • Take the template object
    • Figure out what page is being asked for
    • Get the requested page and put it in the correct place in the template object
    • Do the same for the site header object
    • And again for the menu object
    • And again for the footer object
    • If there is a side column, do that too
    • Everything is finished and the page gets served
  • Sounds simple! In reality it takes a lot of time and coffee and often you start banging tour head against the wall in frustration and often you have to adjust the CSS, template and/or any of the other objects to get the reuslts you want.
  • Then I do all the static content pages and the SEO that is needed for them.
  • Dynamic content pages such as contact forms, guestbooks (sometimes called "testimonials"), galleries, eCommerce pages etc are next and again there can be much coffee consumed and sometimes some wall/head banging involved - that is just how it is !
  • And once this is done, I take a deep breath because it is now time to make the entire site "Responsive"

Making a site look good on mobile devices
AKA Responsive Design

Until recently the problem of your site being almost totally unusable on a small screen device such as a smartphone or tablet was solved by creating a "mobi" site. Essentially a totally separate site for mobile devices.

Apart from the nightmare and cost of maintaining 2 sites, there are so many different sizes of mobile screen sizes out there that the question now became "What screen size (specifically width) should I cater for?"

Whatever size you decided on meant that most of the mobile market would not be catered for so either you gave up trying to cater for the mobile market or you make a seperate site for each mobile device screen width - a super expensive option.

Then some very clever individuals figured out how to make a web page "respond" to the size (width) of the screen that it was being displayed on.

And Responsive Displays were born - just another thing to make a developer's life a nightmare.

In theory it sounds simple but like many "simple" things, it can be a major problem due to previous decisions made during the design and development process of the "full size" site.

However, an experienced developer is always asking in the back of his mind "Will this be able to be made responsive?" while developing the main site and if it wont be responsive, figures out how to do it so that making it responsive will not be impossible.

Often I am not even aware that I am making a "responsive" based decisions when I do something in the main site development phase - it just happens - it is "experience" !

Questions I am asked relating to Responsive Design

Like many other developers, I am often asked to do work relating to Responsive Design. Here are some of them and my answers (with reasons).

Can you make my site Responsive?

The answer is "It all depends on how your site was written"
The reason for such a vague answer is that in pre-CSS3 days, the best (and sometimes, only) way to make sure that everything was displayed where you wanted it was to use what is called the "HTML TABLE" structure and this structure cannot comply to responsive directives because it was never meant to.
The problem started back when CSS2 was introduced and Microsoft decided that it was too much trouble to impliment CSS2 in Internet Explorer.
At that time, IE had over 90% of the browser market and what Bill Gates said was considered law.
That meant that developers had to keep using the old table method of formating displays instead of the more modern CSS2 (and later, CSS3) methods.
However, things change! Internet Explorer has lost massive market share (now about 50%) and the trend seems to be continuing.
Unfortunately, many sites more than 2 or 3 years old used the "table" display formatting and it requires a complete redevelop of the main site to get it to a point that it can be made responsive.
Sorry but that is how it is!

Do you work on CMS systems like Wordpress, Prestashop, osCommerce, Joomla, Drupal etc

The answer is NO!
Firstly, all these CMS systems were developed by may people and sometimes they adhered to the rules and sometimes they did not - this is particularly dangerous as it applies to security and that is why so many of them get hacked.
Secondly, when you purchase a fancy new template from Template Monster or somewhere, these "templates" often overwrite important code in the initial package and often the new code does not comply to "the original rules" - the developers of these "templates" put together something that looks good, hack the code to get it to work "more or less" and sell it to you - when it fails they are not worried because they already have your money.
Thirdly, when any of these CMS systems start they load script after script after script (I stopped counting at 100 scripts when I did an analysis of Wordpress a while back). This is before the work of serving the page starts.
And that is why there are so many project requests to "MAKE MY SITE FASTER" - for the most part, these CMS systems are "Bloatware" and to make it faster, the CMS system has to go and that is not something that someone who has spent a hundred bucks for a new "template" wants to hear.
Fourthly, you often see project requests like "I INSTALLED A NEW TEMPLATE NOW MY SITE IS DOWN -PLEASE HELP"
Its the same story - You have paid for the template and now you are on your own and the developer is smiling and thinking "SUCKER!"
If it takes me on average 3 minutes to track down what script is being loaded, open it, have a look for any obvious issues in what is often a bowl of spaghetti code then to do the first 100 scripts (I do not know how many more there are - as I said, I stopped counting) then that is 300 minutes or 5 hours and I most probably will not have found the issue yet.
No-one in their right mind is going to pay 3 to 5 times what they paid for the "template" in the first place just to get it up.
I would rather leave that to someone else thank you very much.

What about your "Custom built CMS"? Are you not being arrogant?

Why would I be arrogant?
What I call "My CMS" does what it needs to and ONLY what it needs to and only when it needs to.
My "CMS" is not a CMS in the tradition of Wordpress and the rest, it is pure PHP code that has had all the unnecessary frills, bells and whistles removed. If it is not needed then its not there - period !
On average, I am loading between 7 and 16 scripts and probably only 1 of them is doing any actual processing.
That means that my page has been served before any of the "Bloatware" systems is even half way to finishing setting itself up - then it has to do whatever processing is required and only then can the page be served.
I do not consider that "arrogance", I consider that "efficiency".
Anyone can use any CMS they want to - they will have to live with their decision but I urge them to make backups every step of the way and I also wish them the best of luck.

Website Developer

Hire me on Freelancer.com

A beef fillet cooked for 15 hours by 30 chefs does not necessarily tast better than a cheeseburger.

Measuring website development progress by lines of code is like measuring aircraft building progress by weight.

Practice safe design: Use a concept.

When debugging, novices insert corrective code - experts remove defective code.