How To Code a Layout

Monday January 30, 2006 0 Comments

One thing I’ve heard a lot from beginners is help or questions on how to code a layout. How to take an image and to put it into a browsable web version using standard compliant code.

Erratic Wisdom has put together a nice tutorial on how to code a layout. And when I say this, no it is not a tutorial to teach you anything about coding. It discusses the method to approach a design when you want to take it from .PSD to HTML/CSS.

Erratic Wisdom’s got an excellent starting point for people to learn how to get their designs into code. This is of course modifiable in order to make it fit your own style. But your style can only grow out of experience. So the best tip for how to code a layout is honestly just to do it. Because everything you will learn about improving the process and making it easier will come out of experience in building a number of websites.

Think Ahead Or You'll Fall Behind

Wednesday January 18, 2006 0 Comments

As my Computer Science 4 professor, nicknamed Crazy Vlad, always harped, planning your programming is essential to the best program you can build. He had a tale that I will now pass on to you to get this started.

He was in a graduate Computer Science program with two other individuals all working on the same project. The three of them would be given six months to develop their program to solve a certain task. Person A thought he was going to be a good graduate student and started coding right away. Person B put a little bit more thought behind his actions and planned for 3 months programmed for 3 months. Person C (Crazy Vlad) planned for 6 months and programmed for a day.

When the testing began Person A’s program executed once every week. Person B’s program executed once every hour. Person C’s program execute a dozen times a minute.

Moral: Planning only helps you in the long run.

Now that that little tidbit is out of the way I’d like to go over some tips to making sure you are able to successfully plan for your project, regardless of the exact implications.

Step 1 – What are you doing?
Get a clear answer for what you are doing and planning on implementing. If you are on a team than this should be a strong collaboration between all members. Get all the basic ideas out on the table so everyone knows where they stand and where they want to go.

Step 2 – What do you need?
Get the essentials of what needs to be done. The example I am going to stick with is software development but it can be modified to fit. With your program you should figure out what classes you need for your OOP code (if it is) and what functions need to be implemented and by whom.

This is the essential and longest stage. You will need to make sure that everything is planned out and you have a basic road map of how to get to your answer for Step 1. Despite being the most essential state this is the step that everyone avoids and skips because it is tedious.

Now the best trick I can give you to making this work is to have a written list for this. Knowing it in your head is not enough. One of my recent projects had the class list and functions list occupy 3 full-size whiteboards each. That’s just a sense of how detailed you should be and how complete they should be.

Step 3 – Plan your time.
If you are working alone this is a little bit easier since you aren’t having to manage multiple schedules. But what you need to do is have a distinct order for implementation and a distinct deadline. Also when planning your time for each of the functions and details you should also delegate the task out to others if you are working in a team.

Delegating and organizing everything will greatly help you in making sure things happen in a timely fashion. But the big trick to delegating is exactly that. You must delegate. If you have a clear enough road map then you should be able to hand out tasks to people so that they don’t have to worry about other people’s work. If the timeline is followed, all will come together fairly nicely.

Step 4 – Double Check
Think you’re ready? Go back to the beginning. Run through the steps again, quicker this time, and make sure everything is covered. Review all your bases in order to confirm you are ready.

If so, you get to go at it. Begin the programming.

Now this may seem like an obvious thing to do in order to make sure things run smoothly, but you would be surprised how many people don’t utilize it. Some people get too excited for their own good. Planning and good management can be the strongest leash to control your inner programming animal.

Caution: Does Not Play Well with Others

Wednesday January 11, 2006 0 Comments

Here at RIT they put a big emphasis through all of our coursework on working in teams and being able to cooperate with others. Now I perfectly understand this mentality. It’s great when you can find people who compliments your skill-set and then being able to produce a better product or project together.

With that said, I HATE WORKING IN GROUPS. I have had three major group projects so far and I always seem to get group members who either have misplaced their brain entirely, or just haven’t read the manual yet on how to use it.

The worst is having group members who don’t yet understand or appreciate the advantage of planning, especially for teamwork. They want to forgo planning and design and just code. So when they jump into the coding they get lost and are unsure of what to do. So they just get it to work in a hodged-podged format instead of properly.

The second most aggravating part of working with others is working with people who have no sense of style standards. Despite declaring a standard for the team right from the bat I’d get code contributions from team members that is not compliant to the standard, let alone commented and readable for other people.

The one thing that I wish my professors put more emphasis on, instead of being nice all the time, is style and readability in code work. Too many times I’ve seen professors who will be like “Well, it works.” and give the credit for the work instead of fixing the issue.

The world would be better if everyone coded the same way and with the same style. Oh what a world that would be.

Putting the Muse in Music

Wednesday January 4, 2006 0 Comments

With the start of 2006 I’ve taken on a lot more design work to try and step up my status as a freelance designer. It was a risky decision taking on so many projects at the same time simply because if I don’t meet deadlines it will have a very negative effect. But I am currently getting through it all. How am I doing it?

My hidden secret that I’ve just pulled out of retirement is my handy iPod. The song lists are a little out of date and I no longer have iTunes installed to manage some playlists, but it has been a nice change of pace to aid in the design process.

I don’t know what it is, but sitting down to my desk and throwing my headphones on I just get lost in the time and in the computer screen. Last night I had a streak of an hour where I came up with 11 concept designs that I spent today fleshing out.

Needless to say that I think I’m going to keep up this practice of using my iPod and drowning out the world around me with music, oh sweet music. :) Now some of you, probably none but I still like to boost my ego, might be wondering what exactly it is that I listen to. When it boils down to it, the music doesn’t really matter and I just need something in the background. But I prefer listening to either alternative, rock, or classic rock. Occasionally the techno or country gets brought out if I’m looking for a certain style. But as long as it’s not rap and classical music it’ll be allowed onto my iPod.

What do some of you other designers and developers use for music while you work?

Make it Compatible

Tuesday January 3, 2006 0 Comments

I’ve gotten a couple of emails asking what’s the best way to get started making a site 100% compatible across multiple browsers. So I’ve gathered up a listing of some of the basic steps to follow in order to make sure your site can be 100% compatible.

The first phase when you’ve got your design completed and are moving to the XHTML / CSS coding of the layout is to start in a CSS compatible browser. For example, I start using Mozilla Firefox when I code my XHTML/CSS. I’ll get everything in order using Firefox.

Once you have everything in order in a CSS compatible browser that is when you move over to a less compatible browser. When you switch to other browsers you must obviously make small tweaks in the original browser in order to make them deal the same. The key to this phase is to avoid “hacks” at all costs. Utilize standard compliant code in order to make sure that as many browsers are understanding the CSS as possible. If this is impossible then that is when you move to browser specific stylesheets. Standard specific stylesheets will allow you to incorporate specific settings per the browser that is being used to view the site’s layout.

Once you’ve handled the most recent generation of browsers that is when you worry about going back to older versions of already compatible browsers. Only after you’ve got the most recent do you ever step back into their old and out-dated versions, otherwise you will run into issues with legacy code.

Now that you’ve got an idea of the process to use how do you check all the different browsers that are available across the multiple platforms. Well to answer that question, there are few different answers. You could …
Install the browsers on your system and test yourself.
Invite friends and colleagues for a closed beta test with a variety of browsers.
Utilize a service to simulate multiple browser environments to see how it would look.
Have a public beta where you just release the site and hope for input from visitors.

Any of these options is feasible, and used quite often, so it’s just a matter of what you feel comfortable doing to make sure that your site is fully supported across the browsers.

Good luck in your quest for compatibility.