November 15, 2006

Technology as a dialogic process? Looks fine on Paper.

With the hullaballo of AIC and the Faculty Senate, a certain phrase has been running through my mind....Informed Consent. Wikipedia (at this moment) defines Informed Consent as:...

...a legal condition whereby a person can be said to have given consent based upon an appreciation and understanding of the facts and implications of an action. The individual needs to be in possession of all of his faculties, such as not being mentally retarded or mentally ill and without an impairment of judgment at the time of consenting...

I would like to add to the list voting Republican, but that may simply be a subset of mental retardation.

...click below to continue

There is real arguement that no matter how well complex medical procedures are explained to a patient, they can never truly have informed consent. This is _not_ because the doctors are smarter. Doctors have the training, background and experience to fully realize the ramifications. In my mind technology is much the same. We can meet with interested parties every so often and talk about patches, switches, operating system vulnerabilities etc, but I honestly do not think that would be productive.

Another way of looking at this issue:

You go out to eat at a sit down restaurant. You order a steak (medium rare), a baked potato (with butter..hold the sour cream), and a side salad (with honey mustard on the side). The salad is okay, as is the potato. The steak isn't tasting too good as it's got a lot of gristle. You decide to send it back. Typically you inform your server of what you don't like about your steak, they whisk it away and attempt to bring out a more pleasing version. You don't ask to stand in the kitchen and tell the cooks what kind of meat to use, what spices to use, when to flip the steak...Doing this is not productive.

Now, for anyone outside of UCS reading this, please don't misunderstand me. I think that we as an organization NEED to step up our regular forms of communication. We distributed a survey to find out from you how to best get info out. We not only want, but NEED your input to determine what it is you want to do (like placing your order). We also NEED the particular details (like ordering dressing with your salad). Once we have that information, the best course is to let us do our job, and prepare your digital food for your approval. If you don't like the meal...as long as you can point to the gristle in your steak, we'll do our best to serve you up a more pleasing version.

Posted by crowej at 05:16 PM | Comments (0)

February 06, 2006

Feasibility of (sparse) Appointments

When wearing my tech supervisor hat, one of the things that I've been resistent to is setting appointments. It's not that I'm against the idea of appointments, rather I've seen it as an unwise use of our limited resources.

For example, when I have a student on shift for two hours (from 2 - 4), I want two complete hours of productivity. If we have an appointment set for 2:30, then I have at least a half-hour that is wasted. We cannot know how long a given task will take. I don't want the student doing half a task. Therefore I am left with assigning quick tasks - if any are available. Couple this with the reality that all techs do not know all things. I have some techs that are very experienced, some that are new this term. On a non-appointment based schedule then one can be assured that a given tech can handle a given task as they rarely get in over their head.

This non-appointment based solution would be a 100% perfect fit if all of the faculty would agree to stop teaching classes and sit in their offices from 8-5 :^)

Since that has yet to come about, I'd like to do a test run of appointments. I'm asking for comment with the following guidelines/boundaries. The times need to occur when I have adequate staffing (think failsafes). I do not want broken appointments if at all possible. I'll begin by:

--no more than 5 hours per week reserved for appointments

--appointments cannot be made for day the task is called in

--appointment time slots will be fixed for a term

If you could comment as to the value of this solution, the times/days that would work best, anything else to consider...

Posted by crowej at 09:59 PM | Comments (0)