This second view is far less superficial as the first article sounds like it came from someone who is not involved in the code behind the site, which is where the real WEB part of the term Web Design comes into play. When a visual design is put together by someone who doesn’t code, there will be no mention of build. The time it takes a visual designer to make slight adjustments visually is not in any way linked to the time it would take to ‘adjust’ the actual Web site. The visual elements may look similar, however, if the layout of the site has been changed, it will more often than not, take the same amount of time to rebuild the page as any Redesign would take. Changes to column widths, from flat navigation to addition of dropdown navigation require significant changes to the underlying technology that makes the site work. Elements of a page are often dependant on those elements around them and as a result the surrounding elements usually require major rethinking. This can often lead to a complete rebuild of the page to achieve the new, seemingly superficial changes.

So what is actually involved?

When redesigning a site you basically start from scratch which means that you can adopt all of your tried and tested skills as an experienced professional designer, to come up with an approach which you truly believe will work for that client both now and into the future. Anyone with experience of modern design will have quite a few tools up their sleeve to start on the new page rather than working around old code. If you are ‘adjusting’ work done four years ago by someone else who may not have the experience required to create a professional Web site, in my experience you are working with old, outdated and badly written code on which you have to perform numerous hacks and workarounds to, for instance, change the navigation so that it is a bar that runs along the top as opposed to having it off to the left.

When designers talk about the adjustment process, or realigning, being somehow cheaper than redesigning it will usually mean that they are being led by a flat design with no thought behind what real adjustments are going to be made to the code and how long those will realistically take. Putting two similar designs side by side and telling a client that one is a ‘realignment’ of the other (as in the list apart article) is leading the discussion on purely visual grounds, not once mentioning how this is going to translate to every modern browser that todays Industry demands. Any visual that a designer produces in photoshop is all it is going to be until the designer who has embraced the technology to make that into something tangible, clickable and attractive to use, is hired to bring it to life. Tagging something with the term realignment doesn’t automatically mean that to achieve something seemingly minor on a visual, will take a small amount of time. As anyone in business knows, time is money.

WYGIWYS, see what I mean?

Realignment isn’t always a cheaper process, it is simply a different one involving differing amounts of work in different areas and care should be taken if suggesting anything otherwise.

From experience of building many Front Ends and becoming a better and better visual designer of modern XHTML, I believe that there are too many factors involved in the design and build of a Web site to be able to confidently say ‘we can realign that for you’ without at least finding out a bit about the existing site first. Here are some important considerations to think about before adopting the realignment process:

1. How old is the current site? If it is more than around 3 Years old, the technology behind it is probably out of date and it would be more cost effective to rebuild from scratch, bring the sites code up to date, making it more future proof.
2. How well does the current site perform? If a site is slow, it is not always because the server it sits on is slow. The way the site is built often has a bearing on speed. Realiging will not solve these fundemental accessibility issues.
3. What do your CUSTOMERS want? If you are simply tired of your current design, you often just want a bit of a spruce up, do your customers want the same as you? The old adage ‘if it ain’t broke don’t fix it’ was made for this situation. Changing a perfectly well performing site could damage your business if your USERS are put off by something that is unfamiliar to what they have grown acustomed to. Consider adopting a feedback strategy instead to gauge the mood of your users before making drastic changes.

What’s the point?

Something I’ve noticed of late is that although the documentation that is available directly from the WordPress site is very comrehensive, it only really tells you about the foundation level features that drive the system. You can use any of them whenever you wish, although most Developers tend to want to know how it all comes together to produce something you can use directly in your theme development to make nice things happen.

As someone who has been using WordPress for years, I have so many techniques I have learnt, forgotten about, learnt again and used on many sites I’ve produced for clients and for myself. I thought it was high time I produced some form of documentation both to keep track of the things I’ve learnt so I can refer back to it, and also for anyone else interested in developing a new Theme for this industry leading resource.

I am planning to keep it up to date with every new technique I learn on every new project so hopefully it will help to get more people plunging into WordPress Theming in a very accessible way, allowing them to include some great features directly into their own sites.

Obviously, my main discapline is Accessible Front End Design, which remains the most important part of my work for clients as it is the most important part for users of their sites. This is why my documentation will remain anchored to the WordPress system and not the fundementals of actually designing and building the html and behaviour of the site.

Marketeers welcome

Webegg understands that although I myself can understand users needs quite easily, sales people and Marketeers simply want to sell a product to prospective clients. To sell any product and be sure that it is right for their client, they first need to know that product. I have not just aimed the documentation at developers but have also created sections for just these types of people, so they can at least look at the evidence in a more easily digestable format. If they do not want to spend the time reading it themselves, they can pass the details along to the client, although this would be quite an unprofessional thing to do.

Head across to http://wordpress3.webegg.co.uk and you can browse through the documentation. There is an ‘index of contents’ at the top via the tab that sticks down from the top of the page. As the documentation grows, this will no doubt need re-thinking but its fine for now. On opening this, you can see that the non-technical section is split off from the main Theme build section. I have also added an ‘Over and above’ section for anything that WordPress won’t do ‘out of the box’.

See what I mean?

• item1
  • item1
    • item1
      • item1

When I use the em unit as a default for font sizes for all content on a page, this is the result you get when you add a nested list. The following shows the markup I used to show the list above. This particular list uses inline styles to illustrate that all list items have the same value applied to them.

Inline styles should be avoided in markup at all times. A separate stylesheet is always best practice to reduce the amount of markup used on a Web page.

The list shows up on the page like the example above because the rules under which em units operate are related to the hierarchy of the DOM (Document Object Model), which dictates that the item the em unit is applied to should be proportionate to the value applied to the element immediately above it.

Knowing this, it now makes complete sense why we get this effect on a nested list. The value I used means that the current list element is 0.8 smaller than the same element in the list element in the one above.

Thats better

• item1
  • item1
    • item1
      • item1

In order to avoid this issue, I have now reverted back to using px units for all lists. As you can see above, all list elements are now the same size as they are being set to a rigid pixel size instead of being proportionate to each other.

The markup is shown above, as you can see, again for illustration purposes (and to override the main css for this site) each nested list item is being set.

What about the rest of the site?

This question was the first thing to pop into my head as soon as I realised this solution and yes, it does have a bearing on the rest of the site. Setting the initial font size and then setting other font sizes in relation to it mean that if you decide to change all other elements globally using your inital font size value, your lists will not follow suit. It’s something I personally don’t mind doing though. I would rather change the nested lists in one go than have to set each level with em units seperately, which just doesn’t make sense.

I think it best to break all your main content elements down anyway, giving them each their own initial values. When I say content elements, I refer to things like <p></p>, <h1></h1>, <h2></h2>, etc, <ul><li></ul></li>,<a href=”"></a> etc etc.

There have been a few occasions over the last few years where I wanted to produce a really functional, usable navigation system that just works. Unfortunately, my full time job as a Front End Developer, which I love, means that I do not make calls on Back End Development. It’s not that I want to either, we have a great system for content management and the necessary Development team members to carry out the Development work on these sites. As a front End Developer, my time is better spent working on new and creative ways to use XHTML, CSS and jQuery, so thats the way I decided to try and solve this issue.

What I want is a left aligned vertical navigation list that contains a nested list of links (so it is accessible). It lent itself to being an accordian style of functionality, for which there are 10′s of scripts. I’ve included the simple accordian script in this article but that isn’t the main point of it.

The real functionality that I want to show you in this article, is the page recognition and how you can use this to make your menu much more usable. Firstly, the following script shows the snippet of html that will structure our menu:

As you can see, it is a fairly standard nested list of links with a div around it with an id to make it unique.

Once this was in place and styled, you can see that full nested list. If you want to test this between different pages, you can save the same menu as ‘about-us.html’ and ‘who-we-are.html’. When you navigate between them, there is currently no active class. Of course there isn’t, nothing is telling to. This is the bit that should be generated dynamically. You can also achieve this using the jQuery below:

Ignore the two commented functions for now, these will be added next. Basically, what is happening here, is that we are assigning the current page location via javascripts built in window.location function and splitting it at the ‘/’. This creates an array of path locations, then discards all but the last one and applies an active class to any links that match this location. Go on, try it!

One step beyond

For usability and style, I wanted to add an accordian to the whole thing, closing up the nested list to hide all child elements and leave only the uppermost list. The top level sections if you like. I have to admit to finding a great slimline script after much hunting around and trying out plugins that just didn’t quite do what I wanted.

With a feeling of utter chuffedness, I then realised that in an ideal world, the menus with child elements should remain open if the user was either on the parent page or the child page of a section with a second list below it.

With a mixture of logic, my understanding of iterating through the DOM, the script I made prior to this and pure godlike Intellect I came up with the following function to find the current active class, iterate through the parent or child elements and make sure that the current page elements are left open.

I did have a few headaches getting the function to work in conjunction with the others. The order is very important and once I included the accordian followed by this nestcheck function, I got the effect I was after.

View the entire menu in action

I have spent days on one area of a design before, partly because I am obsessed with getting the design the same across browsers without losing any of the graphic designers visions. I suppose it is good in a way that a Photoshop weened graphic designer is designing a Web site. This means that they have no bounderies to their creative process. That does not mean that they are not there, although with technologies like HTML5 and CSS3, more will be possible as the Web matures. It is therefore up to the Front End Developer to bring this flat design into the browser.

So, you just code designs then?

Most people who cross paths with a Front End Developer, either because they work with one, have employed one to build a site professionally and correctly (maybe even to graphically design their web templates for them), seem to regard them as number crunchers of design.

Making something appear beautiful across a browser range by crunching numbers alone, in my experience, is simply not possible.

You can plan a design down to the last pixel, work out your grid to perfection (if you aren’t using a pre built one) by crunching those numbers and coming up with an end result which WILL work. When it comes to actually building the thing, one of those browsers will inevitably defy logic at some point, forcing you into a blur of hacks, back tracking and what is not too an unexpected scene, a complete rebuild.

There is no rule book for Front End Development

There are so many discplines and technologies a Front End Developer touches on to get things made, they are in danger of getting a reputation for being a Jack of all Trades but a master of none. My quest is to make Front End Development more clearly understood in the grand scheme of the Web.

Most people who want to build Templates for Websites are creative people who have a passion for how people use Websites and want users of a Website to have the best experience possible. We are not nerdy enough to be able to build a full blown application but will often be able to build a working shell through the use of XHTML/CSS/Javascript and superficial use of a server side language like php.

I often have visions of what I want a particular page to do and will be able to make the functionality work on the front end (a working prototype if you like). An example might be a quick contact form that might need to check a username before sending anything. False data could be passed to the form in order for it to appear to work, giving the client a working demo of the form.

I think this working version is an important thing for a Front End Developer to be able to achieve. There is nothing more descriptive to the person who has to program the Back End, than something that actually works and can be shown working.

Plugging the Front End into the Back End

This is the grey area. There aren’t many Back End Developers (none that I have yet met) understand what a Front End Developer does. They seem to be of the understanding that if something needs styling, then it must be down to the Front End Developer. In many ways this is true although with new front end technologies emerging every day, the Front End is becoming more and more important in the modern Web, with more areas to cover and things to consider. This is starting to demand that content be delivered from the back end in certain formats, with Accessibility being the driving force behind it all. Accessibility, in my experience anyway, is a word that not many programmers seem to understand at the moment.

Let me explain a particular example. Say you want to paginate a load of results from a database. A Back End developer tends not to understand that in order to make the result as accessible as possible, they really need to make the server handle pagination using their back endy programming magic. If you are asking your browser to load 100 or so results and then paginate them after load with something like jQuery, load time will be hugely increased making the page rank very low on Accessibility.

You can never make a Web Developer embrace Accessibility, although it should be something that everyone involved is aware of as most of it is based around logic.

As a front end developer who is conscious of the way businesses have to run, I have been concerned for some time about the current design process within the Industry. It simply does not cater for all these browsers in a way that supports the workflow of a business.

I absolutely love the build process and try to build every site I am involved with from the start, in a way that is as near perfect as possible.

Where we are TODAY

With new browsers comes new technologies, rendering engines and tools that, with a little help from webstandards.org are made to make everyones lives a little easier. Most people involved in the front end development of Web sites (within that I include UX Designers and strategists, Designers AND sales and Marketing guys) want to be able to use these technologies as soon as possible and who can blame them, as the people who actually put Designs into browsers, Front End Developers are champing at the bit to use them.

I personally believe that a bit of education and changing the way clients and users in general view the Web, could be the way to make the Web a little more accessible for all the browsers and devices available today.

Move with the times

In a world that is fast becoming rammed full of devices that can now access the internet, we need to be able to make the content of Web sites available, potentally, on all of them in the future. Progressive Enhancement is the way in which we can do this. We want to be able to use ideally the same Website and reformat the information to appear on other devices in the most user friendly, accessible way possible.

In my experience, a selling point of a lot of Web sites is the fact that it will look the same in all browsers. This is both misguided and will often be the cause of the Front End build running over time, adding extra cost to the project. If the client were to be educated early on, maybe even offering a key individual a browser upgrade to firefox so they can see how much improved their site will be, it would be a step in the right direction. If every agency did something like this and word spread, it could only be a good thing.

With all the different kinds of things browsers are capable of these days with all their varied features and different types of support for various standards, I believe we should be viewing them in the same way we view say, the iPhone and Nexus One. They are similar devices but what drives them is completely different. The same is true of Internet Explorer when comparing it to Firefox and we need to move with them, instead of trying to force them to do things which slow them down or make them harder to find on google.

My suggestions

Taking everything I’ve already said above:

• What are the actual benefits of being more friendly to Web standards?
• Why aren’t we building with future browsers in mind, rather than staying in the past?

Well in an attempt to answer these questions, I have built two virtually identical Pages which use very different techniques to demonstrate the benefits:

Demo site A – EXACTLY the same in all browsers

The above site would keep everyone happy. It looks the same no matter where you are or what you are using. My question is, would you rather have this Front End with its enourmous amount of markup and css, images that are unnecessary and which isn’t easily scalable?

Demo site B – ALMOST the same in all browsers but with enhanced markup/files

This looks exactly the same if you are in any of the forward thinking browsers like Firefox and safari but will have the minor difference in that the corners are squared off in Internet Explorer. The benefits of this to the accessibility of the site outway the slight differences in design across browsers. The file size across an entire site and the resulting reduction on strain on the server and loading times is reduced, markup is cut down by virtually a half, making updates easier and also makes it more transferrable across other platforms and devices.

The end decision is of course up to the client, however, they need to be made aware of what is possible and why the differences would far from being a bad thing, for future proofing and making their site accessible to many other formats, it is the way of the future.

I used the example of rounded corners as an easy to undertsand example. It is a common design feature these days, so it seemed appropriate. This idea could be applied to many new techniques coming into existance with very similar streamlined results.

Once I had the design down in photoshop, I was trying to figure out a way of making the girl stand out when it came to putting the design in a browser, just in case the user had missed her and the eerie effect proved useless. I love horror films and those spine tingling moments in films when something unsettles you. A particular scene in the film ‘The Ring’ inspired me to use a flickering effect on the girl to give the whole scene an unsettling appearance.

The first thing was to seperate the girl from the rest of the image using css, so that I could target her with jQuery more effectively.

I did this by structuring the page and putting the zombie div after the topnav div. I also added a small piece of jquery just after the zombie div to hide it from view immediately. This is to make sure that everything is set up correctly before the sequence begins. The following shows the css rules applied to the zombie div.

As ever, IE shows problems when trying to animate opacity values and for now I decided not to make this effect available to IE browsers

Knowing that all I want to do for now is flicker the div, I was safe to add position and structure using css to move the zombie image where I wanted it.

As with any new idea, planning and setting things up with your goal in mind is essential. Most of the donkey work is done in setting things up correctly in the first place. I almost knew what the main jQuery needed to do once I’d reached this point in the development process. It mostly consists of stringed animations and pauses but timing them was the tricky part. Flickers needed to seem almost random, so I mixed long pauses in with quick changes in opacity till it looked right.

Another hurdle that needed jumping was the looping issue. I wanted the effect to be continuous. I got over this one by effectively having a function within a function. runit() has an animation sequence within it. This function is called after an initial animation sequence. The clever bit is that the function gets called at the end of itself, this keeps the flicker going forever.

Yet another thing that needed resolving was the fact that Different things load at different times. With everything else loading around it, the zombie girl animation was in danger of simply being lost because the user would be distracted by other elements popping up around it. I needed the girl to be the focus of the users attention for it to be effective. I utilised jQueries excellent bind feature to execute the above only after everything within the DOM window had loaded. I wrapped the animation sequence in this bind function and things worked brilliantly.

View the effect on the Home page of the finished site

Object Oriented Programming is better than Procedural

The reason programmers and developers use OOP techniques is because it creates a ‘framework’ that they can build on for future projects and to expand existing ones. Indeed OOP seems to be the most widely accepted and best way forward for large applications like facebook or twitter. Lets be honest though, for smaller projects and ‘brochure’ type websites, OOP seems a bit overkill doesn’t it? Searching through a template to find a clue about where the back end is coming from, only to delve into about 3 different classes to find out where to change the information that is contained in a boxout is both time consuming for a developer and costly for a client.

In this kind of situation, a mixture of Well formed XHTML/CSS in the front end and a Developer who knows their onions and can make the change directly to the markup seems much more cost effective as it can be done in five minutes.

In the past, I have seen things like this to set and get a title for a page across a reletively straightforward 10 page site by a third party that I worked on. Thankfully I knew where to look but it took me a while to change the title I can tell you. Firstly in the template for a page, this was what I faced:

I knew this must have referred to a function that created the title somewhere and found a file with this code in it:

I then tracked this code in a file more closely related to the page I needed and found a call to it like this

For me, this seemed a rediculous way to build what was essentially a 10 page brochure site and simply not right for the client or the development company.

It would make much more sense, if a server side resource is needed at all, to use procedural code. At the most, a simple php file with a few functions that pages can call upon as required, would make much more sense for a developer and a business for smaller sites which are not likely to grow too much.

Client side is easier to achieve than Server side

This is one of the biggest fallacies of them all. Anyone who suggests this is either not providing the correct service to their clients, or is providing the wrong service without knowing it.

If a Server side programmer knows what they are doing, they know what they are doing with usually ONE of the following server side languages in the modern Web design Industry:

• Ruby on Rails
• ASP
• PHP
• Perl

This is because they all provide the same functionality (give or take a few) and all can be made to provide the same services from the server. Compare this to the Client Side, Front End or plain old Web Designer function. Whatever you want to call them, their duties have to cover ALL of the following:

• xhtml
• css
• javascript – Consisting of general understanding of the core scripting language plus use of one, somtimes a few of the frameworks:
  • jQuery
  • Mootools
  • Prototype
  • Dojo
• Templating languages
  • Template Toolkit
  • Server side includes
  • Smarty
  • PHP (Some templates use raw PHP)

The Design should be the first thing to do

The problem with assiging time to the Design process and spending all that time on it at the start of a project, is that when the client changes something halfway through a project, the designer complains at having no time left to adjust their design and consequently the project is left in limbo and can all too easily get out of control.

The best way to start a project is to create a series of Wireframe diagrams for it.

A Wireframe diagram is a document which lays out any particular Web page into a grid based format, showing the content and features of that page

This way, these diagrams can be a quick reference to anyone, Web Developers and non Web Developers (clients and admin staff) alike, which will quickly resolve any uncertainty about what is included or not yet included as part of the project. Once this Wireframe has been completed and signed off by both the Web Development organisation and the client, that is when the design should be done.

Surprisingly few examples exist of Wireframes and it really is quite a simple concept. Openinterface.ie have a fairly good example of a Wireframe they produced for the South Dublin City Council website. It illustrates well that essentially, all Web pages have to be split into a grid and once that grid is established and built, it would take a considarable amount of further work to change the layout. The finished site has a few different images from the original and some elements may have swapped around a little bit but it looks like the Wireframe system worked.

Some might argue that it would be a waste of time to do a wireframe diagram for the smaller projects. I say – a plumber wouldn’t take on a plumbing project without listing every item and labour costs on an invoice. The same is true of building a Web site, if you are doing it as a business. Every item of work needs to be accounted and payed for by someone or you start to lose money and if it is only a small site, it shouldn’t take long to put a wireframe together for it.

There are a few other points I’ll probably add to this post in future but for now, I think this covers quite a few things that come up regularly.

New to my bookmarks is this tutorial from How to forge http://www.howtoforge.com/perfect-server-fedora-10 and it details all the steps to get Fedora 10 up and running on your own. Obviously you can’t just do something like this without having a little bit of web savvy but anyone in the same boat as me, this should be perfect for you.

I also had the dynamic IP problem to deal with but thanks to dyndns.org and some research into what goes on with dynamic IP’s and how to get around them, I’m now well on the way to having a server that functions for all my needs.

Dynamic IP solution

If you connect to the web through a router, mine is a Netgear DG834G, most modern routers have a section related to Dynamic IP’s. Have a look at your control panel for something in the main menu like ‘Dynamic DNS’ or ‘Dynamic IP’. Mine is the former and has settings which allows me to connect to an account I created on dyndns.org using the domain mydomain.dyndns.org, my username and password. This means that everytime I connect my router to the interweb, it logs into this account and updates the ip address to whatever my computers IP address is at that time.

This, together with the custom DNS service they provide means that any new sites I create on my server, I register a new domain with dyndns and it goes through this account, straight to my server every time.

The Twitter API can be used via the address bar to get hold of a json output of your account. This gives you the relevant information that you can break up and display on your page (I use jQuery to do this – well I did). The following javascript is part of what I used to use:

To my surprise, whenever anyone visited my site where this script was getting the latest tweet, it automatically logged them into my twitter account, giving them access to all my settings.

It was only thanks to a local small company who hadn’t realised exactly what had happened and send me a message, that I found out about this security loophole in the Twitter API. I was very lucky and now do it properly with php so it won’t happen again. Hopefully this little word of wisdom will help any other developers fix this issue on their own sites.