[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Initial survey discussions - organization

>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).
This sounds like a reasonable idea, coupled with the thoughts below re: filling out sections of the survey at a time.

>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 
This is a good reason to split the survey into pieces, but make sure each piece is a single page, and it is very clear what the user is doing, where, and why, at all times.  A TOC for all the parts might be good.

>(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.
It can be done several ways, either by sending the data back and forth repeatedly via the POST method, retainig it locally in the database, sending a cookie, or (likely) a combination of the three.  Simon has a point (in a 'future' message) that we can and should ignore technical details such as these for the time being.

>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 

Erik Walthinsen: Wireless Geek Type Person - omega@omegacs.net
SEUL - Simple End User Linux (www.seul.org) - omega@seul.org
Linux United! (linuxunited.org) - omega@linuxunited.org

Written on a PalmIII (so don't be surprised if it doesn't look complete...)