September 29, 2008

WARNING: This is a post about website creation. I am keeping the jargon and such to a minimum and I think there's content in here for non-techie people, but if you're a non-techie person, just know that you'll want to scan bits of this post to get to the non-tech stuff. (I swear I'll keep it short and intelligible!)

I have known that I need to sit down with a couple of Javascript books and learn to program a tad for quite some time now. But, I just never seem to have the time I need to devote to it. There's just always some other project that takes precedence.

I am responsible for the basic building of our church's website and it's been a while since the last design. In fact, the last design was probably around 2001 or 2002 - and it involves the old style of site building - using tables instead of stylesheets. I built a prototype design that I kinda liked and then I got all excited. What if!

What if I could make the site so the church office manager could update one file which stored our upcoming events and that would automatically update a little box on the homepage AND also update the larger events page? That would be cool! It would minimize typos and conflicting information and it would look COOL. (Our office manager is excellent and meticulous - but EVERYONE gets interrupted and forgets that they updated one page with some information and forgets that they didn't get a chance to update the other area. This would just simplify things.)

I know, in theory, that I can build a type of file called an XML file and we could store all of the event information there. Then, I knew there was a way to tell the various webpages, "Hey, go get this information and put it on your webpage." I was pretty sure this involved Javascript ... but like I said, I've never quite gotten around to learning Javascript. So, I hunted around online a few times, looking for a script which would do this and generally experienced EPIC FAIL in attempting to find what I wanted.

At one of my job interviews last week, I was asked if I knew Javascript. "Crap," I thought to myself. "I really need to learn this!" The interviewer shrugged and asked if I knew jQuery.

"I've looked at it a few times, but I haven't used it yet."

"Well," he replied, "that's really what we use. You should pick it up quickly."

"It's a Javascript library, isn't it? So you don't have to know Java superwell to use it anyway, right."

Pretty much. (For the non-techie who are still reading - all this means is that bits of Javascript code are already written for you - and stored in a library. It's better to think about it in terms of LEGOs. These snippets of code make up different LEGO bricks. So as a non-programmer, all you have to do is put the bricks together to build the program you want.)

So this morning, I was sitting at the computer, surveying my now beautiful and clean living room - my project Friday and Saturday had been bulldozing the living room - and wondering what my next project should be. With my allergies, I can't clean house too many days in a row or I'll wind up sick and in bed. I firmly believe dust should be left in place because cleaning it just throws it all back into the air and into my lungs and nose until I can't breathe.

At any rate, I looked around the clean room ... realized I had no projects pending really ... and I thought, hey! This is the perfect time to look at jQuery.

Oh. My. Word.

One of the first things I see is a tutorial on using jQuery to parse (read) an XML file.

The library itself is only about 54kb ("The minified version, while having a larger file size than the packed version, is generally the best version to use on production deployments."). I had expected from their quote that the larger file size would be a lot more than 54kb.

There's a great tutorial session which has already given me what I need to build a prototype for the church website. I can have the homepage show the event, date and time ... and the events page can show those items plus show a longer description. It will take me a little time to finesse the script to display everything the way I want, but I'm really excited to be able to add some dynamic functionality to the church website -- and to know that I can add that to my own sites or new creations as I move forward.

Now, of course, I have a major project! Seriously go to town on the church website.

Even if I don't get that job (and boy oh boy oh boy am I hoping that I do get it!), I've learned something useful and will probably springboard me into finally really learning javascript.

Posted by Red Monkey at September 29, 2008 5:19 AM | Design | | StumbleUpon Toolbar Stumble |


David Rodger said:

I see the article says it's important in these days of Web 2.0, but why would you want the client (browser) to parse an XML file? Surely the whole thing would be quicker on the server side? (You might use any of PHP's XML functions, for example.)

I thought Web 2.0 was mainly server-side scripts reading remote sources and spitting the whole mashed-up thing to the browser!

Secondly, you want someone in the church office to be able to update the file. Do you expect that person to write raw XML? (That's a bit of a troll, because if you can write a script to present events to a site visitor, you can write one to present a form of some sort to an administrator.)

Thirdly, where will that all-important file be kept? An administrator of the sort I expect would work in such an office is probably more accustomed to keeping files on a local file system or a server in the building. Are you going to make that server available to the internet (with all the dangers that entails)?

Finally, that file is going to get pretty big (unless it's pruned -- and if you want a record of past events, you may not want to). Relying on one ever-growing XML file is going to cause your site to crawl. (Apple's iPhoto uses an XML file to store metadata about all the photos you keep in it, and it takes forever to load as a result.)

Honestly, wouldn't it be simpler to have a Google account, save events in Calendar and use the API to access that for the web site? That'd be pretty Web 2.0!

Red Monkey says: Thanks for your comments. I don't pay much attention to what's Web 2.0 or 1.0 or version whatever (I saw a site claiming web 3.0 the other day) - so that part is not an issue.
1) Why have the client parse instead of the server? I don't know PHP and I did figure out how to do it with jQuery. I ran searches off and on for quite a while to figure this out in PHP or AJAX or Javascript and I couldn't figure out quickly how to do this.
2) Given the semantic nature of the XML file I created and our office manager's computer skills, yes, I think she can keep this file updated easily.
3) She can access it via the server just fine.
4) The file will only have the up-to-date info, so yes, it will be pruned frequently. At this time, the events page is currently a static HTML page which is frequently updated to keep up with events. Using the method I posted about gives us the ability to only update one page instead of trying to update the homepage and the events page - but I don't claim it's the best way to do this. It's just the first way I was able to make work like I wanted. As for Google's calendar - I looked at that and a couple of other calendar apps and I never found one that I both liked the calendar and the way the APIs looked on a site - I wanted more control of the look & feel.
5) And this will probably make all of my decisions more clear to you and make you shake your finger at me all at the same time: I'm primarily a designer, not a developer. I enjoy digging into the code and learning how to make my grand ideas work. But since I'm not primarily a developer, I often am behind in my ability to use the absolute most perfect, most appropriate tech to achieve a certain effect.
At this point, I'll probably start out the site using what I have and then begin exploring the PHP route you've suggested.
September 29, 2008 8:03 AM

I read the article as it said there would be stuff for fairly non-techical people (like myself). Sadly it went way over my head. We run our church website in www.church123.com. They have an easy to use content management system (so I don't have to worry about the code stuff). I thought I'd mention it as they have 20 or so pages of free hints and tips for churches. Even if you are a techie you may find them of some use. Hope the site goes really well and that you get that job. Paul

Red Monkey says: I'm sorry it was too techy for you. We already have a system in place - we just needed some backend coding is all. Hopefully this will help someone else!
September 30, 2008 6:14 AM


David Rodger said:

There won't be any finger-wagging from me! Given your current skill-set, I can appreciate that this solution, if it works, would be the most viable. And there's no reason you couldn't change it later. Even without another language under your belt, so to speak, you might later add the event entry/update page using the jQuery.

Keep in mind that you might have a certain number of events a month, which makes predicting the likely size of the XML file easier, some events might be planned and announced a long way ahead. If there's a significant number of them, that file size could blow out.

So unless the number of events is quite small, you might find Javascript is pretty slow ... until we're all using Google's new browser anyway!

A counter-argument is, of course, that perhaps I'm too concerned about "premature optimization" (look that up in Wikipedia).

Red Monkey says: I suppose that must be the crux of the issue - we have very few events going during a single month. So far, the test site is loading pretty darn fast. Later on, when everyone gets used to having that functionality and we continue to grow - you're right, we'll probably need to switch to something else later on. And by then, hopefully my skills will be up to it as well.
Thanks so much for continuing the conversation - I really appreciate it!
September 30, 2008 6:34 AM
Free Pixel Advertisement for your blog