Can't get to milestone from bug

Especially annoying since the milestone link looks like a normal link.The picker should be confined to the edit icon once a milestone has been chosen.

I'm not sure if limiting the link to the edit icon only is good enough, because I'm concerned that it would make interacting with the widget too difficult. But I agree that it would be good to have a way to navigate to the milestone.

I think limiting the JS to the edit icon would be fine, but I'll point out another idea. You could add a list of active milestones to the portlet.

Could the milestone picker overlay have "(view)" links embedded in it next to each choice? Or would that be too noisy/messy/difficult?

2009/8/19 Gavin Panella <email address hidden>:
> Could the milestone picker overlay have "(view)" links embedded in it
> next to each choice? Or would that be too noisy/messy/difficult?

I think it would be better to reinstate the link in the table itself.
If it's in the overlay users will have to edit the milestone to get to
the link, which doesn't really make sense and won't be available to
most users.

I expect that changing the data is something people want to do more often, or more quickly, or probably both, than navigating to other bug reports that share the same values. So I think it would be inappropriate to revert to a Launchpad-2.0-style design where changing the data has a much smaller target area than navigating to other bug reports does.

Shortly before I stopped working on Launchpad, I did paper-prototyping of an iTunes-like design for the table: clicking the data (importance, assignee, milestone, etc) would let you change the data, but there was a little (➩) link at the right end of each table cell that would let you navigate to other bug reports that share that value. For example, the (➩) button in an assignee cell would take you to other bugs assigned to that person, and the (➩) button in a milestone cell would let you see other bug reports targeted to that milestone.

Unfortunately, out of the six people I tried it with, not one person understood the purpose of the buttons. They all thought that you would need to click a button to change the data. Maybe this was partly because they had gotten used to the weird 2.0 design with its similar ⊽ button for changing the data. In that case, the presence of the edit icon alongside the navigation icon would make this clearer than it was in the design I tested.

Fixed in devel r9226.