Re: [Libreoffice] EasyHack: Improved bug filing form / flow
Hi Samuel, hi Ivan, all! Am Montag, den 04.04.2011, 22:57 +0100 schrieb Samuel Atkins: On 04/04/2011 11:14 AM, Ivan M. wrote: [...] I do have one question though: would the submitted form actually submit a bug report in Bugzilla, or would it get sent to someone for moderation/confirmation? [...] I think the plan was to have it submit directly to bugzilla, but it may well be beneficial to have some sort of moderation. I don't know whether this had been discussed already - but I think Bugzilla itself may be the tool to do the moderation (unconfirmed -- confirmed). But then it'll be helpful to identify where the bug came from ... maybe adding a keyword like BugFromSimpleBugForm that enables filtering? E.g. for letting QA focus on such issues, or even doing some statistics (e.g. how many of these bugs turned into duplicates). Last year, I've attended a very nice research talk that dealed with Mozilla bug reports and their reporters. Just by 2 cents. Thank you both for working on that! Cheers, Christoph ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] EasyHack: Improved bug filing form / flow
Hi all, Well, I didn't get enough time to make a mockup, but I do have a number of suggestions, as I hinted yesterday, so I'll run through them here. I would envision taking the existing steps (with a few tweaks here and there) and turning them into a step-by-step wizard-like experience with each step sliding in and out from right to left as it is completed. So, for 'LibreOffice crashes', there would be a separate screen for 'when does LibreOffice crash,' 'Operating System,' etc - maybe with a progress bar to show the user's progress through the process. I think this kind of simplicity and feedback would be a user-friendly way of making this 'technical' process accessible (this would also mean providing help and hints - e.g. how to take a screenshot). I do have one question though: would the submitted form actually submit a bug report in Bugzilla, or would it get sent to someone for moderation/confirmation? The first step would be to search for similar bugs. IIRC this is (or was) a mandatory step when submitting a Ubuntu bug on Launchpad, and it might help us to do the same. I realize that this is a careful balancing act - making it easy and simple for the end user in order to increase participation, but also not flooding the QA team with poor quality time wasting reports. So, step 1 for me would be that - perhaps in an iframe so that we can offer a link the user can click if they can't find their bug (so that they can proceed) A good number of these steps involve users submitting data, and I think there should be more disclaimers around that (e.g. please be sure to remove any private or personally identifiable information). We should also inform the person about what's going to happen to their material - will it be available online for others to examine? If so, there may be potential copyright issues. Concerning 'LibreOffice is hard to use', it may be difficult to differentiate between a bug report and a feature request - is it a feature or a bug? We could simply forward these reports (since they could contain very valuable data) to people who are involved with UX (i.e., Christoph's mailbox :P) where that decision can be made more easily. Potential differentiators could include 'LibreOffice doesn't do what I expect,' 'I find it difficult to use a particular feature,' and one or two others. With website feedback, the range of possible problems could involve display issues, broken links, trouble downloading, typos (if we want to be pedantic - maybe 'wording' might be a better term since it could cover cultural/language issues, or instances where something is not clear) and perhaps (if applicable) user account issues with LibO websites (for now I can only think of the wiki - sure, we have Silverstripe logins, but only for people who have a reasonable idea of what they're doing). I hope this 'brain dump' helps a little - I think this is something that will steer LibO and its user in the right direction (especially if we include a link to this from within LibO). Regards, Ivan. On Sun, Apr 3, 2011 at 9:52 PM, Ivan M. iv...@patentpending.co.nz wrote: Hi Christoph, Samuel all, Hey, this is pretty cool! :) On Tue, Mar 29, 2011 at 9:49 AM, Christoph Noack christ...@dogmatux.com wrote: I CCed Ivan who might add his thoughts here ... and there. I know that he's pretty busy at the moment (changes in his private life), but maybe he'll be able to spend some minutes. Ah. the private lives of LibO community contributors :) Although I now need to improve my free-time management, things like this definitely get my attention (eventually - sorry for the late response). Actually, any graphical mock-ups of how it should look would be useful, if anyone fancies giving it a go. :) It's fairly ugly right now. Hoping for Ivan ;-) If he lacks the time, then we'll CC design / website list. Personally, I fear that I'll be unable to help here, since my private life changes as well - spending time for LibO gets more difficult :-) I'd like to enhance the design by making it even more simple with one-step-at-a-time logic. I'll try to provide a low-fi mockup tomorrow as right now I'm reading through the backlog of LibO emails (a constant battle). jQuery could help here with some nice transitions that make the process (dare I say it) enjoyable. I'll think about it some more in the meantime, but will definitely try to have something done tomorrow. Regards, Ivan. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] EasyHack: Improved bug filing form / flow
Hi Ivan, Glad you found some time to have a think about this. :-) On 04/04/2011 11:14 AM, Ivan M. wrote: I would envision taking the existing steps (with a few tweaks here and there) and turning them into a step-by-step wizard-like experience with each step sliding in and out from right to left as it is completed. So, for 'LibreOffice crashes', there would be a separate screen for 'when does LibreOffice crash,' 'Operating System,' etc - maybe with a progress bar to show the user's progress through the process. I think this kind of simplicity and feedback would be a user-friendly way of making this 'technical' process accessible (this would also mean providing help and hints - e.g. how to take a screenshot). I do have one question though: would the submitted form actually submit a bug report in Bugzilla, or would it get sent to someone for moderation/confirmation? Cool idea! I've quickly had a go at a mockup myself (I happen to have just written a scrolly thing, so it was pretty simple. :-) ) which is located here: http://atkinslg.dyndns.org:4080/stuff/wizardmockup.html There are some stub slides in there showing how it could work well even when branching (different sets of questions based on problem type, etc). It already feels very nice, and much simpler. :-) I think the plan was to have it submit directly to bugzilla, but it may well be beneficial to have some sort of moderation. The first step would be to search for similar bugs. IIRC this is (or was) a mandatory step when submitting a Ubuntu bug on Launchpad, and it might help us to do the same. I realize that this is a careful balancing act - making it easy and simple for the end user in order to increase participation, but also not flooding the QA team with poor quality time wasting reports. So, step 1 for me would be that - perhaps in an iframe so that we can offer a link the user can click if they can't find their bug (so that they can proceed) Not sure about how to make it mandatory (probably possible to an extent though). I haven't put the iframe in yet, but that's more because I was busy playing with the other stuff. :-) A good number of these steps involve users submitting data, and I think there should be more disclaimers around that (e.g. please be sure to remove any private or personally identifiable information). We should also inform the person about what's going to happen to their material - will it be available online for others to examine? If so, there may be potential copyright issues. Should be fine to include it every time data has to be submitted now, as it'll still only be one per slide, so not that cluttered. Concerning 'LibreOffice is hard to use', it may be difficult to differentiate between a bug report and a feature request - is it a feature or a bug? We could simply forward these reports (since they could contain very valuable data) to people who are involved with UX (i.e., Christoph's mailbox :P) where that decision can be made more easily. Potential differentiators could include 'LibreOffice doesn't do what I expect,' 'I find it difficult to use a particular feature,' and one or two others. Forwarding should be simple enough, yeah. Though if stuff is moderated, maybe it wouldn't need to distinguish between bugs and feature requests? With website feedback, the range of possible problems could involve display issues, broken links, trouble downloading, typos (if we want to be pedantic - maybe 'wording' might be a better term since it could cover cultural/language issues, or instances where something is not clear) and perhaps (if applicable) user account issues with LibO websites (for now I can only think of the wiki - sure, we have Silverstripe logins, but only for people who have a reasonable idea of what they're doing). Sure. I think with this and the 'hard to use' category, it'll be a while until stuff has to be properly nailed-down, so there's no rush. I'll probably have to chat with some QA people at some point, see what kind of bugs generally come-up. I hope this 'brain dump' helps a little - I think this is something that will steer LibO and its user in the right direction (especially if we include a link to this from within LibO). Regards, Ivan. Sure! Very helpful. :D And it's always good to have a fresh view on things. But yeah, I'm very pleased with the wizard idea. :-) Thanks again, ~ Sam ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] EasyHack: Improved bug filing form / flow
Hi Christoph, Samuel all, Hey, this is pretty cool! :) On Tue, Mar 29, 2011 at 9:49 AM, Christoph Noack christ...@dogmatux.com wrote: I CCed Ivan who might add his thoughts here ... and there. I know that he's pretty busy at the moment (changes in his private life), but maybe he'll be able to spend some minutes. Ah. the private lives of LibO community contributors :) Although I now need to improve my free-time management, things like this definitely get my attention (eventually - sorry for the late response). Actually, any graphical mock-ups of how it should look would be useful, if anyone fancies giving it a go. :) It's fairly ugly right now. Hoping for Ivan ;-) If he lacks the time, then we'll CC design / website list. Personally, I fear that I'll be unable to help here, since my private life changes as well - spending time for LibO gets more difficult :-) I'd like to enhance the design by making it even more simple with one-step-at-a-time logic. I'll try to provide a low-fi mockup tomorrow as right now I'm reading through the backlog of LibO emails (a constant battle). jQuery could help here with some nice transitions that make the process (dare I say it) enjoyable. I'll think about it some more in the meantime, but will definitely try to have something done tomorrow. Regards, Ivan. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] EasyHack: Improved bug filing form / flow
Hi Christoph, Sorry about taking a while to reply. I'm dangerously close to actually having a life, hence disruption. ;-) On 28/03/2011 9:49 PM, Christoph Noack wrote: Hi Sam! That already looks *amazing* ... especially the thoughtful textual descriptions - thanks for your hard work. Nevertheless, I played a bit with the site and came up with some stuff - mostly minor things or questions. And - as always - skip those items that might have been mis-interpreted on my side. Or just tell me (even better)... General * If people (like me) look through some of the options, then most of the stuff gets saved, although options are not shown. I don't know whether this may be a problem, but maybe options that exclude each other are saved at the end. Yeah, I need to find a way of resetting things. Doable, just probably fiddly. * I'm not sure whether I missed it, but might it be helpful to ask (also for the Search) for the version of LibreOffice? Or is this page opened via a link from LibO that automatically pre-selects the required version? I'd completely forgotten about versions! I'll add a question for it, and a help text. Section Search for Similar Bugs: What shall people do who find similar looking bugs? Something like If yes, then it is likely that we are already working on resolving it. To me, it looks more promising ;-) Sure! And thanks. :-) Section File a New Bug * Chatroom: How about adding this to the top of the page? Then all help related stuff is grouped - and the chat might already be helpful for searching for bugs. Good idea. * LibreOffice crashes * When does LibreOffice crash?: Here, it seems that you place all the options directly below the currently selected radio button. In other place, you place the new content below the group of radio buttons. The latter one seems the preferred version, since it avoids jumping of the page, and causing large gaps between the single radio buttons. I hadn't done that consciously, but yeah, I can see how having new things after would be clearer. :-) * Which operating system have you found the crash on?: * How about Windows -- Microsoft Windows, Mac OS X -- Apple Mac OS X Sure. Thanks for pointing that out. :-) * Linux: * Type in Please follow th*g*ese instructions Typo (and the other one later): oops! I should use a text editor with a spell checker. * Is the backtrack mandatory? If not, it would be great if we could mention it ... otherwise it might. Hmmm. I'm not sure. It could be too complicated a thing to force people to do. * Another potential OS * Sorry, I don't get the meaning of potential in this case. * Might it be helpful to ask for the tag line in the about box? I'm not sure whether it already contains the OS name, but we talked about it some time ago. Sorry, this section was meant to be a placeholder for other OS sections, I didn't make that clear enough. From the download page it seems that LO is only available on Windows, Mac and Linux, but I expect there are probably others (and will be in the future). Then again, for now it would probably be better to have a box to enter the name of a different OS. The OS doesn't appear in 'about' in 3.3.2, which is what I'm running, so I can't say whether it's in yet! But it sounds useful. * Which operating system have you found the crash on? * Placeholder: If an error message ...: A question, do you intend to ask for a screenshot to e.g. get the complete error message? To me, it seems that some people might be thankful for typing in the message (but again, it is likely that people type in strange / shortened / whatever stuff). Yeah, getting a screenshot of the error message would be ideal, though a text box as well would be useful. * My document looks wrong when I load it * Are you sure you have the fonts installed?: A less platform specific way might be to refer to e.g. the Format - Characters dialog. If a selected font is not installed, then a corresponding message gets shown above the font preview. (Just remembered that we have
Re: [Libreoffice] EasyHack: Improved bug filing form / flow
Hi Samuel, On Monday 21 March 2011 21:53:54 Samuel Atkins wrote: Hello all, I'd like to pick-up this project, as it looks like something I could accomplish! I looked at this task yesterday, so I guess we started at the same time. I have added your name to the task on the easy hacks site in the wiki to prevent double work. I've had a go on it the last couple of days, and the current page is at http://atkinslg.dyndns.org:4080/stuff/submitbug.html - I'm mostly working from Michael's proposal. I've spoken with him on IRC already, and he gave me a couple more pointers. As my javascript already is a huge load of unmaintainable code with probably less than 5 percent of the workflow I am quite happy that you stepped up. So this is largely an introduction. So, hello! And of course, if anyone has any input, feel free. One technical question. Do you already know how to interact with the bugzilla? I thought of creating the bug with javascript via the xml-rpc api of bugzilla. Some other, and probably nicer apis like JSON or REST seem not to be activated on the freedesktop bugzilla. Regards, Michael ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] EasyHack: Improved bug filing form / flow
Hi Cristoph, thanks for the quick feedback (in great quantity!) On 21/03/2011 10:41 PM, Christoph Noack wrote: Just a few questions at the beginning: * Is that bug filing form intended to help less experienced users? (Within this mail, I'll assume that). Yes, that's the idea. * Is the formatting of the page final, or will it be embedded in another web page? It's not final. I'm not sure whether it will be embedded into another page, but for the moment I'm not focusing on the appearance of it. At the moment, there are some minor issues and some things that look a bit illogical to me (but this may only be me). So please bear with me when I simply state some of these issues: * When choosing the options, users might miss the information whether they are finished or not. So my proposal would be to state a text / placeholder like Further information required. and add visual clues (spacing, subtle headings, or ...) between the different questions. 'Further info needed' message sounds good. Maybe unanswered questions should be a different colour to stand out, that'd be pretty simply to implement. * The large heading Before you file ... seems to be a heading for the whole page - I'm sure it is not. The whole page is about the bug report (= the heading) and some hints to consider before filing any issue (proposal: a separate box at the top). There, please include the If you are having more than one problem ... Yeah, that heading is left-over from the previous person's work, I hadn't got round to changing it. * The whole text seems a bit too technical (assumption: less technical users). There is #libreoffice IRC, crash, ODF (on the wiki pages), bug, ... Thanks, it wouldn't have occurred to me that this was too technical. I'll have a go at making it simpler. * The combination of some entries seems a bit strange, e.g.: * There is a problem with the website + Crashes the program Hmmm, the website message thing is a bug, that's not meant to be there! * LibreOffice crashes + Does it crash ... load or save ... document? YES + Do you need to load a document to execute those steps NO. Yeah, that section needs reorganising. Actually, it probably makes the most sense to have to pick one of crash when load/save, crashes when I do these things and crashes randomly. * Some helpful hints might be less helpful for users, e.g.: * If possible, please search the bug reports before ... -- If the users are less experienced, how and where to do that? If I remember correctly, Gnome let the user enter some terms and then searches within such kind of bug filing form. Looks like a bug-search form should be simple to add. Good idea. * Are you sure ... fonts installed. Bear in mind ... may list fonts that are not installed. -- How should the user identify what kind of fonts are installed (still, I assume less experienced users). I did try and look for some existing documentation about seeing what fonts are installed/how to install them, but couldn't find any. If anyone knows of any, or could write some, it'd be helpful. :) * document ... then attach it -- where? (Maybe it's not yet implemented, but I didn't see the nice placeholders you used elsewhere). Not yet implemented. I'm not yet sure whether picking a file on this page can be used to fill it in on the bugzilla form. Or if going the more ideal route of directly bypassing the form, how to submit multiple files (for instance screenshots as well). However, it looks like Michael Munch might have a better idea of that side. (I'll address that in another post shortly). * Formatting stuff: * The Description fields are very small - maybe the problems are small as well, but I think it is helpful to increase the field size a bit. (On my computer, the current size is approx 4x2 cm) * The radio buttons are itself a list, so we might skip the additional bullets. I haven't yet spent time making it look pretty, including these two things. I'll fiddle with the formatting once everything is working. :) * It would be just great if the For help on this, see here could just open an additional section below the current section. That would save the users to jump back an forth with the newly opened browser windows. H. It looks like the wiki has an API, so it would be possible to grab sections from the wiki. eg, http://wiki.documentfoundation.org/index.php?action=rendertitle=User:AtkinsSJ/BugFiling
Re: [Libreoffice] EasyHack: Improved bug filing form / flow
Hi Michael, On 22/03/2011 7:15 PM, Michael Münch wrote: Hi Samuel, On Monday 21 March 2011 21:53:54 Samuel Atkins wrote: Hello all, I'd like to pick-up this project, as it looks like something I could accomplish! I looked at this task yesterday, so I guess we started at the same time. I have added your name to the task on the easy hacks site in the wiki to prevent double work. Aha! Thank you, and sorry. I was having trouble with the wiki the last couple of days, and couldn't add a 'taken' note, but it now seems to let me edit pages. I hope you didn't spend too long on it. As my javascript already is a huge load of unmaintainable code with probably less than 5 percent of the workflow I am quite happy that you stepped up. Hehe, thanks! I'm not that great at Javascript, but I did manage to write a couple of more general functions than what was there. One technical question. Do you already know how to interact with the bugzilla? I thought of creating the bug with javascript via the xml-rpc api of bugzilla. Some other, and probably nicer apis like JSON or REST seem not to be activated on the freedesktop bugzilla. Ah, I do not know how to interact with bugzilla, so if you do then that would be wonderful. :) I was wondering about using an API in order to attach multiple files to a bug when the user clicks 'submit' - things like the problem document, and screenshots. It would be very handy if you could work on that type of thing. :) ~ Sam ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] EasyHack: Improved bug filing form / flow
Hello all, I'd like to pick-up this project, as it looks like something I could accomplish! I've had a go on it the last couple of days, and the current page is at http://atkinslg.dyndns.org:4080/stuff/submitbug.html - I'm mostly working from Michael's proposal. I've spoken with him on IRC already, and he gave me a couple more pointers. So this is largely an introduction. So, hello! And of course, if anyone has any input, feel free. ~ Sam (AtkinsSJ on IRC, etc) ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] EasyHack: Improved bug filing form / flow
Hi Samuel, great to hear that you continue this project ... Am Montag, den 21.03.2011, 21:53 + schrieb Samuel Atkins: Hello all, I'd like to pick-up this project, as it looks like something I could accomplish! [...] So this is largely an introduction. So, hello! And of course, if anyone has any input, feel free. Just a few questions at the beginning: * Is that bug filing form intended to help less experienced users? (Within this mail, I'll assume that). * Is the formatting of the page final, or will it be embedded in another web page? At the moment, there are some minor issues and some things that look a bit illogical to me (but this may only be me). So please bear with me when I simply state some of these issues: * When choosing the options, users might miss the information whether they are finished or not. So my proposal would be to state a text / placeholder like Further information required. and add visual clues (spacing, subtle headings, or ...) between the different questions. * The large heading Before you file ... seems to be a heading for the whole page - I'm sure it is not. The whole page is about the bug report (= the heading) and some hints to consider before filing any issue (proposal: a separate box at the top). There, please include the If you are having more than one problem ... * The whole text seems a bit too technical (assumption: less technical users). There is #libreoffice IRC, crash, ODF (on the wiki pages), bug, ... * The combination of some entries seems a bit strange, e.g.: * There is a problem with the website + Crashes the program * LibreOffice crashes + Does it crash ... load or save ... document? YES + Do you need to load a document to execute those steps NO. * Some helpful hints might be less helpful for users, e.g.: * If possible, please search the bug reports before ... -- If the users are less experienced, how and where to do that? If I remember correctly, Gnome let the user enter some terms and then searches within such kind of bug filing form. * Are you sure ... fonts installed. Bear in mind ... may list fonts that are not installed. -- How should the user identify what kind of fonts are installed (still, I assume less experienced users). * document ... then attach it -- where? (Maybe it's not yet implemented, but I didn't see the nice placeholders you used elsewhere). * Formatting stuff: * The Description fields are very small - maybe the problems are small as well, but I think it is helpful to increase the field size a bit. (On my computer, the current size is approx 4x2 cm) * The radio buttons are itself a list, so we might skip the additional bullets. * It would be just great if the For help on this, see here could just open an additional section below the current section. That would save the users to jump back an forth with the newly opened browser windows. I hope this list doesn't look discouraging - quite the contrary. To me, it's a real please that somebody picked up this topic. So if you need more detailed proposals / an in-depth review, then please let me know (or just ping the Design Team). I'll wait for your request until you think it's ready ... Again, thanks for working on that! Cheers, Christoph ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] EasyHack: Improved bug filing form / flow
Hi Daniel, also from my side - thanks for having a look at the bug filing and the results created so far. It's great to see somebody picking up stuff like that to improve some hidden sides of LibreOffice ... If anybody wants to continue with this topic, then please CC the Design Team or me, so that we can help here (usability, text descriptions, ... Michael already provided a great proposal). Again, thanks for you work! Cheers, Christoph Am Sonntag, den 27.02.2011, 21:55 -0500 schrieb Daniel Neel: Alrighty, I've attached the current progress to this message and will be updating the wiki shortly. Thanks again everyone for your time. On Fri, Feb 25, 2011 at 9:37 AM, Jan Holesovsky ke...@suse.cz wrote: Hi Daniel, On 2011-02-24 at 19:37 -0500, Daniel Neel wrote: I think this project is moving a bit beyond what I currently have skill and time to complete with quality. I think it would be best for me to pass the current work on to someone else. Sorry to hear that :-( You are doing great from my point of view, but of course, cannot force you ;-) Would the best course of action be to update the EasyHacks page with a notice of the current progress on the hack, an attachment of the file, and maybe a link to this mailing list conversation? I look forward to helping out LO in other ways soon. Yes please - the best would be to send your current work to this mailing list (as a mail attachment), and add the description + link to the mail with the attachment in the mail archive (http://lists.freedesktop.org/archives/libreoffice/) + link to the entire conversation to the wiki. All the best, Kendy ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] EasyHack: Improved bug filing form / flow
I think this project is moving a bit beyond what I currently have skill and time to complete with quality. I think it would be best for me to pass the current work on to someone else. Would the best course of action be to update the EasyHacks page with a notice of the current progress on the hack, an attachment of the file, and maybe a link to this mailing list conversation? I look forward to helping out LO in other ways soon. Thanks, Daniel On Mon, Feb 21, 2011 at 1:15 PM, Michael Meeks michael.me...@novell.comwrote: Hi Daniel, On Fri, 2011-02-18 at 22:32 -0500, Daniel Neel wrote: Ok, a quick status update on this. Have been working on it some more - the current code is available at http://dneelyep.webs.com . Notes on the current progress below. Ooh :-) it looks really sweet ! This is a great start Daniel. Added a Submit button - not currently setup to bring up a pre-filled bug report. I wonder, if we can't avoid showing the bugzilla page entirely - and simply provide a nicer whizzy front-end for that. Does anyone have more suggestions by chance to improve this? I'm definitely interested :). Yes; making it more lush and graphical would be good for a start. As an example - the process of binary chopping documents down is really useful to understand - IMHO we need more documentation on that, perhaps with a picture of a document being chopped to help people understand. I think we probably also need to make the questions easier to understand (think expert friendly, but idiot proof), of course this will require a lot of thought to get the taxonomy right: Radio buttons: ( ) can you crash LibreOffice somehow ? ( ) does your document not look right when it is loaded ? ( ) did other people have trouble reading the document you sent ? ( ) is there an unpleasant user interaction that makes it difficult to use ? [ if several of these, please file multiple reports ] I would also tend to hide everything else (including the submit button) until the data is useful - so people have a fairly linear flow. ( ) can you crash LibreOffice somehow ? ( ) does this happen when you load or save a certain document ? + link to making minimal documents blurb :-) ( ) is there a simple set of steps, and button clicks that can crash with no document loaded ? + link to how-to-get-stacktrace documentation ( ) is the crash intermittent and un-predictable ? + link to how-to-get-stacktrace documentation ( ) does your document not look right when it is loaded ? + link to making minimal documents blurb [x] I am certain that I have the correct fonts installed on the system for this document + link to fc-list (Linux), and Mac/Win details + NB. the 'font' drop-down in LO lies - we should explain that. + ask for screenshots before / after of the problem ( ) did other people have trouble reading the document you sent ? ( ) Do you have the original document in OpenDocument format ? No == very hard to work out what went wrong. can you try to reproduce what you did, and first save it in ODF, before exporting ... Yes == link to producing minimal document description ;-) ( ) is there an unpleasant user interaction that makes it difficult to use ? + no idea where to go here I guess. I suspect we could avoid asking which component is involved, and just look at up-loaded test document / file extensions in many cases to auto-select the component. I liked your proxies for severity: causes loss of content etc. - asking people the severity of their bug is almost never a good idea :-) [ which is why I like the plan to hide the actual bug form from them ]. Anyhow - this is a really sexy initiative :-) Hopefully we can get some more artwork support from the design team, to actually make it fun / pretty to file really good bugs. What can we do to make it easier to file ? eg. can we wrap the account creation flow in some pleasant way ? Perhaps that should be step #1 - without an E-mail address and a real account, it is fairly pointless filing a bug IMHO. Thanks ! Michael. -- michael.me...@novell.com , Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] EasyHack: Improved bug filing form / flow
Hi Daniel, Daniel Neel píše v Čt 17. 02. 2011 v 22:33 -0500: Hello all. I've been working on the EasyHack Improved bug filing form / flow (http://wiki.documentfoundation.org/Development/Easy_Hacks#Improved_bug_filing_form_.2F_flow) and have finished the part that asks questions about the bug being file-specific. The current work is available at http://www.dneelyep.webs.com . The next part (adding custom tags to bug reports) seems a bit advanced and maybe beyond my current abilities. Cool, thank you a lot! :-) One more request to the workflow; when it is a crasher, and on Linux, please ask (the similar way as you are asking about the document) to attach a backtrace that is to be obtained as described here: http://wiki.documentfoundation.org/BugReport#How_to_get_backtrace_.28on_Linux.29 The next part (adding custom tags to the bug report) raised some questions. First, would the questions and tags be best added to the current bug reporting page (https://bugs.freedesktop.org/enter_bug.cgi?product=LibreOffice)? This seems to be a good place - doing so allows the bug reporter to report all information in one step. If this is the correct place to implement the questions/info, where/how would it be possible to edit the default LibO bug reporting page? I think it does not have to be exactly part of this page; I can imagine even some kind of www.libreoffice.org/report-bug which would do this pre-triage. If we advertise it accordingly, most of the reports will go through that. To implement tags on bug reports it seems that adding tags (such as crashes program or causes content loss) would require an admin to create them before you could add them to bug reports. Then you could have a series of checkboxes for the various tags (as seen on my mockup), which would add tags to the bug report if selected. I think for the beginning these can be just a text in the first comment that you'll generate for the bugreport; or Whiteboard tags. Do these ideas seem to be the best way to implement the bug flow? That is, should the questions about the bug report being file-specific and the custom tags be added to the current bug reporting page? I would start with a standalone page; but of course, Michael added the task, so I'd say - his call :-) Unfortunately, he's out today. Thank you, Kendy ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] EasyHack: Improved bug filing form / flow
On Fri, Feb 18, 2011 at 2:11 AM, Jonathan Aquilina eagles051...@gmail.com wrote: Daniel just a suggestion if its not already available in the current method. I am not sure if you have worked with launchpad the ubuntu bug tracker, but with it you have the ability to assign a bug to a team or user. Is that something that could be implemented so that users who are signed up to the bug tracker can file bug and assign themselves to the bug if they can fix it? That will help avoid duplication of work and allow others to work on other bugs :) Hmm, I think something similar is implemented in Bugzilla, but I'm not sure since I haven't really used it yet. There's an 'Assign To:' field that seems to be enabled in all bug reports. I'm not sure if you can specify teams to assign it to, or just individuals. I looked this up a bit and it seems to be half-implemented on the current bug reporting form. At https://bugs.freedesktop.org/enter_bug.cgi?product=LibreOffice , click Show Advanced Fields. On some other projects on freedesktop bugzilla, when you select an item in the Component: list, the Assign To: field changes to the corresponding person/team. The LibreOffice bug reporting just defaults to reporting all bugs to the libreoffice-bugs mailing list though. So I'm thinking that the people who deal with triaging bugs would prefer to assign all bugs to the same mailing list, rather than individual people/teams? On Fri, Feb 18, 2011 at 4:00 AM, Jan Holesovsky ke...@suse.cz wrote: Cool, thank you a lot! :-) One more request to the workflow; when it is a crasher, and on Linux, please ask (the similar way as you are asking about the document) to attach a backtrace that is to be obtained as described here: http://wiki.documentfoundation.org/BugReport#How_to_get_backtrace_.28on_Linux.29 Will get started on adding this and the tags now. I'm thinking a solution would be to have a 'Submit' button at the bottom of this form, that when clicked links to a new bug report on Bugzilla with some of the fields pre-filled (tags, other things?). I think it does not have to be exactly part of this page; I can imagine even some kind of www.libreoffice.org/report-bug which would do this pre-triage. If we advertise it accordingly, most of the reports will go through that. Good deal, that makes sense. After the work is finished I can look into making either a dedicated page for the pre-triaging (maybe a sub-page of http://www.libreoffice.org/get-involved/qa-testers/) or another page that can be linked to. Either way, it should be possible to change the current links for reporting bugs (on the website, wiki, etc) to link to the pre-triaging page. I think for the beginning these can be just a text in the first comment that you'll generate for the bugreport; or Whiteboard tags. Hmm...would Whiteboard tags be better here? I'm not really sure how they work. I get the impression that they're tags which the bug reporter can make up, rather than having to be pre-defined by an admin? If so this seems like a good solution - would allow people to view a list of, say, all the crasher bugs at once. Unless I'm understanding the idea incorrectly? ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] EasyHack: Improved bug filing form / flow
Ok, a quick status update on this. Have been working on it some more - the current code is available at http://dneelyep.webs.com . Notes on the current progress below. Added the information on getting a Linux backtrace Added information that can pop up depending on which checkboxes are checked. Currently missing information in several items - is there helpful stuff to be added, or best to leave some of them blank? Added a Submit button - not currently setup to bring up a pre-filled bug report. Clicking it takes you to the bug reporting page - this should be set up to link automatically to the pre-filled report instead - currently working on this. Added a link to bypass all of these steps if the user wants to. Only remaining steps are to fill in the checkbox info with useful information, add new checkboxes if needed, and set up the bug reporting pre-filling thing. So the plan for doing the custom fields is to generate a custom URL, based on the options selected by the user. An example pre-filled URL: https://bugs.freedesktop.org/enter_bug.cgi?alias=assigned_to=mclasen%40redhat.comblocked=bug_file_loc=http://bug_severity=normalbug_status=ASSIGNEDcomment=component=generalcontenttypeentry=contenttypemethod=autodetectcontenttypeselection=text/ plaindata=dependson=description=form_name=enter_bugkeywords=maketemplate=Remember%20values%20as%20bookmarkable% 20templateop_sys=NetBSDpriority=lowproduct=accountsserviceqa_contact=rep_platform=Othershort_desc=version=unspecified The fields available appear to be: https://bugs.freedesktop.org/enter_bug.cgi?alias= assigned_to= blocked= bug_file_loc= bug_severity= bug_status= comment= component= contenttypeentry= contenttypemethod= contenttypeselection= data= dependson= description= form_name= keywords= maketemplate= op_sys= priority= product= qa_contact= rep_platform= short_desc= version= Which can for our purposes be narrowed down to (I think): comment= # Fills the description field. Can be used to remind the user to attach files depending on previous answers. keywords= # If used, will need to follow this format: word1,%20word2,%20word3 (the %20 represents a space) product=LibreOffice The 'keywords' field can be filled with info such as a crashesprogram or lossoflayout field or similar while the 'comment' field can, as mentioned, provide reminders to the user to perform actions. Does anyone have more suggestions by chance to improve this? I'm definitely interested :). Thanks, Daniel On Fri, Feb 18, 2011 at 7:58 PM, Daniel Neel dneel...@gmail.com wrote: On Fri, Feb 18, 2011 at 2:11 AM, Jonathan Aquilina eagles051...@gmail.com wrote: Daniel just a suggestion if its not already available in the current method. I am not sure if you have worked with launchpad the ubuntu bug tracker, but with it you have the ability to assign a bug to a team or user. Is that something that could be implemented so that users who are signed up to the bug tracker can file bug and assign themselves to the bug if they can fix it? That will help avoid duplication of work and allow others to work on other bugs :) Hmm, I think something similar is implemented in Bugzilla, but I'm not sure since I haven't really used it yet. There's an 'Assign To:' field that seems to be enabled in all bug reports. I'm not sure if you can specify teams to assign it to, or just individuals. I looked this up a bit and it seems to be half-implemented on the current bug reporting form. At https://bugs.freedesktop.org/enter_bug.cgi?product=LibreOffice , click Show Advanced Fields. On some other projects on freedesktop bugzilla, when you select an item in the Component: list, the Assign To: field changes to the corresponding person/team. The LibreOffice bug reporting just defaults to reporting all bugs to the libreoffice-bugs mailing list though. So I'm thinking that the people who deal with triaging bugs would prefer to assign all bugs to the same mailing list, rather than individual people/teams? On Fri, Feb 18, 2011 at 4:00 AM, Jan Holesovsky ke...@suse.cz wrote: Cool, thank you a lot! :-) One more request to the workflow; when it is a crasher, and on Linux, please ask (the similar way as you are asking about the document) to attach a backtrace that is to be obtained as described here: http://wiki.documentfoundation.org/BugReport#How_to_get_backtrace_.28on_Linux.29 Will get started on adding this and the tags now. I'm thinking a solution would be to have a 'Submit' button at the bottom of this form, that when clicked links to a new bug report on Bugzilla with some of the fields pre-filled (tags, other things?). I think it does not have to be exactly part of this page; I can imagine even some kind of www.libreoffice.org/report-bug which would do this pre-triage. If we advertise it accordingly, most of the reports will go through that. Good deal, that makes sense. After the work is finished I can look into making either a
Re: [Libreoffice] EasyHack: Improved bug filing form / flow
Daniel just a suggestion if its not already available in the current method. I am not sure if you have worked with launchpad the ubuntu bug tracker, but with it you have the ability to assign a bug to a team or user. Is that something that could be implemented so that users who are signed up to the bug tracker can file bug and assign themselves to the bug if they can fix it? That will help avoid duplication of work and allow others to work on other bugs :) ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
