Please be praying we find someone good (or, suitably sinful but repentant and appropriately talented, because there’s nearly no such thing as a good person).

Ad proper after the break:

A Christian youth organisation (Anglican Youthworks) is looking for a programmer to commence immediately as part of a small team.
This is a project-based role in which you will be equipping youth ministries across Sydney with web-based communication/publishing tools and quality evangelical content.

If you have experience in:

• building dynamic websites using MVC-style PHP, Python or Java
• with a relational database (MySQL/PostgreSQL preferably, but it’s a clean slate!)
• publishing PDF documents securely online
• creating AJAX-powered interfaces securely
• connecting to 3rd party service providers using APIs (payment gateways, SMS, etc.)
• using code versioning systems (Subversion or CVS)

We’d love to hear from you.

Knowledge of frameworks such as Django, Struts or similar would be beneficial.

Learn more about the project at http://cyiada.com/

This high-visibility project would suit a young developer with a passion for sharing Christ and building up his disciples through the Internet.

Interested applicants please email joinus.code@cyiada.com

Josh Street
Anglican Youthworks | CYIADA Project

It’s almost frustrating to find such good and mature CMS products on the market and not have any need to use them for CYIADA… I spent the last week mostly trying to shape fairly simple data models for different aspects of the website and it’s rapidly becoming clear just how structurally complex multi-tiered community/community generated content sites are. At least in terms of relational DB complexity, yes, this is bigger than MySpace.

Anyway, SilverStripe looks worth a look for simpler endevours.

The complexity is mostly introduced where users become authors, which defies traditional CMS workflow altogether. It’s also far more structured than Wiki systems are, and far more private. Privacy is being balanced against flexibility which is being balanced against community and all of these are being met with time/cost concerns.

But I like to keep telling myself I don’t really know what I’m talking about and getting a programmer will solve all these dilemmas … yeah, right.

I’ve got sick of sitting on my hands and just want to be a web practitioner again. I know the product inside out, it’s been planned to the hilt, stakeholders are universally intrigued/waiting for it, and I’m being impatient and feeling generally like charging forwards. Which is, in all probability, not the best way to be approaching things.

These two consultants came in a week ago and we explained the project to them and (what I heard was) they said “we want flowcharts and scope documents”. I’ve killed a few trees in my time, but the next person to help me in that isn’t going to be a consultant telling me to rehash (yet again — I’ve written documents in so many forms, website copy so many times, etc.) what I’ve got without any further input. I’m in this weird place now where waiting for a programmer is nearly required for further planning action, and everyone but me appears to want more planning before action… meanwhile, I’m writing models for Django and scaring myself with the complexity and learning Adobe products better and generally landing squarely back in front-end territory, which is where I’ve comfortably been for the last two or so years. Well, with the exception of Adobe products, which I only finally caved to last year… whatever :P

Then it hit me — this is perfect for shuffling documents around. CYIADA (see-uh-da), is (partially) about selling documents and resources electronically — and it does that with pre-paid credits. This, of course, means that there doesn’t have to be any cumbersome checkout stage. Better than Shopify (excellent though that is), potentially.

Drag documents you like when browsing into a floating “My Resources” bin on the side of the page, AJAX is used to throw up a “confirm purchase” DIV which presents simple “yes”/“oops” options, and keep moving. It’d be trivial to modify the confirm view to have a “purchase for my whole group” checkbox (which would, of course, change the cost), too. Anything beyond that might be too complex.

Of course, there would be graceful degradation for those without JavaScript turned on… because someone has to ruin the party :P

Because it’s a library, it’s basically one big search engine. Which means that autocomplete is a really handy thing to have, and being able to click on a piece of information and edit it straight away (so, taking plain text and converting it into a textarea or input field for editing immediately, without a separate admin view) is absolutely priceless for moving through a library quickly. This is so the way content editing should be heading — I’m hoping we all get there in the end.

But even more exciting than Javascript usability gimmicks was to see that he’s still using CSS, now more extensively and without assistance, and with kick-arse semantics. I looked at the source of his page quickly and the only complaint I had was his use of a span for a header instead of an Hx… totally wonderful to see a few months after the resident standards nazi (that would be me) has taken off!

So we threw around ideas about that (including ripping timecode off DV tape and trying to set marker points, importing EDL’s for use inside the library, automating transcoding processes and exporting H.264 or FLV for previews, and a couple of other equally fun things), then eventually started chatting about what I’m doing over here at Youthworks these days.

I think I made him kind of jealous. I’ve seriously got one of the best jobs in the web development world right now. I get to come up with stuff that’s genuinely useful for users (and productive for the Gospel, yada yada — that’s the implicit goal of all of this), entirely in response to their needs, without being burdened in particular by history, or legacy systems that need to integrate, or any major competitors — it’s wonderful. So we started talking about platforms and whatever and I said I was considering Django (and got a big tick accordingly, which was nice) with an RDBMS (i.e. MySQL, just because that’s pretty much all I have experience with insofar as DBs go) but then outlined a bit more about the project and he recommended an LDAP system pretty strongly.

LDAP is a directory-based database which is strongly heirarchical and finely granulated in nature. Which is bloody useful when you’ve got a user structure five layers deep:

But, of course, moderators do not “contain” leaders any more than leaders “contain” youth. All of these tiers exist independently of one another. They are internally defined by their extrinsic relations, even though their user experience of the website will vary depending on their heirarchical position. The latter makes LDAP seem entirely sensible, but the former definition of personal identity (that is, what constitutes a “self” or independent user entity — a Distinguished Name, in LDAP-speak) seems to rile against that directory concept.

“Moderator” is, in fact, a property of “Leader”. That is, it is a quality belonging to the user, who belongs to the group “leader”. Users should be unique and belong to an Organisational Unit (again, in LDAP speak) that reflects their role within the system. Thus, moderatorship generally will necessitate belonging to two OUs: one does not cease to lead within their own group context if they are appointed as a sitewide moderator — likewise, moderators may be appointed who do not have any formal role as a leader of a youth group. (This problem may be circumvented by creating such users at a CYIADA Global administration level, instead — for example, I do not lead a youth group in the target demographic, and I volunteer to edit content occasionally: I am not the webmaster administrator (hypothetically), but require moderation powers without being a leader associated with any group).

Groups, of course pose their own set of stupid difficulties. They appear to have no heirarchy at all: indeed, even where they could (for example, a Katoomba Convention branch with KYCK, KYLC, KEC, etc. sub-branches, or a CMS branch with Summer School, MMM, etc. sub-branches) this isn’t particularly useful (and, consequently, not desirable).

They don’t constitute OUs, because OUs have already been used to assign roles (probably a bastardisation of standard X.520 practice, but so much of this will be I don’t particularly care). The only way I could see it working would be by defining multiple Organi[s/z]ation components, but even then…

I don’t know. My head has been in relational database space for so long I want everyone to have a numeric identifier linking them to another table chock full of organisation records. It makes me comfortable. But then, LDAP would manage authentication and roles, if not association, and appears to generally have potential to make life a lot easier. So perhaps there’s some way to connect directory and RDBMS happily?

Feedback more than welcome. I’m not worried about platform specifics, just about the theoretical architecture of such a beast (and my conception of LDAP in general). If you’re reading this and know anything about OpenLDAP or AD or RHCS or any other platform, or just know about connecting to existing sources and extending them, please leave a comment and make me happy :-)

Modest gradients, no shadows, occasional (even rare) curves (logo excepted, but I think the logo sucks/is childish so whatever), and tables for layout.

Oh, wait…

I’m using it now because I want to put something quick and dirty together, but there’s no way I’m seriously considering changing anything else to WordPress 2.0.x, nor, in the future, will I consider building other sites around it. There’s one blog-only site (this is unusual: we’re not that groovy and Web 2.0 — RSS feeds seem to be an uphill battle!) we’re going to do this week at work: that can be my initial foray into TextPattern.

From there, who knows (Who knows all). If I don’t like it/it’s not flexible enough (Fortunately, WordPress is rather flexible. I’m not stuck with it’s crappiness, I’d just prefer not to have to deal with it in the first place.), it’s probably back to the land of roll-your-own solutions again. There are a few decent-looking Rails-esque frameworks for PHP floating about out there at the minute, so I might try using one of those. Apparently Rails/Ruby is ridiculously slow compared to PHP, so I’d rather not use it and really like it and be trapped in this framework that’s very Web 2.0, very expendable, and very crap.

Can you tell I’m embittered with web (2.0) products at the minute?

The site

This is the vaguely alluded to website of a few days ago, for Seven Network’s breakfast show (I refuse to describe any such commercial network drivel as “current affairs”!), Sunrise. The Sunrise Family is essentially an incentive/loyalty scheme vaguely akin to Triple M’s (recently-abandoned… doubtless to be re-released in nearly exactly the same form under a different brand) Freq Club and Entertainment Book–style discounts. 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 coming… I’d love to replace Sunrise’s boring ROSwall form with something akin to the infamous Flash Just Letters interactive fridge thingo, though maybe in an add-only type way, which would link in to viewers’ existing Family login (i.e. so they don’t have to enter their name every time, etc.), but that’s just an idea of mine.

The technology

So, the deals.

The interface is using AJAX, presently with inline onClick triggers — because, unfortunately, 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 anyone can tell me how to write an event handler that converts an ID into a string which I can then feed to an onClick handler (and, server-side, explode() using PHP) I’m still very keen to fix that “properly”. The ID’s have two data elements because the Deals interface is designed to add support for multiple states (i.e. localised offers, etc.) in the future. And they’re prefixed by d_ because, obviously, valid identifiers can’t start with a number. D can stand for “deal” or “data”, whatever :-)

As for how the AJAX is pulling down data, I’m just using innerHTML, because it works in pretty much everything and is lots faster and lots simpler than “real” DOM methods, especially here. Observe the “Details” pane on the right of that page, and how there are different numbers of paragraphs of text, different types of data (lists, anchors, etc.), then consider how ridiculous it would be to use DOM scripting there. Euuuuccch. So, I’m not-quite standard but perfectly comfortable about that. I am, however, using HTML 4.01 as the doctype. There is no reason to use XHTML, and I’m not happy to use XHTML and not serve it properly. And, if I serve it properly, it’s too likely to break (parsers spit the dummy when encountering bad XHTML, because tolerance is zero) for a production site. Further, obviously, innerHTML doesn’t work when documents aren’t served/parsed as anything other than text/html.

I’d rather do absolutely awesome HTML 4.01 than valid but mediocre (and ultimately pointless, seeing as it’s not being parsed as XML even) XHTML.

In other nifty technology-related stuff, Yahoo!7’s partnership means (hopefully) that Seven will up the ante in terms of what technologies they’re unfurling. For us, this means taking a step forward and providing syndication services (both Atom and RSS formats) for the deals. For Seven as a whole? Well, maybe they’ll start to get rid of their once-ubiquitous table-based layouts, and (maybe) embrace more of an open broadcasting paradigm in line with their web strategy — assuming Yahoo! are directing that in any way, and/or that Seven’s online team have open minds — I don’t really know and haven’t personally dealt with anyone there, so I’ll just assume they must have a handful of cluey people on board!

The RSS and Atom feeds won’t be available if you’re checking it out on Monday, but it’ll likely be running by the end of the week. For Yahoo! users, this means they can add Sunrise Family Deals to their personalised page (but, seriously, who uses portals? I never understood that whole thing). For everyone else, you should be able to download a feed reader and add the feeds. I’d love to have a page telling people how to do this on the site, but imagine Yahoo! would object. So I’m saying it here: the people that matter know how to do it! (Though, I imagine, the “people that matter” — you, dear reader — aren’t particularly regular Sunrise viewers. Or, like me, never Sunrise viewers. Heh.)

We’ve also implemented a spot of JavaScript to fix text-selection in Internet Explorer. My layout is pretty insane in terms of the sheer quantity of absolutely positioned elements, which broke that functionality in Internet Explorer. One quick question to the WSG mailing list later, someone had provided a JavaScript fix (which we had to edit a little bit to make work properly, because we had problems with flickering elements even with cache enabled).

The eye-candy

I’ve implemented useless (but rather cool) eye-candy on the Deals page in the Details pane whenever a new deal is selected. A variation of the Fade Anything Technique, which is only meant to be pretty. No originality is claimed, we’ve had this technology all millennium.

Accessibility

Disable JavaScript and you lose the fades, and use a little more bandwidth as the entire page reloads for every item you click. In terms of non-visual user agents with JavaScript disabled, I’ve put the “Details” above the list of offers in source-order, and on every reload they only hear “Sunrise Family. Link: Skip to main content” (presuming they select the link) before getting to the actual details, so I’m fairly happy on that front.

Additionally, I’ve got the “header” from Yahoo!7 last in source-order, so anyone with assistive technologies don’t have to skip over that EVERY TIME they change the page. It was a little painful to figure out, not in the least because Yahoo’s supplied universal header isn’t at all nice for sites that are built properly — i.e. with web standards and accessibility in mind — but I much prefer it this way. This is also something we had to achieve silently and without complaining, because, whilst anyone who has a clue about web accessibility will immediately see this is a good idea, marketing people would conceivably think: “But we want people to see our search bar more often!”. Er, no, you don’t achieve anything by pissing off users. No matter, we pulled it off without making any noise about it!

We’re server-side sniffing for Firefox and handing it an “Add Yahoo!7 to the Firefox Search Box” link (which, incidentally, has particularly horrid inline JavaScript — but I don’t care because the only UA it’s being served to can do something useful with it), whilst IE users get a “Make this my homepage” link in its place. Yahoo’s version (which you can see on Seven’s — pure Flash, *obligatory shudder* — Australian Open website, though I think that version (of the header, not the website) might now be deprecated) uses JavaScript for that, but it was fairly obtrusive and, seeing as we have the ability to do that server-side, I’d much rather reduce page weight.

In terms of accessibility generally speaking, I’ve bundled in all the usual goodies such as a skip to main content link, as well as skip to login on the front page, base font size of 100.01%, and relative font sizing throughout… but extensive image replacement techniques mean that the headers are probably sub-optimal in terms of visibility. This one is out of my control, and everyone else in the workplace seems to love small text (even Lyn, who seems to often put on glasses to read things on a screen… go figure!) so I wasn’t going to fight too hard about it. All other text will scale pretty well, with the exception of the deals — because the layout is so tight, it’s only really possible to go up one, maybe two size steps in most browsers.

We’re lacking any explicit accessibility statement, and we’re also lacking access keys. Mostly because I’m convinced access keys are practically useless, and rarely bother to implement them. (On forms, there are never enough buttons for access keys and/or there’s no logical combination available, and everywhere else it sort of seems a bit pointless unless everything has an access key. Where do you draw the line?)

This site is interesting to me because, even though it’s a television audience, I still can’t make assumptions about how people will be browsing. PDA devices, for example, would struggle with our built-for-1024 layout had we done it with tables. For this site, PDA/mobile users are realistic: for example, if someone incidentally is near a Wendy’s store and remembers they might’ve seen something on the Sunrise website but can’t remember the details, they can quickly and painlessly look it up.

Further, the site also has to cater for people with cognitive or motor disabilities. For cognitive disabilities, one thing in our favour is that we’ve provided a short summary of each deal before a more heavy-duty fulltext item. For users with motor disabilities, the entire website should be accessible via tabbing — including the JavaScript-enabled Deals page.

I lost an argument regarding target=“_blank”, but will eventually win this point. A handful of advertisements — including those for intra-network links, such as for the Seven Store — open in new windows, which I am most certainly not a fan of. All external links, however, should have the rel attribute set to external. There is unfortunately no visual cue associated with this. Links I count as my biggest area of defeat in this website, which is pretty good (as in, I’d rather it just be that than something more significant such as iframe usage, enormous usability problem though new windows may present).

Inline JavaScript is completely unrelated to accessibility in light of the way this has been implemented. Admittedly, it would be advantageous to use event handlers in place of inline JavaScript (and we will be thinking that to ourselves as we look at the traffic statistics), but from an accessibility perspective it has very little impact. Standard HREF’s are defined, and caught with Javascript using return false; No functionality is lost. I much prefer this method to scattering iframes throughout the site! At any rate, I’m still trying to resolve this one, accessibility related or not. It’s a matter of personal pride, I suppose.

The Styles and Bugs

The entire design (done in-house by Dacien) is awesome (in my opinion — 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 Firefox from breaking the layout (1 pixel difference) when a link was active (as they are when you click a deal and it’s caught by JavaScript rather than actually reloading the page — the link remains active), adding a 1 pixel dotted border. Cross browser support is pretty awesome — it should be good in IE back to 5 — Opera, Safari, Konqueror, and even (mostly) IE 5.2 Mac are happy. Firefox deserves special mention: it has so many little (big for this site) things wrong with it that it’s often rather painful to make work properly. In fact, of all browsers mentioned, Firefox 1.0.x (on non-Windows platforms) is the only one whose behaviour I’m definitely not happy with (mostly because I expect better from it, but also because it gets some things horribly wrong).

Such as, for example, the “Meet the Family” page. It works perfectly or near-perfectly in every other browser, but certain Firefox variants on certain platforms render only the first two items in the “Sunrise Team” list(/right column, if you’ll excuse my presentational-speak) on first load… and then renders perfectly if you refresh the page. This is what I meant by my “predictable inadequacy” post of a few days ago. I’m fairly certain it’s something to do with floated list items, but possibly not.

Another bug is (also in Firefox — noticing a trend, anyone? No, I didn’t build for IE. I wrote about 90% of the stylesheet sitting in Firefox 1.5.x using Chris Pederick’s Web Dev extension, and both that browser and Opera operate near-perfectly) Firefox 1.0.x’s penchant for adding scrollbars where they’re not required with overflow:auto (see front page on non-Windows platforms, and the Deals page — lots of style overlap/common classes there, so this is to be expected).

By far the most interesting rendering difference I encountered building a layout this tight was between Internet Explorer/Windows XP with and without Windows Themes enabled. Yes, it does make a difference. Interface widgets shouldn’t really interfere with styles at all, IMO, but they did here. The solution basically entailed shaving off a couple of pixels where required, so I didn’t come up with something particularly innovative for it!

Summary

In all, I’m pretty happy with the site. Seven’s internal Online team apparently noticed/complimented our team on the absence of layout tables, which I (perhaps arrogantly) take with some degree of indifference: people shouldn’t be building sites with tables for that purpose anyway. If we are to be complemented, then it should be on the design (and, as part of that, achieving a design this ‘tight’ with CSS), or on the usability benefits realised by intelligent integration of AJAX, or the development pace (again, partially because of the flexibility CSS gives us), or maybe on lightweight, semantic code as a cost-saving mechanism.

Truth be told, I now believe we may have even gone a little overboard with the tables elimination. If I could do it all again, the Deals page would feature a table instead of a list, and I’d use DOM scripting to insert/delete records rather than replace the “state” part with innerHTML. The markup might gain a (very) little bit of weight, but it’d be worth it. It would, of course, remain semantically sensible and completely accessible. It’d probably be more semantically sensible, actually. I realised a table would work great about two days after I’d finished 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 building a “pseudo table” without realising. At least it wasn’t that complex!

Anyway, I’m really interested to hear what people have to say about the site. We’re being plugged every half hour on Sunrise tomorrow morning from 6am, and will be anxiously watching the server to see what, exactly, the effect of promotion on a show with 4 million viewers daily has on bandwidth, etc. I’ve also installed an AWstats tracker to collect aggregate data (as on this site) which we’ll parse later on (assuming the horrible monster that it’s running on, Zeus, outputs normal-ish log files for me! Oh, and it doesn’t support mod_rewrite, but instead has some retarded alternative that seems like a cross between VBA and AppleScript — and fails as much as the latter did in terms of actual ease of use, despite trying to use human language. It’s very dumb.) to figure out how Australia is doing in terms of browsers, operating systems, screen resolutions, JavaScript support, and the like. Should be incredibly interesting stuff, and I can’t wait!

Such pages, however, tended toward dullness and infrequent updating.

Or, to put it another way: Such pages tended to fulfill the original vision of the Web, which was to allow absolutely anyone to publish information that might otherwise be lost to the public, in a way that allows it to be searched, indexed, bookmarked, and linked to related information. And accessed by absolutely anybody who’s looking for it.

As opposed to today’s “dynamic” Web, where you need a broadband connection, an industrial-grade graphics workstation, and more plug-ins than a Roman orgy just to look up the atomic weight of molybdenum. Which you can’t bookmark because the URL is a dynamically-generated conglomeration of the hostname, your session ID, the phase of the moon, and the bra size of the webmaster’s current girlfriend, that doesn’t point to a page that’s actually stored on disk somewhere.

As nifty as it is that people have found new ways to make use of HTTP and HTML, we seem to be slowly losing the very concept of “publishing” as “preserving a record of today for future recall”. Instead of being the equivalent of an “address” where one can “go” to retrieve information, the URL has become a “magic incantation” that instructs a distant server to perform some action that may or may not produce the same results as the last time it was used.

In some ways, that’s good: it’s nice to be able to use the same mechanism to say “Bring up the latest edition of Dan’s blog”, “Show me the current pressure and temperature readings of Injection Molder #7″, and “Display page 7 from our company’s 2003 annual report”.

But there’s some very scary Orwellian potential here, as well as the risk of exacerbating the Digital Divide by constantly ramping up the minimal platform needed to access much of the web. Those librarians Dan mentioned lately shouldn’t be the only ones worried about making sure that a large percentage of online content remains “dull” and “static”.

I think the “Orwellian potential” bit is a load of scare-mongering crap (in relation to the other concerns posed in the article, at any rate), but everything else rings true.

I am, at present, working on the first large-scale project I’ve been involved in where <a href=“http://en.wikipedia.org/wiki/AJAX/ title=“Asynchronous JavaScript and XML”>AJAX is being utilised. In this instance, yes, it was my call: yes, I do feel it’s justified (reasons include traffic, and the advantage of not having to reload an entire page — yes, it’s large scale enough for that to be significant — and simple usability, because the architecture is such that users will desire to move quickly between elements of content, and AJAX facilitates that. More details post-release). We’ve been very careful to preserve functionality in non-XMLHttpRequest enabled UA environments, but it’s still not perfect — bookmarking is one (minor, given the nature of the content) problem that still requires rectification: that’s one thing I’m hoping to resolve tomorrow (along with general CSS compatability back to IE 5, possibly 4 — but that’s not particularly relevant). The Javascript is not particularly “unobtrusive” (still using inline onclick), which I’m hoping to similarly resolve prior to launch, but it’s not of any particularly great consequence.

This is not a site to be archived, as the author of the comment above laments. But he shouldn’t. That wasn’t ever this site’s purpose, so I’m not particularly concerned if the markup isn’t prestine. Yes, there will be RSS/Atom syndication. It’s a fairly Web 2.0 buzzword-compliant site, though (I hope) not particularly unneccessarily adoptive of such technologies. We’ll see.

Via Karmakars

Far out. This thing is incredible. Database design with AJAX… there’s a demo on the site, and you can download the app. Must play with. Incredible. Reduced to incomplete sentences by its awesomeness.