Wednesday, June 3, 2009

Going Custom: What We've Learned So Far

 
Here's some of the lessons we've picked up taking our Lil Nyet web site from a packaged to a custom platform:


  • No matter how portable a commercial host says your site is, be skeptical. A rebuild is probably required, both because of design differences, and the fact that canned code tends to be sloppy. Some of the pages we inspected from our previous host (now called Yola) were dismally sloppy, though in their defense our big sites probably taxed their resources.
  • No matter how well you get along with you coding help, asking someone to code a complex website is like asking them to write a novel based on an outline, and expecting it to come out the way you want it. There is a lot of uncertainty, especially at the beginning and end.
  • I have spoken about my enthusiasm for the simple trick of dynamic art -- items that change when you visit or refresh the screen. I still like the effect, but you have to consider what will work well. If you have a dynamic zone next to your title, for example, and the title is your main character's name, you are setting people up to assume that whoever appears there is the main character.
  • I would like to say that working with coders, even friends, relieves you from programming knowledge as much as having a merchandise fulfillment company relieves you of shipping knowledge. If you're comfortable buying a car without knowing its operating fundamentals, fine. But I find myself increasing the amount of time dedicated to learning CSS and PHP the more I become involved in collaborations. Some programmers speak English and some speak Codish, so learning as much Codish as I can helps.
  • I advocate having an overview understanding of the key languages, especially XML, CSS and some PHP, though database languages I prefer to leave to others. For example, here's a fine CSS  site that can demystify, or, with practice, lead to mastery.
  • Advice to double or triple your estimated completion time is accurate.
  • Impasses give way. Sometimes when it seems that people want to go in different directions, the best approach is to set aside the issue and work on something else for a day.
  • Clear, prompt email communication is essential. Test in advance.
  • Sleep on big decisions.
  • Most people seem to underestimate the importance, complexity and programming issues associated with typography. I hope to find good source material on this for future mention here.
  • Monitor your load speed for finished pages in case the programmer doesn't.
  • Have the bulk of your design figured out and run it by the coder before you begin collaborating. Then, make adjustments. It's often the design time that causes project time to expand.
The new site will be ready to view soon, and I'll be sure to mention it here.

Also:

I've been trying Verdana for the font for this blog for a bit. I'm going back to TNR if there aren't a ton of complaints.