Page MenuHomePhabricator

Embedding a mock or a file in a task should add a link in the header
Open, Needs TriagePublic


In tasks with many comments, it becomes more difficult to find uploaded assets within tasks. The top structured area of a task could aggregate all uploaded media and mockups.

The proposal, in more detail:

  • It should be possible to add Files to the header of a task, just like Mockups today.
  • Mockups and Files embedded in the task description or a comment (using curly brackets {M...} {F...} would be added to the task header. This behavior is consistent with the possibility of adding projects and users by mentioning them in a specific way.
  • Mentions of Mockups or Files in descriptions or comments (plain M... F... references) would not be added automatically.

Original report:

Event Timeline

qgil raised the priority of this task from to Needs Triage.
qgil updated the task description. (Show Details)
qgil added projects: Maniphest, Pholio, Files.
qgil added a subscriber: qgil.

I feel this is the same as the mention of Projects, without some level of explicit inclusion, the behaviour is confusing and causes additional work to correct when it occurs. Our expectation for attaching such items now is by using the action link on the task or by editing the description.

Some previous discussion on Files specifically in T3742#39414.

In the Files case, we had this in the past (@chad's link has more discussion) and it wasn't very useful. The number of tasks with meaningful/important assets seems very small, at least on this install and based on feedback from other users.

Our current recommendation is to edit the task description if you want to call out specific important files or other objects which aren't directly associable to tasks. You can format them nicely and contextualize them (e.g., "here's the latest slide deck" or whatever), which is impossible with an automatic list.

One thing we could possibly do is maybe put "mentioned objects" on a tab or a link somewhere. It's technically easy, but I'm really not sure about the value of this.

I also don't want to attach semantics to {Txxx} vs Txxx; I think this is confusing, and it should be possible to do long-form embeds or embeds-with-options without triggering additional logic.

I feel like there was a second discussion when we actually removed this, but can't locate it offhand.

Your reasoning makes sense. I think the actual problem behind this request is that adding a file to a comment is a lot easier than embedding a new mockup to the header or description of a task, counting the steps each path takes and the extra fields that a new mock offers.

What if "Edit Pholio Mocks" would include an option to create a new mock just requiring a file upload (rest of fields being optional) and resulting in a new mock linked in the header and rendered in the description? (this is a deviation from the original request and I can file a task for it; in fact there is a similar request in Wikimedia).

Adding a file either requires you click "edit" and drag in a file or scroll to the bottom and comment and drag in a file. I think both are equally easy, just different.

It might be worth discussing though adding some sort of 'attach x' to the remarkup box in general. Right now these actions are separated, but I don't know they need to be.

I should mention long-term I want to make the Pholio comment controls work on any image in lightbox, not just Pholio mocks.

Are there some example tasks on the WMF install where assets are few/simple enough that making a mock is overkill, but numerous enough that finding the latest versions is time consuming/complex? If an asset (like an icon) is straightforward and doesn't need discussion, how often are there a ton of versions of it?

In T6831#89086, @chad wrote:

Adding a file either requires you click "edit" and drag in a file or scroll to the bottom and comment and drag in a file. I think both are equally easy, just different.

Adding a mockup to a task implies

  1. Leave task to Create Mock
    1. Add a required name
    2. There are a bunch of fields for title, projects, CC, etc that are optional.
    3. Upload a file
      1. Which comes with an additional title and description which are optional.
  2. Go back to the task
  3. Edit the description and/or "Edit Pholio Mock" to add a link in the header.
  4. Add a comment about the mock just uploaded (which could also go in the Mock page, and this is another point of confusion).

It is really no surprise that many new users will consider just slapping a file to a comment several times before going through the mockup process.

Our designers are comparing the Phabricator process with Bugzilla, where there is an area for "Attachments", and whenever a new attachment is added it gets a link from that area and in the comment history. In exchange, Bugzilla has no rendering of images at all and no editable descriptions ("Comment 0").

I guess as a designer myself I don't understand the optimization here (quick create Pholio). I fundamentally work one of two ways. Serious 'pre-product' or explorative designs (which take 10, 20, 40 hours), which I expect revisions and long discussions on. This product is Pholio. The second is lightweight corrections or attachments to tasks. The 'hey go make this' or 'i just threw this together'. In those cases I drag and drop into comments/descriptions on a task or diff.

If you want to iterate on an image inside a task without Pholio, that's awesome and fine. Designers or whoever can then once 'final' is hit, can update the description and do whatever is next in their 'build feature x' pipeline.

Being able to more quickly attach as Pholio Mock I don't think solves any current problem. It makes the initial attachment easier but still requires more work to update the image. I think users would still skip the initial attachment and drag and drop files inside the task.

I have worked in more design heavy environments (Apple) and managing many real assets (photos, fonts, vector images) that all might go into a single banner or poster could be significantly better than they are today (I think I was the only one trumpeting keeping the "Files" area on a task). I do see some value in the OP report that managing many design assets in a task is currently difficult. @epriestley's mentioned objects might alleviate some of this.