On Sat, Jun 7, 2014 at 3:51 PM, Erik Moeller <erik(a)wikimedia.org> 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.
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
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l