EE August 2014

ee@lists.wikimedia.org

26 participants
29 discussions

OOjs, MobileFrontend and Flow
by Jon Robson 20 Sep '14

20 Sep '14

Shahyar, Juliusz, Trevor, Roan and I met to discuss using oojs inside the mobile and Flow projects. The following 3 patches kicks off moving MobileFrontend's class model towards that of oojs - many thanks for Roan for doing most of the legwork :-): https://gerrit.wikimedia.org/r/155593 https://gerrit.wikimedia.org/r/155589 https://gerrit.wikimedia.org/r/129336 On the long term we'd look to swap out the Class.js and eventemitter.js files in MobileFrontend for oojs, but this is going to be tricky and require some care, possibly mixing both oojs and MobileFrontend's class code in the repository at the same time. e.g. increasing JavaScript on the short term, but reducing it on the longterm. The MobileFrontend core development team will need to work out how best to manage this transition. Since Flow is very DOM-focused, as opposed to many smaller JavaScript modules with element management per the currently-accepted use of OOjs, it is unclear how we may go about integrating with OOjs fully. However, some potential use cases have been identified as candidates for implementing OOjs on an interim basis, primarily by abstracting some current FlowBoardComponent workflows, such as those which handle (re-)rendering of existing and new content fetched from the API.

3 6

Fwd: Non-JavaScript Flow: Hiding non-ready functionality
by Jon Robson 11 Sep '14

11 Sep '14

Whoops this was meant to be to the public mailing list! ---------- Forwarded message ---------- From: Jon Robson <jrobson(a)wikimedia.org> Date: Wed, Aug 27, 2014 at 2:39 PM Subject: Non-JavaScript Flow: Hiding non-ready functionality To: "Editor engagement list for the core E2 development team." <e2(a)lists.wikimedia.org> I noticed in a code review today that S was confused to why actions are unavailable in titlebar and posts (.client-nojs .flow-menu" has display:none in CSS) Recently in the last retrospective the Flow team agreed to record on the mailing list decisions, and since this decision happened prior to the meeting (about 3/4 weeks ago) I should try my best to record that decision. May, Danny, Shahyar and I sat down and spoke about the non-JavaScript version of the site, in particular with respect to mobile, as many mobile devices on slow connections will hit the non-JS site at some point. The summary was that the current non-js needed lots of love, but that we should focus on the topic and reply workflows (which are currently being looked on as part of this iteration [1]) Any functions that didn't fit into this, where the UX was suboptimal would be hidden, even if they were functional. The link to summarize for instance will take you to a page like this: http://en.wikipedia.beta.wmflabs.org/w/index.php?title=Topic:S15sspioi5wvqz… The page simply shows a textarea and doesn't really help you understand what you are doing. Likewise clicking edit title takes you to a page like so: http://en.wikipedia.beta.wmflabs.org/w/index.php?title=Topic:S15sspioi5wvqz… Displaying them again is pretty easy (Shahyar already has a patch [2]) but the UX love is much needed before doing so. [1] https://trello.com/c/fp2odUa3/531-g-1-mobile-no-js-make-reply-field-a-link-… [2] https://gerrit.wikimedia.org/r/153354

3 8

Standardising icons across projects
by Jon Robson 10 Sep '14

10 Sep '14

Since we had the luxury of having several people in the office, Trevor, Juliusz, Rob Moen, Ed Sanders, Shahyar, May, Monte and I sat down to talk about the problem we currently have of having no standard way to create icons. Here is my write up of this meeting, again, if you attended please add/correct me on anything and if you were not please ask for clarification where needed. Currently we have two modes of creating icons in MediaWiki 1) Using a font 2) Using SVGs with PNG fallbacks and the markup varies depending on what extension you look at. We discussed both approaches and advantages and disadvantages of each. One of the major disadvantages of the WikiFont is the additional HTTP request it creates to download the font and cannot be embedded in the stylesheet using data uris like SVGs can (due to URL size restrictions). One of the major advantages of WikiFont is you can design a grayscale icon, and style it using font colour. Shahyar was happy to move Flow to using SVG based fonts if we could build grayscale SVGs and change their colours using ResourceLoader. One concrete example is when you have an icon used in a constructive anchor. The icon needs to be green, but when hovered over a lighter green. Another advantage brought up by May was that currently she finds it much easier to build icons in this way, and that having to maintain separate coloured versions of the SVGs is a pain point to her. We decided that we should push towards using SVGs that can be built into fonts for the purpose of the app. As next steps 1) Monte to explore using SVGs in the Wikipedia apps. He will create font from SVGs. He will work with May to ensure her workflow is as easy as before. 2) Trevor is going to look into how we can automatically generate different colour versions of SVGs and automatically create PNGs from them. 3) I am going to aim to agree on a standard icon HTML markup for mediawiki ui. We still have an issue with the fact that everyone is using different HTML markup to create icons. After reviewing all our current approaches [1] it was clear that we were relatively closely aligned and that it simply is a case of agreeing on class names. We aim to get all the above done by Sept 15th, 2014 so please poke us on the mailing list if you haven't had a follow up then. Full disorganised notes can be found here [2]. [1] https://www.mediawiki.org/wiki/Icon_standardisation [2] http://etherpad.wikimedia.org/p/Icon_standardisation

2 3

The future of skins
by Jon Robson 09 Sep '14

09 Sep '14

Shahyar, Juliusz, Trevor, Kaldari, Roan and I sat down yesterday and talked about the future of skins. Hopefully this mail summarises what we talked about and what we agreed on. Feel free to add anything, or ask any questions in the likely event that I've misinterpreted something we talked about or this is unclear :) Specifically we talked about how we are unhappy with how difficult it currently is for developers to create a skin. The skin class involves too many functions and does more than a skin should do e.g. manage classes on the body, worry about script tags and style tags. Trevor is going to create a base set of widgets, for example a list generator to generate things like a list of links to user tools. The widgets will be agnostic to how they are rendered - some may use templates, some may not. We identified the new skin system will have two long term goals: 1) We would like to get to the point where a new skin can be built by simply copying and pasting a master template and writing a new css file. 2) Should be possible for us in future to re-render an entire page via JavaScript and using the modern history push state re-render any page via the API. (Whether we'd want to do this is another consideration but we would like to have an architecture that is powerful enough to support such a thing) As next steps we agreed to do the following: 1) Trevor is going to build a watch star widget on client and server. We identified that the existing watch star code is poorly written and has resulted in MobileFrontend rewriting it. We decided to target this as it is a simple enough example that it doesn't need a template. It's small and contained enough that we hope this will allow us to share ideas and codify a lot of those. Trevor is hoping to begin working on this the week of the 2nd September. 2) We need a templating system in core. Trevor is going to do some research on server side templating systems. We hope that the templating RFC [1] can get resolved however we are getting to a point that we need one as soon as possible and do not want to be blocked by the outcome of this RFC, especially given a mustache based templating language can address all our current requirements. [1] https://www.mediawiki.org/wiki/Requests_for_comment/HTML_templating_library

8 14

Flow: Concept work for searching on a board
by Danny Horn 09 Sep '14

09 Sep '14

One of the big things that we have to work on next is searching on a Flow board. It's important for people to be able to easily browse and find the relevant topics, and a busy board will sink older topics pretty quickly. Because each Flow conversation is an individual, discrete unit, we actually have the opportunity to do interesting things, to filter and remix threads in a number of helpful ways. ErikB and I were talking about how to represent Flow search results, and we came up with a model that's based on Gmail search results. It's a very similar use case -- you're searching for keywords in a large body of threaded conversations -- so I think the model is instructive. (See the attached screenshot of Gmail search results for an example.) So I put together a few early concept wireframes, which are also attached. On these wireframes, the exact placement of the elements are entirely hypothetical -- I just wanted to put them somewhere on the page as a starting point for discussion. The user flow is: * A user clicks into the entry field, and types keywords to search for. * This brings up a Gmail-style list of topics that contain that keyword set. This is simple flat keyword matching -- it doesn't weight a match in the topic title more heavily than a match in the posts. * The list of topics is arranged in reverse chronological order, so the user can scan back through time to find the topic they're looking for. (This will be especially helpful for the use case of "Where's that discussion we had about X? It was about two months ago...") * In the list, there's a limited amount of useful metadata. In this wireframe, I tried out showing the number of posts in the thread, and the watch star to indicate threads that you're subscribed to. * The user clicks on a topic title, and navigates to that thread's Topic page, where the matching keywords are highlighted. * On the Topic page, there's a clear way to get back to the list of search results. So -- this is early stuff, just communicating the general direction that I think we should go. What do you guys think? Danny

2 1

Flow: Table of Contents progress
by Danny Horn 09 Sep '14

09 Sep '14

We had a meeting this afternoon to talk about the Table of Contents for Flow boards -- May and Jared (design), Shahyar and Jon (front-end), Danny (product) and Nick (community). The purpose of the Table of Contents is to encourage browsing through topic titles for a quick overview of the discussions on the board, and allow quick one-click navigation from one topic to another. This seems like a simple thing to do, which turns out to be technically more complex than you'd think. :) The core that I think we're agreed on is that the ToC lives in the right rail on desktop (either fixed on its own, or connected to a fixed sort bar, with an icon replacing the current collapse icon). The thing we're trying to figure out right now is the UI when a user jumps to a topic that's further ahead than we can easily load at once. For example: on page load, we load all the posts for topics #1-10. If I scroll down past #10, we lazy-load the next set of topics: #11-20. So, starting at the topic with #1-10 loaded: -- If I click on ToC item #5, then I scroll to that topic, easy. -- If I click on ToC item #15, then we lazy-load 11-20 and scroll to 15, easy. -- If I click on ToC item #37....... we have to figure out how to represent the intervening topics without actually loading the full #11-37 all at once. Shahyar, May and I came up with a possible solution -- loading the intervening topics just as a topic title, similar to our current most-collapsed state. So if I jump from the top to #37, we've got #1-10 fully displayed, then a list of topics from #11-36, and then I scroll down to #37, which I see in full. At that point, if I scroll back up from #37, I'll see just the compressed topic titles. I can click on a compressed topic to open it up. If I use the ToC to jump from #37 back up to #28 (which is currently compressed), then I scroll to #28 and it's automatically loaded for me. That's not perfect, but it's got potential as a next thing to try. May is going to work on some mockups, which we'll look at in the Design check-in meeting on Wednesday. May's card is here: https://trello.com/c/1Mdiy4Fn Danny

4 4

Recommending things to edit
by Steven Walling 05 Sep '14

05 Sep '14

Hi all, I'd love to get some feedback on a new Growth team project: task recommendations for Wikipedia editors. The design specification and background for this is at https://www.mediawiki.org/wiki/Task_recommendations. I also gave a brief introduction to this at the last Foundation Metrics & Activities meeting, viewable at https://www.youtube.com/watch?v=2JbZ1uWoKEg#t=3483 The two prototype recommendation systems are live now on Beta Labs ( en.wikipedia.beta.wmflabs.org). If you edit copies of real articles (like Dog, Cat, or Cheese) you'll get some good results. However, this replica of English Wikipedia is a bit slow, so be patient with us. The next step for this project is to A/B test this with newly-registered users on Wikipedia. Since translations of the interface have been pretty quick (thank you translators!), we'll likely A/B test in at least English, German, and French, if not other languages too. We've done some usability testing, including at Wikimania, but we need to run a randomized experiment to give us a first look at whether these recommendations can have a positive impact on new editor productivity and retention. Right now, the main goal of the recommendations we've built is to get someone who's made their first few edits to keep going. That's why it only looks at the last article you edited, and makes recommendations off of that. In the future, we might consider doing something more sophisticated, such as combing through your entire edit history to recommend articles. We hope that we can build something which can be continually useful for a content contributor as they get more experienced. Thanks, -- Steven Walling, Product Manager https://wikimediafoundation.org/

7 21

Flow scrum notes, Fri Aug 29.
by Danny Horn 02 Sep '14

02 Sep '14

Some people are out for the long weekend/overseas: Erik, Jon, Matthias. *Benny*: Bug in notifications from Echo changes (new users don't get notifications). The patch is merged to the branch but not to master. He'll merge it. Working on script to delete old notifications. Conv about when to delete notifs. S created a bug, Danny will check in. Worked on performance issues -- it should be better at Mediawiki now, if we see it slow now, we should report it. today -- more tests on the old notifs script. What's up with "no formatting defined for notification error"? It's not logged, we can't find it. Benny will try to investigate more. Danny will test out having lots of notifs, see if we can reproduce. *Shahyar*: Working on mw-ui standardization.

3 3

Echo regression - new users are not getting notifications
by Jon Robson 29 Aug '14

29 Aug '14

Good news - Echo has a working browser test suite Bad news - we broke something (but this is why we now have browser tests and why they are a good thing :-)) Now if a user registers they get no notification - see https://bugzilla.wikimedia.org/show_bug.cgi?id=70139 I will leave S and Danny to work out how important this is to fix, or hopefully a patch will come from the community :-).

4 3

Re: [EE] [Design] Standardising icons across projects
by James Forrester 28 Aug '14

28 Aug '14

On 28 August 2014 11:22, Max <max(a)koehler-kn.de> wrote: > You're welcome. Do you guys have a grunt workflow set up? I'd love to help > out. > Yes, here for OOjs UI <http://git.wikimedia.org/blob/oojs%2Fui.git/HEAD/Gruntfile.js> – we'd definitely welcome suggestions and patches. :-) J. -- James D. Forrester Product Manager, Editing Wikimedia Foundation, Inc. jforrester(a)wikimedia.org | @jdforrester

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

EE August 2014