Found a great piece on enforcing model-view separation for web applications. Lots of technobabble (I had to reread the part referencing Chomsky’s grammar classes), but it helps in moving towards having a comman base for creating templating engines. Nice read.
Monthly Archive for November, 2004
Nearing crunchtime to the big presentation, and I’m still plagued by major design changes to the prototype.
Makes me want to barf, but I can’t, because, really, I’ve painted myself in the corner on this one. I was so keen on sticking to standards-based design that I totally ignored how it would render on “less-worthy” clients. Bah! Let them upgrade! I say.
Thing is, majority — no, in fact, all of them — of the audience for the site I’m developing don’t know an upgrade (much more how to go about doing one) if it lands in their collective noses. So strike one for usability. Also, the information architecture is still way too convoluted. Okay, so I’ve made it easier to navigate, but it’s still not as intuitive as I thought. Again, it was arrogance on my part: it was easy enough for me to wade through content because I know what to look for, but what about first-time visitors? And, the structure is more than three levels deep, and that, for me, is a bad sign.
Still, I have made the design decent enough so I can easily make changes to the look without dabbling with the content. It’s just not tight enough — there are still gaps in the semantics. But I’ll get to that.
Now, for the old-browser problem: worse comes to worse, I’d have to implement a bandpass filter on that one. Hope it doesn’t get to that. An alternative stylesheet i s a no-go, because those old geezers just don’t do stylesheets that well. But I’ve narrowed down my major fault to this: I was so damn stuck on how to make the site look good that in an effort to separate it from the content, I’ve let the content stagnate.
Solution: baby steps and lots of hand-holding for visitors. Maybe make a print-publication-type analogy at first, then move on to the nuttier (more substantive stuff later). Would-be users of the site are still not comfortable with the medium, so I’d have to simulate the look of the medium they’re cozy in. Later on, I’ll introduce features that highlight the difference between the media so they can transparently “move on”. For this to work, though, I’ll need the design principles I started with: “separate content and presentation”, “stick to standards”, “focus on usability”. In short: “make simple things easier, and difficult tasks possible.”
Hey, maybe I’m on the right track, after all.
S!M!T!O!E!, this one does.
Just when I thought I was nearing the homestretch (linting the code, polishing it for PHP), IE and its ilk comes along to break my code in ways only its (IE’s) designers know.
Pictures — browsercam shots in this case — speak volumes. Well here, they fairly shout.
Just when I thought I was almost through with the site prototype, yet another CSS gotcha caught me.
It’s a trivial flaw, actually: see, embedded Flash does not cooperate with CSS positioning. No matter how deep the value I add to the z-index property, the Flash element always bleeds over other HTML elements that overlap with it on the page. (See screenshot below.)
I haven’t explored this problem deeply — haven’t got the time: crunch time is less than two days away — but I think this is similar to another layer-bleed problem that occurs with select elements. Although I could place the Flash content in its own horizontal layer without any adjacent layers that will overlap it (like the popup menu I’m using for the site), that would result in real estate coverage for the Flash content larger than I would have preferred.
Well, why use Flash at all? I mean, I could just replace it with a static image, and it would work sweetly, but that’s not really what I want to accomplish, either. The Flash thingy is there to serve as a hook to the page. I’m talking about unsophisticated(?) users here whose attention spans I have to lengthen so they’d go over the rest of the page and take a look. The content is rich enough, I know, but without a visual target on which they can focus their attention at a glance, I would have lost them. Good design is when one knows how to use the appropriate tools at the right time. I can be quite dogmatic about my sticking to a standards-based design, but if I could squeeze in a few more bytes to make the site more visually enticing, so be it. But I know when not to overuse it, though — there’ll still be a lo-res image substitute to the Flash content.
Oh, well. Gotta refurbish the site. Good thing I have other templates on the ready. This is the most wonderful thing about standards-based web design: with the separation of form, structure and content, I can change the look without touching one piece of the semantically valid content. This is my reward for thinking about standards from day one of the development phase.
Had to refurbish the whole site prototype because of one trivial flaw: Flash doesn’t cooperate with CSS position that well. (See screenshot below.)
I’m nearing the homestretch — in fact, crunchtime is less than two days away — and yet, I have this nagging feeling that if I can’t find a quick workaround to this, I’m better off trashing the design. I’m being a bit dogmatic about CSS, I know, but I can’t have it any other way. I’ve made a commitment to stick to standards, and I’m going to make the site as usable and accessible as possible.
The users should not be made to suffer because of poor design and ill-conceived adhockery. So back to the drawing board. Good thing I’ve got several other templates ready. The nice thing about standards-based design is that I can retool the site without so much as touching the semantically valid (I hope) content. Heck, I could even add CSS skins, if I could afford the time — and if users can handle the sophistication. Might as well hang on to this principle, because in the end, real satisfaction can be derived from seeing clients use your site easily and effectively.
