I should have stated more clearly why I think that an alternative bug reporting interface is interesting.
There are frequently mails on the users and discuss lists which are reasonable bug reports or enhancement requests. Sometimes it is quite obvious that these emails have come from users who are "simple" users i.e. they are obviously only just comfortable using the "open office" application, explorer and outlook but not much more. Maybe someone like your mother or your aunt. Now if we think that bug reports from someone who has a reasonable understanding of IT and IT development then we should not change anything as I think that the current multitude of choices scares most others away. However if we do value input from non-IT people then I think that there needs to be an alternative input form(s). Obviously the current input forms are useful for the developers and QA people so they should also remain. My proposal was trying to highlight those links and fields which I think are either not relevant for non project people (CC field, priority, initial state, assigned to ) or may not be clear enough (why show a version from 5 years ago as the default version number - and why show all of the development version numbers, etc). On Fri April 7 2006 12:51, Bernd Eilers wrote: > CPHennessy wrote: > > Hi all, > > Hi there! > > > I've just had to entry a bug report and it is quite an unpleasant > > experience : > > http://qa.openoffice.org/issue_handling/submission_gateway.html > > > > There are too many choices for and this only scares way many potential > > bug reporters (Obviously if we do not want those reports... ) > > > > Assuming we do want those reports, I think that some changes need to be > > made to the above page. What I suggest is to provide a javascript > > interface where the user is brought thru a number of obvious steps : > > > > 1) choose from : installation, writer, calc, impress, database, printing, > > upgrading, other (e.g. web, other langs, ... ? ) > > > > 2) choose version ( latest version being the default - with links to > > download it). > > Downloading and submitting issues are two totally different and > unreleated tasks. I don´t think a download link is in any way useful at > all at such page. If one wants to download he/she goes to the download > page, if one does want to submitt issues he/she goes to the > corresponding issue submit page. Users don´t usually decide to download > a different version in the middle of reporting a problem. And if we > would provide that option so that they may do that than this would only > distract them from the task they just started which was reporting the > issue, which we shouldn´t do assuming we do want those reports. Ok ,agreed. > > 3) choose OS > > 4) issue type should only be a choice between "bug" or "new feature" > > 5) OS ( set by default from what the browser sends) > > OS twice? We already selected that in step 3 ;-) Oops. That's what I get for writing an email so late at night :) > Preselecting that information with what the browser sends is already > done by issuezilla. Great. > And on the other hand I don´t thing you can rely on the information send > by the browser and not offer to change it. Because first I do believe > that there may be quite a couple of firewalls which block that this > information is being send at all and than there are some browsers which > would eg. tell you that they are "java" browsers instead of telling you > the OS and second there may be quite a few cases where a different OS is > being used when submitting the issue than when using the application ( > eg. issue occured at home but was submitted at work where the only > internet access the user has is ). Ok, so the platform needs to be selectable, but maybe rename it to "operating system" ? > > 6) Summary > > 7) Description > > 8) "Submit issue" > > > > Things which do *not* need to be shown for the "simple user" : > > - on the main page : > > - software components > > Well that´s the most important information issuezilla needs, you do need > a component to which to submitt the issue leaving this most important > information empty is not possible. That is you can´t create any HTML > page using javascript which feeds information into issuezilla whithout > having a component. That means you would have to select one of the > existing components as default component for "simple" issues or create a > new "simpleissues" component or something like that. Actually I was not suggesting removing the component, but rather renaming as "Application" as that is how most users think and adding 3 or 4 more general choices which should cover most bug reports. So component is always chosen by the user. > > - by project > > - by language > > - by code module > > You are aware that all those "by ..." links on the > submission_gateway.html page already are some kind of simplified > interface to the "real thing" which can be found at the link "the > classical way"? Please remember that I am not suggesting removing any functionality or choices for advanced users but rather removing making the interface as clear as possible by keeping it simple for the user to give enough information without giving up. > > - on the "Enter issue" page > > - subcomponent > > - initial state > > - assigned to > > - platform > > - priority > > - cc: > > > > Opinions ? > > For those things you do NOT want to show to the "simple" user but which > would be necessary fields of the issue in the database and for handling > them what should become the default values for those things than and > who´s gonna sort out all those "simple" submitted issues in a a way so > that these values are actually gonna be filled out correctly so that > anyone can actually start to work on these issues? I guess this really depends on what number of interesting bug reports are being "lost" because the simple users are scared of the complexity of entering a bug report and what quality are the bugs being reported (i.e. are all of the above fields being set by new bug reporters ? ). > How do you suppose to get volunteers for doing the > extra work of getting those "simple" issues into a shape that fits with > the current processing of issues by developers and qa? Maybe an analysis of bugs reported would be interesting : are those that are reported by users who have never reported a bug before useful, are the fields all wrong ? > For those things which are optional information anyway do you really > thing it is that scaring to the users to have some more fields in the > form which are optional? I imagine going to a restaurant for the first time where there was 4 or 5 pages of choices for the main plate. How much fun there is in choosing and how much more time you would spend reading all of the descriptions to find one particular meal which is either so unusual that it is the obvious choice or at least to eliminate the choices one by one to reduce your choices to a small number of options over the 4 or 5 pages. Now compare that to a menu (for those new to "Brazilian food from the barios") with only 3 or 4 choices for the main plate. The choice is simpler and clearer, plus it is easier to discuss the choices with your 3friends around the table. Ok, maybe a stupid example, but it is not that far from the point I am trying to make. I think that we are missing good bug reports and interesting enhancement requests as the current input form is over complicated and offers too many choices for the "simple" user. CPH --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
