Menu
▾
▴
Re: [phpesp-dev] Introduction; proposal for phpesp fixes
|
From: Keith S. <ph...@on...> - 2009-04-13 18:44:59
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> </head> <body bgcolor="#ffffff" text="#000000"> Thanks for the replies, Franky.<br> <br> First, very happy to hear those two dashboard issues have already been caught and fixed.<br> <br> Second, my apologies for the problems with HTML posting. I was unaware the list manager was going to warp it. Clearly, no more of that.<br> <br> Third, I'll pick up either the latest official release or the trunk before submitting any patches. I believe everything else will still apply.<br> <br> Lastly, just an observation: I think my experience in software has me treating the term "enhancement" differently from you. In my eyes, each of the items I listed below constitutes a bug, because even though the application works, and doesn't throw an error, I consider the behavior to be fundamentally wrong. To me, an enhancement is something that is "nice to have", but is not necessary, and/or only useful for a subset of users.<br> <br> But this is just a matter of semantics, because I think we still agree on the value of the change, as you indicated for most of them that what I described is what "should" happen. That's perfectly fine by me -- a rose by any other name, blah blah blah. (Not an English major.)<br> <br> Cheers!<br> <br> --<br> Keith<br> <br> <br> On Sat, 11 Apr 2009 18:02:19 -0700<br> Keith Swartz <a class="moz-txt-link-rfc2396E" href="mailto:phpesp@on..."><phpesp@on...></a> wrote:<br> <br> > Greetings,<br> > <br> > I sure hope this list isn't particularly large. I've been using<br> > phpesp for several months now, and have made numerous fixes and<br> > enhancements to the project, which I'd like to give back to the<br> > community.<br> > <br> > Before logging bugs and submitting patches willy-nilly, I wanted to<br> > do my first round via the developers list. I welcome any comments on<br> > these before I submit patches and log bugs -- I want to make sure I'm<br> > staying consistent with the community that has worked on it for so<br> > long, and that I remain close to the mission of the product, not<br> > expecting it to do things it wasn't meant to do. Also, think of this<br> > as my attempt to introduce myself and describe how much I've looked<br> > at the product. :)<br> > <br> > Here's the list of major issues I plan to attack, in about this order.<br> > Signup fails: realm is not quoted in INSERT statement Account<br> > creation always fails: the insert statement into the respondent table<br> > is the culprit, because the value of realm is not in single quotes.<br> > (I gotta wonder, though -- how could this not have come up as a bug<br> > already?)<br> <br> Hi Keith, it has come up lately :-) And fixed in the git repo. And<br> another fix is in progress and being tested by Bishop (hopefully<br> completed this week). Then I'll release a new version that contains the<br> latest fixes.<br> So for now I would suggest: get the git and do your patches against<br> that. See the latest version of CHANGELOG at<br> <a href="http://phpesp.svn.sourceforge.net/viewvc/phpesp/trunk/phpESP/" target="_NEW">http://phpesp.svn.sourceforge.net/viewvc/phpesp/trunk/phpESP/</a><br> <br> > Resume survey link broken after saving in test mode Link to<br> > resume survey after saving in test mode is missing the survey name.<br> > <br> > Emailed survey results must display questions ordered by position,<br> > not by id Emailed survey results display questions/answers by order<br> > of id, rather than by order they are shown in application. If you<br> > add/remove questions several times, the IDs will definitely not<br> > represent the order in which the questions are presented. The results<br> > could be extremely confusing or even wrong, especially if questions<br> > are worded in such a way that you need to read them in order. (For<br> > example, if a question just says, "If not, why not?")<br> <br> not a bug, but an enhancement :-) But you're correct. It should be.<br> <br> > [Related enhancement: add the question number to the email. I have<br> > found that when respondents typically correspond with the survey<br> > administrator, or with other respondents, they reference questions by<br> > their number, since it's prominently displayed in the survey. For<br> > instance, "I didn't understand question 12." By including it in the<br> > results that are emailed, it allows the two to be correlated.]<br> <br> not a bug, but an enhancement :-) But you're correct. It could be (but<br> should be optional).<br> <br> > View private survey results by username i/o rid To view survey<br> > results, the admin must select from a random number counter. This<br> > number is of no meaning to anyone, so doesn't serve well as a lookup<br> > key. With the current implementation, it is impossible to look up<br> > survey results for a specific user, which is a common use case for<br> > private surveys.<br> <br> again an enhancement. And again a good one :-)<br> <br> > The drop-down should display the username in it so its contents can<br> > potentially be identified. My solution is to display the username,<br> > followed by the response ID (rather than a generated counter) in<br> > parentheses after it. The response ID is included because, unlike the<br> > counter, this value doesn't change. So an admin might remember, "Oh<br> > yeah, joeuser's survey with ID 145 is the one with the weird<br> > answers", and easily retrieve it.<br> <br> again an enhancement. And again a good one :-)<br> But a counter is also nice sometimes, so keep both if possible. Some<br> admins like the counter (even more when the admin is not very technical<br> at all).<br> <br> > For public surveys, it should display only the response_id, rather<br> > than an incremental counter. This is a minor improvement, but a<br> > useful one, because -- again -- the number will remain fixed. So<br> > looking up the results for survey 45 will ALWAYS show the results for<br> > survey 45, even if other surveys or results end up getting purged,<br> > which may change the number if it were just counting rows returned by<br> > a SQL query.<br> <br> well ... wether you use the response id or not, it doesn't say much,<br> since it's public. If a regular (again non-technical) admin looks at<br> results, he sometimes likes it more to see a counter . Sometimes it's<br> easier to say "look at 25th response ..." instead of "look at response<br> with ID 247"<br> <br> > This fix doesn't solve every use case -- it only goes so far with<br> > multiple submissions -- but it's a vast improvement. A further<br> > improvement, which I included, sorts the drop-down box by username<br> > followed by response ID, for the same reason.<br> > <br> > This can be done for public surveys as well as private ones, but it's<br> > much more meaningful for private ones, as querying by IP address is<br> > going to be almost as useless as querying by response id. My fix only<br> > applies to private surveys, although a future enhancement could add a<br> > config option to control this. The first two, by the way, are very<br> > easy one-line fixes. If someone can easily verify that the first one<br> > is a bug for all users, I'd advocate putting that into the upcoming<br> > release. The others can probably wait a little bit if nobody else has<br> > really complained, and I can provide fixes for those once the<br> > impending release branches.<br> > <br> > Cheers.<br> > -- Keith<br> > <br> <br> Already thanks for any work done on phpESP, it helps to make it better<br> all the time!<br> <br> Franky <!-- google_ad_section_end --> <pre class="moz-signature" cols="76"> </pre> </body> </html> |
