Saturday, November 7, 2009

Gradebook rant #1 and #2

#1 - The first quarter ("cycle") in CPS closed last night (Friday, 11/6) at midnight. But then CPS goes and locks the online software teachers need to use, so no more first quarter grades can be entered now.

I don't get this. If the quarter ends on Nov. 6 (Friday), the next one can't start until Nov. 9 (Monday). And report card pickup this year isn't until 11/18 or 19 depending (due I think to the late school year start because of the late Labor Day this year, and Nov. 11 Veteran's Day getting in the way). So why lock Gradebook at the cycle end and prevent teachers getting last minute grades in? Not that I want to spend the weekend getting final quarter grades in, but I'd rather do it clear-headed on a Saturday than late Friday night. Why not lock it Sunday midnight?

There is an implicit understanding that teachers cannot complete their work within the standard 6.25 hour CPS workday (hence closing Gradebook at midnight and not the end of the workday). The Professional Development Day (yesterday, Nov. 6) as a day to get grades in is a joke, because it gets loaded up with, well, PD. So what is CPS thinking? Most of the teachers at my school were assuming they had some time to get the quarter grades in, and only heard Friday (yesterday) morning that the deadline was midnight last night. I'm guessing more than 3/4 of teachers will need to have their Gradebooks unlocked by the school's Gradebook administrator or heaven forbid, someone in the technology support area.

It is another example of trying to force (what looks to me to be) silly and not-thought out dictates and demands on the troops-in-the-trenches (and believe me, it is WWI out here), which ends up making more work for everybody all the way round.

I guess the good news is that the time I was going to spend today fixing up the grades is freed up now.

#2 - I attended the CPS Information Technology Services (ITS) "TechTalk 2009" event last Tuesday at the UIC Forum. TechTalk is an opportunity for the technology apparatus at CPS to talk to the "techcos" (a conflation of "technology coordinator") from the 600 CPS public schools. [Aside -- the techco position is a role, not a position. Typically a teacher or some other staff member is assigned the role of "techco", not hired as such. Techcos form a critical rubber-hits-the-road role in the chain of CPS technology service delivery, but they are stretched between multiple responsibilities. I tire myself thinking about this.] Anyway, at TechTalk 2009, attendees were treated to a talk about Gradebook, which is CPS's branding of a commercial third-party product called Gradespeed.

The presenter gave one of those classic tech talks where the end users were morons who did not read instructions. In fact users are generally smart people confronted with a confusing interface that could easily be fixed up. It is a poor technologist who blames the user for design shortcomings. Case in point: teachers can enter a numeric code to represent comments like "Is too easily distracted" (but only one for elementary schools we learned, even though there are five boxes!) . If the code is "028", you need to enter the leading zero. Why? Lazy programming. The person I was sitting next to and I agreed that this could be fixed in a couple of lines of code and eliminate untold headaches on the part of teachers who enter "28" instead of "028". Thinking about it, it isn't a couple lines of code -- it is less, just a matter of wrapping the user input in a couple of functions that check the input and clean it up for the user -- maybe 20 extra characters of code.

Example #2: The user has a row of links at the top of the screen to control options:

This is an online application, so you might think that you can click on the image, that it is a button? Nope. Only the text is a link. I have worked with computers for over 25 years and this one tripped me up. One gets in the habit of thinking how things should work, primarily a habit of life experience. Software designers design an experience, and the best ones anticipate user expectations. The user should be at the center of the design, not the designer. That's what "participatory design" and incorporating real live users in the design process is all about. Put them in a room and see what they try to do before releasing the product.

Another example is that when entering assignments, you must click an "Add" button to add a new assignment. However, after clicking "Add", you see a blank form again. No program feedback is provided to indicate that the assignment was saved. Was it saved? How would you know? Only by exiting the "Add" function by clicking "Finish" (what are you finishing?), and seeing if it now appears in the assignment list. Again, some simple code to acknowledge that the "Add" operation was successful would be a trivial enhancement.

The computer experience is often akin to stumbling around with a bucket on your head -- you have precious little feedback on where you have been or where you are or what lies ahead. The best software designers provide lots of feedback: cookie trails with trackback links, alerts, the use of color in logical places, and so on. Not so with Gradespeed / Gradebook. Instead the poor user who only wants to accomplish a task and not "work a computer" is blamed for not understanding the software.

Too much ranting? It's a beautiful day today. And now no grades to enter. Yay I think.


1 comment:

Russ' said...

Thanks for the mention.