Hoi,
I like your story and I understand the sentiment. For me the story is about
the kind of functionality that we may or may not need in Flow. The story is
not about retaining what went before.. Mark my words, I cannot wait for the
old talk system to go.
As I understand the current situation, Flow is gaining in functionality and
it is being used in all kinds of settings. As time goes by, it becomes
feature rich and increasingly versatile. I am sure the husband "learned"
from the first time an egg was presented to his wife. I am sure they shared
fond memories of this moment of embarrassment. Life is short and learning
how to improve your ways makes life more pleasant.
The lessons of the egg are for all of us. Do not single out anyone and do
not think any of us is beyond the need of learning from past mistakes.
Thanks,
GerardM
On 7 September 2014 03:17, Risker <risker...@gmail.com> wrote:
> I'm not going to reply in-line here, because I think there's been an
> undoubtedly unintentional missing of the point here. Instead I will tell a
> story about a friend of mine.
>
> Some years ago, when her children were 3 and 4, their family had a lovely
> traditional Christmas Day, but something felt like it was "missing". She
> told her husband about a tradition in her own family, where she and her
> siblings had (since they were very young children) always bought their
> mother a Terry's Chocolate Orange for Christmas - no matter what else her
> mom got, that was considered the one "essential" Christmas gift under the
> tree. Mom would glow with joy when she unwrapped it, and her most
> heartfelt thanks was for this specific present. Some time later in the
> day, she'd smack it open and everyone would get a piece. My friend thought
> it would be wonderful to start a similar tradition in her own young family.
>
> Her husband remembered this story in the weeks leading up to the next
> Christmas. He plotted with the children, now 4 and 5; he researched the
> "best" types of similar treats; and ultimately he "helped" the children
> obtain a chocolate orange made of the finest Swiss chocolate, filled with
> Grand Marnier liqueur, presented in an elegant marquetry box. Everyone was
> surprised when she burst into tears instead of smiles, and spent the whole
> day snapping at people and generally being a grouch. Finally her husband
> confronted her and insisted she explain her behaviour.
>
> What happened, of course, was that despite his best efforts, he'd missed
> the real purpose of the chocolate orange. He thought it was symbolic of
> the esteem in which the matriarch was held. Really, it was about the
> familial sharing of a special treat; the joy that the sharing brought to
> both the recipient and the presenters. But she couldn't share
> liqueur-filled chocolate with her children, and could barely bring herself
> to smack open the beautifully designed and presented chocolate. In other
> words, even though the gift looked brilliant on paper, it missed the point.
>
> I think the design of Flow is much like the liqueur-filled chocolates.
> It's missed the point of a discussion space on Wikimedia projects. All the
> use cases in the world, no matter how carefully researched and accounted
> for, will help you build a discussion system to effectively replace a
> discussion system if you don't understand that the one overriding,
> incontrovertible feature of the current system is that it is a page that
> acts just like all the other wiki pages, with all the same functions, and
> anyone who can work on one wiki-page can work on any of them. In other
> words, you're building something that is explicitly different from
> wiki-pages - but the expectation of the majority of the people who will use
> these pages is that they work exactly like any other wiki-page.
>
> This is what I mean when I say that you've not really understood how
> wiki-discussion functions, and you've created the "bells and whistles"
> without demonstrating an understanding of what the real, core functions of
> these pages are. The priority in design should focus on being able to
> produce identical results for basic wiki-editing and page management: we
> move pages, we protect them, we undo and revert edits, we fix typos and
> correct URLS and links in each other's posts, we quote each other and
> copy/paste, we modify each other's words when collaborating on the wording
> of a complex section of an article, we get rid of trolling, we delete and
> sometimes suppress personal attacks, we hat and archive individual
> discussions. Whether or not a post gets auto-signed is a "frill" compared
> to those basic functions, and it is inevitable that the deprioritization of
> "the basics" will result in people not really caring much about the frills
> (no matter how well they are executed) and focusing instead on what the
> new "system" doesn't do. This is the real parallel between Flow and Visual
> Editor - focusing on the "difference" between the new product and that it
> was intended to replace, instead of ensuring that things that had to be
> similar or identical were considered the first step of design.
>
> Risker/Anne
>
>
>
>
> On 6 September 2014 02:13, Erik Moeller <e...@wikimedia.org> wrote:
>
> > On Fri, Sep 5, 2014 at 10:42 PM, Risker <risker...@gmail.com> wrote:
> > > The major deficiencies that have long been identified in the current
> > > discussion system (and that can be addressed by technology) are all
> able
> > to
> > > be addressed in MediaWiki software or by extensions. Automatic
> signatures
> > > have been done by bots for years; indenting could be added to the
> editing
> > > function gadget and moved to an extension; much work has already been
> > done
> > > on graceful resolution of edit conflicts. The ability to watchlist an
> > > individual thread or section of a page is more challenging but, I have
> > been
> > > told, still possible.
> >
> > Let's just acknowledge that the limitations of what can reasonably be
> > layered onto wikitext-based representation of comments have not been
> > fully explored, rather than jumping to conclusions about what's easy
> > to address and what's hard. As noted separately, I agree it may be
> > worth pushing the boundaries a bit more on this, if only to know
> > exactly where they are, and to achieve short term improvements.
> >
> > > Automatic signature (something that is currently
> > > functional on Flow, but is not customizable) turns out to be more of a
> > > challenge when users are widely known by a signature line that doesn't
> > > match their username,
> >
> > I've not talked to them about it explicitly, but I'd guess that the PM
> > and the UX folks have a negative aversion against custom signatures
> > because of their free-form nature (including sometimes
> > layout-exploding ones). Perhaps a middle-ground can be found here,
> > with some more sanitization applied to prevent some of the
> > sigs-from-hell occasionally found. Other than that I can't see a good
> > reason to not just show them when they're set, and it's certainly
> > technically trivial to do so.
> >
> > > and there is no method by which users can add an
> > > "explanatory" note to their signature such as "formerly known as
> > > User:Whatever".
> >
> > From the point forward that Flow is in wide use, a user rename would
> > be automatically reflected in old comments if desired, much as it is
> > reflected in old edits. But if signatures were supported, as above,
> > you could still use them for these types of indicators, as well.
> >
> > > The "more efficient" indenting has reduced possible
> > > indents to three levels, without exception;
> >
> > This seems to be the most religious topic when it comes to Flow. The
> > database stores all threading information. It'd be trivial to expand
> > the threading level if that's more popular and usable.
> >
> > I've heard the argument that this doesn't work on mobile, but we could
> > just set a different threading level on mobile.
> >
> > I think it's worth experimenting with flat pages (with quoting) for
> > certain purposes, and Danny wants to, but it strikes me as most
> > reasonable to start with something that more closely resembles talk
> > pages as they are now (which is why we did that with LQT originally).
> >
> > > "Rigid predictable technical
> > > restrictions on who can edit what" has resulted in inability to remove
> > > posts that are obviously unsuitable (there's no "undo" or "revert"
> > > function), replaced with a "hide" function that can only be applied by
> > > certain users that's practically a red flag for people to look-see what
> > the
> > > problem edit is.
> >
> > The team has pretty strong arguments why they don't want posts to be
> > editable (the gist is, they fear that no other discussion system does
> > this, and it will freak people out -- they see the introduction of a
> > new system as a good opportunity to reset expectations). I personaly
> > am not religious about it; when we built LQT we made posts editable
> > (and made it clear who had edited someone else's posts) to preserve
> > that normal aspect of wiki-style editing. I think we should keep
> > talking about this.
> >
> > I've not seen it named as a dealbreaker for small scale deployments.
> > The architecture can easily support both models.
> >
> > > At the core is whether or not there is value in developing a
> "discussion
> > > system" that is radically divorced from any other interface used by the
> > > system.
> >
> > That's a legitimate question, although it's not as "radically
> > divorced" as you would think; ultimately it'll use the VisualEditor
> > (probably with a simplified toolbar by default) just like Flow does.
> >
> > As for the claim that the team never looked at current use cases,
> > having spent hours in rooms with them where they pored over printouts
> > of hundreds of talk pages, analyzed use cases, categorized them,
> > prioritized them, etc., I can assure you there's been a lot more of
> > this kind of thinking than you appreciate. There also have been round
> > tables and other outreach efforts, and a dedicated community liaison
> > from the start. Still, I don't think there's been enough talking to
> > each other -- we're still getting better at doing that, collectively,
> > and trusting in the value of conversation even when there's a lot of
> > noise and a lot of heat.
> >
> > This is an opportunity for me to remind folks that the cost of heat
> > (accusations, insults, reverts, etc.) is that people withdraw. We
> > (WMF) have to do our part to prevent things from getting heated, but
> > I'd ask folks who notice this kind of thing and who understand why
> > it's harmful to help step in and contribute to a calm, rational,
> > constructive dialog, as well. I can take a lot of heat, as you may
> > have noticed, but a lot of folks just tend to back away when things
> > get personal.
> >
> > Thanks,
> > Erik
> >
> > --
> > Erik Möller
> > VP of Engineering and Product Development, Wikimedia Foundation
> >
> > _______________________________________________
> > Wikimedia-l mailing list, guidelines at:
> > https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> > Wikimedia-l@lists.wikimedia.org
> > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> > <mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe>
> >
> _______________________________________________
> Wikimedia-l mailing list, guidelines at:
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> Wikimedia-l@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> <mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe>
>
_______________________________________________
Wikimedia-l mailing list, guidelines at:
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
<mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe>
