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
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.
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
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
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
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
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
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/
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
>
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.