EE September 2014

ee@lists.wikimedia.org

31 participants
49 discussions

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

Flow scrum notes, Tues Sept 9
by Danny Horn 09 Sep '14

09 Sep '14

We backported bug fixes to Mediawiki yesterday afternoon -- those look stable and helpful, so we're pushing it to enwiki this afternoon, as per previous emails. Those seem to be the most urgent fixes, and I think they'll help to remove distractions that have been bothering people since Thursday. We're continuing to work on some more Echo and Monobook bugs; those will go to Mediawiki on Thursday, and then enwiki the following Thursday. If something urgent gets reported that today's deploy doesn't fix, then we can talk about accelerating. Reminder for team members: Check out the bug triage list that Jon sent; let him know if you're having trouble working through the list. *Matthias*: Reviewed & merged for some X patches, backwards compatibiltiy Worked on Close --> Lock text change Has a question about the modal in Monobook -- needs to check with Shahyar or Jon. *Benny*: Yesterday, worked on X cards and backporting to Mediawiki Working on G-101 (order unread notifs by reverse chronology) -- still concerned about the performance issue. (Post-scrum update: We came up with a new idea that connects G-101 with the script to clear old notifications. The script will be set to clear the oldest notifications when the # of read + unread items goes above 5,000). *Jon*: Worked on H-5 (take Reply links off Locked posts), H-9 (Show Topic pages uncollapsed). These are in code review. One of the Alerts changes that we backported yesterday caused a regression -- Jon will fix the unit test. Questions about the watch star-related bugs -- should we rethink using a different star for board pages? We're now building hacks upon hacks. (Post-scrum update: S created a spike to research this -- we need to know the relative cost of making these bug fix/hacks vs making the functionality work in the regular location.) *Shahyar*: Has working code for the modal, a little hacky because of the way we handle Flow containment stuff. we assume that anything Flow created appears inside a Flow widget. but we have elements created outside of the board, but belong to the board. Adjusting our JS and markup so that we can create elements that are outside of the normal workflow, like modals, but they're assigned to the Flow board. Still working on Notifications -- topic title should be easier to read. Should get a Gerrit patch up today. Tomorrow -- in transit going back home -- he'll be unavailable tomorrow. Erik: Yesterday -- all backporting and bug fixes, and hooray. Today -- lots of code review.

1 0

Re: [EE] moderation in Flow
by svetlana 09 Sep '14

09 Sep '14

i apparently have mail client issues so i can't reply properly ... S Page, yes I agree that protect should be more user friendly -- i think it should also not let anyone edit at all -- page is /protected/ . but what should be the process for debating a past consensus ? anyone can do this, right now? maybe we actually should DO lock ... i mentally come back to the 'message types' concept where a folk can say 'this message formally declares a reached consencus' which puts warnings as appropriate - with (reasonably subtle) means to challenge it... similarly to 'this message solves the problem'... show it in topic subtitle: '5 comments, 1 solution', '5 comments and consencus' ... i think people should be able to define such message types on-wiki (and what they do) in a flexible way without locking down a topic completely but with possibly changing its appearance 'i locked your topic' sounds like a much much more horrid thing than 'i think your topic has a new msg about reached consencus' or 'i think your topic has an msg that solves the problem'... because 'locked' is too generic and puts the whoever-locked-the-topic into a non-collaborative position, but a position of power, which is imo against wiki philosophy... svetlana

2 1

Current status on Flow/Echo changes
by Danny Horn 09 Sep '14

09 Sep '14

Hi, here's an update on the Flow and Echo changes that went out on Thursday to enwiki. We released the new version of Flow/Echo code to enwiki earlier than we should have. There are bugs, and features that aren’t fully cooked. I’m sorry that we pushed this out too fast, and created some irritating distractions that got in the way of people’s editing work. Having read lots of feedback and seen the reported bugs, we talked as a team about whether to roll back the latest version, or move forward with bug fixes and retuned features. Rolling back would probably cause more problems than it would solve -- some of the reported bugs are already fixed on Mediawiki, so we can get things on enwiki fixed faster if we deploy those, rather than roll back to a week ago. Our plan is to backport some more fixes to Mediawiki later today, and if those are stable, then we’ll move them to enwiki tomorrow afternoon. Meanwhile, there are two things that you can do if you’re finding the current system too distracting right now: * There is and will be a lot of testing done on the test/sandbox boards. If you’re getting bothered by notifications to those boards, it’s probably a good idea to stop watching them for now. * You can also turn off Echo notifications for Flow in your preferences. (There’s still one bug that shows up even if you’ve turned them off -- it’s in the list below.) Here’s the current status, as I know it right now. The following items are planned for Mediawiki later today, and then enwiki tomorrow: * Make the Alerts tab the default when you open the flyout, unless you’ve only got new Messages notifications and no new Alerts. * Email notifications bundled per topic, limited to once every four hours. * Bundling “created a new topic” Echo notifications, so you don’t get multiple notifications for the same board at once. * “No formatting for notification” errors displayed in the notifications flyout. Other bugs we’re fixing, but may not be out tomorrow: * If you’ve never had Flow notifications, don’t make the Alerts link clickable. * Swap the color of the Messages and Alerts tabs, so the clickable link is blue. The active tab shouldn’t be clickable. * Monobook: Can’t hide topics, because the modal dialog is grayed out. * When you create a Flow topic and mention a user in the first post, that user gets two identical notifications. * With Flow notifications turned off in preferences, a mention on a Flow post still sends a notification. * Monobook: Messages/Alerts text in flyout is too small. * Monobook: Page tabs are not clickable on Flow boards. * Monobook: Watch star on Flow boards is in the wrong place. There’s a balance between responding to questions and actually getting fixes and features tested and out -- so we might be slower in answering some questions. We’ll keep everybody updated as much as we can, and we really appreciate all of the feedback, ideas, and bug reports. Danny

3 3

Re: [EE] upcoming changes to Flow moderation and undo
by svetlana 09 Sep '14

09 Sep '14

Hi, FYI I'm not very satisfied with these plans. They are not in line with existing feedback, partly, and partly are not in line with the practices I've observed at various on-wiki village pumps. Please look at https://www.mediawiki.org/wiki/Flow/Prior_discussion-thread-roundup#Post_Mo… a bit more. I would like to encourage more thought put into this while performing programming work. And put early. S Page wrote: > * To deal with spam topics and posts, we're going to append "(hide)" > (and delete | suppress for admins) to "created new topic"/"commented" lines on > board and topic history pages. These will work the same as > hide|delete|suppress actions do on Flow board and topic pages. "Concerns about access to viewing or editing others' posts" in the link I gave has a bunch of topics about this. Looks like people want anyone to be able to delete others' comments. I haven't seen this as a problem for years. Please don't restrict delete to admins. (Suppress is another story and limiting it to admins makes sense.) S Page wrote: > * We're going to rename Close topic to Lock topic. This better matches what > it actually does, which is prevent new posts and changes (with lots of bugs > currently). To make it more obvious what Lock does, we'll remove the Reply > and Edit links from a locked topic, instead of them failing on submit. > > Note many use case of "This topic is closed" fit well with the Summarize > topic action. People can and should put {{done}}, {{abandoned}}, > {{answered}}, etc. templates and markup in a topic's summary. This wasn't discussed with people at Talk:Flow before, but I plainly think that's a wrong way to do it. The reason is that I follow-up a resolved topic rather often. "Hi this template is broken" "I fixed it in this edit" "thanks!" "[locks thread]" - and then I want to ask how to fix another one a day later, I tried the same fix but it didn't work?? I should spend hours of my time pressing UNLOCK when nothing should have locked it in the first place??? Hm. On the other side, with Flow, we don't have archives. We don't want old topics to resurface with 'thanks!' and go all way to the top of 'recently active' list. OK, please redesign the LOCK feature a little. :-) 0) Please add a 'this answer solved the problem' button - anyone should be able to click it. It could go to 'this topic has 3 comments and 1 solution' subtitle in the topic title. 1) When a thread is active recently (less than N days), it can't be locked. People are able to follow-up within the same thread. 2) When a thread is inactive recently (active more than N days ago), it's automatically archived. This means it takes extra effort (and warnings dumped onto your head) when you try to reactivate it. 3) The number "N" should depend on a page activity. If a talk page of an article is dead, it makes no sense to archive anything, even if it's a year old. 4) It should be possible to 'HAT' a topic if it's inflammable before the N days time. I hope this will ease usability too - it's much easier to click a specific message and click "it solves the problem" than go through the process of locking down the entire thread. Related topics: https://www.mediawiki.org/wiki/Topic:S0duk9t3t90a4c67 - Stop making reply impossible to closed topics https://www.mediawiki.org/wiki/User:Gryllida/Flow - thoughts on moderation in Flow - DONTs: "Nothing should prevent anyone from replying to a message under any circumstances." > > > We'll probably begin developing these in the next two-week sprint. > Hope this helps. > -- > =S Page Features engineer svetlana

5 8

Re: [EE] [Wikitech-l] Is simplicity is the key to success of Echo and Watchlist?
by S Page 09 Sep '14

09 Sep '14

On Fri, Sep 5, 2014 at 3:33 AM, Michał Łazowik <mlazowik(a)me.com> wrote: > Wiadomość napisana przez Danny Horn <dhorn(a)wikimedia.org> w dniu 5 wrz > 2014, o godz. 02:00: > > > Rather than going directly to the topic page, the bundled "new topic" > > notifications will take you to the board, sorted by newly-created topics. > > The plus, obviously, is that you get fewer notifications; the minus is > that > > you may need to scroll down on the board to make sure you don't miss > > something. > > Maybe mark unread messages somehow? Some vertical line on the right/left > maybe? > You mean like the way the "UserName and three others responded" notification of new posts on a topic highlights the new posts? (try it e.g. < https://www.mediawiki.org/wiki/Topic:S12prb6trf24nhkz?fromnotif=1#flow-post… >) The "3 new topics on Talk:Sandbox" notification could do something similar, showing a vertical line next to the title bars of new posts. We could add a "Highlight all posts newer than this" to each post's action menu, but it feels a bit esoteric. User JS or a gadget could easily do it. Regards, -- =S Page Features engineer

1 0

moderation in Flow
by svetlana 08 Sep '14

08 Sep '14

I had previously posted suggesting to rename Lock to Archive. I apologise, this feature is not needed at all. It should only be needed where a discussion is quite permanently closed per policy (such as a past request for permissions). In this case, such thread should be simply protected using the standard page protection tools available to sysops. I worked out some more suggestions here: - https://www.mediawiki.org/wiki/Thoughts_on_moderation_in_Flow -- svetlana

2 1

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

Re: [EE] [Wikitech-l] Is simplicity is the key to success of Echo and Watchlist?
by Danny Horn 05 Sep '14

05 Sep '14

The new version of Flow and Echo on Mediawiki.org right now is the team's first draft of the new notifications and subscriptions feature. This version definitely has some flaws, and we're going to be re-tuning the system in the next sprint to make it work better. We held back this version from going live to enwiki, because we knew there were some bugs and that we needed to make changes. So here are some notes on where we are, and what we're about to fix: *One notification item per topic* The big advantage that individual subscriptions offers is the ability to focus on the conversations that you're interested in, and tune out the ones that you don't care about. This could be especially helpful for people who are involved in a lot of conversations, because you won't have to keep checking diffs when someone responds to another thread that you're not interested in. But a key point to making that actually work is to only give somebody one notification item per thread. If your Echo icon says 3, it's because there are three separate conversations that have had activity since you last checked (A, B and C). If 100 more people post messages on thread B, then you'll still only get one notification item for that discussion. The number on the Echo icon will only go up to 4 if somebody responds on thread D. This is partly done in the current version, but in one case, we're currently sending two notifications for the same thing. We're going to kill one of them. *Subscribing to a board * We talked a lot on the team about what subscribing to a board means. There are two versions: 1) subscribe to a board = subscribe me to every new topic, or 2) subscribe to a board = notification that a new topic has been created, but don't subscribe me to that topic. In the latest version, we did #1, but we knew it might be too much. This is the kind of thing that you can play with when your product is only deployed on about five active pages on Mediawiki, and one of them is a sandbox. So now we've gotten some really clear feedback that #1 is too much, and it feels like spam. We're going to change this to #2 in the next version, which will probably go out to Mediawiki.org next week. After that, we're still going to be retuning to make sure that the notifications are helpful. One possibility is to combine the notifications about new topics being created -- maybe rolling them up into one notification item, which links to the board with the new topics highlighted. We also need to keep working on the best way to represent this on the Watchlist. Some people only (or primarily) use Watchlists to keep track of conversations, some people only (or primarily) use Echo, and some use both. We want to make it possible to keep track using either tool, but there's going to be a lot of tuning to make it work. *Email notifications* We're also sending *way* too many email notifications right now. We're going to dial that back, and this is actually a good opportunity for me to ask for feedback on how. One idea is to treat Flow emails the way that we treat watchlist emails -- you get one email for the first post on a topic that you subscribe to, and then we don't send any more emails about that thread until you visit the page. Another version is to use email bundling, where we send the first email about a topic, and then bundle any following notifications every four hours. Right now, the plan is to try the four-hour bundling version next, but I'd be happy to hear people's thoughts about it. So I hope this helps to explain what's going on -- what you're seeing right now is not at all a final version that will be rolling out as default to the universe. :) Both the Echo notifications and the watchlist are really important to me and the team. Individual subscriptions and notifications have the potential to make wiki discussions a lot more efficient for active users, but we need to find the ways to be helpful and not annoying. It's going to take us a few iterations before we get to that sweet spot. I'm sorry that we've caused some headaches this week -- we'll get another iteration out, and we're going to keep the experimental stuff contained to Mediawiki.org while we're making these changes. We'll keep talking about what's going on, feel free to ping me with ideas or questions or complaints. Danny On Tue, Sep 2, 2014 at 10:17 AM, Ryan Kaldari <rkaldari(a)wikimedia.org> wrote: > Ah, I just tried using Flow on mediawiki.org. Now I understand what > everyone's talking about. > > This is definitely not how Echo was intended to be used. The Echo scope > definition[1] on mediawiki.org specifically says that it is not to be used > for watchlist items. The developer guide also says that new notifications > should be opt-in by default unless they are critical.[2] > > 1. https://www.mediawiki.org/wiki/Echo_%28Notifications%29#Scope > 2. > > https://www.mediawiki.org/wiki/Echo_%28Notifications%29/Developer_guide#Con… > > Ryan Kaldari > > > On Tue, Sep 2, 2014 at 8:08 AM, Derric Atzrott < > datzrott(a)alizeepathology.com > > wrote: > > > >>> - *it* *doesn't* *scale* (constantly seeing a "(3)" or new emails pop > > up > > >> if you're active in ~6 discussions is a pain) > > >> > > >> OK, so how do you suggest changing it? > > >> > > >>> - _nothing_ on-wiki ever warrants an urgent reaction ever > > >> All the community members who clamored for the return of the Orange > Bar > > of > > >> Death seem to disagree with you. > > >> > > > You use the past tense. I *still* clamor for the Orange Bar of Death. > > > > Agreed! I participate in a fair number of discussions pretty regularly, > > and > > being notified of mentions and pings is probably my favourite thing about > > echo. Perhaps I am just a WP:Wikipediholic, but there are definitely > > things > > that happen on-wiki that warrant urgent reactions. > > > > Just last night I accidentally screwed up someone's talk page and I'm > very > > happy for the notification that I was left a message ("What the hell were > > you doing in this edit?!?") so that I could revert my edit quickly and > > apologise. > > > > > To me, the answer is obvious: pull messaging out of echo, and summarize > > > notifications on echo for the remaining notifications (i.e. if a > > > notification for a given page is already sitting unread, don't bump the > > > number, and replace the message with "x AND y have happened on z". For > > > messages, give us back the OBOD. > > > > This is actually a good idea. You could have the individual items listed > > on Special:Notifications and just have the summarized items under the > list > > in echo. > > > > >>> - Echo is a consequence of a watchlist page which many people find > > >>> insufficiently informative, intuitive, or easy to control. > > >> > > >> Yes, the watchlist page needs a total overhaul. Notifications aren't > > >> necessarily about articles though. We considered having Echo > integrated > > >> into the watchlist, but this would have make the project much more > > complex > > >> and politically contentious. As you say below, "simplicity is the key > to > > >> success". > > > Don't get that. > > > > You can't change things too much without it becoming politically > > contentious. > > One needn't look any further than the Mediaviewer controversy to see > that. > > I'm sure there are other reasons as well that I am unaware of. > > > > > I want Flow notifications if someone replies to me, or mentions me in > > > a talk post. Or even for everything if that Flow board would happen to > > > be my own talk page for instance. BUT, that is separate from watching > > > a page. > > > > > > Normally, when watching a page, I would not want notifications on > > > every page that I visit, for every reply to every post, new post or > > > retitled post. I want to see what the last major changes were. Mostly, > > > new topics, and the last change to a new topic. > > > > > > Currently, I feel like Echo is forcing me to consume Flow discussion, > > > where rather, I only want to be 'subscribed' to them and then consume > > > the subscription at the moment that I feel comfortable doing that. It > > > is like it is mixing my mailbox with my newspaper... > > > > I haven't played around with Flow yet, but if that is how Flow integrates > > into Echo, I can definitely see that being a huge complaint from a ton of > > people. I'd find that somewhat annoying too. > > > > Thank you, > > Derric Atzrott > > > > > > _______________________________________________ > > Wikitech-l mailing list > > Wikitech-l(a)lists.wikimedia.org > > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > > > _______________________________________________ > Wikitech-l mailing list > Wikitech-l(a)lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l >

2 2

Flow scrum notes, Thurs Sept 4
by Danny Horn 04 Sep '14

04 Sep '14

Sprint H kickoff is today! *Benny*: Worked on G-11 -- adding topic name to create a new notification (G-11). Jon has a comment, Benny will address that feedback. Also - Hidden topic: Clicking on the History link from Watchlist throws a fatal error. (S suggests a browser test.) Update user contribs to make it consistent. Fixed reverse chronology in unread notifications. (G-101) He'll talk to Erik about performance concerns. Today -- address feedback in his patches. *Matthias*: Most of the day bug triaging Wanted to start working on G-3a (preview in no-JS edit/reply/add), but discovered a regression with recent merged code & fixed it. Already merged the fixed patch. Will work on Search, based on Danny's wireframes for now. *Erik*: Removed auto-subscription from watching a board Idea for bundling new topic notifications -- just link to the board, with new topics sorting. This is a good idea -- just needs to check with Benny (for G-14) and Danny Jon had found a problem with handlebars, fixed it *Shahyar*: Working on generic modal dialog -- writing an email to send out about it Today - Go through all the To-Dos in the code, making a list to figure out what we should tackle for the next iteration Also go through Gerrit and review Jon's patches *S*: Some regressions reported by Jon -- S can't reproduce the Mark all as read problem, it's rendering correctly on Beta.

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

EE September 2014