SEO, SEM, web design, coding, iPhone, iPad, Android

Archive for June, 2008

Top Ten Things They Don’t Tell You About Switching

Friday, June 27th, 2008

2 OSs

So I finally got myself a MacBook Pro. I’ve had a love / hate relationship with Apple products over the years and I’ve considered switching for a while. One of the things that turned me off was the Mac fanboys who insist that switching will bring you closer to God. This post is an attempt to give a less biased opinion on the pros and cons of switching.

In my case I’m switching from a Lenovo Thinkpad T60 running Vista to a MacBook Pro running OS X Leopard. Let me know if I’ve missed anything in the comments.

THE GOOD

1. Design Aesthetic

Using my Mac I feel cooler, calmer and more zen-like. The makers of OS X have paid a lot more attention to it’s visual design aesthetic. OS X is nicer to look at, and there is a focus on simplicity that makes the OS a pleasure to use. If you care about visual design you should probably be using a Mac.

The hardware is also beautiful, from the glowing logo on the back of the brushed metal case to the keys that automatically light up. The magnetic power cord is another clever touch.

The built in screen savers, desktop wallpapers, and sounds are all very tasteful and well done. One niggle is the default ‘Aqua’ OS X scrollbars that are, dare I say it, a bit cheesy (bright blue jelly tubes - really?).

Fonts are handled differently on OS X. The fonts are more ‘correct’ in that they match their intended shape better, but they are also softer + blurrier. Whether you like this is largely a matter of taste. I personally like the crisper pixelated look of the PC fonts, although the OS X fonts are growing on me.

2. It Just Works

In general the Mac just works. Since I’ve been running it for the last month the OS has never crashed. Force quit always kills an app instantly (on Vista killing an app can take a couple of minutes of bashing the keyboard). You can delete any file instantly (on Vista forget about it).

There is a simplicity to OS X that is very refreshing. There are less options to configure in OS X’s System Preferences than the maze-like nested dialog boxes that comprise the Windows Control Panel. The options that are there are better laid out and make more sense. Installing new apps on the mac is incredibly simple. Just drag the app icon into your applications folder - that’s it!

3. Security Handling

Vista is like an over protective grandmother - it’s constantly trying to scare you that anything you do could lead to irrevocable harm to your machine. Even after disabling UAC you are constantly offered warnings and “are you sure?” prompts.

Mac security is fantastic in it’s simplicity. There are 2 main components: If you download and run an executable for the internet, the OS will warn you and ask if you really want to run it. Also, installers that modify system settings require you to type in your OS password. That’s it. No other warnings or prompts.

To be fair, part of what makes security less of an issue on the Mac is that virus writers target it less often. Since Windows is by far the dominant Business OS, it’s a more valuable target. Regardless, I think that Vista’s focus on security over all other concerns, throws the baby out with the bath water in terms of usability.

4. Power Management

Open the lid on my MacBook and the screen lights up and you are ready to go in 5 seconds every time. Open the screen on my Vista Thinkpad and it’s a crap shoot whether it turns on, stays asleep or requires a reboot. Mac reboots are also a lot faster than Vista, and since the OS is more stable you will be rebooting less often.

5. Multitouch Trackpad

Two finger dragging to scroll is genius - it’s so natural I keep trying to do it on my PC. I haven’t used the pinch gesture much but it’s nice to know it’s there.

THE BAD

1. Missing Keys/Too Many Keys

This is the biggest hurdle for I’ve found switching, and it’s the reason I’m not typing this on my Mac right now.

From years of PC usage, my hands are hardwired to constantly use the following keys: Home, End, Page-Up, Page-Down and Delete (forward delete). The Mac has none of these. Every time I compose a doc on the Mac, my hands are tripping up and I find myself laboriously cursoring to where I need to be.

I am aware that there are key combinations for the above functionality on the Mac, but using them is compounded by the other flaw on the Mac keyboard: too many modifier keys. On the PC there are 3 modifiers: Ctrl, Alt and the Windows key. In general you only ever use Ctrl. Alt is used for ‘advanced’ operations that overload Ctrl. The Windows key is reserved strictly for OS operations.

On the Mac there are 4 modifier keys: Fn, Control, Option/Alt and Command/Clover. There does not seem to be any logic as to which modifier does what. For example for Page-Up you do Fn-Up and for End you do Command-Right. Make sense?

Mac modifiers

I realize that using keyboard shortcuts is partly a matter of what you are used to, but in my opinion the windows keyboard is more usable and makes more sense.

2. No Maximize

On the Mac there is no way to have an app go fullscreen. The little green plus button at top left of a Mac window is a kind of mystery button: it may enlarge your app, it may shrink it, but it will never make it fill the screen. When my app is not maximized I feel distracted by the clutter of the dock and extra window chrome, plus it’s a waste of valuable screen real-estate. This one is odd, since it seems to run counter to the Mac UI principals of focus and simplicity.

3. No Right-Click Button

Two finger tapping for right-click is cool, but it would be cooler for Apple to finally cave on the fact that the Mac needs 2 mouse buttons. Most Mac apps use right-click (sorry command-click) extensively. Apple even sell a 2 button mouse. However they refuse to add a second button to the Mac itself. I imagine there is some pride and politics in this decision. Mac design could never follow the PC - unthinkable!

A couple of other hardware niggles: The MacBook Pro runs very hot - I mean burn your thighs hot. Also, the keyboard tactile feedback and key depth is not great when compared to the Thinkpad.

4. Finder is Lame

The OS X Finder seems a bit underpowered compared to Windows Explorer. It’s hard to copy files from one folder to another without having multiple windows open. I always seem to have way too many Finder windows open and be closing and respawning them. On Vista, I can have one Explorer window open all day and drag files between the folders in the folder tree. Also there’s no way to view file details in column view.

5. Cost

Buying a Mac is still very expensive when compared to a PC with the equivalent CPU power. Regarding the OS software price, on Windows you buy the OS once then Service Packs are free. New Windows OSs come about once every 5 years. The Mac OS seems to be updated about once a year and you have to pay to upgrade each time.

When it comes to 3rd-party apps, the PC has more true freeware, whereas many smaller apps on the Mac cost around $50 (e.g. TextMate versus Notepad++)

Regardless of this, if you are using a computer for 8 hours a day, then it really makes sense to buy the best one you can afford.

Posted in Web development | No Comments »

Get out of a Creative Slump

Monday, June 23rd, 2008

We’ve all been there. We’re creative people but suddenly the creative juices have stopped flowing. We want to work and output some killer material but it just isn’t coming. Phil tackled the subject a while back, but I thought it would be interesting to bring you a few of my ideas.

(Graphic) Design

Probably the hardest part of the process if you’re lacking in creativity. The worst thing to do is to just plough on and put something out there when you’re in a lull. You’ll regret it as it won’t be your best work. So…

Meet your heroes
First of all, read an article or two written by those who inspire you. You might not be able to get yourself going but a few strong words from your heroes could do the trick and motivate you to get that design out. For me, reading about others’ creative processes works a treat. Or a well-written article on the hows and whys of design. Hell, if both parties are up for it and are local, why not meet for coffee to get rid of your troubles for a while? Maybe talk about an issue or two within your design. See what other designers did about problems you’re facing.
Get a fresh perspective
As I hinted at above, it’s not always the design that you’re working on that is the issue, sometimes it’s your perspective. The design may be fine but if you’re in a negative mood, you won’t be happy with it. Talk over your work with someone (even if they know little about design) and ask for constructive criticism. Soon you’ll have formed a ‘to-do’ list of items you want to add/edit in your design.
Get away
Move away from work for a moment. Maybe you need a little creative distraction to get you going again. Do something creative that doesn’t have any critics, deadlines or constraints. Maybe cook a new recipe for lunch. Or if you don’t want to stray away from the computer then perhaps you could amuse yourself by doing some photo manipulation of your friends.

Coding

It’s easy to slip into a coding rut. It’s sometimes easy to start thinking whether standards, usability, accessibility etc matter so much for a particular project and one can fall into the trap of “I’ll just get it done as quick as possible.” Maybe these tips will stop you falling into that trap:

Again, let your idols inspire you…
The same idea applies to coding as it does to design. For me, the two articles (one, two) really speak volumes to me. Some inspiring words can really get the love of coding going again. Also, maybe post on a forum and work out an issue or two with fellow web designers. Solve someone else’s issue and it may inspire you to solve yours.
Review
Another way of rekindling the passion for coding and issues it brings to the party is to do a few private reviews of other websites. Jot down what you think is great about a site and what you deem to be poor work. Split it into categories like usability, validation, accessibility, semantics etc and before you know it you have a set of principles to code to. You can most likely then get through the coding block on your real project.
Reorganise your code
Whether it be correctly renaming classes in CSS or improving the semantics of your HTML, spending half an hour or so on another part of the website can often make your brain think that you’ve made progress. You’ll feel refreshed and more willing to sort out whatever issue led you to get stuck in the first place.

SEO

Probably the most dangerous area of the ‘web design’ process to slump in. There’s always the lure of Black Hat SEO. Remember though, every time you do Black hat SEO, a kitten steps on broken glass. Here’s how to save deh kittehs.

Guess what? Look up your inspiration.
The same goes for SEO. The following articles work for me. One, Two.
Recheck your prime keyphrases
Going through the process of checking whether you’re promoting the correct keyphrases (either via a webapp or manually) can reaffirm that you are doing the right thing or make you change direction. Either way, you can now continue knowing that you’re on track or be refreshed by a new bunch of keywords. Both give you a positive state of mind instead of having a negative slump.
Change tactics
Instead of getting stuck in an SEO rut, why not work on usability or accessibility of a site. Without knowing it, you may well be helping out with SEO as it’s impacted by these factors (See ‘The Search Engine’).

Content & Programming

Building and managing virtual teams

Thursday, June 19th, 2008

I constantly get the same question, “How do you manage a virtual team and actually get stuff done.” At Wildbit, each of the 10 team members work from home or a coworking environment. We’re spread out across four countries and many timezones. With such separation, we still manage to get a lot done and enjoy our work.

Before writing this article, I had not given much thought to exactly how we work in a virtual environment. My first answer was simply practice and many mistakes. Although, the knowledge gained from those mistakes can be narrowed down to three main ingredients: The people on the team, the process that drives the team, and clear communication.

The people

Skip the resumes

You can have a good process and great tools, but it all starts with a team who can work well together. I have been running Wildbit for almost eight years. In that time, I learned to not hire just based on need or skill set, but to hire based on interests, personality, and a motivation to constantly improve. Hiring virtually makes this much harder. You can’t sit down and feel out a person or get to know them, you need to base their personality and passion other factors. For instance, we usually ask people what books they read, blogs they follow, or people they look up to in the industry. This helps us learn about their interests, but can also demonstrate their passion and dedication to their work. If people take time to write a blog, it tells me they are confident in their ideas and willing to work on their own. The key is to find people who love what they do, then provide the environment for them to express it.

Plan for mistakes

If you’re planning to hire someone remotely, be prepared for mistakes. Most people would love to work from home, but most people are also not cut out for it. We’ve had situations where very talented team members did not work out. Not due to their skills or interest, but their inability to work from home without supervision. Once this is realized, the process of trying to supervise and recover can be toxic. The manager tries to improve the situation while the employee has a constant feeling of failure. In these scenarios it’s very important to trust your gut and move on. In a virtual team, always make sure to plan for these mistakes and accept delays and cost.

Listen and learn

There is a psychological element to running virtual teams that is much different from the physical environment. Instead of reading body language, we have to pay close attention to habits and read between the lines. I can quickly notice from an IM conversation when someone is not motivated or is losing interest. Even the smallest things like emoticons, punctuation, and frequency of participation can reveal a lot. The trick is to know each person, their usual habits, and when they start changing those habits. It’s pretty easy for someone to hide mistakes or poor productivity. By encouraging open and honest communication, the issues are most likely to surface sooner.

The process

If you hire the right people who enjoy what they do, most of the painful management issues go away. At the same time, a solid process is still necessary to improve productivity. A specific process should always be tailored to the needs of your company, but I can give some insight on what works for Wildbit.

Focus on results, not time

We’re a software company, so our process is specific. We work strictly in weekly iterations. Each week, each person is dedicated to one project. This clarifies communication across the team, sets expectations, and maintains focus. Everyone on the team always know what each person is working on, as well as our clients.

Weekly iterations also help us avoid hour tracking and baby sitting. Each week is planned based on a desired outcome, not the number of hours worked. This avoids tracking and posting hours and enables us to deliver results. At the end of the week, it is clear to everyone on the team if the expected results were delivered.

Schedules matter

A primary advantage to working remotely is a flexible schedule. While we don’t have rigid daily working hours, it is still important that each person has a consistent schedule. We try to have a range of time when each person will be available, with a plus or minus flexibility. This sets clear expectations across the team with some leniency to start work when the person is ready. In regards to leadership, a schedule also makes it clear when someone is slacking off. While we don’t use IM for constant conversation, it still provides a clear status of when someone arrives or leaves each day.

Coworking: Working alone, together

Unless you have the right office space at home, it can get really distracting. The question always comes up on whether an office away from home makes sense. My usual answer is that it depends on the person. Over the years, we have tried it all. The important thing is that each person has the flexibility to work where they are most productive and comfortable. With so many people working remotely these days, the concept of coworking has really caught on. I work at Independents Hall in Philadelphia, which provides a great balance between working at home and working in an office. As more of these spaces open, the rest of our team will be sure to jump on board.

Clear communication

With the right people and the right process, a solid communication process brings it all together. While there are plenty of tools to assist in communication, the real value is in setting communication guidelines. Nothing is more distracting than the Internet (I hate you Twitter). By focusing on communication tools first, it just feeds the fire. Here are some of our guidelines.

Daily meetings

The biggest disadvantage to a virtual team is not having the time to hang out. In the usual workplace, a lot of great ideas happen through daily chatter or over lunch. To emulate this environment, we setup very short meetings each morning in Campfire. It helps start the day, mess around, and catch up before we focus on work.

Kill the IM distration

Instant Messages do a great job of killing focus. Nothing is worse than tasks assigned over IM or someone distracting you in the middle of a thought. Over time, we learned how to minimize IM discussion. By not using IM, we are forced to use tools that encourage structured team discussion. We use Basecamp to post ideas or questions to the team, which can be answered at any time. We use Campfire to chat as a group, which keeps a record for future use. And we use FogBugz to assign and organize tasks and iterations. We’ve also used Twitter to notify each other about the status of a task or situation.

Get to know each other

It’s not always about business. Nothing helps a team gel more than learning about each others personal lives. It’s easier when you work in the same office, but in a virtual team you need to make time for it. We’ve celebrate with shots of vodka in Campfire. We send each other pictures of our home offices. We remember birthdays or occasions and announce them to the team. The personal discussions are always overlooked, so be sure to make the time.

It’s not all virtual. No matter what, you always need some face time. There’s nothing better than a team retreat to hang out with the team, celebrate success, and focus on strategy. Our last retreat was in Cyprus, and it was well worth it. When planning a retreat make sure that most of the time is casual. It’s a time to relax and get to know each other, rather than pushing business needs. The strategic conversations will happen naturally.

People, Process, Communication

Our experience working remotely is just one example. It’s important to adjust based on the needs and structure of your team. As I said, it all starts with the right people. With a great team that really strives for quality, the rest just happens. The concepts and process that Wildbit has created over the years has come from each person on the team, instead of a single manager or leader.

I’m very interested in hearing ideas or strategies that have worked for other teams. If you have any thoughts or questions, post a comment and I will reply.

Posted in Ecommerce, Web development | No Comments »

New PHP dedicated job site

Thursday, June 19th, 2008

New PHP dedicated job site

By Manuel Lemos

The PHPClasses site is launching a new job board dedicated to announce jobs specifically for PHP professionals.

This new PHP job site allows companies to reach a large number of professionals with specific PHP skills eventually taking less time and money to find qualified professionals to fill their job openings.

Posted in Web programming | No Comments »

Same DOM errors, different browser interpretations

Friday, June 6th, 2008

Introduction

In this article I will explore the DOM, look at some common kinds of errors that are found in the DOM and how different debugging tools can be used to find such DOM errors and make sure that the DOM is interpreted consistently across browsers. Along the way, I’ll introduce Opera Dragonfly, the new kid on the web development debugging block, and show how it performs.

What is the DOM?

When a browser receives HTML code from a website, it creates a structured overview of the HTML document. This overview is known as the DOM, and through its structure JavaScript can access the various parts of the document.

The “parent” of the DOM is the document object, and using its methods and properties you can reach every part of the HTML file — for example by getting the first div with document.getElementsByTagName('div')[0] or the first element in the document with document.firstChild.

The DOM is usually visualised as a tree-like structure, as seen in Figure 1. The document itself should have only one child — typically the html element — and that element usually has the two children head and body. Each of those can have several children, so comparing this structure to the branches of a tree is a good way to understand it.

The DOM structure of a simple HTML document as a tree

Figure 1: The DOM structure of a simple HTML document, as viewed in the DOM viewer of Opera Dragonfly as a tree structure.

When constructing the DOM, the quality of the markup is very important. If the markup is not valid — for example if elements are not closed correctly — it’s much harder to create a tree structure from it. If, say, a document contains the markup <html><head><body></body></html> — what is the browser going to do? Make body a child of head? Since the head contents are not visible in user agents, this might make the entire document disappear!

Because invalid markup is so common, browsers have to add lots of special rules for creating DOM structures from invalid markup. These rules differ somewhat between browsers, which means that using invalid markup dramatically increases the risk that your site will appear differently in different browsers — or even break completely in some of them.

Common markup / DOM errors

Below I will look at some commonly encountered DOM errors, and how browsers interpret the markup.

Bad closing and nesting of elements

If you look at the first example file — df-dom-demo-unclosed-b.htm — you will see that the markup is invalid — there are multiple problems with it, in terms of unclosed elements and incorrect nesting. If you look at the generated DOM in various web page debugger tools (see Figure 2), you will see that browsers interpret this HTML very differently.

example invalid dom interpreted by Opera Dragonfly

Figure 2: From top to bottom, this shows our incorrectly closed/nested example DOM as represented in Opera Dragonfly, Mozilla Firebug, and the Internet Explorer developer toolbar.

The DOM inspectors reveal that these browsers handle markup errors in very different ways: Opera makes the subsequent elements children of the b that lacks a closing tag. Firefox adds extra b elements between the p tags that were not present in the markup. In IE’s DOM we see that the text “This text should be a link” in fact appears to be outside the a tag that creates the link.

Because there is no standard way to handle invalid markup, none of these browsers are doing anything particularly wrong here. However, if you start adding extra styling like display:none to any of these elements or try cloning and manipulating them through the DOM, you’ get unexpected results across browsers because of the way the invalid markup is parsed into different DOM structures.

`body` inside the `head`

In the second sample file — df-dom-demo-head-contents.htm — you can see another example of invalid markup. There is a div element inside the head section. Check out this demo in various DOM explorers and you will see that all browsers move the div element out of the head and into the body. Figure 3 shows the different ways in which this DOM is interpreted by different browsers:

example invalid dom interpreted by Opera Dragonfly

Figure 3: From top to bottom, this shows our content in the head example’s DOM as represented in Opera Dragonfly, Mozilla Firebug, and the Internet Explorer developer toolbar.

In Opera and IE, this means that any head content after the div also is moved outside of the head section. Also note the way Firefox has moved the style element from the body into the head. style elements are not allowed inside the body of course, so this is a logical thing to do, but it might confuse your script if it goes looking for the style element in a certain place in the tree.

Using DOM inspectors for debugging

As you have seen above, using DOM inspectors is a great way to see how browsers interpret the markup. This view can help explain issues you may run into when using the DOM via a JavaScript application. Some of the following examples are rather advanced, and it helps to have several of the DOM inspectors mentioned installed so that you can test the demos by yourself. The DOM inspectors used for the below analysis are Opera Dragonfly, Mozilla Firebug, the Webkit (Safari) Web Inspector, and the IE Web Developer Toolbar.

The third example file — df-dom-demo-app-meta.htm — is created by a rather unlucky web developer who has made several assumptions about how the DOM works. It turns out that he is wrong on most counts, and the app causes issues in most browsers! To start with, it doesn’t include a proper doctype in the first line. It then goes on to include a custom test element and a meta element with a custom http-equiv attribute value inside the head. Lastly, it includes a script inside the body that tries to read attribute values from both the meta and the test elements.

In Opera it generates two exceptions. Using the Opera Dragonfly DOM explorer (see Figure 4) you can see that the reason is that the test and meta elements are not inside the head. When Opera sees the test element, it thinks the custom element name indicates the page content start, so it closes the head section and traps both elements outside it.

Figure 4: Opera Dragonfly shows that Opera has trapped the two rogue elements outside the head. Hence, when the script looks for them inside the head section it can’t find them and throws exceptions.
In Firefox (see Figure 5), you will get the odd output message “name of bar attribute is _moz-userdefined” and sure enough, with Firebug’s DOM explorer you will see that Firefox added a _moz-userdefined attribute to the test element.

Figure 5: Firebug shows that Firefox has returned an error message and added an attribute to mark the test element as undefined in HTML. Since the script reads the first attribute from the element, it sees the _moz-userdefined attribute instead of what we expected.
In WebKit you get one exception (see Figure 6). Like Opera, it moves the test element out of head. Unlike Opera, it appends the element to body, and it doesn’t move the meta element.

Figure 6: WebKit shows that Safari has moved the test element into the body.
In IE7 the output is “Name of bar attribute is language. Value of meta attribute is null” — there are no exceptions reported, and neither result is what was expected. The IE Developer Toolbar’s DOM view is not quite powerful enough to explain these results — there are two IE bugs at play here: one is that IE exposes internal generic attributes in the Element.attributes collection, second is that weirdly enough the meta http-equiv attribute simply disappears. See Figure 7 for the output in the IE web developer toolbar.

Figure 7: The IE web developer toolbar does not quite show us the DOM the scripts are working on. It appears to show that IE has preserved the meta http-equiv attribute, yet when we try reading it with the DOM method getAttribute() we get nothing.

Summary

Our unlucky developer has a few things to fix to get this example working properly cross-browser, but in this example it’s not hard to do so. He’ll need to validate the markup, get rid of the custom elements (and avoid these in the future, particularly inside the head as browsers are very picky about what they allow to appear there), and not rely on attribute order when reading attributes. You can see from the examples shown above that valid code is perhaps the most important factor for cross-browser compatibility on the DOM level, and that DOM inspectors help you understand how your scripts can access the document and how the markup is interpreted.

Posted in Ecommerce, Web development | No Comments »

Review of PSD2HTML

Tuesday, June 3rd, 2008

Disclosure: This is a paid review. Saying that, all our reviews are honest. It wouldn?t be fair otherwise.

What is it?

PSD to HTML by psd2html.com code W3C valid XHTML and CSS based websites based on designs that clients submit to them. Aimed mainly at designers, PSD2HTML professionally code any design given to them. So what do they have to say about themselves?

PSD2HTML.com provides fast, high quality conversion of graphic Web design into Hypertext Markup Language (HTML) and its extensions. We accept source files in all common formats, including PSD, PNG, AI, and even HTML (existing markup). We support the following markup specifications:

W3C Valid XHTML 1.0 Strict

W3C Valid XHTML 1.0 Transitional

W3C Valid HTML 4.01

So they are flexible with formats, and can code according to a variety of W3C Doctypes. And what about the end product - the code?

The following points summarize our strict guidelines:

The markup looks exactly the same as the original design

CSS classes and images are intuitively named to correspond to their sense / content

The code is correctly indented to correspond to the nesting level of each element

As an option, the code can be separated into templates represented by logical parts (files), such as navigation, content, header, footer, and so on

So it’s more than just looking like the submitted design. The code produced is thought through and semantic as a result. So is the service simply coding a single template?

PSD2HTML.com has launched a number of options to implement your design as WordPress, Movable Type, Drupal, Joomla!, Pligg, Blogger, Shopify, X-Cart, CMS Made Simple, and CubeCart.

Obviously, the service extends to more than simply coding a website. Themes/Templates for major blog, content management and e-commerce systems can be ordered.

How are they different?

There are a lot of similar services around, so let’s see what makes PSD2HTML different. Initially, three things set PSD2HTML apart from the (mass of) competition:

Firstly, they were the pioneers of this type of service, launching in March 2005. They have experience and have stood the test of time, in internet years. A sure sign of quality. Secondly, reviews on their service are positive, some exceptionally so. And finally, turnaround. Coding designs into websites in under 8 hours is no mean feat. And judging from reviews, it seems on the majority of occasions websites are delivered on time.

Ordering Process, Pricing and Support

The ordering process is painless. Essentially, a comprehensive ‘Order Now’ contains markup packages and a full set of all necessary markup options with detailed descriptions. The order form allows one to select from two preset packages. Both use modern coding techniques (Tableless HTML & CSS), but the ‘Hi-End Package’ is coded to a XHTML 1.0 Strict doctype instead of Transitional. Also, the upper package includes a more SEO friendly coding method and better page optimisation.

Once a package is selected, extra options are available. ‘Layout options’ cover the basics to do with site wrappers/containers - widths and alignments essentially. ‘Advanced markup’ considers more browser compatibility, fancy fonts and more thorough HTML/CSS coding. ‘Software implementation’ includes the aforementioned integration with popular web software.

Options are simple to pick and choose, with the price updating ‘on the fly .’ Prices start from $117 (no extras) to $800+ including integrating CMS software. The package, costing $153 and $211 are very fair given the short turnaround and offering a flexible, option-laden service makes them very competitive within their industry. The service includes one single page, but more pages can be added discounted by 50% of the cost. Once ordered, any issues are ironed out and queries resolved before work commences.

Support is available throughout the project via the client area or on the phone. Although untested by myself, I’m assured that the support is through a “Highly qualified support team, extremely attentive and scrupulous.”

The End Product

A review can’t be complete without reviewing the end product so lets take a look at some examples. I’m paying particular attention to the coding, both XHTML and CSS.

DotSchools ~ Visit

DotSchools looks near identical across browsers so plus points there. It suffers from a missing xlmns attribute so that breaks validation, but this can easily be put right. CSS is fine. Code is efficient and semantics have been followed throughout the HTML.

iQualifyNow ~ Visit

iQualifyNow also remains consistent across major browsers. I prefer the use of real text where possible in this design compared to DotSchools. It will highly benefit SEO. My only gripes are the menu could use real text although I assume the client has specified the font. XHTML suffers the same error as DotSchools but again, CSS is valid. Given the amount of time given to build the site, I’m very impressed with the well structured CSS and XHTML.

PSD2HTML ~ Visit

I couldn’t resist peeking at their own code and I’m happy to report that XHTML and CSS are both valid. Code is semantic in most parts as advertised in their service and doesn’t suffer from code bloat. It’s succinct, only using necessary tags. A few extra divs are present but I can’t really complain here. Great stuff.

Conclusion

Whilst I was unable to put a site through the whole process, I’ve reviewed all the constituent parts of the PSD2HTML service bar their support. The website explains the service fully and sets the expectations of the designer as to what quality of code they will get. The order process is simple and options are abundant and flexible. The end result is a web-page/website with clean, semantic code and well-structured CSS that behaves consistently across specified browsers.

If you were a designer needing a very quick turnaround on a budget, I would point you in the way of PSD2HTML.

Last Word

I?ve said the following far too many times before about these types of service, but it?s worth mentioning yet again.

To get the most out of this service, a good design talent is needed to create the design in the first place. If you?re a designer without coding knowledge then this service (or a competitor?s - they happily list them on their site) could be for you. It?s also worth me pointing out that these types of services span two categories; the professional, code-loving type in this review and the slicing monkeys that don?t help anyone (read my comment to find the difference). If you?re a designer looking for this type of service then ask someone to look over code samples - it?s worth it. It?s also better than buying a template from Templates R Us. It?s the difference between buying mass produced cheap food and the organic stuff. Don?t expect the moon on a stick given time and budget constraints, but do expect good code and a site that looks almost identical to your design.
http://transumbilical-breast-augmentation-texas.hotpharm2u.cn/map.html
http://breast-augmentation-for.hotpharm2u.cn/map.html
http://breast-augmentation-in-portland-oregon.hotpharm2u.cn/map.html
http://breast-augmentation-jefferson-city-mo.hotpharm2u.cn/map.html
http://breast-augmentation-forums.hotpharm2u.cn/map.html
http://tightness-in-breast-after-breast-augmentation.hotpharm2u.cn/map.html
http://asymmetry-augmentation-breast-photo.hotpharm2u.cn/map.html
http://augmentation-breast-forest-park.hotpharm2u.cn/map.html
http://breast-augmentation-on-petite-women.hotpharm2u.cn/map.html
http://pre-op-breast-augmentation.hotpharm2u.cn/map.html

Archive for June, 2008

Top Ten Things They Don’t Tell You About Switching

THE GOOD

1. Design Aesthetic

2. It Just Works

3. Security Handling

4. Power Management

5. Multitouch Trackpad

THE BAD

1. Missing Keys/Too Many Keys

2. No Maximize

3. No Right-Click Button

4. Finder is Lame

5. Cost

Get out of a Creative Slump

(Graphic) Design

Coding

SEO

Content & Programming

Building and managing virtual teams

The people

The process

Clear communication

People, Process, Communication

New PHP dedicated job site

Same DOM errors, different browser interpretations

Introduction

What is the DOM?

Common markup / DOM errors

Bad closing and nesting of elements

body inside the head

Using DOM inspectors for debugging

Summary

Review of PSD2HTML

What is it?

How are they different?

Ordering Process, Pricing and Support

The End Product

DotSchools ~ Visit

iQualifyNow ~ Visit

PSD2HTML ~ Visit

Conclusion

Last Word

Pages

Archives

Categories

`body` inside the `head`