Re: Initial survey discussions - organization

[Roger Dingledine <arma@mit.edu>]

In message <3582A980.35952460@iname.com>, pete_st_onge@iname.com writes:
>> So, actually in my opinion we needed knowledge, what people do with their
>> computers and what they wanted to do. Better not to ask what the people
>> want in an OS nut what they want in an hd... For example this old macOS
>> here is OK as long as it doesn't crash and I'm *able to switch easily
>> between web-browser, wordprocessor, e-mail etc*... the OS is OK as long as
>> you don't notice it at all!?
>     I totally agree, though I fear we would be getting into a
>conundrum: we want to get a really good idea of what the various users
>want, but we want to keep the questions to a minimum. I checked kmself's
>SAS survey, and it didn't seem to be too long to me. I fear that it
>might be perhaps too short for the info we want to collect, however,
>given the complexity of the applications and our goals.

Well, we have to strike a balance somewhere in there. Perhaps it might be
acceptable to write off the people who aren't willing to sit through a mid-
or long-length survey, on the grounds that linux is not yet ready for them
and won't be for a long time? I guess it depends how many of the surveys
we think we can get people to answer. :} Perhaps also we could have several
versions of the survey (experienced long, experienced short, beginner long,
beginning short).

>     What we might do is to give the user a choice of the survey to fill
>out, say a common section to get the users to describe themselves,
>machine information, etc. Then they could choose which other survey(s)
>they would fill out - user interface, word processor, spreadsheet,
>database, etc. 

Or we could divide it up like this. I think Karsten has a very good
point though about putting every question we want them to answer on the
same page: if they can't see the whole length of it up-front, they'll
get bored after a while and quit partway through. This is poor.

I'm thinking a "or skip this section" thing to click on that brings
you to a different section of the page would be a simple way to solve it.
(Or do we lose the data in browser widgets if they click on a new link
without submitting? I guess we could kludge around that with a simple
cgi to "forward" their answers to the new version of the page, but
ick.) I know a huge amount about perl programming, but I haven't used
it for cgi for a long time.

>     If the info from the first section (self-description) could be
>saved as state data (cookie - with appropriate explanation to ensure
>that they accept the cookie), this person could come back at some other
>time and fill out other survey sections (without having to give the
>redundant), and we can keep track of who does what. This would also
>allow us to get as much info as possible about a specific area without
>having users give up because they don't see the end of the survey.

Alternatively, we could have a way of revising or taking a new survey
that has you fill in your name and email address, and it remembers
the rest of it. (cgi+mysql can do this easily.) But this brings
authentication into the issue, which I don't think we want to deal
with. (Is authentication already in the issue? Do we care if people
forge responses? How will we know?)

>     Just a thought.
>
>     Pete

--Roger