Re: [Launchpad-dev] RFC: UI for +filebug while waiting-for-blob-to-be-processed
On Tue, Feb 16, 2010 at 5:06 AM, Graham Binns gra...@canonical.com wrote: I'm currently working on the Apport blob processing story [1], whose aim is to make sure that +filebug doesn't time out when apport uploads an enormous blob (the problem being that the blob is currently processed in-request, so the bigger ones cause timeouts fairly regularly). ... Hey Graham, There's already been some great feedback on this thread. I just wanted to ask how including every 10 seconds helps the user? What would be the impact of removing it? jml ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] RFC: UI for +filebug while waiting-for-blob-to-be-processed
On 17 February 2010 01:52, Martin Pool m...@canonical.com wrote: On 16 February 2010 21:06, Graham Binns gra...@canonical.com wrote: I want the UI to be fairly simple - just a message and a spinner. I've attached a screenshot of what I'm thinking of. Suggestions and comments are welcome. Thanks for circulating it. Thanks for replying. Please wait. Launchpad is processing the extra bug data you uploaded. This page will refresh every 10 seconds until processing is complete. * To me 'refresh' means reload completely; that seems redundant with having a spinner, and a bit unnecessary? Well, I bunged it on the page as a way of saying something's happening but you're right; in this iteration, where we're doing complete reloads, it's probably unnecessary. * It's not really 'you' because the upload is coming from apport and the user is just cooperating with it. Hmm, good point. * Are we processing it or just loading it? We're parsing it to extract the salient data. So I would suggest Please wait while bug data is sent. spin spin I think processed or loaded is better, though I'm ambivalent about which is better. The fact that the page will eventually reload should be obvious. Ideally you would show how much data is to be sent (4MB or whatever) but that may be hard. Good idea. That shouldn't be hard; we can get filesize data from the librarian. And it's not the 4MB uploads that cause the problem. It's the 90+MB ones... -- Graham Binns | PGP Key: EC66FA7D ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] RFC: UI for +filebug while waiting-for-blob-to-be-processed
On 16 February 2010 10:06, Graham Binns gra...@canonical.com wrote: Hi folks, I'm currently working on the Apport blob processing story [1], whose aim is to make sure that +filebug doesn't time out when apport uploads an enormous blob (the problem being that the blob is currently processed in-request, so the bigger ones cause timeouts fairly regularly). I've already written the code for processing the blobs server-side using the Jobs system, so all that's left is to make +filebug aware of that system. The idea is that +filebug will check to see whether the blob has been processed before allowing the user to proceed. If it hasn't, +filebug will wait a while and check again; if it has, +filebug will use the processed data as normal. The idea is that we'll do this using Javascript eventually, but in the first iteration of this we're going to do it with meta refresh tags, since that's reasonably quick to develop, meanting that if we don't have time to finish the JS work this cycle the UI that does land will still be useful. I want the UI to be fairly simple - just a message and a spinner. I've attached a screenshot of what I'm thinking of. Suggestions and comments are welcome. This looks quite nice. I wonder if it might be a bit nicer to re-use a formatting device we already use elsewhere - the message box. I think that putting the text inside a message box, as well as the spinnre, right-aligned, might look more like other places in Launchpad where the user has to pay attention to some new and extraordinary piece of information. Another variation on this which I think is worth exploring is placing the spinner in the icon position (overlapping the top left corner) to create a new kind of message. ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] RFC: UI for +filebug while waiting-for-blob-to-be-processed
On 17 February 2010 11:05, Tom Berger tom.ber...@canonical.com wrote: On 16 February 2010 10:06, Graham Binns gra...@canonical.com wrote: Hi folks, I'm currently working on the Apport blob processing story [1], whose aim is to make sure that +filebug doesn't time out when apport uploads an enormous blob (the problem being that the blob is currently processed in-request, so the bigger ones cause timeouts fairly regularly). I've already written the code for processing the blobs server-side using the Jobs system, so all that's left is to make +filebug aware of that system. The idea is that +filebug will check to see whether the blob has been processed before allowing the user to proceed. If it hasn't, +filebug will wait a while and check again; if it has, +filebug will use the processed data as normal. The idea is that we'll do this using Javascript eventually, but in the first iteration of this we're going to do it with meta refresh tags, since that's reasonably quick to develop, meanting that if we don't have time to finish the JS work this cycle the UI that does land will still be useful. I want the UI to be fairly simple - just a message and a spinner. I've attached a screenshot of what I'm thinking of. Suggestions and comments are welcome. This looks quite nice. I wonder if it might be a bit nicer to re-use a formatting device we already use elsewhere - the message box. I think that putting the text inside a message box, as well as the spinnre, right-aligned, might look more like other places in Launchpad where the user has to pay attention to some new and extraordinary piece of information. I like this idea. It also ties in with the way the page currently handles having extra data to include in the filebug process. Another variation on this which I think is worth exploring is placing the spinner in the icon position (overlapping the top left corner) to create a new kind of message. -- Graham Binns | PGP Key: EC66FA7D ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] RFC: UI for +filebug while waiting-for-blob-to-be-processed
On Tue, Feb 16, 2010 at 11:06 AM, Graham Binns gra...@canonical.com wrote: Hi folks, I'm currently working on the Apport blob processing story [1], whose aim is to make sure that +filebug doesn't time out when apport uploads an enormous blob (the problem being that the blob is currently processed in-request, so the bigger ones cause timeouts fairly regularly). I've already written the code for processing the blobs server-side using the Jobs system, so all that's left is to make +filebug aware of that system. The idea is that +filebug will check to see whether the blob has been processed before allowing the user to proceed. If it hasn't, +filebug will wait a while and check again; if it has, +filebug will use the processed data as normal. The idea is that we'll do this using Javascript eventually, but in the Hi Graham, Do you mean that you'll do both the polling (easy) and the automatic updating of the bug page (time consuming) with JS eventually? And if so: first iteration of this we're going to do it with meta refresh tags, since that's reasonably quick to develop, meanting that if we don't have time to finish the JS work this cycle the UI that does land will still be useful. I'm wondering how much extra effort would be involved to do the polling via JS on the bug page itself (with a message similar to yours: Launchpad is processing the extra bug data you uploaded and then when the info is ready, simply change that message to Launchpad has finished processing the extra bug data you uploaded. [[Refresh]], where the refresh link would simply reload the bug page (as a first cut)? This would allow people to work with their bug while waiting (although that might not be so useful given the timeframe) and perhaps be closer to the final result that you want to end up with? I want the UI to be fairly simple - just a message and a spinner. I've attached a screenshot of what I'm thinking of. Suggestions and comments are welcome. [1] https://bugs.edge.launchpad.net/malone/+bugs?field.tag=story-blob-processing -- Graham Binns | PGP Key: EC66FA7D ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] RFC: UI for +filebug while waiting-for-blob-to-be-processed
On 16 February 2010 11:50, Abel Deuring abel.deur...@canonical.com wrote: On 16.02.2010 11:43, Michael Nelson wrote: On Tue, Feb 16, 2010 at 11:06 AM, Graham Binns gra...@canonical.com wrote: Hi folks, I'm currently working on the Apport blob processing story [1], whose aim is to make sure that +filebug doesn't time out when apport uploads an enormous blob (the problem being that the blob is currently processed in-request, so the bigger ones cause timeouts fairly regularly). I've already written the code for processing the blobs server-side using the Jobs system, so all that's left is to make +filebug aware of that system. The idea is that +filebug will check to see whether the blob has been processed before allowing the user to proceed. If it hasn't, +filebug will wait a while and check again; if it has, +filebug will use the processed data as normal. The idea is that we'll do this using Javascript eventually, but in the Hi Graham, Do you mean that you'll do both the polling (easy) and the automatic updating of the bug page (time consuming) with JS eventually? And if so: first iteration of this we're going to do it with meta refresh tags, since that's reasonably quick to develop, meanting that if we don't have time to finish the JS work this cycle the UI that does land will still be useful. I'm wondering how much extra effort would be involved to do the polling via JS on the bug page itself (with a message similar to yours: Launchpad is processing the extra bug data you uploaded and then when the info is ready, simply change that message to Launchpad has finished processing the extra bug data you uploaded. [[Refresh]], where the refresh link would simply reload the bug page (as a first cut)? This would allow people to work with their bug while waiting (although that might not be so useful given the timeframe) and perhaps be closer to the final result that you want to end up with? I'm writing this without checking how we currently tie the apport data to the bug, so I might be talking nonsense, but: Couldn't we simply let the user file the bug and let the apport job add the interesting data later? OK, this makes the apport job processing more complex. It must deal with the situation that the bug has not yet been filed so that the initial bug description can be generated by the apport job, as well as with the situation that data must be added to an existing bug. I like this idea, but we rejected it early on because there's some data in Apport blobs that can be used to populate the +filebug form. Of course, we could add it after the fact, for example updating the bug description to be apport description + user description and so on. I'm ambivalent about doing that though. That said, it wouldn't be hard to have the job class tied to the bug once it's been filed and then, once the job's complete, updating the bug with the data from the blob. I'll look into how the data from the blob is used again (I can't remember why we rejected this approach before; I'm assuming there's a good reason that I've forgotten). If it's possible to do it this way then maybe that's how we should proceeed. -- Graham Binns | PGP Key: EC66FA7D ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] RFC: UI for +filebug while waiting-for-blob-to-be-processed
On Tue, 16 Feb 2010 11:56:12 +, Graham Binns gra...@canonical.com wrote: I like this idea, but we rejected it early on because there's some data in Apport blobs that can be used to populate the +filebug form. Of course, we could add it after the fact, for example updating the bug description to be apport description + user description and so on. I'm ambivalent about doing that though. That said, it wouldn't be hard to have the job class tied to the bug once it's been filed and then, once the job's complete, updating the bug with the data from the blob. I'll look into how the data from the blob is used again (I can't remember why we rejected this approach before; I'm assuming there's a good reason that I've forgotten). If it's possible to do it this way then maybe that's how we should proceeed. A surprising number of people delete the apport info from the bug description, so appending that afterwards would reduce the incidence of that (at the cost of an extra bugmail I assume). However, the title of the bug is what worries me. We have a tough enough time with people deleting the apport-suggested title and putting in Crash!!! or similar, and that is all we would have if apport didn't suggest a title at all (I'm not sure how you would join the apport and user set titles). Also, usually people have no clue as to what caused the bug, so asking them to fill in blank boxes will stop some people filing. At least having them prepopulated allows people to write I don't know what happened, I was just asked to submit this without feeling like they aren't conveying any information whatsoever. Thanks, James ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] RFC: UI for +filebug while waiting-for-blob-to-be-processed
On 16 February 2010 12:30, James Westby jw+deb...@jameswestby.net wrote: On Tue, 16 Feb 2010 11:56:12 +, Graham Binns gra...@canonical.com wrote: I like this idea, but we rejected it early on because there's some data in Apport blobs that can be used to populate the +filebug form. Of course, we could add it after the fact, for example updating the bug description to be apport description + user description and so on. I'm ambivalent about doing that though. That said, it wouldn't be hard to have the job class tied to the bug once it's been filed and then, once the job's complete, updating the bug with the data from the blob. I'll look into how the data from the blob is used again (I can't remember why we rejected this approach before; I'm assuming there's a good reason that I've forgotten). If it's possible to do it this way then maybe that's how we should proceeed. A surprising number of people delete the apport info from the bug description, so appending that afterwards would reduce the incidence of that (at the cost of an extra bugmail I assume). However, the title of the bug is what worries me. We have a tough enough time with people deleting the apport-suggested title and putting in Crash!!! or similar, and that is all we would have if apport didn't suggest a title at all (I'm not sure how you would join the apport and user set titles). Also, usually people have no clue as to what caused the bug, so asking them to fill in blank boxes will stop some people filing. At least having them prepopulated allows people to write I don't know what happened, I was just asked to submit this without feeling like they aren't conveying any information whatsoever. Right. Having looked at the code, there are also practical considerations. For example, apport data can be used to decide whether or not the bug should be private (which is interesting because you can't actually make a bug private using the +filebug UI at the moment). So, I think it's safe to say that we need to have the apport data in the +filebug process and not after. -- Graham Binns | PGP Key: EC66FA7D ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
