I'm a web developer who works with HTML, PHP, CSS, ExpressionEngine, Javascript, jQuery, MySQL, SEO and UI/UX design. Always looking to learn new web related stuff, and a bit of a PC gamer. You can also find me on Twitter and LinkedIn.

Posts Tagged: design

Text

I’m not much of an article writer, especially on opinions, although I did do one a while ago about my iPhone, and there are some rangom things on here. But the majority of stuff I post is intended as a record of things I’ve learnde which may help me again in future, or hopefully benefit others who come across the same development issues. With that said, here I go anyway:

I used my friend Google to search for ‘define:Weblog’. Here’s a selection of the results:

A blog (a contraction of the term weblog) is a type of website, usually maintained by an individual with regular entries of commentary …
A website in the form of an ongoing journal; a blog
a website which contains posts or short dated entries in reverse chronological order.

Not once is it mentioned that a blog is for other people to commment on. And I believe they shouldn’t be. At least not directly.

If you’re writing a blog it’s basically a journal, whatever the subject matter, just one that anyone with access to an internet connection can read. If it was your journal, offline, would you be letting people write their comments on it?

If you want to discuss a topic of your chosing you’d use a forum. The Google results for ‘define:Forum’?

a public meeting or assembly for open discussion
A forum, or message board, is an online discussion site. It is the modern equivalent of a traditional bulletin board, and a technological evolution of the dialup bulletin board system.

If you want a good discussion on any matter, why not use a forum.

If you don’t want this so-called back-patting ‘designer clique’, disable comments on your blog. Sure it won’t stop it totally, but at least you won’t be encouraging it.

People can pat backs all day long by sharing things via social media, just don’t encourage it on your own site.

If people want to comment about your article or article or piece of work, they can do it on their own blog and reference it. At least then they’ll have to put some thought into a response. Which is exactly what you’ll have to do with this one.

Text

Make your copy easier on the eye.

Avoid stark contrasts.

For example, if your text is on a white background (#FFF), rather than black text (#000), use something slightly lighter like #222.

Alternatively, you can reverse the effect and make the background slightly darker and keep the text black.

The other side of this coin is to ensure you have “sufficient contrast”. Here is some information on Understanding Color and Accessibility, and a great Colour Contrast Check tool created by Jonathan Snook.

Text

Validate your code.

Why?

Well, the W3C can tell you why you should validate your code, and they do a much better job of telling you what you need to know than I would. But I will list the basic reasons if you can’t be bothered to click the link:

  • Validation used as a debugging tool
  • Future-proof quality checking
  • Helps teach good practices
  • Gives a sign of professionalism

How?

There’s a great little Firefox add-on called HTML Tidy. In conjunction with viewing the source of a page, you can easily track down invalid code to set it back on the straight and narrow.

You can also use the online W3c HTML Validation Service and the online W3c CSS Validation Service if you develop using other browsers.

Text

Indent your code.

Quite simple reasoning to this one, it makes it easier to read. I mean, what would you rather look at when coding? This:

<html>

  <head>

    <title>This is our home page</title>

  </head>

  <body>

    <h1>Hello World!</h1>

    <p>Here's a list of random stuff:</p>

    <ul>

      <li>Alligator</li>

      <li>Radiator</li>

      <li>Flibbetygibbet</li>

    </ul>

  </body>

</html>

Or this:

<html><head><title>This is our home page</title></head><body><h1>
Hello World!</h1><p>Here's a list of random stuff:</p>
<ul><li>Alligator</li><li>Radiator</li><li>Flibbetygibbet</li>
</ul></body></html>

Text

Comment your code.

It doesn’t really matter what code you’re writing, whether it’s HTML, PHP, CSS, Javascript or anything else, commenting your code can become very important.

There are a number of reasons why we should look to comment our code;

  1. If someone else has to work with your code, it will help them decipher what the hell is going on.
  2. It can be used to search for a specific block of code by adding key phrases/symbols to search for in the comments.
  3. If you haven’t worked with a piece of code for a long time, it can refresh your memory, saving you having to work it all out again.
  4. Other people can learn from what you’ve done.

Number 4 on that list is my favourite. I’ve learnt a great many things by seeing something I like on the web, checking out the code and having a go at building it myself. Help out your fellow developers, let them learn from your work.

Text

Test, test and test again.

It is a fairly obvious one this, but it’s amazing how many bugs and errors can slip past the radar during development. The internet is a notoriously difficult medium to test on (yes, we all hate IE6, deal with it), since a website is generally intended for everybody in the world to see.

Every single user can view the website at a multiude of resolutions, browsers, browser sizes, operating systems and so on. What we can do is try to limit these bugs and errors by;

  1. Testing thoroughly throughout development (check the site in all browsers roughly every hour whilst developing, checking your most recent work).
  2. Methodically checking the entire site once the client has signed it off and its ready to go live (you may also get the client to test at this point).
  3. Testing when any maintenance is carried out or updates are made on the live site.

In an agency environment, where you may be working on multiple projects and maintaining all of your current websites, you can be pressed for time. However, this is another one of those situations where a little time spent now can avoid losing a lot more time, money, and even clients, further down the line.

Text

When to use tables for layout.

This post would be much shorter if I could just say NEVER!

However, there are two instances when you should use them. One is the correct reason for using tables, the other is unfortunately borne out of necessity.

You should use tables for: tabular data.

The key word there is data. It is to be used when you have information to present that would best be displayed in the form of a spreadsheet.

So, when is it necessary for you to use tables? HTML email newsletters.

For anyone who tries to conform and promote web standards, HTML email newsletters are a horrible trip back in time, like an LSD fuelled Flux Capacitor.

Sorry.

HTML email newsletters are the bane of the purist web developer for more than just this reason, but that’s another post for another time.

So, there we go, use tables for displaying data on web pages, and for layout ONLY in an HTML email newsletter.

Otherwise? NEVER.

Text

How to get what you need from a client.

It can be a bit of a nightmare getting the information you need in order to get the job done as efficiently as possible. If you know what you need, why not let the client know?

Without being condescending (this is very important), spell out everything that you need for a piece of work, whether it be for a large amount of content or a minor update. The more clear and concise your instructions to the client, the less often you will find yourself chasing for information, or further amendments cropping up in future.

For example, if a client wants you to add a special offer to their e-commerce website, where a free product is bundled with every order, make no assumptions on any part of the task at hand, however small the task may be (you should all know assumption makes an ass out of u and mption).

Check that you have the right products for the offer, the correct images, text, links and anything else. Asking for everything before you do anything will ultimately save you, and your client, a great deal of time and effort.

Text

Choose the right CMS.

Don’t decide what CMS platform you’re going to use before you’ve got the brief.

Forcing a complex site into WordPress will cause more problems than it’s worth. Using something like Magento can be overkill for an e-commerce site selling just a handful of products.

Get your site requirements down on paper, then see what fits best. I tend to stick to WordPress for standard blogs, ExpressionEngine for more complex blogs through to large dynamic multi-lingual site, and a bespoke CMS system for small dynamic sites which only require content like News and Events to be updated.

These are obviously just my opinions, it’s up to you what works best for your situation, your knowledge and your preferences. Just don’t crowbar your preferred CMS into something that it won’t fit. Round peg, square holes and all that.

Text

Step beck for some perspective.

Everyone gets a mental block at some time or another, whether it’s during planning, designing, or coding.

You’ll be amazed at what can happen if you step back when you “can’t see the wood for the trees”.

Simply take a break, go for a walk, make a cuppa, or work on something else. When you come back to it, whether in 5 minutes or 5 hours, you’ll be taking a fresh perspective, and hopefully something will click and you’ll realise the solution.