Page MenuHomePhabricator

Change the location of Flow's timestamps within posts
Open, HighPublic


Timestamps are currently at the bottom of each post, which is closer to the post below (incl author name) than to the associated post. E.g.

IXfZUom.png (1×1 px, 203 KB)

Suggested solution, move the timestamps up to the same line as the author. E.g. (cut&paste mockup)

rIBWXeY.png (565×922 px, 84 KB)

This is more intuitive, as well as being closer to the model that existing editors are used to.

Event Timeline

Quiddity raised the priority of this task from to Needs Triage.
Quiddity updated the task description. (Show Details)
Quiddity added a subscriber: Quiddity.
Restricted Application added a subscriber: Aklapper. · View Herald Transcript
Catrope triaged this task as Medium priority.Aug 5 2015, 11:32 PM

I think this is a good idea; I'm happy to make this change if @Pginer-WMF agrees.

DannyH raised the priority of this task from Medium to High.
DannyH set Security to None.

Problem to solve
From what I see in the description, it seems that we are talking about an activity that involves moving across different usernames and timestamps. I assume (feel free to add more details on the specific usecase) that we are considering a scenario such as "trying to find the reply Cronopio gave last month, which I recall was nearby a comment from "Peter" around the same date". That requires the user to move across several topics using both the authorship and time information.

If we want to optimise for that kind of use, it makes total sense to present user names and timestamps in a way that is easier to scan.

The proposal

I'd start by considering placing both pieces of information next to each other. That will present them as a group that can be consumed together or individually (since the username will be much more prominent by the use of colour, it should be easy to focus on users when not interested in timestamps). I think that makes sense conceptually (both pieces of information are about authorship) and will result in a reduction of the scanning distance and the total number of groups of elements.

The later is one of the reasons I prefer the proposed approach to adding the dates to the right side as @Quiddity illustrated, but also to keep the access to the topic actions clean and avoid confusion by having a date next to the star for logged-in users.

user-timestamp.png (918×1 px, 128 KB)

Further considerations

  • The proposal is not very different from the previous state or the way information is organised in a timeline-intensive service such as Twitter.
  • Once you hover a username, additional information is expanded (talk and contribs link), when they are not displayed we need to make sure that they don't create a big gap between the username and the timestamp (it seems currently the html element for them is invisible but keeping the space). When hovering the username, the timestamp will move to leave space to the new info which may result in a small inconvenience we need to pay attention to.

Yeah, I think moving the timestamp closer to the username makes sense.

I'm not sure about how that would work with the hover state -- both the name and the timestamp have different hover effects. Hovering on the name adds more links to the right (displacing the timestamp), and hovering on the timestamp replaces the timeago with the exact date and time. That feels potentially like too much hover-change in the same place.

Re: timestamp placement - The main reason for placing it on the opposite side, are so that All the timestamps (in a topic, or a page) can easily be skimmed, at once. Whereas if it were next to the usernames, then the different length of usernames (1-85 characters) mean that the timestamps position could vary wildly in horizontal location.
However, either solution would be acceptable.

Re: timestamp hover change (elapsed vs exact), there's the issues and research (and a suggested solution) at T94648#1178640 and further issues in the See Also there (T93437: Flow: There is no way to see the precise timestamp on mobile web and T94353: It is impossible to copy the timestamps of Flow comments) - (that should be discussed there. I just wanted to remind us of those aspects.)

@Pginer-WMF, just a ping about my question above, and Nick's comments. What do you think about the timestamp placement?

Regarding the layout, it is dependent on how frequent people look for dates only versus username + timestamp, but considering the pros and cons I'd recommend placing the timestamp next to the username.

Placing dates next to usernames adds some turbulence to the scanning line when you are looking only for dates, but considering that dates are using a different colour from usernames it should not be hard to focus on them as you scroll. Overall I think it provides more advantages in terms of layout to aligning dates to the right (where you have to move from edge to edge of the board in the "username + date" scenario).

Regarding the hover behaviour, I think the only potential issue is with the username hover pushing the timestamp to the right. In particular the following situation may be problematic: A user trying to reach the timestamp from the left side hovers the username area which results in the timestamp to move further to the right. As the user keeps moving the mouse to the right to reach the timestamp, the cursor leaves the username area and the timestamp moves left again. That will cause the timestamp to be running away from you as you try to reach it, which is frustrating.

We should at least make sure to avoid the second part of the previous example: if a user hovers the username, and "contribs + talk" links are shown, we should hide them only when the user leaves the whole authorship area (username and timestamp).

I created a prototype and recorded an animation to illustrate how to deal with that situation:

datetime-animation.gif (300×480 px, 190 KB)

(as a glitch of the prototype, the username remains underlined even when the cursor is not over it, which is not desirable)

In the long term, the way to access "contribs + talk" info can definitely be improved and avoid pushing other content, but I don't think it should be a blocker for this.