| • flimport | |
| Jun 12 2014, 6:16 AM |
| F5722303: T234-searchbar.png | |
| Feb 20 2017, 12:56 PM |
| F5722309: T234-magnifier-tags-field.png | |
| Feb 20 2017, 12:56 PM |
| F4723583: typeahead-browse-button.png | |
| Nov 14 2016, 7:42 AM |
Related task upstream: https://secure.phabricator.com/T11034
When filing a new task I entered "Ph" and the autocompletion suggested several projects. I had no clue of the difference, I chose a random one.
See Also:
T97751: Search projects by description
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | Qgil | T553 Engineering Community team goals for October 2014 | |||
| Resolved | Qgil | T174 Launch Wikimedia Phabricator Day 1 | |||
| Resolved | Qgil | T175 Nominate a team in charge of deploying and maintaining Wikimedia Phabricator code | |||
| Resolved | • RobLa-WMF | T17 Allocate resources for the migration and maintenance | |||
| Resolved | Qgil | T19 Define which features existing in our current tools are really missing in Phabricator | |||
| Resolved | Qgil | T15 Migrate Bugzilla to Phabricator | |||
| Resolved | Aklapper | T22 Identify features Bugzilla users would miss in Phabricator | |||
| Declined | None | T141457 blog.wikimedia.org post on Phabricator improvements | |||
| Resolved | • mmodell | T137727 Write blog post highlighting recent Phabricator improvements | |||
| Resolved | Aklapper | T136213 Complete the round of Phabricator improvements funded by Wikimedia | |||
| Resolved | Aklapper | T234 Projects dropdown should offer project descriptions |
Let's see whether this is a problem after Day 1, when we have real names of real projects. If the differences between names are unclear, the first thing we need to think about fixing are those confusing names.
I don't think that this is a significant problem now that we have real projects. If several names of projects are unclear, the first questions to ask is whether these names can be improved.
I propose to decline this task, as I don't think the current behavior is problematic in practice.
I think it would be useful. Take this task for example: What is the difference between the Phabricator and the Phabricator (Upstream) projects?
Click on those projects, click the first icon in the pane on the left, see the descriptions.
So far it works pretty okay'ish, and if it does not someone corrects the projects associated to tasks. Though Bugzilla did offer descriptions on enter_bug.cgi I don't see a way higher "failure" rate to find the right project in Phabricator so far (personal impression not based on any numbers).
I can't click on those projects in the projects dropdown. Or rather: I can, the projects get selected, and then I can click on the project and nothing happens. And if I don't click on it, no tool tip appears.
Of course it depends on the metric you apply: If it is "a wrong project has been associated", then the numbers may be low indeed.
That's true, you cannot click on them when you are on the "Create Tasks" page (or any such dropdown fields).
Still I state that missing display of project descriptions "inline" so far hasn't given me the impression that it creates an issue bigger than in Bugzilla when it comes to setting the right projects on tasks.
Why is this declined? It seems like a low-priority issue, not something we're against implementing.
@Mattflaschen: I'm against implementing this as a downstream diff, at least. :)
If this ever happens then it will be in upstream: https://secure.phabricator.com/T5403
But if we want to really mirror every upstream ticket here in the Phabricator (Upstream) project we can leave this open with lowest priority, indeed. I'm definitely not against it if it is implemented in upstream.
Dropping other potentially related upstream items apart from https://secure.phabricator.com/T5403#101768 :
https://secure.phabricator.com/T6501#82983 states that "Description is a CustomField and covered by https://secure.phabricator.com/T5873#148084 " which states "this is blocked on https://secure.phabricator.com/T7715 providing new ApplicationSearch-driven endpoints".
https://secure.phabricator.com/T6579 also talks about "tooltips to tasks, showing an excerpted project description".
I'm not sure why this is still open. The upstream task is still open because it has a wider scope than this one, however, the feature described in this task is implemented and deployed.
@mmodell: Are you sure? The general Search field in the upper right corner offers project descriptions, but not a "Projects dropdown" when entering a project name in the "Tags" field in the "Create Task" form or using "Change Project Tags" here.
So I'd reopen this task...
Just found it: If you click on the search icon in (any?) project field, the search results show the project descriptions. IMHO that's not very intuitive (and not the auto-completion case this task was about), but now at least you have some way to achieve the goal.
The project description is shown in the 'browse' interface which you access by clicking the magnifying glass icon. I've highlighted it in the following screenshot:
epriestley has requested feedback related to this feature on the upstream task: https://secure.phabricator.com/T11034#177259 so if anyone has opinions, now's the time that they might be helpful.
Project descriptions are displayed after clicking the magnifier icon in any "Tags" input field:
They are not displayed in the global search bar in the upper right corner, but I don't consider that very helpful anyway (as those project pages would also display the project description, or it is one click away if the workboard is linked per default instead):
Feedback was requested in https://secure.phabricator.com/T11034#201013 (and also asked for in this very task in T234#2845156):
If there's some remaining use case here, I'd also like to step back and understand it better since I suspect the best solution we can pursue is not any kind of UI change which makes it easier to find things by randomly typing guesses into the typeahead.
For example, if there's some set of common tags that a lot of tasks should be getting tagged with when they're created, but they aren't being tagged because newer users don't know they exist, maybe the help text above the form could include (or link to) a table describing those tags?
As no feedback was provided I assume that the latest improvements and the correct implementation is sufficient?
Two calls in this task for feedback and no replies, hence I proposed to close the related upstream task and am also closing this long-standing downstream task.
The current implementation looks like a good balance between not throwing a wall of text onto a user, but still allowing to access project descriptions via a single click on the magnifier icon in a "Project tags" field.
It is up to us to inform users about clicking the magnifier icon which has been covered in our documentation for a while now.