LiquidThreads - how do we kill it?

classic Classic list List threaded Threaded
47 messages Options
123
Reply | Threaded
Open this post in threaded view
|

LiquidThreads - how do we kill it?

Danny Horn
The Flow team is going to work in a few weeks on automatically archiving
talk pages, so that we can enable Flow on pages where there are already
existing conversations. Basically, this means moving the old discussions on
an archive page, and leaving a link for "See archived talk page" visible on
the new Flow board.

That means there'll be a minute where a currently active discussion would
get interrupted, and have to be restarted on the new Flow board. That will
be a pain, but it would only be a one-time inconvenience during that
transition moment.

The team's goal for LiquidThreads transition is essentially the same --
turning the existing conversations into a form that we can archive, and
preserve for the future. If we tried to turn ongoing LQT discussions into
ongoing Flow discussions, we'd actually be spending more development time
on archiving the deprecated feature than we would spend on archiving wiki
talk pages.

There's a few more big features for Flow that we're working on this summer;
we'll have some new things to show off pretty soon.

Danny
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: LiquidThreads - how do we kill it?

Juergen Fenn-3
2014-06-06 0:16 GMT+02:00 Danny Horn <[hidden email]>:

> The Flow team is going to work in a few weeks on automatically archiving
> talk pages, so that we can enable Flow on pages where there are already
> existing conversations. Basically, this means moving the old discussions on
> an archive page, and leaving a link for "See archived talk page" visible on
> the new Flow board.
>
> That means there'll be a minute where a currently active discussion would
> get interrupted, and have to be restarted on the new Flow board. That will
> be a pain, but it would only be a one-time inconvenience during that
> transition moment.

Interesting point. Thanks for keeping us up to date. You might like to
know, though, that on German Wikipedia most discussions about Flow
seem to focus on how to turn it off or how to keep it out of the
project altogether. Switching to Flow would require a community
consensus anyway. So could you please consider a global switch for
communities that would rather like to disable these new features
completely.

Regards,
Jürgen.

PS. We have never enabled the LiquidThreads extension neither. And the
new Beta link up right did not stay there for long.

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: LiquidThreads - how do we kill it?

Gerard Meijssen-3
Hoi,
While some may think it perfectly ok to be contrary and argue vehemently to
keep old hat technology operational for them and everyone around them, I
wonder if they consider cost and consequences.
* Cost to maintain duplicate and increasingly feature incompatible
functionality
* Cost to the users who are appalled by the archaic software they have to
suffer
* Cost to the increased problem of recruiting new contributors.

When I read what is said, it gives me a really bad impression of what
"community" means. It is a priori not positive at all when you argue for a
blanket switch  to disable new features.

I find it impossible to argue to our donors that the additional money spend
in keeping ancient software alive is well spend.
Thanks,
      Gerard


On 6 June 2014 01:24, Juergen Fenn <[hidden email]> wrote:

> 2014-06-06 0:16 GMT+02:00 Danny Horn <[hidden email]>:
> > The Flow team is going to work in a few weeks on automatically archiving
> > talk pages, so that we can enable Flow on pages where there are already
> > existing conversations. Basically, this means moving the old discussions
> on
> > an archive page, and leaving a link for "See archived talk page" visible
> on
> > the new Flow board.
> >
> > That means there'll be a minute where a currently active discussion would
> > get interrupted, and have to be restarted on the new Flow board. That
> will
> > be a pain, but it would only be a one-time inconvenience during that
> > transition moment.
>
> Interesting point. Thanks for keeping us up to date. You might like to
> know, though, that on German Wikipedia most discussions about Flow
> seem to focus on how to turn it off or how to keep it out of the
> project altogether. Switching to Flow would require a community
> consensus anyway. So could you please consider a global switch for
> communities that would rather like to disable these new features
> completely.
>
> Regards,
> Jürgen.
>
> PS. We have never enabled the LiquidThreads extension neither. And the
> new Beta link up right did not stay there for long.
>
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: LiquidThreads - how do we kill it?

Nick Wilson (Quiddity)
In reply to this post by Juergen Fenn-3
On Thu, Jun 5, 2014 at 4:24 PM, Juergen Fenn <[hidden email]>
wrote:

> 2014-06-06 0:16 GMT+02:00 Danny Horn <[hidden email]>:
> > The Flow team is going to work in a few weeks on automatically archiving
> > talk pages, so that we can enable Flow on pages where there are already
> > existing conversations. Basically, this means moving the old discussions
> on
> > an archive page, and leaving a link for "See archived talk page" visible
> on
> > the new Flow board.
> >
> > That means there'll be a minute where a currently active discussion would
> > get interrupted, and have to be restarted on the new Flow board. That
> will
> > be a pain, but it would only be a one-time inconvenience during that
> > transition moment.
>
> Interesting point. Thanks for keeping us up to date. You might like to
> know, though, that on German Wikipedia most discussions about Flow
> seem to focus on how to turn it off or how to keep it out of the
> project altogether. Switching to Flow would require a community
> consensus anyway. So could you please consider a global switch for
> communities that would rather like to disable these new features
> completely.
>
> Regards,
> Jürgen.
>
> PS. We have never enabled the LiquidThreads extension neither. And the
> new Beta link up right did not stay there for long.
>


Flow has to be improved further until reaching a state where it will be
deployed generally. That tipping point is not going to be soon, and will be
at different times on various wikis.

During the process of getting there, the team needs as much patient and
insightful feedback as we can collectively give them, regarding what
existing features we need to match (along with examples and edge-cases) and
what new features we'd love to have created. It aims to result in something
better for newcomers *and* better for all types of poweruser. Just like VE,
it's an epic-scale and long-term project, that has to be deployed step by
step as VE should have been instead of its quick early introduction.

Slow and steady feedback at the talkpage
<https://www.mediawiki.org/wiki/Talk:Flow>, over the months and years
ahead, is much appreciated.

--
Quiddity / Nick
Community Liaison
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: LiquidThreads - how do we kill it?

S Page-3
In reply to this post by Juergen Fenn-3
On Thu, Jun 5, 2014 at 4:24 PM, Juergen Fenn <[hidden email]>
wrote:

> You might like to
> know, though, that on German Wikipedia most discussions about Flow
> seem to focus on how to turn it off or how to keep it out of the
> project altogether. Switching to Flow would require a community
> consensus anyway. So could you please consider a global switch for
> communities that would rather like to disable these new features
> completely.
>

Technically, the Flow extension first has to be installed on a wiki, and
then Flow is enabled on particular talk pages or classes of talk pages on
that wiki (currently 18 pages on production wikis). After a mis-step on
meta-wiki, we seek consensus on both steps. Currently both are PHP changes;
the Flow team is figuring out how the second will work in the future. We
have no plans to install Flow on German Wikipedia let alone on any
particular talk page, so your discussions can focus on other issues.

The tone of your message made me want to cry, quit my job, and punch the
wall in frustration  :(  But I appreciate you being open about your dislike
and suspicion of Flow, and can only hope that over time Flow's growing
feature set leads users to *want* it enabled on the talk pages they visit.

--
=S Page  Core Features (Flow) engineer
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: LiquidThreads - how do we kill it?

Juergen Fenn-3
2014-06-06 22:28 GMT+02:00 S Page <[hidden email]>:

> The tone of your message made me want to cry, quit my job, and punch the
> wall in frustration  :(

I am sorry, S, this is certainly not what I intended. I apologise for
the tone of my last mail.

> But I appreciate you being open about your dislike
> and suspicion of Flow, and can only hope that over time Flow's growing
> feature set leads users to *want* it enabled on the talk pages they visit.

The most important point about everything new the WMF is currently
developing is that it really can frustrate and drive away even more
old editors. The WMF only talks about new editors, but does not take
into account that we need to keep the old ones in the first place.

@Gerard: Losing old editors is the biggest cost of all those changes.
This is why we have to keep these as small as possible and we have to
avoid them wherever possible. There always has to be a switch for
disabling everything new and to return to the old state.

To give you some more background: Our community has suffered a lot of
stress over the past years which results in frustration in many
places. Many long-time editors have gone inactive because of that.
Some of the stress is self-made, some came in from the German chapter,
mostly last year (this will hopefully change now), and some of the
stress comes from San Francisco. The latter stems mostly from new
developments in technical terms. Remember that this is only a small
community of only a few hundred regulars, and that we had to fight
against visual editor, and when media viewer was announced the first
question was whether it would still be possible to switch it off when
it would not be beta any more. Many of us are exhausted and tired to
fight against the Wikimedia bodies.

That's why I interfere when there is talk about Flow. Both visual
editor and flow have the potential of providing another and perhaps
final blow to the still active old editor community. There is only one
community. We don't have another one as substitutes to take over. If a
wiki project is dead and broken once it will be broken forever.

Regards,
Jürgen.

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: LiquidThreads - how do we kill it?

Arcane 21
Going to have concur on this. Flow and VE would be great for attracting new users, but leaving the foundation of the community in the dust in favor of innovation strikes me as a bad idea.

I support the idea of having the ability for the old methods of editing and talk pages to work when and where possible and for the transition to newer ideas to be as gentle as possible on those who might otherwise be alienated by the changes.

> Date: Sat, 7 Jun 2014 02:39:17 +0200
> From: [hidden email]
> To: [hidden email]
> Subject: Re: [Wikitech-l] LiquidThreads - how do we kill it?
>
> 2014-06-06 22:28 GMT+02:00 S Page <[hidden email]>:
>
> > The tone of your message made me want to cry, quit my job, and punch the
> > wall in frustration  :(
>
> I am sorry, S, this is certainly not what I intended. I apologise for
> the tone of my last mail.
>
> > But I appreciate you being open about your dislike
> > and suspicion of Flow, and can only hope that over time Flow's growing
> > feature set leads users to *want* it enabled on the talk pages they visit.
>
> The most important point about everything new the WMF is currently
> developing is that it really can frustrate and drive away even more
> old editors. The WMF only talks about new editors, but does not take
> into account that we need to keep the old ones in the first place.
>
> @Gerard: Losing old editors is the biggest cost of all those changes.
> This is why we have to keep these as small as possible and we have to
> avoid them wherever possible. There always has to be a switch for
> disabling everything new and to return to the old state.
>
> To give you some more background: Our community has suffered a lot of
> stress over the past years which results in frustration in many
> places. Many long-time editors have gone inactive because of that.
> Some of the stress is self-made, some came in from the German chapter,
> mostly last year (this will hopefully change now), and some of the
> stress comes from San Francisco. The latter stems mostly from new
> developments in technical terms. Remember that this is only a small
> community of only a few hundred regulars, and that we had to fight
> against visual editor, and when media viewer was announced the first
> question was whether it would still be possible to switch it off when
> it would not be beta any more. Many of us are exhausted and tired to
> fight against the Wikimedia bodies.
>
> That's why I interfere when there is talk about Flow. Both visual
> editor and flow have the potential of providing another and perhaps
> final blow to the still active old editor community. There is only one
> community. We don't have another one as substitutes to take over. If a
> wiki project is dead and broken once it will be broken forever.
>
> Regards,
> Jürgen.
>
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
     
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: LiquidThreads - how do we kill it?

Juergen Fenn-3
2014-06-07 2:44 GMT+02:00 Arcane 21 <[hidden email]>:
> Going to have concur on this. Flow and VE would be great for attracting new users, but leaving the foundation of the community in the dust in favor of innovation strikes me as a bad idea.
>
> I support the idea of having the ability for the old methods of editing and talk pages to work when and where possible and for the transition to newer ideas to be as gentle as possible on those who might otherwise be alienated by the changes.

Again, I would like to invite you to think twice. I talked about the
psychological foundation for participating in such a large project as
Wikipedia. It needs tact not to harm an already suffering community
when such sweeping changes should be introduced.

No one has ever asked for our opinion whether we want this or not. It
is decided over our head, par ordre de mufti. Most of us insist on
community processes taking place for introducing new technology on
such a big scale, not in order to deactivate it.

Again, this is all about breaking a community. And we cannot discuss
this in terms of what is good or bad because you cannot revert the
negative impact new technology will have on old editors. This is not
only about technology. It's about psychology. And the latter will
prevail.

Regards,
Jürgen.

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: LiquidThreads - how do we kill it?

Max Semenik
So you propose to never ever change the look and feel because it might piss
off some old-timers?


On Fri, Jun 6, 2014 at 6:01 PM, Juergen Fenn <[hidden email]>
wrote:

> 2014-06-07 2:44 GMT+02:00 Arcane 21 <[hidden email]>:
> > Going to have concur on this. Flow and VE would be great for attracting
> new users, but leaving the foundation of the community in the dust in favor
> of innovation strikes me as a bad idea.
> >
> > I support the idea of having the ability for the old methods of editing
> and talk pages to work when and where possible and for the transition to
> newer ideas to be as gentle as possible on those who might otherwise be
> alienated by the changes.
>
> Again, I would like to invite you to think twice. I talked about the
> psychological foundation for participating in such a large project as
> Wikipedia. It needs tact not to harm an already suffering community
> when such sweeping changes should be introduced.
>
> No one has ever asked for our opinion whether we want this or not. It
> is decided over our head, par ordre de mufti. Most of us insist on
> community processes taking place for introducing new technology on
> such a big scale, not in order to deactivate it.
>
> Again, this is all about breaking a community. And we cannot discuss
> this in terms of what is good or bad because you cannot revert the
> negative impact new technology will have on old editors. This is not
> only about technology. It's about psychology. And the latter will
> prevail.
>
> Regards,
> Jürgen.
>
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>



--
Best regards,
Max Semenik ([[User:MaxSem]])
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: LiquidThreads - how do we kill it?

Juergen Fenn-3
2014-06-07 3:11 GMT+02:00 Max Semenik <[hidden email]>:
> So you propose to never ever change the look and feel because it might piss
> off some old-timers?

To sum it up for tonight, I was speaking about tact and psychology in
the first place. And I said that this is not about some old-timers,
but about the bulk of our community. The heart of this project is
comprised of some 300 to 400 editors you cannot substitute.

Regards,
Jürgen.

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: LiquidThreads - how do we kill it?

Risker
In reply to this post by S Page-3
On 6 June 2014 16:28, S Page <[hidden email]> wrote:

> On Thu, Jun 5, 2014 at 4:24 PM, Juergen Fenn <
> [hidden email]>
> wrote:
>
> > You might like to
> > know, though, that on German Wikipedia most discussions about Flow
> > seem to focus on how to turn it off or how to keep it out of the
> > project altogether. Switching to Flow would require a community
> > consensus anyway. So could you please consider a global switch for
> > communities that would rather like to disable these new features
> > completely.
> >
>
> Technically, the Flow extension first has to be installed on a wiki, and
> then Flow is enabled on particular talk pages or classes of talk pages on
> that wiki (currently 18 pages on production wikis). After a mis-step on
> meta-wiki, we seek consensus on both steps. Currently both are PHP changes;
> the Flow team is figuring out how the second will work in the future. We
> have no plans to install Flow on German Wikipedia let alone on any
> particular talk page, so your discussions can focus on other issues.
>
> The tone of your message made me want to cry, quit my job, and punch the
> wall in frustration  :(  But I appreciate you being open about your dislike
> and suspicion of Flow, and can only hope that over time Flow's growing
> feature set leads users to *want* it enabled on the talk pages they visit.
>
>
Spage, please don't take the criticism of the product to be a criticism of
you or your own work. It's really not about you, or even necessarily about
Flow,  it's about a much bigger picture.

Flow is a product that wasn't asked for, is intended to do things that
people didn't ask it to do, and is a fundamentally different user interface
than the two major ones we already have (Mediawiki and VisualEditor).
Thus, it is adding complexity to the editing experience that does not
currently exist. Mediawiki may be difficult to learn, but it's only one
interface. VisualEditor, an interface the community has been seeking for
over 10 years, gives a visual result that, from the perspective of the
editor, is still a wiki-page; it may work somewhat differently, but it
still looks like a wiki.

There were four problems with talk/discussion pages that users across
multiple communities over multiple years have identified:

   - Automatic signatures for posts/edits
   - More efficient method for indenting that is not dependent on arcane
   wikicode knowledge
   - More graceful handling of edit conflicts
   - Ability to watchlist an individual thread or section of a page

The first two could undoubtedly be done in Mediawiki; we already have bots
that add signatures automatically, for example, and it should be elementary
to create an "indent" button that goes in the same line as the other
editing icons currently in use.  The third point has already had
significant work, although more can be done there.  I have had several
experienced Mediawiki developers say that the fourth point is possible but
very difficult.  In other words, given sufficient focus, effort, talent and
willingness, these issues are all likely to be solvable without creating a
new user interface that wasn't requested and is visually divorced from wiki
editing.  Now, I know it's a lot more interesting and exciting to create
something new than it is to make major renovations to something that
already exists, and I'm pretty sure after all these years that Mediawiki
code is a mess.  But I've increasingly been getting the impression that
there aren't a lot of WMF staff who actually like wikis, let alone
developing Mediawiki core.  (Even if that impression is not correct, it's
out there and it's based on conversations with WMF engineering staff.)

Meanwhile, Flow does automatic signatures, but its current design actually
makes indenting much more problematic from a reader perspective than the
current indenting structure.  It's difficult to tell which post is being
responded to, who's responding to whom, the responses don't thread well,
and it's not possible to rethread a discussion.  Edit conflicts don't
exist, but they result in odd threading of responses. It's not obvious how
to watch specific threads at this point, or how one would make it
possible.   In other words, it's not really doing a great job of solving
three of the four issues that have long been seen as problems.  Meanwhile,
it's introduced new issues, many of which users have identified as
problematic: endless scrolling, inability to archive, inability to
completely remove a thread from a page without actual deletion and/or
suppression, categorization issues, complex process to find, create, and
edit page headers, etc.

There was always an underlying assumption that the benefit of having a
large number of engineers working together under the direction and
leadership of the WMF would result in a much more consistent process for
creating products, better prioritization, and more cross-product
consistency.  Instead, what we are seeing is that each product team is
working in a silo.  Common UI issues are being addressed differently across
products, increasing the complexity of editing for both new and experienced
users.  There's no overall integration of the design process, and there
really doesn't seem to be a serious master plan that goes into detail about
cross-product integration.  Yes, there's the roadmap, but it's all
individual product teams working on their own product, with very little
cross-pollination.  In other words, this is a leadership issue that is
playing out repeatedly across each product line, and it's pretty much the
same issue over and over again, just focused on a different product. It's
not the fault of the back-room engineers; it's at the PM level and above.

Risker/Anne
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: LiquidThreads - how do we kill it?

Erik Moeller-4
Dear Anne,

Thank you for the thoughtful critique.

> There were four problems with talk/discussion pages that users across
> multiple communities over multiple years have identified:
>
>    - Automatic signatures for posts/edits
>    - More efficient method for indenting that is not dependent on arcane
>    wikicode knowledge
>    - More graceful handling of edit conflicts
>    - Ability to watchlist an individual thread or section of a page

Indeed, Flow is designed to address these issues, as well as others:

- Overall reduced user experience latency (time spent loading pages,
positioning the cursor, typing characters, etc.).

- Support for cross-wiki discussions, to reduce fragmentation of conversations.

- Better tools for organizing (e.g. tagging) and searching conversations.

- Making it easy to see what's new/changed, irrespective of watchlisting.

- Simple ways to participate in relevant conversations on mobile devices.

The architecture reflects these combined needs. While it is possible
to incrementally hack away at a single wikitext representation of an
entire discussion, logically, without clear boundaries for each
comment, any kind of functionality that operates at the comment-level
is difficult or impossible to build.

With that said, we will likely experiment with improvements to the
existing talk page model as well, just to see how far we can push it.
The mobile apps team is interested in implementing talk page support
in the apps, and since Flow is still some way out, that may be a good
case study to see what we can do on the basis of the existing wikitext
conversational model.

Flow is intended to be a system that is effective both for new and
experienced users. Everyone working on the system understands that it
cannot succeed if it doesn't serve the needs of experienced users.
This is why we're intentionally designing it in the context of a
gradually increasing number of real-world use cases.

As an example, the Teahouse would be an interesting real-world use
case where both new and experienced users interact. Longer term, high
volume pages like Village Pumps may make for good use cases.

We can measure and compare the characteristics of conversations in
such venues over time. At the most basic level, how many new and
experienced users participate? At the more granular level, how long
does it take users to perform tasks? Only if Flow compares well to
other methods of organizing talk pages, should it be used.

> But I've increasingly been getting the impression that
> there aren't a lot of WMF staff who actually like wikis, let alone
> developing Mediawiki core.

The WMF technical staff is a pretty healthy mix of people with prior
Wikimedia editing experience, people who became Wikimedians on the
job, people who contributed to MediaWiki before, people who've not
contributed to MediaWiki but who've been part of other open source
efforts, and people who're completely new to both Wikimedia and open
source. I'll let them speak for whether they like wikis or MediaWiki
core, but I think a love/hate relationship with both is not uncommon
nor unwarranted. ;-)

> Meanwhile, Flow does automatic signatures, but its current design actually
> makes indenting much more problematic from a reader perspective than the
> current indenting structure.

Flow stores the comments as a structured tree, so it's possible to
build different interfaces for it. I personally don't have a strong
opinion in the threaded vs. flat vs. hybrid debate -- I think we
should pick the system that proves effective and that users will adopt
and embrace. When I originally proposed the (now doomed) LQT effort
nearly 10 years ago (
https://meta.wikimedia.org/w/index.php?title=LiquidThreads&oldid=100760
), I defaulted to a thread view, because that's what I was familiar
with from the forums that I used. Many very successful forums use
either approach.

A strong argument in favor of a flat, chronological view is that it is
just that -- it lets you easily see the most recent comments.
Structure is then supplemented by quoting comments, as I'm doing in
this email, which my mail client renders as part of a flat,
chronologically ordered conversation. In a long thread that spans
multiple screens, quickly noticing the comments that have been added
after a certain date is otherwise difficult.

LQT's implementation actually tries to solve for this -- LQT does deep
threading, and you can track the history of an entire thread, with
highlighting of when comments have been added:
https://www.mediawiki.org/w/index.php?title=Thread:Project:Support_desk/help_to_restore_an_abandoned_wiki&lqt_method=thread_history

Flow, which displays threads with a limited depth, currently shows the
history as a meta-structure, which then gives you access to the
individual comments.
https://www.mediawiki.org/w/index.php?title=Talk:Flow&workflow=rvzy5wgxmdmgbfqa&action=history

Neither user experience feels efficient (nor does mentally parsing a
wikitext diff). It may be possible to create intuitive ways to display
change over time in a thread view -- if folks have seen examples of
that, I'd love to see them.

With that said, rather than maintaining that any given display is
inherently superior, or that a fundamental change is inherently bad, I
think we should formulate changes as testable hypotheses to the
greatest extent possible. Are we increasing readability? Are we
improving the quality of conversations? Are we enabling people to
participate who otherwise would not?

> It's difficult to tell which post is being
> responded to, who's responding to whom, the responses don't thread well,
> and it's not possible to rethread a discussion.

Flow doesn't yet have any kind of quoting functionality, which I think
would be necessary to add even if we ultimately commit to a deeply
threaded default display. It's a hybrid model with limited thread
depth, which arguably gives us some of the drawbacks of threading (no
clear chronological structure) with some of the drawbacks of flat
forums (no consistent reply-level structure). Danny (Flow PM) very
much wants to test different user experiences; it's even possible that
the "best" experience will vary by use case.

> endless scrolling, inability to archive,

The current archiving system for talk pages is an adequate way to
retain the history of conversations, but it doesn't actually make it
very accessible. I can't easily see all posts by a certain author, for
example, and individual threads cannot be categorized or tagged.
Summaries, to the extent that they exist, don't automatically surface
in relevant places.

Suffice it to say that one of the design goals of the Flow project is
very much to build a searchable and understandable history of
conversations. We will want to test different mechanisms and see how
well they function to manage large conversational archives, including
intuitive search tools, tagging of specific threads, etc.

> inability to completely remove a thread from a page without actual deletion and/or
> suppression,

The current "comment corpses" have already been identified as an issue
and we'll experiment with different ways to manage hiding/deletion of
comments.

> complex process to find, create, and edit page headers, etc.

There's an "Edit" button which pops up next to the header when mousing
over it. I agree that discoverability could be improved, and this UI
pattern is also not mobile-friendly. LQT solved this through [Edit↑]
[History↑] [Delete↑] links right next to the header.

> each product team is working in a silo.  Common UI issues are being addressed
> differently across products, increasing the complexity of editing for both new
> and experienced users.

This is absolutely a fair criticism -- there are pretty significant
silo effects in the current org, and mechanisms and venues for
cross-functional conversation and cross-team mobility are lacking.
These are common organizational challenges at times of fast growth,
and ones we're tackling on multiple fronts right now. Specifically
with regard to Flow:

- Flow was always designed with VisualEditor in mind, and already uses
Parsoid as its parser. Having many mini-VE invocations on a single
page is not entirely trivial, but a challenge the team absolutely
wants to take on (currently slated for Q2 in the next fiscal).

- Jon Robson from the Mobile Web team will soon begin day-to-day work
with Flow to help the team develop in a more mobile-oriented fashion,
and also to share code/templates to the greatest extent possible
(currently through an extension shared by both projects).

- The Mobile Web team has recently ported VisualEditor to the tablet
user experience in alpha mode, and in the process, helped uncover and
address issues with VisualEditor's libraries and development
assumptions.

- We're looking into the best ways to resource the mediawiki.ui
efforts for better integration of standard utility libraries,
frameworks, assets, and templates in MediaWiki core, to ensure better
standardization of the user experience.

The main product lines have a pretty clear common through line:
enabling more users to become part of Wikimedia projects and enabling
existing users to work more effectively, by modernizing the user
experience, in partnership with the community. We tend to err on the
side of being bold, but we're also prepared to walk back when we move
too quickly or haven't paid sufficient attention to concerns.

All best,
Erik
--
Erik Möller
VP of Engineering and Product Development, Wikimedia Foundation

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: LiquidThreads - how do we kill it?

Martijn Hoekstra
On Sat, Jun 7, 2014 at 3:51 PM, Erik Moeller <[hidden email]> wrote:


> With that said, we will likely experiment with improvements to the
> existing talk page model as well, just to see how far we can push it.
> The mobile apps team is interested in implementing talk page support
> in the apps, and since Flow is still some way out, that may be a good
> case study to see what we can do on the basis of the existing wikitext
> conversational model.
>
> Flow is intended to be a system that is effective both for new and
> experienced users. Everyone working on the system understands that it
> cannot succeed if it doesn't serve the needs of experienced users.
> This is why we're intentionally designing it in the context of a
> gradually increasing number of real-world use cases.
>
> As an example, the Teahouse would be an interesting real-world use
> case where both new and experienced users interact. Longer term, high
> volume pages like Village Pumps may make for good use cases.
>
> We can measure and compare the characteristics of conversations in
> such venues over time. At the most basic level, how many new and
> experienced users participate? At the more granular level, how long
> does it take users to perform tasks? Only if Flow compares well to
> other methods of organizing talk pages, should it be used.
>
> > But I've increasingly been getting the impression that
> > there aren't a lot of WMF staff who actually like wikis, let alone
> > developing Mediawiki core.
>
> The WMF technical staff is a pretty healthy mix of people with prior
> Wikimedia editing experience, people who became Wikimedians on the
> job, people who contributed to MediaWiki before, people who've not
> contributed to MediaWiki but who've been part of other open source
> efforts, and people who're completely new to both Wikimedia and open
> source. I'll let them speak for whether they like wikis or MediaWiki
> core, but I think a love/hate relationship with both is not uncommon
> nor unwarranted. ;-)
>
> > Meanwhile, Flow does automatic signatures, but its current design
> actually
> > makes indenting much more problematic from a reader perspective than the
> > current indenting structure.
>
> Flow stores the comments as a structured tree


That seems a fundamental mistake. A discussion isn't a tree, it's a dag.
It's possible for a single comment in a discussion to refer to zero or more
earlier comments.

-- Martijn

 It may be possible to create intuitive ways to display

> change over time in a thread view -- if folks have seen examples of
> that, I'd love to see them.
>

If it's sturctured as a tree, you won't be able to catch all context.


>
> With that said, rather than maintaining that any given display is
> inherently superior, or that a fundamental change is inherently bad, I
> think we should formulate changes as testable hypotheses to the
> greatest extent possible. Are we increasing readability? Are we
> improving the quality of conversations? Are we enabling people to
> participate who otherwise would not?
>
> > It's difficult to tell which post is being
> > responded to, who's responding to whom, the responses don't thread well,
> > and it's not possible to rethread a discussion.
>
> Flow doesn't yet have any kind of quoting functionality, which I think
> would be necessary to add even if we ultimately commit to a deeply
> threaded default display. It's a hybrid model with limited thread
> depth, which arguably gives us some of the drawbacks of threading (no
> clear chronological structure) with some of the drawbacks of flat
> forums (no consistent reply-level structure). Danny (Flow PM) very
> much wants to test different user experiences; it's even possible that
> the "best" experience will vary by use case.
>
> > endless scrolling, inability to archive,
>
> The current archiving system for talk pages is an adequate way to
> retain the history of conversations, but it doesn't actually make it
> very accessible. I can't easily see all posts by a certain author, for
> example, and individual threads cannot be categorized or tagged.
> Summaries, to the extent that they exist, don't automatically surface
> in relevant places.
>
> Suffice it to say that one of the design goals of the Flow project is
> very much to build a searchable and understandable history of
> conversations. We will want to test different mechanisms and see how
> well they function to manage large conversational archives, including
> intuitive search tools, tagging of specific threads, etc.
>
> > inability to completely remove a thread from a page without actual
> deletion and/or
> > suppression,
>
> The current "comment corpses" have already been identified as an issue
> and we'll experiment with different ways to manage hiding/deletion of
> comments.
>
> > complex process to find, create, and edit page headers, etc.
>
> There's an "Edit" button which pops up next to the header when mousing
> over it. I agree that discoverability could be improved, and this UI
> pattern is also not mobile-friendly. LQT solved this through [Edit↑]
> [History↑] [Delete↑] links right next to the header.
>
> > each product team is working in a silo.  Common UI issues are being
> addressed
> > differently across products, increasing the complexity of editing for
> both new
> > and experienced users.
>
> This is absolutely a fair criticism -- there are pretty significant
> silo effects in the current org, and mechanisms and venues for
> cross-functional conversation and cross-team mobility are lacking.
> These are common organizational challenges at times of fast growth,
> and ones we're tackling on multiple fronts right now. Specifically
> with regard to Flow:
>
> - Flow was always designed with VisualEditor in mind, and already uses
> Parsoid as its parser. Having many mini-VE invocations on a single
> page is not entirely trivial, but a challenge the team absolutely
> wants to take on (currently slated for Q2 in the next fiscal).
>
> - Jon Robson from the Mobile Web team will soon begin day-to-day work
> with Flow to help the team develop in a more mobile-oriented fashion,
> and also to share code/templates to the greatest extent possible
> (currently through an extension shared by both projects).
>
> - The Mobile Web team has recently ported VisualEditor to the tablet
> user experience in alpha mode, and in the process, helped uncover and
> address issues with VisualEditor's libraries and development
> assumptions.
>
> - We're looking into the best ways to resource the mediawiki.ui
> efforts for better integration of standard utility libraries,
> frameworks, assets, and templates in MediaWiki core, to ensure better
> standardization of the user experience.
>
> The main product lines have a pretty clear common through line:
> enabling more users to become part of Wikimedia projects and enabling
> existing users to work more effectively, by modernizing the user
> experience, in partnership with the community. We tend to err on the
> side of being bold, but we're also prepared to walk back when we move
> too quickly or haven't paid sufficient attention to concerns.
>
> All best,
> Erik
> --
> Erik Möller
> VP of Engineering and Product Development, Wikimedia Foundation
>
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: LiquidThreads - how do we kill it?

Martijn Hoekstra
Oops, sent too soon. More comments below.


On Sun, Jun 8, 2014 at 1:18 AM, Martijn Hoekstra <[hidden email]>
wrote:

>
>> Flow stores the comments as a structured tree
>
>
>

 That seems a fundamental mistake. A discussion isn't a tree, it's a dag at
best. It's possible for a single comment in a discussion to refer to zero
or more earlier comments, and it's also possible for a single comment to
refer to part of an earlier comment, which means a comment isn't an
indivisable node.

>
>
>  It may be possible to create intuitive ways to display
>
>> change over time in a thread view -- if folks have seen examples of
>> that, I'd love to see them.
>>
>
If it's sturctured as a tree, you won't be able to catch all context, ever.



> > It's difficult to tell which post is being
>> > responded to, who's responding to whom, the responses don't thread well,
>> > and it's not possible to rethread a discussion.
>>
>
Indeed, following the wiki model, it should be ok to make technical
mistakes, and those mistakes should be easily fixed by someone else. If you
mess up the graph in an edit, it should not only be possible to fix that
after the fact, but easy.


--Martijn

> _______________________________________________
>> Wikitech-l mailing list
>> [hidden email]
>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>>
>
>
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: LiquidThreads - how do we kill it?

James Forrester-4
On Sunday, June 8, 2014, Martijn Hoekstra <[hidden email]> wrote:

> On Sun, Jun 8, 2014 at 1:18 AM, Martijn Hoekstra <
> [hidden email] <javascript:;>>
> wrote:
>
> >> Flow stores the comments as a structured tree
>
> That seems a fundamental mistake. A discussion isn't a tree, it's a dag at
> best. It's possible for a single comment in a discussion to refer to zero
> or more earlier comments,


Flow stores each discussion as a tree, with a Flow "Board" being a forest
of discussions for precisely this reason.


> and it's also possible for a single comment to
> refer to part of an earlier comment, which means a comment isn't an
> indivisable node.


Hmm. I'm not convinced that there has ever been a successful/useful/good
discussion system that encouraged sub-comment structured replies. In my
experience they are unusable morrasses of confusion. Instead, a lightweight
quoting tool achieves the specificity at the least complexity and greatest
clarity for users.

I could be convinced otherwise, but it'd need to be a fairly stunning
design concept.

J.


--
James D. Forrester
Product Manager, VisualEditor
Wikimedia Foundation, Inc.

[hidden email] | @jdforrester
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: LiquidThreads - how do we kill it?

Krinkle
On 8 Jun 2014, at 17:22, James Forrester <[hidden email]> wrote:
— Krinkle

> On Sunday, June 8, 2014, Martijn Hoekstra <[hidden email]> wrote:
>
>> On Sun, Jun 8, 2014 at 1:18 AM, Martijn Hoekstra <
>> [hidden email] <javascript:;>>
>> wrote:
>>
>>>> Flow stores the comments as a structured tree
>>
>> That seems a fundamental mistake. A discussion isn't a tree, it's a dag at
>> best. It's possible for a single comment in a discussion to refer to zero
>> or more earlier comments,
>
>
> Flow stores each discussion as a tree, with a Flow "Board" being a forest
> of discussions for precisely this reason.
>
>
>> and it's also possible for a single comment to
>> refer to part of an earlier comment, which means a comment isn't an
>> indivisable node.
>
>
> Hmm. I'm not convinced that there has ever been a successful/useful/good
> discussion system that encouraged sub-comment structured replies. In my
> experience they are unusable morrasses of confusion. Instead, a lightweight
> quoting tool achieves the specificity at the least complexity and greatest
> clarity for users.
>
> I could be convinced otherwise, but it'd need to be a fairly stunning
> design concept.
>
> J.
>


Throughout the years I've had to use at many different incarnations of conversation workflows. Such as:
* Inline comments (such as on StackOverflow).
* Issues trackers (like Bugzila or GitHub Issues).
* Mailing threads (as rendered by Gmail or Apple Mail, both for 1-on-1 threads and those from mailing lists).
* Helpdesk ticket systems.
* Disqus.
* Feedback systems (like GetSatisfaction and UserEcho).
* WordPress comments.
* LiquidThreads.
* Your typical 90s-style forum board (like phpBB or vBulletin).
* ..

And I can't really come to any conclusion other than that the user experience is significantly worse when any of these used a tree structure (especially LiquidThreads and forum boards). It always ends up a mess.

Fortunately, most of these have now either exclusively opted for a linear model or have an option to view it as a linear model (I think LiquidThread is the only exception on this list). Some systems, like Disqus and WordPress comments, handle it by only allowing a very limited number of nesting levels, though I'm not convinced this is useful.

I agree with James and feel that having a good system for citing would significantly increase user experience more than any tree structure ever would (and having a tree of any kind always negatively impacts user experience).

-- Timo

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: LiquidThreads - how do we kill it?

Federico Leva (Nemo)
I see traditional email and newsgroup clients missing a bit from
Krinkle's list. Subthreading works perfectly fine in Thunderbird (but
even in Outlook Express!). Indenting is the one characteristic found in
all wiki conversations: subthreading can't be discarded based on gut
feelings.
In my experience shepherding thousands of it.wiki conversations (mostly
on their own subpages), the biggest issue are offtopic and personal
tangents, hence the most important technical feature in wikitext is that
I'm able to easily tell apart, link and move subthreads.

Nemo

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: LiquidThreads - how do we kill it?

Pine W
Can I just chime in briefly and say I am glad this conversation is
happening before Flow goes into production. This is the kind of
conversation that leads to better software, especially when power users
participate in the discussion and influence design decisions long before
software is pushed out the door, and when production team members take the
time to thoughtfully engage in the discussion as they are here. Thanks all.

Pine


On Sun, Jun 8, 2014 at 11:42 PM, Federico Leva (Nemo) <[hidden email]>
wrote:

> I see traditional email and newsgroup clients missing a bit from Krinkle's
> list. Subthreading works perfectly fine in Thunderbird (but even in Outlook
> Express!). Indenting is the one characteristic found in all wiki
> conversations: subthreading can't be discarded based on gut feelings.
> In my experience shepherding thousands of it.wiki conversations (mostly on
> their own subpages), the biggest issue are offtopic and personal tangents,
> hence the most important technical feature in wikitext is that I'm able to
> easily tell apart, link and move subthreads.
>
> Nemo
>
>
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>



--
Pine
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: LiquidThreads - how do we kill it?

Martijn Hoekstra
In reply to this post by James Forrester-4
On Sun, Jun 8, 2014 at 8:22 AM, James Forrester <[hidden email]>
wrote:

> On Sunday, June 8, 2014, Martijn Hoekstra <[hidden email]>
> wrote:
>
> > On Sun, Jun 8, 2014 at 1:18 AM, Martijn Hoekstra <
> > [hidden email] <javascript:;>>
> > wrote:
> >
> > >> Flow stores the comments as a structured tree
> >
> > That seems a fundamental mistake. A discussion isn't a tree, it's a dag
> at
> > best. It's possible for a single comment in a discussion to refer to zero
> > or more earlier comments,
>
>
> Flow stores each discussion as a tree, with a Flow "Board" being a forest
> of discussions for precisely this reason.
>

That takes care of the issues of replying to one comment (a new node in an
existing tree), zero comments (a new root node), but not multiple comments
(which would break the tree).


>
>
> > and it's also possible for a single comment to
> > refer to part of an earlier comment, which means a comment isn't an
> > indivisable node.
>
>
> Hmm. I'm not convinced that there has ever been a successful/useful/good
> discussion system that encouraged sub-comment structured replies.


Current MediaWiki talk pages do this, as well as mailing lists.


> In my
> experience they are unusable morrasses of confusion. Instead, a lightweight
> quoting tool achieves the specificity at the least complexity and greatest
> clarity for users.
>
> I could be convinced otherwise, but it'd need to be a fairly stunning
> design concept.
>
> J.
>

That's precisely my point. Because current talk page discussions are - on
the software level - unstructured, it allows social conventions to do
everything you want it to do structure wise, and to invent new uses as we
go. The domain model is just that complicated that we found that we need
that power in implementation (even if we all(tm)[citation needed] agree
that the current discussion form is pretty horrible UI wise). If you're
going to force a software structure on in it will most likely not be as
powerful[1] as what there is now and represents a trade off without us
having a clear sight of what we will lose, even if we can have a somewhat
clear picture of what we will gain: easier use and navigatability for the
kinds of discussions we do support. Discussing a trade off where only one
side is known is hard.

[1] i.e. a tree structure is far less powerful than what we have now to
approximate the domain, a dag with dividable nodes probably comes closer,
and is already fiendishly complicated to pull off on a UI level. And then I
haven't even gone in to the current practices of taking a comment back by
striking it, which means that nodes aren't only arbitrarily and multiply
dividable, but also mutable over time in a linear(?) history? 'sblood man,
discussions are complicated.

-- Martijn


>
> --
> James D. Forrester
> Product Manager, VisualEditor
> Wikimedia Foundation, Inc.
>
> [hidden email] | @jdforrester
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: LiquidThreads - how do we kill it?

David Gerard-2
In reply to this post by Federico Leva (Nemo)
The key thing about Usenet and email is that the first-class entity
was the individual message - on web forums, the first-class entity is
the thread. On Usenet or email, a "thread" is something strung
together on the fly from the surviving References: headers of whatever
messages have made it as far as you. (This is why Gmane is a bit weird
to use as a forum, even on a mailing list with no messages getting
lost.)

Trees work in places like Reddit or LessWrong, and to some degree on
Slashdot - though the latter lacks the ability to collapse a fruitless
tree in the interface.

Some ramblings on Usenet vs web forums:
http://reddragdiva.dreamwidth.org/566555.html

On 9 June 2014 07:42, Federico Leva (Nemo) <[hidden email]> wrote:

> I see traditional email and newsgroup clients missing a bit from Krinkle's
> list. Subthreading works perfectly fine in Thunderbird (but even in Outlook
> Express!). Indenting is the one characteristic found in all wiki
> conversations: subthreading can't be discarded based on gut feelings.
> In my experience shepherding thousands of it.wiki conversations (mostly on
> their own subpages), the biggest issue are offtopic and personal tangents,
> hence the most important technical feature in wikitext is that I'm able to
> easily tell apart, link and move subthreads.
>
> Nemo
>
>
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
123