By: Greg

Greg — Fri, 25 Aug 2006 02:02:38 +0000

Thanks for the comments everyone.
Mike — I’m glad you found this stuff useful.
Jem — Approval getting more complicated than a simple thumbs up/down, definitely falls into the category of something I don’t even want to start to think about until later. One of the biggest lessons I’ve taken away so far in my limited design experience is that just as the perfect can be the enemy of the good, the desire for a general all-purpose solution (worrying about all possible ramifying complexities that may lie down the road for your app) can stop you from solving the immediate, often much simpler, problems that lie directly in front of you, problems which can prevent you from ever getting far enough along to even actually face those future complications.
In this case, I would say that the general design outline I sketched here defiinitely supports scaling from a simple boolean approval to a more complex set of criteria from which we then calculate the boolean. All you’d do is hook up the very same approval code that will at first be connect to user input to the output of some other process. If the methods involved are at all well designed this switch shouldn’t be too painful.
The one other note I would make on this topic without wanting to dive into it too deeply would be to say that I can see a potential danger lurker down the road of adding complexity to the approval process. If an approval outcome (i.e. whether or not a paper actually ends up on the site) ceases to be easily predictible by the administrators (i.e. it becomes hard for them to tell whether clicking a particular button will allow a paper through or not) transparency, accountability, and usability are all lost. On the other hand, I can defnitely imagine the usefulness of a “graduated” approval which would pass along additional concerns or qualifications to anyone who reads the paper much along the lines of what wikipedia does now.
Benjamin — Thanks for the compliments. I could definitely see the usefulness of a readers’ digest version of this. Right now, I’m just trying to capture as much as I can about my process (and especially the gotchas and hidden background info that might be hard for new coders to grapple with) as clearly and as comprehensibly as possible. Maybe, I can go back and summarize things into bullet points at the end. Or better yet, maybe, through the magic of the blogosphere, someone will come along and do it for me. But for now, I’ve got a 4000+ word part two to finish up so I’ve got my work cutout for me!

By: Benjamin

Benjamin — Thu, 24 Aug 2006 23:51:20 +0000

You wrote a lot of great content here. Now, I think readers will greatly benefit (especially those short on time to read these things in their great length) in having a summary of bullet points of the items you find summarize what you said here and are the most important. Well done and please continue to share your creative process.

By: Jem

Jem — Fri, 18 Aug 2006 15:29:34 +0000

Excellent start here!
I think we might need to think about the dynamics of approval a bit more (is it strictly boolean or more graduated [with a system of thresholding to produce pseudo-boolean behavior where desirable]?). Is there sufficient flexibility in this envisioned structure for future potential implementations of conditional approval?
Nice essay in and on the sort of serious, imaginative thinking that will save a heck of a lot of time later on!
Jem.

By: MikeInAZ

MikeInAZ — Fri, 18 Aug 2006 11:02:51 +0000

Thank you! Thank you!
I found your tutorial very informative and helpful.

Comments on: learns_to build Academic Archive::Part 1:Introduction, Concept, and Design

By: Greg

By: Benjamin

By: Jem

By: MikeInAZ