Page MenuHomePhabricator

Echo icons change size slightly during load
Closed, ResolvedPublic

Description

After a second or so, they visibly increase by about 1px in size.

Event Timeline

Esanders updated the task description. (Show Details)
Esanders raised the priority of this task from to Needs Triage.
Esanders added a project: Notifications.
Esanders added a subscriber: Esanders.
Restricted Application added a subscriber: Aklapper. · View Herald Transcript
Legoktm reopened this task as Open.Sep 11 2015, 7:45 AM
Legoktm added a subscriber: Legoktm.

Going to make this a blocker instead.

The problem is the nojs version uses different html (one <a> tag as an iconElement, instead of a butonElement with a separate label and icon) so rounding errors creep in when adding heights and padding.

Quiddity set Security to None.
Quiddity triaged this task as High priority.
Quiddity added a subscriber: Quiddity.

Change 237540 had a related patch set uploaded (by Mooeypoo):
Dim the nojs buttons for js-version of Echo

https://gerrit.wikimedia.org/r/237540

The problem is the nojs version uses different html (one <a> tag as an iconElement, instead of a butonElement with a separate label and icon) so rounding errors creep in when adding heights and padding.

Yes. We can't use php ooui element because personal toolbar *only* accepts <a> tags with a specific structure. We did our very best to make it as close as possible to the js version. but there are differences in how the browser displays each of them.

The only thing we could really do is make it look as close as possible in size. We did come up with a patch to at least mitigate the effect by making the initial nojs buttons semi transparent while the js version loads. This will also be a good indication to the user that clicking on the buttons in that stage will be different. It won't open the popup but rather bring them to Special:Notifications.

From #wikimedia-dev yesterday:

[17:15:58] <legoktm>	 MatmaRex: do you see any way around https://phabricator.wikimedia.org/T112218#1630159 besides allowing the PersonalUrls hook to take OOUIPHP widgets?
[17:16:58] <MatmaRex>	 legoktm: you could not recreate the HTML generated by PHP, i guess?
[17:17:11] <MatmaRex>	 legoktm: or make the badge use the same HTML structure and classes as the PHP one
[17:17:51] <MatmaRex>	 (you can change everything about widget.$element after it is generated, it's all just HTML)

I was actually thinking on similar lines. We can recreate only the button part of the widget and make its main element <a> and then leave the rest of the popup as is.

It's not ideal, but it's a good solution to get things to look the same.

There is a secondary problem, however. The button will still behave differently between the no-js and js versions. In the JS versions clicking on the button pops up the notification list. In the no-js version, cliciking the button takes you to Special:Notifications.

Do we want to make this difference clear? If so, do we not still want to leave the semi-transparency of the nojs while the js version is loading?

Quiddity added a comment.EditedSep 13 2015, 4:14 AM

There is a secondary problem, however. The button will still behave differently between the no-js and js versions. In the JS versions clicking on the button pops up the notification list. In the no-js version, cliciking the button takes you to special:Notifications.

Do we want to make this difference clear? If so, do we not still want to leave the semi-transparency of the nojs while the js version is loading?

This is the way it always worked. If we clicked on the badge too fast,
before the page fully loaded, it would take us to special:notifications.

Do we want to make this difference clear? If so, do we not still want to leave the semi-transparency of the nojs while the js version is loading?

I don't think it's necessary. I think people already have the expectation that if you click on things before the entire page loads, all functionality might not be ready yet. I'm not sure if people will find the semi-transparency -> full change distracting?

There is a secondary problem, however. The button will still behave

differently between the no-js and js versions. In the JS versions clicking
on the button pops up the notification list. In the no-js version,
cliciking the button takes you to Special:Notifications.

Do we want to make this difference clear? If so, do we not still want to

leave the semi-transparency of the nojs while the js version is loading?

This is the way it always worked. If we clicked on the badge too fast,
before the page fully loaded, it would take us to special:notifications.

Yes, it's the way it worked before, without the visual indication and without the 1px difference between the buttons. Should we leave the semi-transparency, would that be enough (Because then the change from nojs to js is half-transparent to fully-opaque) or do we *also* need to make them look exactly the same?

Do we want to make this difference clear? If so, do we not still want to leave the semi-transparency of the nojs while the js version is loading?

I don't think it's necessary. I think people already have the expectation that if you click on things before the entire page loads, all functionality might not be ready yet. I'm not sure if people will find the semi-transparency -> full change distracting?

Yea, I don't know. We do have a separate type of expectation here. The page has loaded (or seems to) but the JS layer is still loading -- that's usually not something we fully see. You can start interacting with the page while the JS is loading without noticing that there's still another layer coming.

We do this in Flow, too. The no-js version looks like it's fully loaded, but in fact you have a JS layer that lets you interact with things differently (and more convenietly.) So while the JS is loading, we're "dimming" the page a bit, to let the user know there's more -- better -- coming.

So, to be honest, I'm not sure which is better for Echo. I personally think it's not a bad idea to give a visual indication that something's not yet loaded fully, but I can also see how this can be distracting to users.

I'd err on the side of non-distraction.

Change 238017 had a related patch set uploaded (by Mooeypoo):
[wip] Get the button out of the <div> widget

https://gerrit.wikimedia.org/r/238017

Change 237540 abandoned by Mooeypoo:
Dim the nojs buttons for js-version of Echo

Reason:
Implemented in an alternative patch that also uses lazy loading.

https://gerrit.wikimedia.org/r/237540

Change 238017 merged by jenkins-bot:
Replace entire <li> element to produce button and popup separately

https://gerrit.wikimedia.org/r/238017

Checked in betalbs for Chrome 44, FF 40, and Safari 8.0.7.

DannyH closed this task as Resolved.Sep 22 2015, 6:31 PM
DannyH added a subscriber: DannyH.