What Josh Does at Youthworks

I’m employed by an organ­i­sa­tion (the one I referred to in my first post about this project, wherein I didn’t bother explain­ing exactly what was going on, but hoped it would be clear to those who already knew) that exists to — amongst other things — resource youth ministry.

One thing we’ve noticed (“we” is myself and a hand­ful of oth­ers with an inter­est in the web) over the past twelve months is an uptake in web usage by youth min­istries — for obvi­ous rea­sons: that’s where kids are spend­ing their time, and it’s a great com­mu­ni­ca­tion tool, and every­one else is doing it.

When I say every­one else is doing it, I actu­ally mean every­one else is try­ing to do it. Every­one has, for the last six to twelve months, been writ­ing the same appli­ca­tions, inte­grat­ing the same soft­ware, pay­ing for the same soft­ware, attempt­ing to train the same peo­ple, and gen­er­ally doing a lot of the same stuff, sep­a­rately. With no point of inter­sec­tion or shar­ing or intel­li­gent resource management.

This is under­stand­able: after­all, the web presents a rel­a­tively new front for churches in gen­eral, and whilst kids have been wast­ing time online for years, only with the rel­a­tively recent advent of social net­work­ing web­sites (I refer to it as ‘Soc­Net’ in these parts — no-one else seems to, but I like it, so what­ever) have the less computer-inclined began spend­ing sig­nif­i­cant amounts of time in front of a keyboard.

There’s also a bit of a catch-22 when it comes to build­ing these things. Peo­ple ask, what are the ben­e­fits? We’ve never had some­one come along to youth group because of our website! — well, no, you’re right. But you also don’t have a web­site, so that’s hardly fair, is it? Nine times out of ten peo­ple will not come along to church (gener­i­cally) because they’ve searched for a church in a par­tic­u­lar sub­urb in Google (though, speak­ing of that, I’ve got to do a bit of SEO work on the Matthias site — it’s not on the first page for a “Church in Padding­ton” query. Changed the title, it’ll be a while til that kicks in. We’ll see.)

They’ll come because a friend asked if they wanted to, or they were walk­ing past and heard peo­ple inside, saw them going in, and won­dered what it was all about.

But this is hardly exclu­sive to hav­ing a web­site. If they have those points of con­tact, a web­site is a great way to invis­i­bly inves­ti­gate fur­ther with­out need­ing to make them­selves uncom­fort­able. It’s easy to find these sorts of web­sites through search engines — you walked past a church and noted its name, you remem­ber the name of your friend’s church, etc.

The same goes for youth groups, obviously.

Peo­ple have just been start­ing to realise this, or at least think of it at all and decide “yeah, we could do that”. So, there’s the ratio­nale for it all. Most peo­ple with decent web­sites already may not have con­sid­ered ratio­nale in any great depth — they’ve got a good web­site because they know some­one who makes them, and vol­un­teered their time (maybe they’re a leader), throw­ing some­thing together with Xoops in an after­noon. It’s quick and dirty, but effective.

We’re try­ing to spend a small but not insignif­i­cant amount of money to equip peo­ple to do these sorts of thing, so it’s only sen­si­ble that some more time is spent con­sid­er­ing what on earth we’re try­ing to achieve. Hence the lengthy pre­lude to what it actu­ally does.

Now, the fea­tures. We have too many tar­get audi­ences for it to be an alto­gether com­fort­able project, but that’s half the fun of it. The prod­uct is being mar­keted to churches (who pay for it) through lead­ers (who want to use it) and for youth (who actu­ally aren’t the cen­tre of the uni­verse on this one, but we need to give them UX that says they are). Out­side of these three, there are also the friends of the youth already in the appli­ca­tion who are just check­ing out the youth group page.

Of course, it’s not quite that sim­ple. We’re also mar­ket­ing this to camps, high school scrip­ture groups/lunchtime bible groups, and maybe bands/events. Which is great and tech­ni­cally only a small step, but it does pretty hor­ri­ble things when you try and explain who’s pay­ing for what in a con­cise business-like fash­ion. If you’ve read this far, chances are you’re well aware that concise-ness has never been my strong point.

So, with these tar­gets in mind, we are (firstly) going to equip them with web­sites. Big woop. WordPress.com and Blog­ger eat your heart out. Cue yawns.

No, seri­ously. We’re going to give them (‘them’ being the var­i­ous enti­ties described above, not indi­vid­u­als so much — there’s no way I’m posi­tion­ing this against other Soc­Net sites because I reckon it’s too frag­mented to last… Face­book or Myspace or Bebo or.… yes.) web pages. Wel­come to 1999.

They’re going to have web pages with cal­en­dars they can chock full of the sched­ule for the term, though. So that’s exciting.

And everyone’s going to have their own user­name, so they can leave com­ments on the inevitable blog­ging ele­ment with iden­tity — this is won­der­ful for com­ment– and generic form-spam. Inci­den­tally, I read a few blogs that Wild St peo­ple are writ­ing and was really excited to see they’re actu­ally enthu­si­as­tic about doing it. There’s quite the bunch of them on Blog­ger these days, and it’s all com­pletely autonomous — so far as I know, no-one has pushed them to start doing it. I was so proud of their keen­ness and inno­va­tion for build­ing up com­mu­nity and spread­ing the gospel! Another aside, my copy hasn’t arrived yet but I believe there’s some­thing about blog­ging in The Brief­ing for Decem­ber (it’s not on their web­site yet, either). My copy arrived today, and I dis­cov­ered the cur­rent issue is in their web­store, just not on the main site. It’s The Brief­ing #339, if you’d care to read it.

Any­way. Blogs will fea­ture. Cal­en­dars will fea­ture. All the stuff you’d rea­son­ably expect to be able to do with a CMS tool these days will fea­ture. Blogs, cal­en­dars, gal­leries, con­tact forms, sta­tic pages. Yay. So that’s the bor­ing stuff that we’ve just got to do the grunt-work for at some point (I’m sure it can be fun, but, just between you and me, I’m not really look­ing for­ward to the cou­ple of weeks we have to spend on that bit).

Now, for inter­est­ing and inno­v­a­tive fea­tures — because, let’s face it, the above is hardly enough to con­vince any­one to switch their exist­ing web­site (if indeed they have one) across to a hosted plat­form for a nom­i­nal (to be deter­mined, but prob­a­bly only payable by church groups, and not for camps/events on account of these being once-off) monthly fee.

Con­tact tools. Yummy. We’re going to give them mail­ers that make it easy to send a mes­sage to, say, all the kids in year 10. Or just guys. Or girls in year 8. Or only to your co-leaders (we’ll have a resource area where they can share files — Word doc­u­ments, PDFs, slide shows — on the site, too: that’s some of the fun CMS stuff). But email’s been done before. Everyone’s used email. Admit­tedly, some­times you just wish there’s a bet­ter way to store and man­age lists of peo­ple, and this tool will cer­tainly do that, but it’s a lit­tle bor­ing still.

So we decided it’d be a good idea to throw SMS into the mix. It’s not just a gim­mick: again, this is in response to what peo­ple are already doing. The only dif­fer­ence is it’s paid on a shared account (used by the lead­ers — the youth kids won’t have access to these tools, for fairly obvi­ous rea­sons) and inte­grates the same con­tact man­age­ment fea­tures as the mailer app. We’re hop­ing con­ve­nience will draw peo­ple across to this tool. Use sce­nar­ios are basi­cally just that you’d use this tool to inform peo­ple of what’s going on this week at youth group, or remind­ing them that the group is on bring­ing sup­per this month, etcetera. The orig­i­nat­ing num­ber will be that of a sin­gle leader, or it could even be that of that person’s own leader.

For exam­ple, one mes­sage is sent to all kids by the group co-ordinator, but that mes­sage is altered depend­ing on who the indi­vid­ual recipient’s bible study leader is, so that it appears to orig­i­nate from them. Obvi­ously com­mon sense would say that you wouldn’t do that with­out con­sul­ta­tion, so we’d prob­a­bly have a check box in the leader’s “my account” page that would say “Allow mes­sages from other senders to orig­i­nate from my mobile num­ber”, or some­thing to that affect.

Beyond con­tact tools, we want to take advan­tage of the fact that this is a service-based prod­uct and entirely a hosted solu­tion. Part of the rea­son we’re strongly pur­su­ing that is it gives an oppor­tu­nity to equip and direct in a way that decen­tralised sites can’t be. So, a few things we’re think­ing of doing are cen­tralised offer­ings like weekly newslet­ters (sent to lead­ers two days in advance so they’ve got an oppor­tu­nity to see it first) and global blog prop­er­ties that give reviews, cur­rent affairs com­men­tary, etc.

That’s the end of the uni­ver­sal fea­tures that are great for kids and lead­ers alike, but there’s lots more for lead­ers. As I’ve already said, we want this to be self-funding. Part of this is sell­ing elec­tronic ver­sions of dead-tree prod­ucts, as DRM’d PDFs, or as unen­cum­bered PDFs with watermarks/obviously time-sensitive adver­tis­ing (so vio­la­tion of copy­right is glar­ingly obvi­ous). The other part is (for me at least) far more excit­ing, and that’s reselling user generated/contributed con­tent (UGC) under an iStockPhoto-esque model (Basi­cally, profit sharing).

This isn’t just about words on a page — I want to get plenty of video stuff hap­pen­ing, too, because (espe­cially in reformed evan­gel­i­cal Anglican/Baptist/Presbyterian, etc. churches) that doesn’t get nearly enough of a work out as is. It’s a really effec­tive tool for sup­port­ing preaching/bible stud­ies, and it’s been largely over­looked until prob­a­bly early this year (I had my first con­ver­sa­tion with some­one about video resources for small group bible stud­ies as late as July or August this year, I think! They had used a Matthias Media resource which I haven’t encoun­tered, and thought it really helpful).

Pric­ing mod­els for all that are still a lit­tle up in the air, but, from a consumer’s point of view, it’s def­i­nitely going to be afford­able. The project will ulti­mately sit on a server main­tained gratis and depend largely on vol­un­teer labour to admin­is­ter con­tent. The only “costs” are those to the estab­lished Youth­works pub­lish­ing divi­sion, but hope­fully we can tran­si­tion the way they do their high-school level con­tent effec­tively, so they’re com­mis­sion­ing con­tent for the web and sell­ing it there. Some­thing that’s really excit­ing is the pos­si­bil­ity that, instead of com­mis­sion­ing con­tent, it’s pos­si­ble to pur­chase it directly and already cre­ated from a pool of resources on the website.

There’s def­i­nitely a work­able model here, somewhere.

Prayer is greatly wel­comed for:

  • wis­dom try­ing to fig­ure that model out
  • energy and resources to make it hap­pen (in what­ever form)
  • adop­tion and enthu­si­asm from youth lead­ers and kids
  • effec­tive­ness in web strat­egy as we attempt to use it as an evan­ge­lis­tic out­reach tool, and a tool for the growth of exist­ing ministry
  • and, hand-in-hand with that last point, that God’s will be done and if He wills it, that growth would be given!
# by Josh on November 30th, 2006 Tags: , , , , , , , , , , , , , , , ,
| 1 Comment »

Sunrise Family website

A screen capture of the Sunrise Family website

The site

This is the vaguely alluded to web­site of a few days ago, for Seven Network’s break­fast show (I refuse to describe any such com­mer­cial net­work dri­vel as “cur­rent affairs”!), Sun­rise. The Sun­rise Fam­ily is essen­tially an incentive/loyalty scheme vaguely akin to Triple M’s (recently-abandoned… doubt­less to be re-released in nearly exactly the same form under a dif­fer­ent brand) Freq Club and Enter­tain­ment Book–style dis­counts. There might be more later on, but that seems to be about it so far as what’s there right now. And, truth be told, I’m not really sure what else is com­ing… I’d love to replace Sunrise’s bor­ing ROSwall form with some­thing akin to the infa­mous Flash Just Let­ters inter­ac­tive fridge thingo, though maybe in an add-only type way, which would link in to view­ers’ exist­ing Fam­ily login (i.e. so they don’t have to enter their name every time, etc.), but that’s just an idea of mine.

The tech­nol­ogy

So, the deals.

The inter­face is using AJAX, presently with inline onClick trig­gers — because, unfor­tu­nately, I’m not quite good enough to make it pull the data from the ID… though, if you view source, I’ve setup the ID’s to have two pieces of data in there. If any­one can tell me how to write an event han­dler that con­verts an ID into a string which I can then feed to an onClick han­dler (and, server-side, explode() using PHP) I’m still very keen to fix that “prop­erly”. The ID’s have two data ele­ments because the Deals inter­face is designed to add sup­port for mul­ti­ple states (i.e. localised offers, etc.) in the future. And they’re pre­fixed by d_ because, obvi­ously, valid iden­ti­fiers can’t start with a num­ber. D can stand for “deal” or “data”, whatever :-)

As for how the AJAX is pulling down data, I’m just using inner­HTML, because it works in pretty much every­thing and is lots faster and lots sim­pler than “real” DOM meth­ods, espe­cially here. Observe the “Details” pane on the right of that page, and how there are dif­fer­ent num­bers of para­graphs of text, dif­fer­ent types of data (lists, anchors, etc.), then con­sider how ridicu­lous it would be to use DOM script­ing there. Euu­u­uc­cch. So, I’m not-quite stan­dard but per­fectly com­fort­able about that. I am, how­ever, using HTML 4.01 as the doc­type. There is no rea­son to use XHTML, and I’m not happy to use XHTML and not serve it prop­erly. And, if I serve it prop­erly, it’s too likely to break (parsers spit the dummy when encoun­ter­ing bad XHTML, because tol­er­ance is zero) for a pro­duc­tion site. Fur­ther, obvi­ously, inner­HTML doesn’t work when doc­u­ments aren’t served/parsed as any­thing other than text/html.

I’d rather do absolutely awe­some HTML 4.01 than valid but mediocre (and ulti­mately point­less, see­ing as it’s not being parsed as XML even) XHTML.

In other nifty technology-related stuff, Yahoo!7’s part­ner­ship means (hope­fully) that Seven will up the ante in terms of what tech­nolo­gies they’re unfurl­ing. For us, this means tak­ing a step for­ward and pro­vid­ing syn­di­ca­tion ser­vices (both Atom and RSS for­mats) for the deals. For Seven as a whole? Well, maybe they’ll start to get rid of their once-ubiquitous table-based lay­outs, and (maybe) embrace more of an open broad­cast­ing par­a­digm in line with their web strat­egy — assum­ing Yahoo! are direct­ing that in any way, and/or that Seven’s online team have open minds — I don’t really know and haven’t per­son­ally dealt with any­one there, so I’ll just assume they must have a hand­ful of cluey peo­ple on board!

The RSS and Atom feeds won’t be avail­able if you’re check­ing it out on Mon­day, but it’ll likely be run­ning by the end of the week. For Yahoo! users, this means they can add Sun­rise Fam­ily Deals to their per­son­alised page (but, seri­ously, who uses por­tals? I never under­stood that whole thing). For every­one else, you should be able to down­load a feed reader and add the feeds. I’d love to have a page telling peo­ple how to do this on the site, but imag­ine Yahoo! would object. So I’m say­ing it here: the peo­ple that mat­ter know how to do it! (Though, I imag­ine, the “peo­ple that matter” — you, dear reader — aren’t par­tic­u­larly reg­u­lar Sun­rise view­ers. Or, like me, never Sun­rise view­ers. Heh.)

We’ve also imple­mented a spot of JavaScript to fix text-selection in Inter­net Explorer. My lay­out is pretty insane in terms of the sheer quan­tity of absolutely posi­tioned ele­ments, which broke that func­tion­al­ity in Inter­net Explorer. One quick ques­tion to the WSG mail­ing list later, some­one had pro­vided a JavaScript fix (which we had to edit a lit­tle bit to make work prop­erly, because we had prob­lems with flick­er­ing ele­ments even with cache enabled).

The eye-candy

I’ve imple­mented use­less (but rather cool) eye-candy on the Deals page in the Details pane when­ever a new deal is selected. A vari­a­tion of the Fade Any­thing Tech­nique, which is only meant to be pretty. No orig­i­nal­ity is claimed, we’ve had this tech­nol­ogy all millennium.

Acces­si­bil­ity

Dis­able JavaScript and you lose the fades, and use a lit­tle more band­width as the entire page reloads for every item you click. In terms of non-visual user agents with JavaScript dis­abled, I’ve put the “Details” above the list of offers in source-order, and on every reload they only hear “Sun­rise Fam­ily. Link: Skip to main con­tent” (pre­sum­ing they select the link) before get­ting to the actual details, so I’m fairly happy on that front.

Addi­tion­ally, I’ve got the “header” from Yahoo!7 last in source-order, so any­one with assis­tive tech­nolo­gies don’t have to skip over that EVERY TIME they change the page. It was a lit­tle painful to fig­ure out, not in the least because Yahoo’s sup­plied uni­ver­sal header isn’t at all nice for sites that are built prop­erly — i.e. with web stan­dards and acces­si­bil­ity in mind — but I much pre­fer it this way. This is also some­thing we had to achieve silently and with­out com­plain­ing, because, whilst any­one who has a clue about web acces­si­bil­ity will imme­di­ately see this is a good idea, mar­ket­ing peo­ple would con­ceiv­ably think: “But we want peo­ple to see our search bar more often!”. Er, no, you don’t achieve any­thing by piss­ing off users. No mat­ter, we pulled it off with­out mak­ing any noise about it!

We’re server-side sniff­ing for Fire­fox and hand­ing it an “Add Yahoo!7 to the Fire­fox Search Box” link (which, inci­den­tally, has par­tic­u­larly hor­rid inline JavaScript — but I don’t care because the only UA it’s being served to can do some­thing use­ful with it), whilst IE users get a “Make this my home­page” link in its place. Yahoo’s ver­sion (which you can see on Seven’s — pure Flash, *oblig­a­tory shud­der* — Aus­tralian Open web­site, though I think that ver­sion (of the header, not the web­site) might now be dep­re­cated) uses JavaScript for that, but it was fairly obtru­sive and, see­ing as we have the abil­ity to do that server-side, I’d much rather reduce page weight.

In terms of acces­si­bil­ity gen­er­ally speak­ing, I’ve bun­dled in all the usual good­ies such as a skip to main con­tent link, as well as skip to login on the front page, base font size of 100.01%, and rel­a­tive font siz­ing through­out… but exten­sive image replace­ment tech­niques mean that the head­ers are prob­a­bly sub-optimal in terms of vis­i­bil­ity. This one is out of my con­trol, and every­one else in the work­place seems to love small text (even Lyn, who seems to often put on glasses to read things on a screen… go fig­ure!) so I wasn’t going to fight too hard about it. All other text will scale pretty well, with the excep­tion of the deals — because the lay­out is so tight, it’s only really pos­si­ble to go up one, maybe two size steps in most browsers.

We’re lack­ing any explicit acces­si­bil­ity state­ment, and we’re also lack­ing access keys. Mostly because I’m con­vinced access keys are prac­ti­cally use­less, and rarely bother to imple­ment them. (On forms, there are never enough but­tons for access keys and/or there’s no log­i­cal com­bi­na­tion avail­able, and every­where else it sort of seems a bit point­less unless every­thing has an access key. Where do you draw the line?)

This site is inter­est­ing to me because, even though it’s a tele­vi­sion audi­ence, I still can’t make assump­tions about how peo­ple will be brows­ing. PDA devices, for exam­ple, would strug­gle with our built-for-1024 lay­out had we done it with tables. For this site, PDA/mobile users are real­is­tic: for exam­ple, if some­one inci­den­tally is near a Wendy’s store and remem­bers they might’ve seen some­thing on the Sun­rise web­site but can’t remem­ber the details, they can quickly and pain­lessly look it up.

Fur­ther, the site also has to cater for peo­ple with cog­ni­tive or motor dis­abil­i­ties. For cog­ni­tive dis­abil­i­ties, one thing in our favour is that we’ve pro­vided a short sum­mary of each deal before a more heavy-duty full­text item. For users with motor dis­abil­i­ties, the entire web­site should be acces­si­ble via tab­bing — includ­ing the JavaScript-enabled Deals page.

I lost an argu­ment regard­ing target=“_blank”, but will even­tu­ally win this point. A hand­ful of adver­tise­ments — includ­ing those for intra-network links, such as for the Seven Store — open in new win­dows, which I am most cer­tainly not a fan of. All exter­nal links, how­ever, should have the rel attribute set to exter­nal. There is unfor­tu­nately no visual cue asso­ci­ated with this. Links I count as my biggest area of defeat in this web­site, which is pretty good (as in, I’d rather it just be that than some­thing more sig­nif­i­cant such as iframe usage, enor­mous usabil­ity prob­lem though new win­dows may present).

Inline JavaScript is com­pletely unre­lated to acces­si­bil­ity in light of the way this has been imple­mented. Admit­tedly, it would be advan­ta­geous to use event han­dlers in place of inline JavaScript (and we will be think­ing that to our­selves as we look at the traf­fic sta­tis­tics), but from an acces­si­bil­ity per­spec­tive it has very lit­tle impact. Stan­dard HREF’s are defined, and caught with Javascript using return false; No func­tion­al­ity is lost. I much pre­fer this method to scat­ter­ing iframes through­out the site! At any rate, I’m still try­ing to resolve this one, acces­si­bil­ity related or not. It’s a mat­ter of per­sonal pride, I suppose.

The Styles and Bugs

The entire design (done in-house by Dacien) is awe­some (in my opin­ion — if I didn’t think it was, I just would have kept quiet about it), but very tight.

So tight, in fact, that I had to set outline:0; on some links to stop Fire­fox from break­ing the lay­out (1 pixel dif­fer­ence) when a link was active (as they are when you click a deal and it’s caught by JavaScript rather than actu­ally reload­ing the page — the link remains active), adding a 1 pixel dot­ted bor­der. Cross browser sup­port is pretty awe­some — it should be good in IE back to 5 — Opera, Safari, Kon­queror, and even (mostly) IE 5.2 Mac are happy. Fire­fox deserves spe­cial men­tion: it has so many lit­tle (big for this site) things wrong with it that it’s often rather painful to make work prop­erly. In fact, of all browsers men­tioned, Fire­fox 1.0.x (on non-Windows plat­forms) is the only one whose behav­iour I’m def­i­nitely not happy with (mostly because I expect bet­ter from it, but also because it gets some things hor­ri­bly wrong).

Such as, for exam­ple, the “Meet the Fam­ily” page. It works per­fectly or near-perfectly in every other browser, but cer­tain Fire­fox vari­ants on cer­tain plat­forms ren­der only the first two items in the “Sun­rise Team” list(/right col­umn, if you’ll excuse my presentational-speak) on first load… and then ren­ders per­fectly if you refresh the page. This is what I meant by my “pre­dictable inad­e­quacy” post of a few days ago. I’m fairly cer­tain it’s some­thing to do with floated list items, but pos­si­bly not.

Another bug is (also in Fire­fox — notic­ing a trend, any­one? No, I didn’t build for IE. I wrote about 90% of the stylesheet sit­ting in Fire­fox 1.5.x using Chris Pederick’s Web Dev exten­sion, and both that browser and Opera oper­ate near-perfectly) Fire­fox 1.0.x’s pen­chant for adding scroll­bars where they’re not required with overflow:auto (see front page on non-Windows plat­forms, and the Deals page — lots of style overlap/common classes there, so this is to be expected).

By far the most inter­est­ing ren­der­ing dif­fer­ence I encoun­tered build­ing a lay­out this tight was between Inter­net Explorer/Windows XP with and with­out Win­dows Themes enabled. Yes, it does make a dif­fer­ence. Inter­face wid­gets shouldn’t really inter­fere with styles at all, IMO, but they did here. The solu­tion basi­cally entailed shav­ing off a cou­ple of pix­els where required, so I didn’t come up with some­thing par­tic­u­larly inno­v­a­tive for it!

Sum­mary

In all, I’m pretty happy with the site. Seven’s inter­nal Online team appar­ently noticed/complimented our team on the absence of lay­out tables, which I (per­haps arro­gantly) take with some degree of indif­fer­ence: peo­ple shouldn’t be build­ing sites with tables for that pur­pose any­way. If we are to be com­ple­mented, then it should be on the design (and, as part of that, achiev­ing a design this ‘tight’ with CSS), or on the usabil­ity ben­e­fits realised by intel­li­gent inte­gra­tion of AJAX, or the devel­op­ment pace (again, par­tially because of the flex­i­bil­ity CSS gives us), or maybe on light­weight, seman­tic code as a cost-saving mechanism.

Truth be told, I now believe we may have even gone a lit­tle over­board with the tables elim­i­na­tion. If I could do it all again, the Deals page would fea­ture a table instead of a list, and I’d use DOM script­ing to insert/delete records rather than replace the “state” part with inner­HTML. The markup might gain a (very) lit­tle bit of weight, but it’d be worth it. It would, of course, remain seman­ti­cally sen­si­ble and com­pletely acces­si­ble. It’d prob­a­bly be more seman­ti­cally sen­si­ble, actu­ally. I realised a table would work great about two days after I’d fin­ished styling the list, and thought “I’ve put way too much effort into this to pull it now”, but felt like Dave Shea must have after build­ing a “pseudo table” with­out real­is­ing. At least it wasn’t that complex!

Any­way, I’m really inter­ested to hear what peo­ple have to say about the site. We’re being plugged every half hour on Sun­rise tomor­row morn­ing from 6am, and will be anx­iously watch­ing the server to see what, exactly, the effect of pro­mo­tion on a show with 4 mil­lion view­ers daily has on band­width, etc. I’ve also installed an AWstats tracker to col­lect aggre­gate data (as on this site) which we’ll parse later on (assum­ing the hor­ri­ble mon­ster that it’s run­ning on, Zeus, out­puts normal-ish log files for me! Oh, and it doesn’t sup­port mod_rewrite, but instead has some retarded alter­na­tive that seems like a cross between VBA and Apple­Script — and fails as much as the lat­ter did in terms of actual ease of use, despite try­ing to use human lan­guage. It’s very dumb.) to fig­ure out how Aus­tralia is doing in terms of browsers, oper­at­ing sys­tems, screen res­o­lu­tions, JavaScript sup­port, and the like. Should be incred­i­bly inter­est­ing stuff, and I can’t wait!

# by Josh on January 30th, 2006 Tags: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,
| 8 Comments »