Online Form Resources

Mike Moore — Thu, 06 Mar 2008 01:13:02 +0000

Recently I've been tasked with coming up with better options for more
functional online forms - on a budget. Improved forms should be:

Easy to setup
Easy to change
Easy to maintain
Be able to generate: Excel, CSV (comma separated values) data files
of selected information

So, with that criteria in mind, I set out, first, via code - commonly:

ASP or php (there may be others via which this can be done - these are
the two I find most often used for this purpose):

Along those lines I found sites like these which generate code based on
user input:

http://www.freeformmaker.com/ (php)

and

http://www.tele-pro.co.uk/scripts/contact_form/ (ASP or php)

just follow the prompts and poof - easy form

that works for sites designed to accomodate do it yourself forms. Not
all hosts are created equal. In that case, my case, I then took to looking
at online form hosts. The form sits on your site (or theirs) but is processed
through their system (free or for reasonable rates). Two sites I found
worth looking at are:

http://www.jotform.com

and

http://www.wufoo.com

I put together a form from jotform in about two hours. Not because it
was difficult but because it was somewhat complex. Have a look:

http://www.elcentrodelaraza.org/volreg/volreg.htm

Mike Moore
Vista Tech - El Centro de la Raza

Project: Web (part one)

John Miller — Thu, 08 Mar 2007 05:46:44 +0000

Back in January, the folks at the Community Software Lab were asked by a university-based non-profit if we could translate an artist's Photoshop mock-up into HTML and CSS. Eager to please (and needing some money to keep the budget balanced), we said "sure" and submitted our estimate for 20 hours of work. It's March, and we're still working. What's the deal?

For my part, I gratefully ignored things until the last week of February, content to let Dan, my boss, manage the project. He had subcontracted the work to Erich, our soon-to-be VISTA, and for the most part, let things be, receiving changes from Erich every few days. It worked great--as long as changes didn't need to be made immediately. Erich put together some pretty good code and certainly earned his 20 hours' paycheck. Then things began to pick up.

Dan and I met with our clients and their contractor, hired to handle eZ publish, the content management system (CMS) behind the existing website. At this point, we were asked to clean up a few errors in our code, and Dan asked me to take over managing our end of the project.

"Sounds fun!" I thought. This initial enthusiasm has kept me at times from tearing my hair out.

First task: talk with Erich and find out how many hours he's worked. Seventeen. Cool. He can fix the styling errors and fill out his 20 hours. I can stay detached from the actual coding and work on learning server virtualization, adding Gallery to another client's website, debugging our Samba server, and installing SMTP authentication on our mail server. It hasn't turned out that way.

Behind every website is HTML. Perhaps that's a bit of a simplification, but it's not too far off. HTML is the end product of every website designed for a personal computer. The web browser knows HTML, and the web browser is boss. It then stands to reason that a large part of any website's success is based on what sort of HTML it gives to the browser. Wonderful HTML doesn't guarantee a good site, but improperly written HTML throws a wrench in the works. It causes some browsers to balk while others work fine. Text turns into links; links turn into text. Cats and dogs live together. Well, it's not quite Ghostbusters-bad.

A big chunk of the issue hinges on the very first line after the server tells the browser "Content-type: text/html<CR><CR>" -- that pesky <!DOCTYPE> declaration (man, I hope Drupal escapes this sentence correctly!). This guy tells the browser which version of HTML is being delivered. There a few different versions these days, but the big ones are XHTML 1.0 and HTML 4.01. XHTML is newer and more programmer-/machine-friendly; HTML requires fewer tags. The crux of the issue, though, is how the browser handles each. Most browsers these days display content differently depending on the <!DOCTYPE> declaration they receive with each page. Give them an XHTML 1.0 declaration, they do one thing; give them an HTML 4.01 declaration, they do another. Thanks to the trial and error of many web developers, this behavior is pretty well documented. Give a browser one declaration, but give it code corresponding to a different declaration--then you have problems.

The old site used the HTML 4.01 declaration, but which declaration to use for the new site? We chose XHTML. It's definitely easier to spot flaws in an XHTML page, and stylesheets work differently with XHTML than with HTML. Mostly, though, it's an aesthetic thing. With XHTML there is no ambiguity. Every tag has a beginning an and ending, and its content is determined by the beginning and the ending of the tag, not by the browser's interpretation of the tag, as is sometimes the case with HTML 4.01. Ask someone else, though, and you'd likely receive a different answer. The point here is that there are pitfalls involved with converting a site from HTML 4.01 to XHTML 1.0. Beware of this. Don't do it just because it's trendy. Even though we're using a content management system, we'll still be uncovering small bugs a month from now.

Back in January, I first received the artists' mock-up as an e-mail attachment. I was cc'ed on the e-mail. Trouble was, in addition to the mock-up, there were two other image attachments along for the ride--a pdf file of the entire mock-up and a gif file of five pictures, arranged in a row, artfully merged together. What to do?

Well, as a bystander, I did nothing for a month. Fortunately I kept the e-mail, though I must say I rarely delete e-mails. When I finally started working on the project, we were asked to smooth out the site's banner image. It seemed a bit blurry, but I wasn't sure why. I asked Erich to take a look and send me an updated image.

Still in error-fixing mode, we needed to keep the left-hand navigation links from resizing if a word got too long. We also needed to keep the main content from dropping below the left-hand navigation when the browser window got too small. Where it existed, we also needed to update the right-hand column.

(End of Part One)

Reworking old websites

brittney fosbrook — Thu, 02 Nov 2006 21:53:27 +0000

I am currently reworking an old website for HPP, Helping-SF. This website is meant for low-income families and case managers. In it's current form, the website is very disorganized both in terms of content and also in terms of pages and locations. There are numerous broken links, orphaned pages and older versions housed within numerous local locations. Although I have some experience with dreamweaver, I have never moved an existing site to a new location. I am not sure if it would be better to work with the existing local files and reorganize that way or whether I should migrate the site to a local folder and start fresh. Any suggestions?

ALSO, I cannot log into the CTC Vista Project site from my computer in the office, but I can from other computers in the office. I was able to when I first started, but I have not been able to since. Any suggestions on how I can change that? This is the reason for my posting lack in the last couple of weeks.

Digital Arts Service Corps - website development

Online Form Resources

Project: Web (part one)

Reworking old websites