TITLE: Thinking About Things Your Users Don't Know
AUTHOR: Eugene Wallingford
DATE: September 14, 2010 9:58 PM
DESC:
-----
BODY:
Recently, one of the software developers I follow
on Twitter posted a link to
10 Things Non-Technical Users Don't Understand About Your Software.
It documents the gap the author has noticed between
himself as a software developer and the people who
use the software he creates. A couple, such as
copy and paste and data storage, are so basic that
they might surprise new developers. Others, such
concurrency and the technical jargon of software,
aren't all that surprising, but developers need
to keep them in mind when building and documenting
their systems. One, the need for back-ups, eludes
even for technical users. Unfortunately,
You can mention the need for back-ups in your
documentation and/or in the software, but it is
unlikely to make much difference. History shows
that this is a lesson most people have to learn
the hard way (techies included).
Um,
yeah.
As I read this article, I began to think that it
would be fun and enlightening to write a series
of blog entries on the things that CS majors don't
understand about our courses. I could start with
ten as a target length, but I'm pretty sure that
I can identify even more. As the author of the
non-technical users paper points out, the value
in such a list is most definitely not
to demean the students or users. Rather, it is
exceedingly useful for professors to remember
that
their students are not like them
and to keep these differences in mind as they
design their courses, create assignments, and
talk with the students. Like almost everyone
who interacts with people, we can do a better
job if we understand our audience!
So, I'll be on the look-out for topics specific
to CS students. If you have any suggestions,
you know
how to reach me.
After I finished reading the article, I looked
back at the list and realized that many of
these things are themselves things that CS majors
don't understand about their courses. Consider
especially these:
the jargon you use
It took me several years to understand just how
often the jargon I used in class sounded like
white noise to my students. I'm under no illusion
that I now speak in the clearest vocabulary and
that all my students understand what I'm saying
as I say it. But I think about this often as I
prepare and deliver my lectures, and I think I'm
better than I used to be.
they should read the documentation
I'm used to be surprised when, on our student
assessments, a student responds to the question
"What could I have done better to improve my
learning in this course?" with "Read the book".
(Even worse, some students say "Buy
the book"!) Now, I'm just saddened. I can say
only so much in class. Our work in class can
only introduce students to the concepts we are
learning, not cover them in their entirety.
Students simply must read the textbook. In
upper-division courses, they may well need
to read secondary sources and software
documentation, too. But they don't always
know that, and we need to help them know it as
soon as possible.
Finally, my favorite:
the problem exists between keyboard and chair
Let me sample from the article and substitute
students for users:
Unskilled students often don't realize how unskilled
they are. Consequently they may blame your course
(and lectures and projects and tests) for problems
that are of their own making.
For many students, it's just a matter of learning
that they need to take responsibility for their
own learning. Our K-12 schools often do not
prepare them very well for this part of the college
experience. Sometimes, professors have to be
sensitive in raising this topic with students who
don't seem to be getting it on their own. A soft
touch can do wonders with some students; with
others, polite but direct statements are essential.
The author of this article closes his discussion
of this topic with advice that applies quite well
in the academic setting:
However, if several people have the same problem
then you need to change your product to be a better
fit for your users (changing your users to be a
better fit to your software unfortunately not being
an option for most of us).
You see, sometimes the professor's problem exists
between his keyboard and his chair, too!
-----