On Sat, Jun 7, 2014 at 3:51 PM, Erik Moeller <[email protected]> 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 > [email protected] > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
