DyKnow

Sorry for the recent absence, but we as developers have been working hard as we enter the final stretch of the Beta period before the 5.2 release.  Last week we crossed one of the major milestones in the release cycle when we had our first mass-scale stress test.  During the test, we go through a series of scripted actions designed to push all elements of the DyKnow system (Server, Client, and Monitor) as hard as possible.  We then compare performance to years past as well as take lots of notes about any bugs or usability issues we encounter.  The more we find in the classrooms at the stress test, the less you have to worry about in your classroom.

This release cycle, in my opinion, has been exceptional when looking at the quality assurance (QA) efforts from the team here at DyKnow as well as so much of the feedback we've been getting from our Beta sites (and if you're a Beta customer reading this, keep it coming!).  DyKnow 5.2 is going to be an even more reliable product than 5.1, but, as with all classroom technology, there inevitably will be problems and that's where error reports hit center stage.



Prior to my employment at DyKnow, I was terrified of "error reporting."  Everything I was working on for the past couple hours was just dealt a sudden deathblow by who knows what and now I have this big scary box telling me that someone is collecting information about me and promising not to abuse it.  It's not exactly an enticing proposition, and who knows if anyone pays attention to them anyway.  Then suddenly one day, I found myself on the other side of that situation where sometimes the only knowledge we have of an error comes from those brave few that choose "send" over "don't send."  The more information we can get about the problem, the more likely we are to be able to track down and fix the issue, and rest assured we definitely read all the error reports that come our way and do everything we can to make sure that it doesn't happen again.

So what goes into these error reports?  Well, first and most importantly, we record and send the error itself including where it happened in DyKnow.  Then, we get some general information about the computer such as what operating system is running, how much RAM is available, how much RAM is free (Out of Memory has a very different meaning when there is 100 MB of RAM free as opposed to 1GB), some networking stack information (one time I remember us even finding some installed spyware), and what other programs and services are running. 

We've found that sometimes that information still isn't enough and so we must ask for the diagnostic logs from the time the error occurred, but you're crazy busy and probably less than pleased there was an error in the first place.  You just want to offer a collaborative note taking environment and really interact with your students not spend all your time troubleshooting with support personnel.  That's why in DyKnow 5.2, we're going to automatically send logs with the other diagnostic information so we can immediately get started making DyKnow better for you.

Computers today have become magnificently complex systems that allow us to collaborate with people across the world, but that complexity comes at a price of manageability and predictability.  Whether it's another application gone haywire, a malfunctioning piece of hardware, or a bizarre timing issue we couldn't have imagined in a million years, exceptional cases are bound to occur.  That's part of the challenge when integrating technology into the classroom.  But when these problems do arise, we want to be sure that we can quickly determine the cause and resolve the issue to keep you focused on what really matters: your students.