launchpad-dev team mailing list archive

[Tom Berger <tom.berger@xxxxxxxxxxxxx>]

2010/1/13 Martin Albisetti <martin.albisetti@xxxxxxxxxxxxx>:
> On 01/13/2010 02:32 PM, Tom Berger wrote:
>>
>> Looking at a bugwatch on the bug page, it is impossible to tell whether
>> the
>> information provided by the bugwatch is up-to-date.
>
> Taking a step back to an ideal world, the system would work well enough that
> the default assumption is that everything is up-to-date, and when something
> isn't, it gets fixed in the background.
> To push us in that direction, I'd try to make out-of-date bugwatches as
> flashy as possible, with a clear path-to-action that contacts us the people
> who can do something to fix is (us?  a question?  a bug?).

Yes, I really like the idea of providing a link for filing a question.

>> The proposed solution is to indicate that synchronisation status of a
>> bugwatch
>> using its icon. We will use three version of the icon, one for unknown or
>> new
>> bugwatches, one for bugwatches successfully synchronised and one for
>> bugwatches
>> with recent failures.
>
> I wonder if newly-added/unknown bugwatches shouldn't be hidden/grayed out
> until we sync?

Yes, that's what I meant by a third icon, for unkown.

>> The bugwatch itself should link to the new bugwatch page (description
>> below),
>> but we should consider the usability implications of not linking directly
>> to
>> the remote bug. The challenge may be to provide links to both the
>> Launchpad
>> page and the remote bug.
>
> As discussed on IRC, I think we should preserve the link to the bugtracker.
> There's a lot of value in letting people jump to the upstream bugwatch
> quickly, but very little in sending them to another page (unless the
> bugwatch failed, which is the exception).
> The edit icon is probably the best way to link to there, although it breaks
> the pattern a little bit.

As we discussed, I think that providing both links is the way to go. I
have a reservation about using the edit icon, since it's used to
indicate something different in other cells in this table. But let's
start with this and see if we can improve on it.

>> === Dedicated bugwatch page on LP ===
>>
>> Currently, we don't have any page representing a remote bug watch. Bug
>> watches
>> appear in bug pages and bugtracker pages, but there isn't a single place
>> where
>> a user can go to look for all the information available about a specific
>> bug
>> watch and its synchronisation status.
>>
>> The bugwatch page will present:
>>
>> * All the remote bug information available in Launchpad.
>> * Link to the remote bug.
>> * Link to the Launchpad bugtracker page.
>> * Information about the bugs this bugwatch is related to.
>>  * Bug number, title, targets (anything else?)
>
>> * Basic information about the bugtracker sync status.
>
> So the status is about the bugtracker, not this specific bugwatch?  If so,
> I'd try to make that a bit clearer.

Sorry, that's a typo. I meant bugwatch.

>
>> * A control for initiating sync.
>
> I would word this "Retry sync now", I think retry is the key word here.
> Also, I'd put it next to the unsuccessful message rather than the last sync
> time, as that's where you will want to retry. I'm guessing you put it there
> because it will be on the page even if it doesn't fail?  For manual syncs
> for the impatient?  If yes, I'd re-word it to "Update now", and maybe offer
> the retry link in the message as well, even though it will end up doing the
> same thing. It's not a great solution, I'm open to brighter ones  :)

Yes, I think retry/update is a good way to word this.

>> === Changes to the bugtracker page ===
>> To indicate the sync status, each line in the table of bugs/bugwatches
>> should
>> indicate the sync status of each individual bug watch. We will do this by
>> adding a column displaying the last sync time and whether an error
>> occured.
>
> I'd order by least-updated first, show totals to get the idea of the amount
> of syncing that is going on, and maybe by default just show bugs that have
> never been synced, or haven't in a $longtime. Offering a link to the full
> list would be good, but the total and the problematic ones may be enough.

I guess you mean last-updated? I think that's a good idea.

>> For the bugtracker as a whole, we need to display information about sync
>> runs,
>> and a way to trigger a new sync.
>
> I'd re-use the same pattern for forcing a sync as the other page.
> Can we show a log?  Maybe next to the last sync, we could show a log so
> people can figure out what the problem is for themselves.

The problem with logs is that we don't run updates for inidividual
bugtrackers necessarily, so we'll have to try and figure out how to
pull out of the log the bits pertaining to the bugtracker. Gavin, any
ideas on how we might be able to do that?

> As for the projects that use this bugtracker, I would be super cool if:
> - You could add a project to it from there instead of going to the project
> - Show the total number of bugswatches each of those have
>
> Finally, a call-to-action for failures to contact us would probably go a
> long way to raise awareness.

Yes, that's the main thing we want to achieve with these changes. I
think that a clear explanaion and a link for filing a question will be
a really good way to do that.

Tom