IRC office hours/Office hours 2014-04-16

Office hours log for the Media Viewer discussion hosted by Fabrice Florin and the Multimedia Team on April 14 , 2014 at 18:00 UTC

[11:00am] fabriceflorin: Hi folks, welcome to our IRC Chat about Media Viewer.
[11:01am] fabriceflorin: We’re getting ready to relase Media Viewer more widely and would appreciate your guidance to make sure we address any critical isues before we do. Learn more about this project here:
[11:01am] fabriceflorin: https://www.mediawiki.org/wiki/Multimedia/About_Media_Viewer
[11:02am] Topic changed to "Media Viewer | https://www.mediawiki.org/wiki/Multimedia/About_Media_Viewer | Channel is logged and publicly posted (DO NOT REMOVE THIS NOTE) | https://meta.wikimedia.org/wiki/IRC_office_hours" by marktraceur.
[11:02am] fabriceflorin: Thanks, marktraceur !
[11:02am] fabriceflorin: Who is interested in discussing Media Viewer with us today?
[11:03am] dschwen: ... me ...
[11:03am] fabriceflorin: dschwen: So glad you’re here. What are some topics you want to make sure we discuss today?
[11:03am] bawolff: nah, lets talk about fonts
[11:03am] • bawolff jokes
[11:03am] dschwen: haha
[11:03am] marktraceur: bawolff: #agreed
[11:04am] fabriceflorin: bawolff: hehe. Multimedia fonts?
[11:04am] kaity is now known as kaity|away.
[11:04am] dschwen: yeah, I get headaches and NOSEBLLEDS and convulsions
[11:04am] bawolff: fabriceflorin: Well actually I was just looking at 2 bugs related to fonts in svgs
[11:04am] fabriceflorin: For anyone who is lurking, Hi, I’m Fabrice, multimedia product manager at Wikimedia Foundation, and I will be co-hosting this discussion with our team members …
[11:04am] marktraceur: Most of the troublesome folks are gone, we can knock out a resolution to use Comic Serif in about five minutes here
[11:05am] bawolff: lol
[11:05am] dschwen:
[11:05am] fabriceflorin: Our team includes the fearless marktraceur, as well as tgr — and Keegan is our community liaison.
[11:05am] dschwen: So the placement of the button on the commons file pages seems to be a bit controversial
[11:06am] dschwen: tgr laid out the reason for putting the button there
[11:06am] dschwen: which I can follow
[11:06am] Keegan: the "expand view" button
[11:06am] Keegan: For clarity
[11:06am] dschwen: yep
[11:06am] TrevorP|Away is now known as TrevorParscal.
[11:06am] fabriceflorin: dschwen: Glad you brought this up. We agree with you that the current placement of that button may not be ideal — and we would like to find a good solution with you.
[11:06am] dschwen: but it seems to me like a band aid to fix some UI inconsistencies
[11:07am] dschwen: well...
[11:07am] dschwen: here is my view:
[11:07am] dschwen: Filepage: (medium size preview)
[11:07am] fabriceflorin: Yeah, we’re interested in finding a better solution, if we can. The rationale for showing the ‘View expanded’ button to all users right away is because all our shared/embed links now go to the Commons file page, where they will open the image in Media Viewer when users click those links. See this Mingle ticket #199 for more background on this feature:
[11:07am] fabriceflorin: https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/199
[11:07am] dschwen: click on medium size preview gives you the full image
[11:08am] dschwen: the tiny "expand view" button gives you the media viewer
[11:08am] tgr: dschwen: the current file description pages consist entirely of UI inconsistencies
[11:08am] fabriceflorin: We think this feature is needed for two reasons:
[11:08am] fabriceflorin: 1. if a user wants to see an image in Media Viewer from a Commons file page, they need a way to open it with Media Viewer;
[11:08am] tgr: so yeah, this is a bandaid
[11:08am] fabriceflorin: 2. if a user views an image in Media Viewer over a Commons file page, then closes it, they need an easy way to re-open Media Viewer (all our shared/embed links go to the Commons file page, where they open the image in Media Viewer, so this could happen to a lot of users)
[11:08am] marktraceur: Meticulously arranged UI inconsistencies
[11:08am] Steinsplitter: hi@all
[11:08am] dschwen: I think it would be more logical to have the media viewer pop up when clicking the preview (like it pops up when clicking thumbnails)
[11:09am] fabriceflorin: dschwen: Do these two goals stated above seem worthwhile to you? Or would you argue they are not important?
[11:09am] dschwen: however there would have to be a clear path to "downloading" the full image
[11:09am] tgr: add to that cross-wiki inconsistencies, since mediaviewer is opt-in on Commons but opt-out on some wikis which use Commons
[11:09am] marktraceur: a wiki*, only mw.org now.
[11:09am] Steinsplitter: i agree with dschwen
[11:09am] fabriceflorin: Steinsplitter: Thanks so much for joining our discussion. We would like to find a solution to the Commons button issue, to make sure that we address all key concerns.
[11:10am] dschwen: fabriceflorin, I agree with the two statements
[11:10am] tgr: marktraceur: right, opt-out on some wikis starting tomorrow
[11:10am] gi11es left the chat room. (Changing host)
[11:10am] gi11es joined the chat room.
[11:10am] pavanaja left the chat room. (Quit: Page closed)
[11:10am] fabriceflorin: dschwen: Good. So the question then becomes how do we support those goals more effectively than we do now?
[11:10am] bawolff: I'm not sure. When I click the preview, its often to download the original file
[11:10am] dschwen: Workflow on typical image sites like Flickr deems to be to allow "viewing" the images at various sizes, and
[11:10am] danmichaelo left the chat room. (Quit: Computer sleeping)
[11:10am] dschwen: have an option to "download" the file
[11:11am] bawolff: but that's probably more indoctrination into a UI that's kind of sucky to begin with
[11:11am] dschwen: correct me if I'm wrong
[11:11am] tgr: dschwen: adding a button is a minimal change which does not impact existing workflows
[11:11am] dschwen: true, tgr
[11:11am] fabriceflorin: dschwen: What do you think of the new Download option we added to Media Viewer, in the ‘Use this File’ tool? Does it work for you in that context?
[11:11am] tgr: opening mediaviewer when you click on the image would certainly more consistent, but also more controversial, i would expect
[11:11am] dschwen: but it adds clutter. I'd rather use the chance to reduce clutter and increase consistency
[11:12am] dschwen: yes, fabriceflorin , the download option is useful
[11:12am] fabriceflorin: dschwen: I agree that the new button adds clutter. What would be a better option to serve the goals above, in your view?
[11:12am] dschwen: yes, I expect it to be more controversial
[11:12am] dschwen: fabriceflorin, what I wrote above. Have the MV open when clicking the image on the file page
[11:13am] tfinc left the chat room. (Remote host closed the connection)
[11:13am] Steinsplitter: agree^^
[11:13am] marktraceur: Steinsplitter, dschwen, I'd feel way more comfortable doing that if we had some consensus from Commons
[11:13am] fabriceflorin: dschwen: I agree with your proposal, but we had feared that people would find it too intrusive. It is also the solution recommended by Pau Giner, our designer.
[11:13am] tgr: dschwen: so, if someone convinces people that that's the way things should be, we will happily make the change, i am sure
[11:14am] dschwen: haha
[11:14am] Steinsplitter: omg, the consensus story...
[11:14am] dschwen: it upsets the olden ways, we sayeth nay!
[11:15am] gi11es: is there a way to consult the commons community effectively about this specific change?
[11:15am] dschwen: no
[11:15am] fabriceflorin: dschwen: pginer had proposed that clicking on the image open the Media Viewer, but that we also add a special icon over the image for people who want to access the original size, as shown in this mockup: http://i.imgur.com/DEeNhvt.png
[11:15am] gi11es: I like the idea, but a sample of 2 seems risky to me
[11:15am] bd808|LUNCH is now known as bd808.
[11:15am] bawolff: or they could click the "Original size" link
[11:15am] dschwen: I'm saying no, because you will most likely poll the hardcore users which have come to terms with the site as it is and have their established workflows
[11:16am] tfinc joined the chat room.
[11:16am] fabriceflorin: gi11es: Good question. I started a discussion page on Commons where we could pose this question to that community: https://commons.wikimedia.org/wiki/Commons_talk:Multimedia_Features/Media_Viewer
[11:16am] fabriceflorin:
[11:16am] dschwen: on the other hand, downloading an image is a typical "reuser action". I dont' quite see where it happens in administrative workflows. Except for duplicate image comparison (but we already have tools for that)
[11:16am] fabriceflorin: There is also a separate discussion on our main MediaWiki.org page on this question: https://www.mediawiki.org/wiki/Talk:Multimedia/About_Media_Viewer#Link_to_Media_Viewer_on_Commons
[11:16am] Steinsplitter: yes... we have bether tools for this
[11:17am] dschwen: so maybe it wouldn't be so controversial after all
[11:17am] moizsyed left the chat room. (Remote host closed the connection)
[11:17am] gi11es: dschwen: we've tried to be as sensitive as we could to those workflows. imho if the click-to-open media viewer on the file page only happens if you have media viewer turned on, we should be fine with the peopel who don't want change. they can just turn off media viewer
[11:17am] moizsyed joined the chat room.
[11:17am] fabriceflorin: dschwen: I would encourage you to propose the idea we just discussed, that clicking on the image on the Commons file page would open Media Viewer — on either of the discussion pages linked above.
[11:18am] tgr: mediaviewer on Commons is in a state of transition right now
[11:18am] tgr: the Commons community uses it on an opt-in basis
[11:18am] apsdehal left the chat room. (Quit: Connection closed for inactivity)
[11:18am] dschwen: By the way: media viewer immediately shows an upscaled thumbnail when opening. This is nice, as it makes the initial display more responsive. But loading the full resolution can take some time, and right now there is no indication that the MV is doing anything during that time.
[11:19am] fabriceflorin: dschwen: What do you think of Pau’s proposal to add an icon over the file page image, for people who want direct access to the original file? So clicking anywhere on the image would open Media Viewer, but power users would retain the option to get quick access as before. http://i.imgur.com/DEeNhvt.png
[11:19am] dschwen: Now, I'm not the greatest fan of "spinners" myself, but some "I'm working to get you a better quality version" would be nice
[11:19am] tgr: but people who arrive from other sites use it on an opt-out bases and expect it to work without any config change when they click on the 'learn more' link on one of the 'pedias
[11:19am] Steinsplitter: as i have sayed months before: pleas don't enable _unstable_ things on commons
[11:19am] tgr: so it is kind of hard to rely on opt-in/opt-out settings on Commons
[11:20am] gi11es: dschwen: regarding the high resolution image loading, there is a discreet progress bar at the bottom of the screen for browsers that are modern enough to support it
[11:20am] marktraceur: Steinsplitter: We'll disable MediaWiki right away.
[11:20am] dschwen: yes, fabriceflorin I think the overlay icon is a good suggestion
[11:20am] fabriceflorin: Steinsplitter: We agree with your position and apologize for any inconvenience with this early release. But we also encourage you to work with us to find a reasonable solution together.
[11:20am] dschwen: let me check this out gi11es
[11:21am] tgr: gi11es: the progress bar is not always visible in my experience
[11:21am] gi11es: tgr: that's mostly dependent on what the browsers provide us in terms of progress information
[11:22am] tgr: probably because the image loading can be stalled when the image is not actually loading
[11:22am] fabriceflorin: gi11es: I think your proposal to initially only open Media Viewer if they have it enabled is a good temporary solution to reduce stress for current users. But eventually, we will want a more permanent solution for casual users who end up on this page and don’t know how to get back to the Media Viewer.
[11:22am] tgr: varnish cache misses are one reason
[11:22am] tgr: a long preloading queue is another
[11:22am] dschwen: yeah, not visible in FF28 linux for me
[11:22am] gi11es: fabriceflorin: if media viewer is turned on for logged out users on commons, these casual visitors should see the button
[11:22am] tgr: also if the api requests lag behind the metadata panel is not visible at all, so no bar
[11:23am] fabriceflorin: Steinsplitter: would you be comfortable with a gradual approach? where we initially only show the button if you have Media Viewer enabled, then in a few weeks, make it appear for all, once we find a reasonable solution for the look and placement of that button?
[11:23am] RandomDSdevel joined the chat room.
[11:23am] gi11es: maybe that's not the case at the moment? (on for logged-out on commons)
[11:23am] danmichaelo joined the chat room.
[11:23am] danmichaelo left the chat room. (Changing host)
[11:23am] danmichaelo joined the chat room.
[11:23am] tgr: gi11es: it is a beta feature on Commons
[11:23am] gi11es: tgr: I was under the impression that we show the panel as soon as the image starts loading, regardless of API progress
[11:23am] gi11es: worth double checking
[11:24am] tgr: we don't
[11:24am] fabriceflorin: gi11es: You are correct that once we turn on Media Viewer by default for all users, this issue would no longer be so important. But this means that for a few weeks the button would not be available. I’m personally willing to live with that, as long as it’s a temporary situation.
[11:24am] gi11es: sounds like a ticket!
[11:24am] tgr: will do
[11:24am] Steinsplitter: fabriceflorin: *make it appear for all* hm... yoc an reall fix all bugs in a few weeks?
[11:25am] Steinsplitter: and pls includ a opt out *g*, maby som users dos not like the new tool
[11:25am] fabriceflorin: Steinsplitter: I think the plan proposed above would address most concerns I have heard so far. dschwen : would it work for you?
[11:25am] RandomDSdevel: Sorry I'm late; I just got here, so I'll check the logs and get back to everybody on what I think if I'm quick enough!
[11:25am] marktraceur: Steinsplitter: We've been over this, that's already built in.
[11:25am] tgr: Steinsplitter: it would be helpful if there was some sort of consensus view about what the serious bugs are
[11:25am] moizsyed left the chat room. (Remote host closed the connection)
[11:25am] fabriceflorin: Hi RandomDSdevel : thanks for joining our chat
[11:25am] edsanders|away is now known as edsanders.
[11:26am] Deskana: Steinsplitter: Generally it'd be more helpful if you said what you don't like about it so that they can work towards fixing that, rather than adding yet another button to our already overloaded preferences system.
[11:26am] RandomDSdevel: You're welcome! Like I said, though, you might not hear from me until I've caught up to where you guys are using the logs…
[11:26am] gi11es: Steinsplitter: Deskana: in case that wasn't clear for sites where media viewer is out of beta, there is an opt-out preference
[11:27am] Steinsplitter: tgr: for example the uploaded by "$username" schows only the username of the last upoder... this might be a problem
[11:27am] fabriceflorin: Besides the Commons button issue, are there other pressing issues that we should address in this chat? I listed some of the new features we just introduced on this main discussion page: https://www.mediawiki.org/wiki/Talk:Multimedia/About_Media_Viewer#Media_Viewer_Launching_Soon
[11:27am] gi11es: it's just not visible on sites where the feature is in beta, because the beta preference panel is how you turn it on/off
[11:27am] marktraceur: Steinsplitter: Not a technical problem, though.
[11:27am] Steinsplitter: fabriceflorin: ok
[11:27am] Steinsplitter: marktraceur: great
[11:27am] Steinsplitter: so you can fix it
[11:28am] Steinsplitter: maby to maka a link "schow full history"
[11:28am] gi11es: tgr: getting more uploaders/submitters was tried and turned out to be to potentially too expensive to get because we need to look at every revision, right?
[11:28am] marktraceur: Steinsplitter: My point is it's not something that causes the functionality to be crippled
[11:28am] marktraceur: Steinsplitter: What you're talking about is a feature request, not a bug.
[11:28am] fabriceflorin: How is the new ‘Use this file’ tool working for you all? (it includes Share, Download and Embed tools). You can try it out on this test page: https://www.mediawiki.org/wiki/Lightbox_demo#
[11:28am] dschwen: ok, yeah
[11:28am] Steinsplitter: marktraceur: this is a bug imho.. it is verry bad for reusers
[11:28am] tgr: gi11es: Steinsplitter: yeah, the current mediawiki API does not support it in a non-awkward fashion
[11:29am] Steinsplitter: argh
[11:29am] gi11es: Steinsplitter: we had identified the need for full history and had it spec'ed, but it turned out that the data is currently too expensive to fetch
[11:29am] Steinsplitter: k
[11:29am] gi11es: the effort/benefit ratio was in strong disfavour of that particular feature
[11:29am] marktraceur: Steinsplitter: I would suggest using the authour field in the machine-readable data, which we do read, and reproduce faithfully in our reuse dialogs
[11:30am] marktraceur: Uploader isn't really required to be credited in reuse scenarios, I think.
[11:30am] tgr: we had some plans to read the first uploader on PHP side and add it to the extmetadata API, not sure if it is within our current timeline though
[11:30am] Steinsplitter: marktraceur: i know, but there ar thousends of files with no informations templates
[11:30am] Steinsplitter: unortunatly
[11:30am] marktraceur: That's not a technical problem either.
[11:30am] tfinc left the chat room. (Remote host closed the connection)
[11:31am] tgr: that's https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/238 btw
[11:31am] fabriceflorin: dschwen: Are there any other critical issues with MediaViewer you think we should address in this chat? Is Media Viewer performing as you would expect it to?
[11:31am] bawolff: gi11es: its too expensive?
[11:31am] Steinsplitter: marktraceur: boah.
[11:31am] Steinsplitter: ...
[11:32am] Steinsplitter: marktraceur: you need to search a technical solution
[11:32am] tgr: bawolff: an extra api call basically
[11:32am] bawolff: If its limitted to the last 50, I can't imagine its that expensive. We already display it on the image page
[11:32am] dschwen: I don't have any other issues
[11:32am] marktraceur: Steinsplitter: For lack of information on a file?
[11:32am] bawolff: tgr: ah, that type of expensive
[11:32am] tfinc joined the chat room.
[11:32am] Steinsplitter: marktraceur: for this reason i have sayed abou the uploaderhyst
[11:33am] marktraceur: Yeah
[11:33am] tgr: bawolff: the issue is that you need to request all file revisions, and if you use the same API call to get metadata etc, you get it for all revisions
[11:33am] tgr: that can be quite large
[11:33am] bawolff: yeah. That's sucky
[11:33am] TBloemink joined the chat room.
[11:33am] tgr: or you make a separate call for all revisions with just uploader name
[11:33am] marktraceur: Steinsplitter: I think as we saw with defaulting to Date.now() in UploadWizard, the uploader may not be a sane default very often
[11:33am] tgr: neither one is really worth it
[11:34am] RandomDSdevel: Hey; I saw in the logs that you guys were discussing the location of some kind of 'Expand View' button. Could you guys point out where it might be in screenshots to me? I can't seem to find it…
[11:34am] Steinsplitter: tgr: gi11es: fabriceflorin: marktraceur: thanks for responding to my questions verry helpful.
[11:34am] fabriceflorin: BTW, for those of you lurkers who don’t have a lot of time to share your feedback here: consider taking this quick survey, to let us know what you think of this tool, and which improvements you would recommend. This helps us get an overall sense of what our wider community perceives its value. https://www.surveymonkey.com/s/media-viewer-1?c=irc
[11:35am] WikiBronze joined the chat room.
[11:35am] RandomDSdevel: @fabriceflorin about the survey: I'll do that after the IRC's over, 'kay?
[11:35am] DarTar: all: the research showcase is starting in a minute in R37 for SF-based folks, remote attendees: you can use the stream link: https://t.co/TpkEC3fG6b and join the conversation on #wikimedia-research
[11:35am] fabriceflorin: RandomDSdevel: Here is the discussion topic for the ‘link to MediaViewer”: https://www.mediawiki.org/wiki/Talk:Multimedia/About_Media_Viewer#Link_to_Media_Viewer_on_Commons
[11:35am] tfinc left the chat room. (Remote host closed the connection)
[11:35am] RandomDSdevel: @fabriceflorin about reply: OK; thanks!
[11:35am] fabriceflorin: And here is the mockup for that button: https://www.mediawiki.org/wiki/Talk:Multimedia/About_Media_Viewer#mediaviewer/File:Media viewer access from Commons design as a button.png
[11:36am] gi11es: hah, the dreaded spaces in links
[11:36am] gi11es: fixed on master, I believe
[11:36am] fabriceflorin: RandomDSdevel: This development ticket provides more details on this feature: https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/199
[11:36am] RandomDSdevel: @fabriceflorin: Again, thanks so much!
[11:36am] tgr: Steinsplitter: so to clarify, showing the first uploader instead of the last is something we could do, but mediawiki makes it complicated, and we might decide other stuff is more important
[11:37am] tfinc joined the chat room.
[11:37am] tgr: if it turns out that a lot of people think it top priority, that might change things
[11:37am] fabriceflorin: RandomDSdevel: At dschwen and pginer’s suggestion, we are considering an alternative implementation, where clicking on the image would open Media Viewer, but power users could also click on a smaller icon to access the original file, as shown on this mockup: http://i.imgur.com/DEeNhvt.png
[11:38am] Steinsplitter: tgr: k, it is a suggestion.
[11:38am] tgr: in general if someone in the community would take up the task of organizing/prioritizing community requests, that would be super nice
[11:38am] Steinsplitter: (sorry for my bad english. :P)
[11:38am] fabriceflorin: RandomDSdevel: We would appreciate your views on whether the solution proposed by dschwen might mitigate the need for an ‘View Expanded’ button.
[11:38am] Steinsplitter: i am not againt MediaW, on Wikipedia it looks verry nice, on commons too... only som functions ... *arggh*
[11:39am] tgr: right now it is like a hundred different requests from a hundred different people, half of them conflicting with the other half, and we need to decide on our own which ones are actually important
[11:39am] ori joined the chat room.
[11:39am] RandomDSdevel: @fabriceflorin about given links: All right, I'll look at everything, but, seriously, that's all of the links, right?
[11:39am] bawolff: Steinsplitter: Do you have a general list?
[11:39am] bawolff: of things that are shitty
[11:39am] tgr: Steinsplitter: don't worry, my German is worse
[11:40am] fabriceflorin: Steinsplitter: Thanks for your kind words about Media Viewer, despite your concerns about our recent deployment. We appreciate your willingness to keep the conversation going, so we can find an acceptable solution.
[11:40am] subbu is now known as subbu|lunch.
[11:40am] Steinsplitter: bawolff: no, if you wish i can send one... only a few things
[11:40am] bawolff: I always like to keep track of things that people don't like
[11:41am] bawolff: No guarantees I'll actually do anything about them...
[11:41am] fabriceflorin: RandomDSdevel: Sorry if I gave you too many links, just wanted you to have access to the relevant information, if you want it. I think we have the start of a reasonable solution, but want to hear from more folks like you …
[11:41am] RandomDSdevel: @fabriceflorin about feedback: When you say that deschwen suggested something that might remedy the situation concerning the 'View Expanded' button, do you mean that you guys discussed something earlier on in this IRC? In that case, I'll look back at the logs again; thanks for telling me.
[11:42am] fabriceflorin: For now, the best way to make us aware of the most critical community issues is to post on our main discussion page: https://www.mediawiki.org/wiki/Talk:Multimedia/About_Media_Viewer — You can also file a bug on Bugzilla: https://bugzilla.wikimedia.org/enter_bug.cgi?product=MediaWiki%20extensions&component=MultimediaViewer
[11:43am] tgr: bawolff: have you seen the video discussion at the bottom of mediaviewer's talk page? i recall you made a patch a couple months ago about displaying videos differently based on size
[11:43am] fabriceflorin: gi11es: Would you like to give folks a quick overview of your findings in terms of image load times?
[11:43am] bawolff: tgr: Hmm, I don't remember doing that
[11:43am] gi11es: sure
[11:44am] tgr: i might be mixing things up
[11:44am] fabriceflorin: If anyone is interested in our first metrics for Media Viewer, you can track them here: http://multimedia-metrics.wmflabs.org/dashboards/mmv
[11:44am] gi11es: so, the stats we're gathering are currently graphed on that page
[11:44am] RandomDSdevel: @fabriceflorin about link bombardment: That's all right; I'm just having a little trouble keeping up with everything that's being discussed here. I've got this IRC discussion's logs and the links you've given me open in some other tabs in this same window, so please forgive me if I don't respond to new posts right away, OK?
[11:44am] gi11es: the 3rd tab is currently experimental, but the rest is real data
[11:45am] bawolff: tgr: That is configurable though.
[11:45am] gi11es: one of the key findings is that api calls can take as much time as the images, and we're currently discussing caching options with ops to make that faster
[11:45am] bawolff: tgr: The change was made about six months ago
[11:45am] fabriceflorin: RandomDSdevel: No worries, that’s fine. I feel the same way as you do about being inundated with ‘too much information’ at times. Take as much time as you need to respond
[11:45am] Pyb joined the chat room.
[11:46am] gi11es: overall the stats have allowed us to measure/verify known pain points (thumbnail generation on demand) and identify things we missed
[11:46am] RandomDSdevel: @fabriceflorin: Thank you so very much! I'll try not to keep you guys waiting too long, though…
[11:46am] tgr: bawolff: could you point Brian in the right direction? i am still mostly clueless about TMH
[11:46am] gi11es: one of the graphs gives an interesting figure in regards to thumbnail generation, which is that it takes 1.3 seconds on average. on that front ops is also working on a solution that will allow us to prerender thumbnails, making that performance issue a thing of the past
[11:46am] bawolff: tgr: Will do
[11:47am] fabriceflorin: Thanks for this quick summary, gi11es . It’s particularly helpful, given that image load times could be one of the key issues with Media Viewer in regions with slow connections.
[11:47am] gi11es: I'm still working on filtering out outliers that currently impact the mean, so that the graphs can tell a story which is easier to interpret
[11:47am] gi11es: at the moment one extremely long load that might happen for freak reasons might make a country on the map turn red, which it shouldn't
[11:48am] gi11es: but basically the goal is to have an ongoing overview of the performance everywhere, so that we can identify issues as soon as they arise
[11:48am] fabriceflorin: But we are addressing that issue very carefully, by doing a gradual deployment that starts with small wikis in the next couple weeks, before going to larger wikis next month, as outlined in this release plan: https://www.mediawiki.org/wiki/Multimedia/Media_Viewer/Release_Plan
[11:48am] gi11es: all the data is available in downloadable form as well, for anyone who might want to generate more graphs or do more analysis
[11:49am] fabriceflorin: gi11es: We really appreciate all the good work you have done to shed more light on this issue, based on actual data, rather than anecdote and guesses …
[11:49am] fabriceflorin: Do other people here have any questions or comments about image load times — or our release plan?
[11:49am] gi11es: right, this is definitely the core idea, decisions in terms of engineering to improve performance aren't done as wild guesses anymore
[11:50am] KuboF joined the chat room.
[11:51am] fabriceflorin: OK, folks, is it the case we’re running out of things to discuss? C’mon, surely there must be an important issue with Media Viewer we haven’t talked about yet?
[11:51am] gi11es: I put everyone to sleep with my graphs talk, it's a gift
[11:51am] fabriceflorin: What do you all think of the tool? Is is working for you? Any important improvements we could make in the next few weeks, before we move on to Upload Wizard?
[11:52am] fabriceflorin: gi11es: hehe. Your graphs do have a hypnotic, mesmerizing effect
[11:53am] dschwen: well... I really am not the target audience for the MMV and it does not show up in my workflows very much
[11:53am] dschwen: i.e. it does not get in my way
[11:53am] fabriceflorin: Is there anything we could have done to better host or promote this IRC chat? We would like to have chats like this about once a month, but want to make sure that everyone gets a chance to participate. Is this a good time for folks? Or would there be a better time?
[11:54am] ori left the chat room. ("Leaving...")
[11:54am] dschwen: but I when I use it (as a wikipedia reader) I find it to be a nice improvement
[11:54am] bawolff: gi11es: I think it will be interesting to see how performance changes once this is wide spread, and varnish caches (or even swift) caches generally are cache hits instead of misses
[11:54am] fabriceflorin: dschwen: Thanks for sharing your advanced user perspective. I am glad that MV doesn’t interfere with your workflows.
[11:55am] kaity|away is now known as kaity.
[11:55am] gi11es: bawolff: I expect that there will be a network effect (i.e. misses going down over time), by virtue of a lot more people triggering thumbnail generation
[11:55am] gi11es: the graphs will certainly confirm or infirm that theory
[11:55am] alantz left the chat room. (Quit: Computer has gone to sleep.)
[11:55am] fabriceflorin: bawolff: Yeah, I can’t wait to see the results in a week, after we have run Media Viewer enabled by default on Catalan, Hungarian and Korean Wikipedias.
[11:56am] fabriceflorin: Keegan: Are you hearing questions from any of our other communities that could be answered here in the 5 minutes that remain?
[11:56am] bawolff: gi11es: indeed. I strongly expect it to confirm, since swift caches last forever and ever
[11:56am] Keegan: fabriceflorin: not at this time!
[11:58am] fabriceflorin: All right, folks. Probably time to wind down the formal office hours. Please post any concerns on our discussion page and ping us directly if there are serious issues that need our immediate attention. Let’s plan another IRC chat like this one next month, when we hope to start talking about Upload Wizard — not just Media Viewer. Thank you all for your great insights, as always!
[11:58am] bawolff: gi11es: Speaking of cache of thumbnails (This is slightly off topic), do you have any thoughts on https://bugzilla.wikimedia.org/show_bug.cgi?id=63440
[11:59am] alantz joined the chat room.
[11:59am] alantz left the chat room. (Client Quit)
[12:01pm] cndiv left the chat room. (Quit: WeeChat 0.4.3)
[12:01pm] dschwen: thanks, bye
[12:01pm] fabriceflorin: dschwen: Do you think that the Commons community would support your proposal to click on the image to open Media Viewer instead of showing the ‘View expanded’ button? (with the special icon shown in http://i.imgur.com/DEeNhvt.png ) - How can we best reach a resolution on this issue? Want me to prepare a new ticket proposing that option, then start a topic on our discussion pages?
[12:01pm] gi11es: bawolff: it would make sense to unify these options with the media viewer buckets, for one...
[12:01pm] dschwen: Yeah
[12:01pm] dschwen: Might as well bring it up in the existing discussions
[12:01pm] dschwen: I'll ask on the Forum
[12:01pm] gi11es: even if currently it would be rare for media viewer to be this small
[12:02pm] fabriceflorin: dschwen: OK, sounds good. I will get things ready, then ping you via Echo when it’s been posted on the existing discussion. Thanks again for helping us find better solutions
[12:03pm] gi11es: bawolff: is there any controversy about picking the same selection for all wmf wikis? there's a ton of discussion in that ticket, it's hard to get a quick understand of what else might be discussed
[12:03pm] gi11es: *understanding
[12:03pm] fabriceflorin: OK, folks, it’s been great to talk with you all. Thanks for making the time to guide our progress, it’s much appreciated!
[12:03pm] bawolff: gi11es: I'm not really clear on what the actual controversy is. It seems like some people are concerned with changing the default thumb value, as that would increase the number of thumbnails stored in swift by a lot
[12:04pm] gi11es: bawolff: that's understandable, in which case I think that the expiring thumbnail sub-RFC might be a prerequisite
[12:05pm] kaity is now known as kaity|away.
[12:05pm] bawolff: although some people have pointed out most thumbs are already rendered at 1.5 times the current size for retina displays, so its unclear how big a concern that really is
[12:05pm] Deskana left the chat room. (Remote host closed the connection)
[12:06pm] gi11es: bawolff: on a related note ori also brought up the fact in a recent discussion that we might want to look at lowering the compression quality for tiny thumbnails
[12:06pm] gi11es: at the moment we compress all jpegs with the same settings, regardless of size
[12:06pm] gi11es: I suspect there will be an RFC soon with side-by-side comparisons
[12:07pm] gi11es: trying to see if we can lower the file size of small thumbnails without a noticeable drop in visual quality
[12:07pm] bawolff: Hmm, I know some of the mobile folks also want lower quality thumbs, just in general
[12:07pm] edsanders is now known as edsanders|away.
[12:07pm] gi11es: zero wants very low quality, for other reasons, which is where the discussion started
[12:07pm] gi11es: but I think there is low hanging fruit in the core experience and how we currently generate thumbs
[12:08pm] bawolff: probably. I think there's even edge cases where we make thumbnails bigger than the original sometimes
[12:08pm] gi11es: for vector images I think that's possible
[12:08pm] bawolff: It used to be for indexed pngs too, not sure if that got fixed
[12:08pm] atgomez left the chat room. (Quit: Computer has gone to sleep.)
[12:09pm] bawolff: on the other side of the spectrum, there's this discussion at commons https://commons.wikimedia.org/wiki/Commons:VP#Terrible_choice_of_filter_being_used_for_image_downsizing.
[12:09pm] tewwy joined the chat room.
[12:10pm] gi11es: I don't think I've seen proper color profile conversion code in our thumbnailing
[12:10pm] gi11es: compared to the code we were running at deviantart to generate thumbs, mediawiki's seems very basic and ignorant of these issues (maybe I missed where that code lives, though)
[12:11pm] bawolff: We just include the colour profile with the thumbnail from what I understand
[12:11pm] bawolff: and hope the browser supports colour profiles
[12:11pm] bawolff: which a good portion do now a days
[12:12pm] gi11es: last time I checked, safari is the only one that interprets them
[12:12pm] bawolff: firefox interprets them now too
[12:12pm] gi11es: it's a vastly ignored issue in browser land
[12:12pm] gi11es: still, profile are heavy, conversion is something that would make sense for small thumbnails
[12:12pm] gi11es: which we're already applying lossy compression to
[12:13pm] prtksxna is now known as zz_prtksxna.
[12:14pm] bawolff: yes it would
[12:15pm] edsanders|away is now known as edsanders.
[12:15pm] bawolff: hmm, https://en.wikipedia.org/wiki/Color_management#Application_level seems to indicate support is not too bad
[12:16pm] gi11es: definitely much better than a few years ago
[12:17pm] gi11es: tbh, I think color profil mostly makes sense for the original
[12:17pm] RandomDSdevel: @all: I just read the discussion that tgr, deschwen, and Steinsplitter had about an hour ago (yes, I'm that far behind you guys; again, I'm sorry about that, and I promise you that I'll catch up) about the fact that any changes that you guys would want to make in the process of fixing the issue that the 'View expanded' button was intended to patch temporarily would need to be agreed to by the community; it made me ch
[12:17pm] gi11es: if we're already compressing the jpeg 80% to render a given size, the fact that the color profile is still the original doesn't really improve things. compression has already screwed with the colors
[12:19pm] gi11es: for PNGs it makes sense to leave it, since it's lossless even after resize
[12:20pm] danmichaelo left the chat room. (Quit: Computer sleeping)
[12:21pm] gi11es: https://www.facebook.com/notes/facebook-engineering/under-the-hood-improving-facebook-photos/10150630639853920 sRGB takes 3kb, I think adobe rgb is worse
[12:22pm] gi11es: certainly nothing to sneeze at for thumbnails that weigh 10-20kb
[12:22pm] subbu|lunch is now known as subbu.
[12:26pm] rfarrand left the chat room. (Quit: Computer has gone to sleep.)
[12:28pm] guillom is now known as basile.
[12:29pm] moizsyed joined the chat room.
[12:33pm] mhurd left the chat room. (Quit: mhurd)
[12:33pm] DarTar left the chat room. (Quit: DarTar)
[12:38pm] rmoen is now known as rmoen|away.
[12:42pm] RandomDSdevel: All right; are we all done here both officially and unofficially (I know we're done officially since I saw fabriceflorin leave, but do you guys know about anything else that you'd like to discuss, especially now that I can join you now that I've finished catching up?)
[12:42pm] tewwy left the chat room. (Quit: tewwy)
[12:46pm] bawolff: RandomDSdevel: Conversation seems to have died, but if there's anything you have questions about, or want to talk about, by all means (Although it might be better to move the conversation to #wikimedia-multimedia at this point)
[12:46pm] bawolff: RandomDSdevel: Really, people will probably answer questions at any time if they are online and not too busy, even if its not "office hours"
[12:47pm] RandomDSdevel: @bawolff: You have a point there; I guess I'll jump ship and head over there now, OK? See ya!

updates on an image reduction RfC
2100-2200 UTC

02:02 <sumanah> #startmeeting RfC review: reducing image quality for mobile | Channel is logged and publicly posted (DO NOT REMOVE THIS NOTE). https://meta.wikimedia.org/wiki/IRC_office_hours

02:02 <wm-labs-meetbot> Meeting started Wed Apr 16 21:02:02 2014 UTC and is due to finish in 60 minutes.  The chair is sumanah. Information about MeetBot at http://wiki.debian.org/MeetBot.

02:02 <wm-labs-meetbot> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.

02:02 <wm-labs-meetbot> The meeting name has been set to 'rfc_review__reducing_image_quality_for_mobile___channel_is_logged_and_publicly_posted__do_not_remove_this_note___https___meta_wikimedia_org_wiki_irc_office_hours'

02:21 * sumanah waits for Brion

02:38 <sumanah> #chair sumanah TimStarling

02:38 <wm-labs-meetbot> Current chairs: TimStarling sumanah

03:13 <sumanah> #chair sumanah TimStarling brion

03:13 <wm-labs-meetbot> Current chairs: TimStarling brion sumanah

03:15 * brion waves

03:18 <sumanah> #link https://www.mediawiki.org/wiki/Architecture_meetings/RFC_review_2014-04-16

03:27 <sumanah> #info Today is probably going to be a short meeting - just 1 RfC on the agenda

03:31 <sumanah> #topic Reducing image quality for mobile

03:42 <TimStarling> the patch seems quite different to what yurik and I discussed at the architecture summit

03:50 <sumanah> ( but brion TimStarling - I may ask some follow-up questions at the end about a few other RfCs and pending things)

03:54 <sumanah> #link https://www.mediawiki.org/wiki/Requests_for_comment/Reducing_image_quality_for_mobile

04:15 <sumanah> #info I asked Yuri what he wanted: 1) an ok from ops to increase thumbnail storage by 2-3% and number of files by 15%, 2) from core/tim/etc to proceed with the proposed patch <yurik> assuming my proposed path is satisfactory to everyone's involved

04:19 <TimStarling> I thought that you should have only quality classes exposed, not expose an API allowing any integer percentage quality

04:59 <yurik> TimStarling, it would be fairly easy to change from a number to a string constant

05:11 <TimStarling> you suggest 30% but probably every mobile app will choose something different

05:12 <yurik> if this is a requirement of course

06:37 <yurik> TimStarling, this is similar to the problem we face with the thumbnail dimension  - every wiki varying images by a few pixels. I propose a somewhat different solution here - an extension that does filtering/rounding of these numbers during the rendering

07:04 <sumanah> thedj: dfoy_ - http://bots.wmflabs.org/~wm-bot/logs/%23wikimedia-office/20140416.txt for the logs up till now

07:21 <TimStarling> I don't see any filtering or rounding in the patch

07:41 <yurik> example: user requested 240x250 image - the ext would say 250x250 already exists, or it is a multiple of 50, hence render it as a link to 250x250, with width=240

08:00 * aude waves

08:11 <aude> yurik: is this something your extension would do? rather than core?

08:12 <sumanah> Hi :)

08:12 <yurik> separate patch - as an extension - to address all such rounding requirements for both image size & quality

08:16 <TimStarling> yeah, you can read my thoughts on that on the relevant RFC

08:47 <yurik> aude, not ours, a new extension whose job is only to "standardize" on thumbnail generation

08:54 <AaronSchulz> gah

08:59 <aude> but not core?

09:11 <sumanah> AaronSchulz: I presume you think that's the wrong approach :)

09:28 * brion just added comment on the patch agreeing with idea to use quality classes rather than expsoing full integer range

09:33 <sumanah> #link https://gerrit.wikimedia.org/r/#/c/119661/ Gerrit changeset, "Allow mobile to reduce image quality"

09:34 <yurik> no, i think core should be more flexible - depending on the site

09:46 * aude prefers we allow any size, but not keep cached so long if it's not requested

09:58 <aude> if that's feasible

10:09 <TimStarling> me too

11:37 <thedj> can i ask what the primary purpose is ?

11:46 <thedj> reduce time to load ?

12:01 <sumanah> thedj: honest question: does the RfC address that? do you think the RfC should be clearer about the problem being solved?

12:03 <yurik> reducing quality? to lower bandwidth consumption

12:36 <thedj> yurik: so download time and download cost ?

13:30 <yurik> both

13:36 <thedj> Do we have some metrics/ideas to give us indications of how much benefit that would translate into ?

13:43 <yurik> especially when the bandwidth is donated

14:22 <yurik> thedj, 30-40%

14:55 <thedj> ah k. so it's to a large degree from the zero perspective that we want to do this.

15:01 <yurik> correct

15:36 <brion> i could see it being handy for hi-dpi devices as well, we could serve the double-size images with a medium quality setting to trade-off brandwidth and visual quality

15:38 <sumanah> BTW, for those who haven't looked, we now have a few more comments on the changeset https://gerrit.wikimedia.org/r/119661 in the last few minutes

15:50 <brion> but definitely the incentive is where we’re pushing donated bandwidth :)

15:55 <sumanah> (there's our brion always looking out for responsive design & gadget stuff :) )

16:19 <bawolff> My comment was just that it shouldn't touch the -quality setting on pngs, and a nitpick on the commit message

17:11 <gwicke> once we move to HTMl storage, is the idea to implement this as a DOM post-processing step?

17:39 <yurik> TimStarling, brion, please take a look at the https://www.mediawiki.org/wiki/Requests_for_comment/Reducing_image_quality_for_mobile#Possible_approaches

18:15 <yurik> it discusses the 3 paths to do this, with 1 path doing everything internally without exposing it via URL

18:43 <brion> *nod* i was assuming the first pass implementation once the qualitys etting was available...

18:52 <TimStarling> probably option 2

18:54 <brion> … was to do it as a dom postprocess step in mf+zero

19:09 <TimStarling> that's not on the list

19:24 <yurik> that's #3 i think

19:26 <brion> agh, i confused that with the js one

19:59 <yurik> tim, you think it is better to let varnish do automagical image url rewrite?

20:19 * AaronSchulz prefers js if possible

20:31 <TimStarling> how would it work with JS?

20:38 <yurik> because we won't have as much info in varnish, plus we would have to put too much biz-logic in varnish (ops won't like it)

20:43 <gwicke> one issue I see with Varnish is transparent downstream caches

20:52 <yurik> yes, that too

20:55 <TimStarling> a DOM ready event?

20:55 <gwicke> the third option (JS) avoids that

21:03 <yurik> JS would rewrite the URL

21:10 <brion> hmm

21:24 <brion> my main concern with that is rewriting urls in JS without often loading the original url is tricky

21:35 <TimStarling> I am wondering what the CPU requirements of option 3 are

21:37 <AaronSchulz> gwicke: related to downstream caches is handling purges

21:51 <TimStarling> and whether there will be flicker, browser incompatibilities, etc.

21:58 <gwicke> AaronSchulz, *nod*

22:02 <AaronSchulz> I guess if it's the very frontend cache it's fine

22:09 <TimStarling> we can't really waste the CPU of phones the same way we can desktop browsers

22:17 <gwicke> we'd have to send s-maxage-0

22:19 <yurik> workflow:    zero ext changes src= to low quality,   JS changes it back to highres if device/network is good

22:21 <gwicke> =0

22:34 <brion> :\

22:45 <yurik> how expensive is a JS image tag search?

22:55 <gwicke> it's pretty cheap I believe

23:07 <brion> replacing them may be slow if it’s a big page with lots of images though

23:19 <gwicke> one querySelectorAll call

23:24 <brion> and you’ve got the issue of loading the original images and then the new ones....

23:25 <TimStarling> image loading will start as soon as the img tag is created, right?

23:27 <yurik> percentage wise i still think it won't be much

23:35 <AaronSchulz> TimStarling: I think so :/

23:45 <gwicke> yeah, I think that's the bigger issue

23:57 <gwicke> we have a similar issue with the thumb size pref

23:58 <yurik> that's the big question - can the low->high quality img tag replacement be done before browser starts loadnig them?

24:07 <TimStarling> what about what brion said, why is that not an option?

24:19 <TimStarling> <brion> … was to do it as a dom postprocess step in mf+zero

24:22 <gwicke> if we can find a way to suppress the original thumb load before resizing / quality downgrading, then that would be awesome

24:46 <yurik> TimStarling, we would have to do it anyway, but there will be users who would want high-end images

25:03 <brion> i think we’re trying to avoid having php-time cacheable differences on zero….. it’s all very scary

25:35 <brion> in general, trying to scale for estimated network bandwidth is just a tricky tricky business

26:45 <sumanah> tfinc: http://bots.wmflabs.org/~wm-bot/logs/%23wikimedia-office/20140416.txt for chat so far

27:18 <yurik> there is another question - i am pretty sure there are many mobile users out there who don't have zero and who might want low bandwidth too

27:24 <TimStarling> what about having a separate new service to do DOM rewriting?

27:49 <yurik> so we really should have a mobile setting "auto/always high/always low"

28:01 <TimStarling> yurik: those users can put up with what we give them

28:05 <gwicke> TimStarling, that's doable for low volume

28:26 <gwicke> which zero is afaik

28:57 <gwicke> what are the peak request rates on zero in pages / s ?

29:00 <yurik> well, not those who are still on 2G, or who is paying high price for their internet.

29:24 <TimStarling> it's out of scope

29:31 <aude> yurik: then i'd want no images, if concerned about bandwidth (imho)

29:40 <aude> maybe my mobile browser allows that

29:45 <sumanah> Those who have questions for Max, he's here now

29:54 <TimStarling> the problem is complicated enough when it is just Zero

30:09 <dr0ptp4kt> fwiw, MobileFrontend already has an Images on/off toggle

30:13 <sumanah> (OK, maybe today's meeting WON'T be a short one after all.)

31:17 <TimStarling> dr0ptp4kt: does it work?

31:26 <TimStarling> or do the images start loading and then get aborted?

31:34 <dr0ptp4kt> TimStarling: it is completely rewritten html

31:40 <dr0ptp4kt> it works

31:40 <MaxSem> it works via DOM rewriting on PHP side

31:53 <gwicke> there are ways to parse html without loading images, using https://developer.mozilla.org/en-US/docs/Web/API/DOMParser for example

32:27 <gwicke> or XMLHttpRequest

32:27 <dr0ptp4kt> one caveat is supporting devices that don't support javascript, or rather "advanced javascript" as determined by rl

32:35 <TimStarling> gwicke: well, that's the kind of thing that I would expect to use a lot of client-side CPU

32:48 <gwicke> not really- it's using the normal html parser

32:59 <gwicke> it does rely on JS support though

33:05 <gwicke> and a non-sucky browser

33:13 <dr0ptp4kt> HA!

33:20 <gwicke> ;)

33:26 <MaxSem> I don't think that many devices we want to support will work well with this

33:53 <gwicke> are you using XMLHttpRequest currently?

34:06 <MaxSem> libxml2

34:14 <MaxSem> be its name foreveer cursed

34:22 <TimStarling> can someone give me a quick overview of how HTML delivery in MF works and what the plans for it are?

34:42 <dr0ptp4kt> we use xhr opportunistically. so it's usually to upgrade the experience, like avoid server roundtrips for newer phones

34:58 <dr0ptp4kt> er, bigger roundtrips

35:15 <MaxSem> шеэы ыешдд мукн кщгпр щт увпуы

35:18 <gwicke> I see, so you are hesitant to require it

35:25 <TimStarling> preferably in a latin script

35:28 <yurik> MaxSem, +2

35:34 <MaxSem> it's still quite buggy so is used only in alpha

35:54 <dr0ptp4kt> sumana, would you please wire up a translation bot now? :)

36:02 <MaxSem> plans are to  fix it

36:06 <MaxSem> ...eventually

36:11 <MaxSem> ...maybe

36:35 <gwicke> I don't see an issue with DOM post-processing on the server and storing that HTML back

36:36 <dr0ptp4kt> yeah, the xhr for w0 is more like getting runtime config to do things ahead of caches being purged (e.g., add zero-rated support for an additional language)

36:58 <sumanah> dr0ptp4kt: I think here it would just emit those cartoon profanity things, like $%#%@

37:17 <gwicke> as long as there are only a few variants and the transforms build on a known DOM spec that should work well

37:52 <yurik> gwicke, zero already does a DOM post-parse rewrite to replace all external URL links with special warning URLs

37:59 <MaxSem> I would reeeeeally love to avoid doing it in PHP again

38:21 <gwicke> it's fairly easy in JS

38:27 <gwicke> you can use jquery etc

38:37 <MaxSem> wouldn't be lethal for zero which already does HTML transformations, but  still sucks

38:50 <yurik> gwicke, assuming flip phone has it :(

38:59 <gwicke> yurik, I mean on the server

39:38 <yurik> do we have a framework for node.js extensions?

39:57 <gwicke> yurik, we have HTTP..

40:08 <gwicke> set up a service, make requests to it

40:24 <sumanah> So we're about 2/3 through the hour and I'm not sure what to #info :)

40:46 <yurik> gwicke, you mean PHP becomes a proxy to another service on internal network?

41:07 <yurik> in any case, this is an optimization for the future, outside of the scope imho

41:19 <TimStarling> sumanah: three of us wrote comments on the gerrit change

41:36 <gwicke> yurik, you can go through PHP if you want; depends on whether it adds info that would be hard to get otherwise

42:04 <AaronSchulz> do we actually need the wikitext syntax addition too?

42:14 <MaxSem> definitely not

42:16 * AaronSchulz leans toward not adding it

42:17 <brion> i think we don’t need the wikitext addition no

42:28 <brion> keep it opaque to that layer

42:32 <AaronSchulz> right

42:33 <TimStarling> #info comments were provided on the image quality gerrit patch

42:33 <brion> it’s a presentation-layer decision

42:34 <sumanah> !link https://www.mediawiki.org/wiki/Talk:Requests_for_comment/Reducing_image_quality_for_mobile#File_insertion_syntax

42:50 <sumanah> er

42:53 <gwicke> -1 on the extra syntax

42:56 <sumanah> #link https://www.mediawiki.org/wiki/Talk:Requests_for_comment/Reducing_image_quality_for_mobile#File_insertion_syntax on wikitext addition

43:03 <sumanah> can I say #agreed ? :)

43:07 <bawolff> +1 on not adding extra options to file syntax

43:27 <yurik> bawolff, how do you mean?

43:27 <TimStarling> #info image scaler backend relatively uncontroversial -- HTML/URL manipulation to access that API is more complex

43:38 <yurik> we need to distinguish low-quality URLs from the highs

43:41 <bawolff> yurik: I'm agreeing with everyone

44:03 <yurik> good position :)

44:05 <bawolff> yurik: as in not adding [[File:foo.jpg|quality=20]] ui

44:15 <yurik> gotcha

44:42 <TimStarling> #info gwicke predictably favours Node.JS service

44:48 <AaronSchulz> lol

44:53 <gwicke> hehe

45:06 <gwicke> that's in response to MaxSem's lament about libxml2 ;)

45:34 <MaxSem> having a service for that would be even more cruffty

45:39 <yurik> ok, i will change the URL syntax to    image.jpg/100px-qlow-image.jpg   this way we can later change it to some other magic keywords

45:45 <sumanah> So it's sounding like people think this is a relatively uncontroversial idea overall and we're just talking about implementation, right?

46:08 * tfinc reads the backscroll

46:20 <yurik> any objections to that URL format?

46:32 <bawolff> yurik: Maybe re-order those parameters. Easier to regex out qlow-100px from the actual name of the file

46:37 <sumanah> "this" being the RfC as a whole

46:53 <MaxSem> +1

46:54 <bawolff> since we're going to be presumably keeping 100px-image.jpg for the normal quality image

47:15 <gwicke> are we sure that we need a different URL?

47:21 <MaxSem> yes

47:29 <MaxSem> varnish rewrites are evil

48:16 <gwicke> do we already have info about zero ip ranges in varnish?

48:27 <yurik> ok, all settled, will implement the first step (core patch), and start implementing JS magic

48:43 <MaxSem> gwicke, for all that is holy, don't

48:44 <yurik> gwicke, yes, varnish detects zero based on ip

48:52 <sumanah> #info <yurik> ok, all settled, will implement the first step (core patch), and start implementing JS magic

49:15 <MaxSem> especially since now only mobile varnishes know about zero

49:19 <gwicke> hmm, then it might not actually be that hard to use that for image request rewriting

50:31 <yurik> #info required modifications: use string instead of integer  "qlow-100px-image.jpg", make it JPG only (no png)

50:31 <gwicke> I'd be against adding that info if it wasn't there already; but since it's already there it seems that the extra complexity would be fairly limited

50:46 <TimStarling> varnish doesn't have a lot of string handling built in, but you can use inline C, I did it once...

51:17 <MaxSem> regexping it would actually be possiblee

51:34 <MaxSem> but still this would SUCK

52:00 <sumanah> I have a few min of "what's up next week + other RfC news you should be aware of" to say before the end of the hour.

52:04 <sumanah> Any closing statements?

52:39 <TimStarling> modules/varnish/templates/vcl/wikimedia.vcl.erb was my own little bit of varnish URL manipulation

53:30 <yurik> if we are done, would love to get +2 for https://gerrit.wikimedia.org/r/#/c/109853/

54:34 <TimStarling> #info Tim skeptical about client-side JS rewrite: potential for CPU usage, flicker, image load aborts, browser incompatibilities, etc.

55:21 <gwicke> avoiding a double-load is hard afaik

55:41 <TimStarling> which is an argument for doing it on the server side

55:49 <AaronSchulz> yeah it may not be possible to use JS

55:50 <gwicke> or in Varnish

56:04 <AaronSchulz> so it's 1-2

56:18 <TimStarling> we have so many powerful tools on the server side now, we shouldn't be so keen to offload processing

56:36 <sumanah> ok, I'm gonna wrap up with a couple other #topics

57:00 <gwicke> for normal desktop page views the thumb size pref is pretty much the only one that can't be easily handled in CSS

57:01 <sumanah> #topic Next week - Associated namespaces

57:07 <sumanah> #link https://www.mediawiki.org/wiki/Requests_for_comment/Associated_namespaces Next week David Cuenca wants to find out whether there are any objections to the "Namespace registry and association handlers" that Mark proposed, discuss possible problems with his proposed approach, and see if there would be any hands available to work on it. He mentioned that "I hope this RFC moves forward because it affects important upcoming and already depl

57:08 <sumanah> oyed projects (Commons migration, templates, Visual editor, WD, etc)."

57:15 <sumanah> er: "it affects important upcoming and already deployed projects (Commons migration, templates, Visual editor, WD, etc).""

57:45 <sumanah> #topic RfC news

57:53 <gwicke> so if we can find a way to do this in Varnish it might be possible to implement those prefs purely in CSS

58:03 <sumanah> #link https://www.mediawiki.org/wiki/Talk:Requests_for_comment/Simplify_thumbnail_cache Mark Bergsma and Aaron Schulz just left some comments on the "Simplify thumbnail cache" RfC - if you're into that one, check them out

58:16 <sumanah> #info Pau Giner has updated his grid system RfC https://www.mediawiki.org/wiki/Talk:Requests_for_comment/Grid_system with more detail, and has submitted a patchset to Gerrit https://gerrit.wikimedia.org/r/#/c/125387/ so that the discussion can get more specific. Also see the example implementation http://pauginer.github.io/agora-grid/

58:34 <sumanah> #info http://www.gossamer-threads.com/lists/wiki/wikitech/451921 "REST and SOA within MediaWiki - is my understanding right?" includes gwicke saying, "ideally the only code that directly talks to the database would live in a storage service, which exposes a REST API." which refers to https://www.mediawiki.org/wiki/Requests_for_comment/Storage_service in case you want to take a look at that

58:49 <sumanah> #info bd808 needs feedback on his structured logging patch - see http://lists.wikimedia.org/pipermail/wikitech-l/2014-April/075921.html

59:24 <sumanah> And as always I welcome your suggestions of what RfCs to talk about in these meetings next - and who specifically needs to be in those chats so we can sometimes change the timing

59:27 <sumanah> That's all from me.

59:57 <sumanah> yurik: did you get what you wanted (somewhat) today? :)

00:03 <sumanah> MaxSem: ^ (same question)

00:13 <sumanah> TrevorParscal: do you have an RfC that needs chatting about sometime soon?

00:17 <sumanah> (for instance)

00:32 <sumanah> #endmeeting