| debt | |
| Feb 11 2016, 10:05 PM |
| F3365138: Screen Shot 2016-02-16 at 5.45.09 PM.png | |
| Feb 17 2016, 12:48 AM |
In order to properly show the search results dropdown on the wikipedia.org portal page, we need to know the dimensions of the visitor's browser the first time they come to the portal page (not if they resize it later).
This ticket is to add that information into what we're collecting.
| Subject | Repo | Branch | Lines +/- | |
|---|---|---|---|---|
| Add systemd unit for logstash | operations/puppet | production | +35 -0 |
Seems that we can add this information to our landing event.
@Ironholds would you approve adding a new field to the schema?
Should we get viewport height only, or have a viewport field that we can extend with more viewport information.
Why would we add it to the schema? If it's for the purpose of the actual user display we don't want to be gathering it on a sampled basis (which the schema is), we want to be gathering it for everyone.
What is the feedback from other frontend engineers (eg Timo) on this? It can't be the first time Wikimedia has run into this problem.
From what I can think of, I guess @debt wanted to collect that information.... to have a better idea of our visitors (and the average screen sizes that we see the most?) ?
Unless the ticket is meant to track writing a getViewportDimensions method in the code, that we can reuse to display an optimized typeahead.
Yup, we want to see what the user's browsers dimensions are - so that we can determine what to do with the search results being displayed below the user's browser window: https://phabricator.wikimedia.org/T126391
If we can use meta name="viewport" to show the user a better experience, I'm all for it!
@debt, forgive me for being confused, but do you want to determine the browser's dimensions (A1) in order to immediately optimize the typeahead position (A2)?
OR
do you want to first collect (B1 = A1) this information and store it via Event Logging (B2), find out what are the most frequent browser's dimensions (B3), in order to make a product decision (B4), that we implement to optimize the typeahead position (B5 = A2) ?
?
I want to avoid having this happen (see attached image), where the search results go outside the height of the browser.
I am understanding from your answer that you don't want to collect such data through event logging.
You just want to determine the screen size, then optimize the typeahead position.
In this case, I think this ticket is too granular.
It feels like creating a ticket for each individual method the code should implement.
I'd suggest we close it.
I'll close this ticket but keep open this one: https://phabricator.wikimedia.org/T126391 to adjust and optimize as necessary the type ahead results list.
Change 274696 had a related patch set uploaded (by Muehlenhoff):
Add systemd unit for logstash