I am getting real sick of the WMF developers shoving shity products down
the throat of their users and saying FUCK YOU. That is the pattern that I
have seen over the recent months starting primarily with Notifcations and
now moving to VE. It really pisses me off that more and more sites are
shoving crap into javascript that just plain sucks, is poorly written and
extremely bloated. Since the devs implemented resource loader it has become
harder and harder to block the poorly developed bloat that has crept into
mediawiki. I used to be able to isolate the JavaScript file causing the
issues (I remember BITS geolocation being a major hog) and just block it.
Now thats not possible any longer. Users WANT a method for turning off an
extremely bloated "Feature" keep in mind that the WMF Staff is dependent
not only on donations by users, but also by what content they produce.
Instead of fucking up stuff why dont the devs spend time going back and
fixing bugs and issues that the community wants fixed. There are major
features and bugs that have been open for over 5 years that need addressed.
Lets stop trying to become facebook and remember what our goal here is.
VE needs a method for disabling the loading of the associated JavaScript,
If users what to test VE again they can, but lets put this piece of shit to
rest until its not a piece of shit
John
On Mon, Jul 22, 2013 at 12:51 PM, Tyler Romeo <tylerromeo(a)gmail.com> wrote:
On that note, I think we should start forcing
MediaWiki developers to use
Eclipse for PHP. Of course some people prefer using just a text editor, but
I'm sure no matter what it'll be more efficient in Eclipse, and if it isn't
we can just have Eclipse fix it.
Seriously, though, I understand why the VE team might want to force
everybody to use VE, because otherwise users just "give up", so to say,
because they don't like the change. But some people really just don't want
to use VE, and I don't see why we should be forcing that upon them,
especially if the community consensus is to add the user option back.
*-- *
*Tyler Romeo*
Stevens Institute of Technology, Class of 2016
Major in Computer Science
www.whizkidztech.com | tylerromeo(a)gmail.com
On Mon, Jul 22, 2013 at 12:47 PM, C. Scott Ananian
<cananian(a)wikimedia.org>wrote;wrote:
On Mon, Jul 22, 2013 at 12:37 PM, Bartosz
Dziewoński <
matma.rex(a)gmail.com
wrote:
The bug for that patch was just WONTFIXed,
synchronizing information.
https://bugzilla.wikimedia.**org/show_bug.cgi?id=50929#c16<
https://bugzilla.wikimedia.org/show_bug.cgi?id=50929#c16>
Just to accomodate people too lazy to chase through two links, in the
interests of having a synchronized discussion I'm cut and pasting from
the
rationale given there:
{{Ping|Adam Cuerden}} Thanks for the thoughtful note. Some initial
thoughts
> -- I'll jump in more when I can, but
also pinging [[User:Okeyes
> (WMF)|Oliver]] and [[User:Whatamidoing (WMF)|Whatamidoing]] who can
help
with
clarifications.
Our overall concern, and the reason we did not offer a preference, is
that
"out
of sight, out of mind" makes it very hard for us to address the
kinds
of efficiency issues you mention. It makes it too
easy for us to ignore
the
> needs of users such as yourself as we improve VisualEditor. I actually
do
> ''not'' agree that the kind
of task you describe needs to be inherently
> less efficient in VisualEditor, but I do agree that it'll take us a
while
to make
VisualEditor a good tool for that case.
I really would like us to be increasingly scientific and systematic about
> this -- enumerate the types of tasks that users perform frequently, and
> measure the relative task performance in VisualEditor and source mode.
I
will
personally not be satisfied with the product until we can exceed
task
efficiency in the vast majority of cases.
If you've followed the deployment a bit, you'll note that even this week,
> we've made some changes to improve task efficiency for templates and
> images. Inserting an image used to take two clicks; now it takes one.
> Filling in a template used to require manually selecting all
parameters;
now
required parameters (as defined by templatedata) are pre-selected,
and
it takes a single click to add a new parameter.
Etc.
So, in other words, we ''do'' care, a lot, about making this not only an
easy-to-use tool, but an efficient one. Many of
us at WMF are
Wikipedians,
and we hate tools that don't do the job.
Where VisualEditor doesn't get
the
> job done, we need to know. Our hypothesis is that we ''can'' build a
tool
that's both powerful and discoverable, not just a nice UI for newbies.
And to be honest, we made the mistake of offering a quick and easy "out
of
sight,
out of mind" preference before. When we did the Vector skin
rollout
in 2010, we offered a trivial "Take me back
to the old look" option --
which lots of users took. Almost any change to a user interface [
http://www.designstaff.org/articles/how-to-avoid-mitigate-change-aversion-2…
with resistance and objections]. As a recent non-WMF example,
> did you see the reactions to Flickr's
design change? I've rarely seen
so
much
hatemail for a company in one place.
By making it easy to switch back, we effectively created two generations
of
users:
the pre-Vector generation and the post-Vector users. Pre-Vector
users, by and large, stayed with Monbook; post-Vector users stayed with
Vector. There may have been legitimate efficiency reasons to stay with
Monobook - things we could have improved in Vector, but didn't. In our
drive to increase usability, we didn't pay sufficient attention to the
needs of advanced users. And because of the "out of sight, out of mind"
effect, we didn't have to.
To avoid this effect, with VisualEditor, you can't make it disappear
completely without resorting to gadgets or user
scripts. You don't have
to
use it, but we encourage you to give it a try
every once in a while to
see
> the improvements and changes, and to point out those annoying bugs
which
we
should have long fixed and haven't. And to
the extent that there are
things
about the new default user experience that we
have to fix to not
interfere
with normal editing (the current section editing
behavior is definitely
still not ideal), please keep us honest and remind us about it.
I hear you on the subject of muscle memory and confusing edit tabs. There
are a couple of things I'd say right now
which may help mitigate this
issue
going forward, and I'd appreciate your
suggestions as well.
1) We can reduce the issue by avoiding inconsistency between "Edit" and
> "Edit source". I believe this is already on [[User:Jdforrester
> (WMF)|James']] agenda, and there was some community energy around this
as
well on
[[WP:VPT]]. What I mean here is that right now, some namespaces
still use wikitext by default. If those namespaces consistently had the
tab
> labeled "Edit source", visually scanning for the right tab to click
would
be a lot
easier. (Having VisualEditor on all Wikimedia projects, as it
soon
will be, will also help with those consistency
issues.)
2) This is more of a personal tip for you: To support muscle memory, we
ensured that VisualEditor does not take over the
existing keyboard
shortcut
for editing in source mode. If you've never
given keyboard shortcuts a
try,
> I strongly suggest it; they should work in all modern browsers. When
you
mouse
over the tab, it gives you the shortcut indicator. So, I can just
press Alt+Shift+E on any page to edit, and it will always edit in
wikitext
mode (Alt+Shift+V will edit in VisualEditor).
Finally, on the earlier point of measuring task efficiency -- this is
something anyone can help with. We may do some
specific community
outreach
> around this, but any efforts to document "It takes me X steps/seconds
to
do
> this in VisualEditor, Y steps/seconds in wikitext" helps ''a
lot''.
It's
worth
noting that VisualEditor has its own set of keyboard shortcuts,
which
> can help with common tasks such as linking (which I actually already
find
> faster in VE). And I do think tasks like
updating image links should
> ultimately be well-supported in VE (even if it's by means of plugins),
so
we should
start tracking these types of use cases in Bugzilla.
--[[User:Eloquence|Eloquence]][[User:Eloquence/CP|*]] 07:19, 17 July 2013
(UTC)
--
(
http://cscott.net)
_______________________________________________
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