Page MenuHomePhabricator

Distracting (animated gif!) compass when typing Maniphest tasks and comments
Closed, ResolvedPublic

Description

When users type Maniphests tasks or comments, a compass might show up, telling the user that the last words aren't saved yet. The intention is good, but the result annoys some users more than others.

It is less annoying when you have big monitor, a fast connection, and perhaps a powerful CPU, but it gets more in the way with smaller screens and slower connections, when the compass takes more % of screen during more time.

The animation could be smaller and less noticeable. At the end it is just a cue of a process that should not bother the busy and concentrated user.

I see you already redesigned this once - T3295 D6095 . Keeping the idea of the compass... does it need to be rendered that big? Does it need to move that much? Since it is supposed to show up just a tenth of second or less, could a static image just work, since it is already animated by appearing and disappearing, and appearing again?

Original report, fwiw: http://fab.wmflabs.org/T114

Related Objects

StatusAssignedTask
ResolvedNone

Event Timeline

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

By the way, when a user reported this problem the first time I had to look again because I almost hadn't noticed the compass from my office connection and the big monitor connected to my laptop. Then I tested from my laptop and a 3G connection while commuting in Caltrain... Try this, and you will see. ;)

I think we should special case these calls so they don't trigger the loading UI, but that should wait for T430.

Yeah, this interaction isn't the highlight of Phabricator, but it's still important for the time being. We'll keep it in mind as other pieces shake out.

You are full of amazing today. All I am doing is cleaning up baby projectiles.

Here's the hipster-style bar:

Screen_Shot_2014-05-04_at_5.50.57_PM.png (156×1 px, 44 KB)

I think Youtube had this for like 3 days and it's already no longer cool, but it seems like a plausible compromise of concerns here.

Is this bar tied to the top of the header? Note that most users in most cases will type their comments without the header at sight.

I'm fine with the compass if it shows less often / in correct situations. Is that the question here? Hipster bar is OK but not really noticable enough for me.

Requests now have a "type", for purposes of showing loading indicators. Here's how they work:

TypeIndicatorPriorityNotes
workflowcompass2000User clicked a link, button, or form which we process with AJAX. We reserve a request slot for these requests. They have the highest priority.
draft(none)750Saves drafts and generates previews. The preview provides an implicit indicator, but we no longer render an explicit one.
contentbar500Loads content into the document. Currently just changesets in Differential and Diffusion.
notification(none)250Loads information about notifications. These have the lowest priority.
(null)(none)N/ASome requests haven't been updated to use this stuff yet. We'll update them over time, and categorize them appropriately.

The bar is only shown for content requests (which usually involve a large queue of requests, and thus make some sense to show a loading bar for). Currently, this just means loading files in Differential and Diffusion. When visible, the bar is fixed to the top of the window, not the top of the document, so it will always be visible.

There's no longer an explicit loading indicator for drafts. The preview itself provides an implicit one, and I don't think this was especially useful to begin with. We may further refine this in the future; the preview mechanic needs some refinement on mobile anyway (see T1895 for some related discussion).

Ah thanks I understand more now. Let's just try it and tweak if it doesn't feel right

Yeah -- the specific indicators may very well merit adjustment, and I'm particularly unsure if the hipster-bar will work well or not in practice. This change is primarily "put the code in place so we can treat different types of requests differently, both when executing them and drawing indicators for them". With that code in place, it also makes a best effort to improve the UI indicator states.

This is live on this install now, but feel free to reopen this or file something else if the newer indicators feel like we aren't quite there yet.

I don't notice the bar/hip version at all. We'd have to go yellow or indigo! to make it noticeable. Maybe that's not wanted.