Hey all,
This is a note of prior explanation about a small design enhancement upcoming.
*## Background*
You might remember that part of the original Vector plans was to redesign section edit links to make them more accessible to new contributors. (Look at the Acai release on usability.wikimedia.org).
Later on, Trevor collaborated with the Community Dept. to run an A/B test on English Wikipedia of his redesign, which conclusively showed that the new look increased both clicks and the net number of edits by a significant amount.
At the time, there was no big push to productize the changes, but the code has been sitting around inside the ClickTracking extension. My team became the de facto maintainers of ClickTracking since we were its most heavy users, and are now deprecating it in favor of EventLogging.
Skipping the big analytics discussion there, suffice it to say that we don't want to throw out the baby with the bathwater, and are working to productize Trevor's road tested new design for section edit links in Vector. (No change in Monobook et al.)
*## Plan of action*
Here's the plan for execution, which I've discussed with Howie Fung and some of the design team so far:
1. We'll deploy the current version of the section edit redesign, which you can see at http://piramido.wmflabs.org/wiki/Hipster_ipsum. I've committed to handling the necessary community announcements and final QA. 2. For the second iteration, Munaf and Vibha will work on a redesigned icon to fit with Agora style, and we'll explore the idea Munaf had -- the icons appearing only on hover in the section. It's a good one.
The current iteration is perhaps not perfect, but it was tested with users and showed an improved conversion across the board. It also appears to be using the previous localization message, so we can safely deploy it everywhere Vector is in use.
The caveat Howie and I have discussed is the fact that no quality measurements were done on the increase in editing. This change is really a basic necessity as far as Product is concerned, so we aren't going to make that a blocker, but should be prepared to roll it back if it makes the wikis explode with vandalism etc.
This is one change I'm pretty excited about, though I agree - it's not perfect at the moment. I think I'll have an Agorable (ugh) prototype we can all paste into our common.js/common.css by tomorrow. Stay tuned!
Munaf
On Tue, Nov 13, 2012 at 3:07 PM, Steven Walling swalling@wikimedia.orgwrote:
Hey all,
This is a note of prior explanation about a small design enhancement upcoming.
*## Background*
You might remember that part of the original Vector plans was to redesign section edit links to make them more accessible to new contributors. (Look at the Acai release on usability.wikimedia.org).
Later on, Trevor collaborated with the Community Dept. to run an A/B test on English Wikipedia of his redesign, which conclusively showed that the new look increased both clicks and the net number of edits by a significant amount.
At the time, there was no big push to productize the changes, but the code has been sitting around inside the ClickTracking extension. My team became the de facto maintainers of ClickTracking since we were its most heavy users, and are now deprecating it in favor of EventLogging.
Skipping the big analytics discussion there, suffice it to say that we don't want to throw out the baby with the bathwater, and are working to productize Trevor's road tested new design for section edit links in Vector. (No change in Monobook et al.)
*## Plan of action*
Here's the plan for execution, which I've discussed with Howie Fung and some of the design team so far:
- We'll deploy the current version of the section edit redesign,
which you can see at http://piramido.wmflabs.org/wiki/Hipster_ipsum. I've committed to handling the necessary community announcements and final QA. 2. For the second iteration, Munaf and Vibha will work on a redesigned icon to fit with Agora style, and we'll explore the idea Munaf had -- the icons appearing only on hover in the section. It's a good one.
The current iteration is perhaps not perfect, but it was tested with users and showed an improved conversion across the board. It also appears to be using the previous localization message, so we can safely deploy it everywhere Vector is in use.
The caveat Howie and I have discussed is the fact that no quality measurements were done on the increase in editing. This change is really a basic necessity as far as Product is concerned, so we aren't going to make that a blocker, but should be prepared to roll it back if it makes the wikis explode with vandalism etc.
-- Steven Walling https://wikimediafoundation.org/
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
On 11/13/2012 06:07 PM, Steven Walling wrote:
Hey all,
This is a note of prior explanation about a small design enhancement upcoming.
*## Background*
You might remember that part of the original Vector plans was to redesign section edit links to make them more accessible to new contributors. (Look at the Acai release on usability.wikimedia.org).
Later on, Trevor collaborated with the Community Dept. to run an A/B test on English Wikipedia of his redesign, which conclusively showed that the new look increased both clicks and the net number of edits by a significant amount.
At the time, there was no big push to productize the changes, but the code has been sitting around inside the ClickTracking extension. My team became the de facto maintainers of ClickTracking since we were its most heavy users, and are now deprecating it in favor of EventLogging.
Skipping the big analytics discussion there, suffice it to say that we don't want to throw out the baby with the bathwater, and are working to productize Trevor's road tested new design for section edit links in Vector. (No change in Monobook et al.)
Compare the old to something much like the new: https://blog.wikimedia.org/2011/03/09/ui-design-experiments/
*## Plan of action*
Here's the plan for execution, which I've discussed with Howie Fung and some of the design team so far:
- We'll deploy the current version of the section edit redesign, which
you can see at http://piramido.wmflabs.org/wiki/Hipster_ipsum. I've committed to handling the necessary community announcements and final QA. 2. For the second iteration, Munaf and Vibha will work on a redesigned icon to fit with Agora style, and we'll explore the idea Munaf had -- the icons appearing only on hover in the section. It's a good one.
The current iteration is perhaps not perfect, but it was tested with users and showed an improved conversion across the board. It also appears to be using the previous localization message, so we can safely deploy it everywhere Vector is in use.
The caveat Howie and I have discussed is the fact that no quality measurements were done on the increase in editing. This change is really a basic necessity as far as Product is concerned, so we aren't going to make that a blocker, but should be prepared to roll it back if it makes the wikis explode with vandalism etc.
Steven, this is great news and I'm looking forward to seeing it live on our sites! Thanks for taking this the last few steps to completion. And thanks to everyone who did the design, coding, analysis, and other thinking on this change.
Good to see this isn't dead.
I agree that a monochrome icon that matches the other work being done would be awesome.
It's sort of been on the back-burner for a while, but mostly because it's not as trivial as it looks.
The reason this is a tricky change is because the output of the parser currently places the section edit link and the heading text in the wrong order. That is, the section edit link comes first (and is floated right) and the heading text comes second. Attached is a screenshot of the DOM structure as it is now on Wikipedia.
It's important to note that the experiment I ran was a JavaScript hack that rearranged DOM elements on the fly. The correct way to do this (as long as we are busting out the "productized" word) is to make these changes before we send the HTML out to the client. This means making changes to the parser's output. This could
Bug #11270 https://bugzilla.wikimedia.org/show_bug.cgi?id=11270 calls for this change to be made, and there's even a patch (but it's 3 years old, so don't get your hopes up). The patch changes the output of the parser, which affects all skins, and then adjusts the CSS for non-Vector skins to make them look the way they used to. Bug #41729https://bugzilla.wikimedia.org/show_bug.cgi?id=41729 calls for the experimental stuff I did a while back to be cleaned up - basically what you are calling for now. There's also #11555https://bugzilla.wikimedia.org/show_bug.cgi?id=11555which relates to this issue, and may be solved by whatever we do to resolve the other 2 bugs.
- Trevor
On Tue, Nov 13, 2012 at 3:13 PM, Sumana Harihareswara <sumanah@wikimedia.org
wrote:
On 11/13/2012 06:07 PM, Steven Walling wrote:
Hey all,
This is a note of prior explanation about a small design enhancement upcoming.
*## Background*
You might remember that part of the original Vector plans was to redesign section edit links to make them more accessible to new contributors.
(Look
at the Acai release on usability.wikimedia.org).
Later on, Trevor collaborated with the Community Dept. to run an A/B test on English Wikipedia of his redesign, which conclusively showed that the new look increased both clicks and the net number of edits by a
significant
amount.
At the time, there was no big push to productize the changes, but the
code
has been sitting around inside the ClickTracking extension. My team
became
the de facto maintainers of ClickTracking since we were its most heavy users, and are now deprecating it in favor of EventLogging.
Skipping the big analytics discussion there, suffice it to say that we don't want to throw out the baby with the bathwater, and are working to productize Trevor's road tested new design for section edit links in Vector. (No change in Monobook et al.)
Compare the old to something much like the new: https://blog.wikimedia.org/2011/03/09/ui-design-experiments/
*## Plan of action*
Here's the plan for execution, which I've discussed with Howie Fung and some of the design team so far:
- We'll deploy the current version of the section edit redesign,
which
you can see at http://piramido.wmflabs.org/wiki/Hipster_ipsum. I've committed to handling the necessary community announcements and final
QA.
- For the second iteration, Munaf and Vibha will work on a redesigned
icon to fit with Agora style, and we'll explore the idea Munaf had --
the
icons appearing only on hover in the section. It's a good one.
The current iteration is perhaps not perfect, but it was tested with
users
and showed an improved conversion across the board. It also appears to be using the previous localization message, so we can safely deploy it everywhere Vector is in use.
The caveat Howie and I have discussed is the fact that no quality measurements were done on the increase in editing. This change is really
a
basic necessity as far as Product is concerned, so we aren't going to
make
that a blocker, but should be prepared to roll it back if it makes the wikis explode with vandalism etc.
Steven, this is great news and I'm looking forward to seeing it live on our sites! Thanks for taking this the last few steps to completion. And thanks to everyone who did the design, coding, analysis, and other thinking on this change.
-- Sumana Harihareswara Engineering Community Manager Wikimedia Foundation
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
Note that currently in the parser editsection links are handled by placing a marker inside the ParserOutput and then replacing them post-parse. Doing that instead for the whole header wouldn't be a bad improvement.
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
On 12-11-13 3:42 PM, Trevor Parscal wrote:
Good to see this isn't dead.
I agree that a monochrome icon that matches the other work being done would be awesome.
It's sort of been on the back-burner for a while, but mostly because it's not as trivial as it looks.
The reason this is a tricky change is because the output of the parser currently places the section edit link and the heading text in the wrong order. That is, the section edit link comes first (and is floated right) and the heading text comes second. Attached is a screenshot of the DOM structure as it is now on Wikipedia.
It's important to note that the experiment I ran was a JavaScript hack that rearranged DOM elements on the fly. The correct way to do this (as long as we are busting out the "productized" word) is to make these changes before we send the HTML out to the client. This means making changes to the parser's output. This could
Bug #11270 https://bugzilla.wikimedia.org/show_bug.cgi?id=11270 calls for this change to be made, and there's even a patch (but it's 3 years old, so don't get your hopes up). The patch changes the output of the parser, which affects all skins, and then adjusts the CSS for non-Vector skins to make them look the way they used to. Bug #41729 https://bugzilla.wikimedia.org/show_bug.cgi?id=41729 calls for the experimental stuff I did a while back to be cleaned up - basically what you are calling for now. There's also #11555 https://bugzilla.wikimedia.org/show_bug.cgi?id=11555 which relates to this issue, and may be solved by whatever we do to resolve the other 2 bugs.
- Trevor
On Tue, Nov 13, 2012 at 3:13 PM, Sumana Harihareswara <sumanah@wikimedia.org mailto:sumanah@wikimedia.org> wrote:
On 11/13/2012 06:07 PM, Steven Walling wrote: > Hey all, > > This is a note of prior explanation about a small design enhancement > upcoming. > > *## Background* > > You might remember that part of the original Vector plans was to redesign > section edit links to make them more accessible to new contributors. (Look > at the Acai release on usability.wikimedia.org <http://usability.wikimedia.org>). > > Later on, Trevor collaborated with the Community Dept. to run an A/B test > on English Wikipedia of his redesign, which conclusively showed that the > new look increased both clicks and the net number of edits by a significant > amount. > > At the time, there was no big push to productize the changes, but the code > has been sitting around inside the ClickTracking extension. My team became > the de facto maintainers of ClickTracking since we were its most heavy > users, and are now deprecating it in favor of EventLogging. > > Skipping the big analytics discussion there, suffice it to say that we > don't want to throw out the baby with the bathwater, and are working to > productize Trevor's road tested new design for section edit links in > Vector. (No change in Monobook et al.) Compare the old to something much like the new: https://blog.wikimedia.org/2011/03/09/ui-design-experiments/ > *## Plan of action* > > Here's the plan for execution, which I've discussed with Howie Fung and > some of the design team so far: > > 1. We'll deploy the current version of the section edit redesign, which > you can see at http://piramido.wmflabs.org/wiki/Hipster_ipsum. I've > committed to handling the necessary community announcements and final QA. > 2. For the second iteration, Munaf and Vibha will work on a redesigned > icon to fit with Agora style, and we'll explore the idea Munaf had -- the > icons appearing only on hover in the section. It's a good one. > > The current iteration is perhaps not perfect, but it was tested with users > and showed an improved conversion across the board. It also appears to be > using the previous localization message, so we can safely deploy it > everywhere Vector is in use. > > The caveat Howie and I have discussed is the fact that no quality > measurements were done on the increase in editing. This change is really a > basic necessity as far as Product is concerned, so we aren't going to make > that a blocker, but should be prepared to roll it back if it makes the > wikis explode with vandalism etc. Steven, this is great news and I'm looking forward to seeing it live on our sites! Thanks for taking this the last few steps to completion. And thanks to everyone who did the design, coding, analysis, and other thinking on this change. -- Sumana Harihareswara Engineering Community Manager Wikimedia Foundation _______________________________________________ Design mailing list Design@lists.wikimedia.org <mailto:Design@lists.wikimedia.org> https://lists.wikimedia.org/mailman/listinfo/design
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
On Tue, Nov 13, 2012 at 3:42 PM, Trevor Parscal tparscal@wikimedia.orgwrote:
It's important to note that the experiment I ran was a JavaScript hack that rearranged DOM elements on the fly. The correct way to do this (as long as we are busting out the "productized" word) is to make these changes before we send the HTML out to the client. This means making changes to the parser's output. This could
Bug #11270 https://bugzilla.wikimedia.org/show_bug.cgi?id=11270 calls for this change to be made, and there's even a patch (but it's 3 years old, so don't get your hopes up). The patch changes the output of the parser, which affects all skins, and then adjusts the CSS for non-Vector skins to make them look the way they used to. Bug #41729https://bugzilla.wikimedia.org/show_bug.cgi?id=41729 calls for the experimental stuff I did a while back to be cleaned up - basically what you are calling for now. There's also #11555https://bugzilla.wikimedia.org/show_bug.cgi?id=11555which relates to this issue, and may be solved by whatever we do to resolve the other 2 bugs.
Thanks for the explanation there.
In the interest of not waiting any more, my instinct is to deploy the first JS-reliant version, and defer perfecting the implementation based on when patches get submitted. :)
For IE 6/7 users, this implementation is slow enough that it can produce a flash of unstyled content. But for IE8-10, FF, Chrome, Opera we're good. And it's not like that problem isn't present in many other elements of the interface on projects like English Wikipedia...
It will cause a flash on pretty much all browsers period.
- Trevor
On Tue, Nov 13, 2012 at 4:17 PM, Steven Walling swalling@wikimedia.orgwrote:
On Tue, Nov 13, 2012 at 3:42 PM, Trevor Parscal tparscal@wikimedia.orgwrote:
It's important to note that the experiment I ran was a JavaScript hack that rearranged DOM elements on the fly. The correct way to do this (as long as we are busting out the "productized" word) is to make these changes before we send the HTML out to the client. This means making changes to the parser's output. This could
Bug #11270 https://bugzilla.wikimedia.org/show_bug.cgi?id=11270 calls for this change to be made, and there's even a patch (but it's 3 years old, so don't get your hopes up). The patch changes the output of the parser, which affects all skins, and then adjusts the CSS for non-Vector skins to make them look the way they used to. Bug #41729https://bugzilla.wikimedia.org/show_bug.cgi?id=41729 calls for the experimental stuff I did a while back to be cleaned up - basically what you are calling for now. There's also #11555https://bugzilla.wikimedia.org/show_bug.cgi?id=11555which relates to this issue, and may be solved by whatever we do to resolve the other 2 bugs.
Thanks for the explanation there.
In the interest of not waiting any more, my instinct is to deploy the first JS-reliant version, and defer perfecting the implementation based on when patches get submitted. :)
For IE 6/7 users, this implementation is slow enough that it can produce a flash of unstyled content. But for IE8-10, FF, Chrome, Opera we're good. And it's not like that problem isn't present in many other elements of the interface on projects like English Wikipedia...
-- Steven Walling https://wikimediafoundation.org/
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
On Tue, Nov 13, 2012 at 5:15 PM, Trevor Parscal tparscal@wikimedia.orgwrote:
It will cause a flash on pretty much all browsers period.
To be clear here: I tested it on the browsers I previously mentioned. It doesn't cause a flash on anything except older versions of IE.
It might do on say, very old versions of Opera, but I tested on everything that had a 1% of greater share of our readership, according to the matrix James F. put together.
On Wed, Nov 14, 2012 at 10:06 PM, Steven Walling swalling@wikimedia.org wrote:
To be clear here: I tested it on the browsers I previously mentioned. It doesn't cause a flash on anything except older versions of IE.
Loading http://piramido.wmflabs.org/wiki/Hipster_ipsum even in Chrome 22 I can definitely see the [edit] links on the right briefly appear before being replaced with the new ones. Also keep in mind that some articles and discussion pages are massive.
Erik
On Wed, Nov 14, 2012 at 10:06 PM, Steven Walling swalling@wikimedia.org wrote: http://piramido.wmflabs.org/wiki/Hipster_ipsum even in Chrome
All I see there is a syntax error in the startup module, and as a result the sectionEditLinks simulator is breaking on a ReferenceError due to jQuery (and other modules) not being available.
Parse error: syntax error, unexpected T_STRING in /mnt/m ediawiki - piramido / extensions / EventLogging / EventLogging.module.php on line 105
Uncaught SyntaxError: Unexpected identifier /srv/mediawiki/load.php?debug=false&lang=en&modules=startup&only=scripts&skin=vector&*:2 • Uncaught ReferenceError: jQuery is not defined
On Wed, Nov 14, 2012 at 5:47 AM, Steven Walling swalling@wikimedia.org wrote:
In the interest of not waiting any more, my instinct is to deploy the first JS-reliant version, and defer perfecting the implementation based on when patches get submitted. :)
I would prefer that we not get too much in the habit of accepting degradation of front-end performance and long term maintainability of our codebase in order to push features out the door more quickly -- especially where it concerns code that gets loaded on every pageview. Existing poor practices and problems are not a good reason for exacerbating the issue (and indeed setting a poor example will reduce our ability to set standards for others).
As you yourself say, site performance really matters, and that includes flashes of unstyled content and DOM changes that shouldn't be necessary. Moreover, JS cruft leads to maintenance burden down the road.
I'm very accepting of doing this when our objective is to learn whether something is working or not (cf. ACUX). But the moment we actually decide that a change makes sense, we should implement it at a reasonable level of quality instead of layering on cruft.
So if you want to make the decision now that this change makes sense based on the data we already have, please do a clean implementation first. It can't become someone else's problem to do so.
Thanks, Erik
Would it be worth holding off on this for a bit and then putting it in the Agora extension when we've got it put together, then? The entire point of the extension (well, other than "stop increasing developer workload and long-term maintenance duties" and "don't make Roan cry by breaking protocol") is to allow us to make small, iterative tweaks structured in such a way as to avoid FOUCs.
On 14 November 2012 16:12, Erik Moeller erik@wikimedia.org wrote:
On Wed, Nov 14, 2012 at 5:47 AM, Steven Walling swalling@wikimedia.org wrote:
In the interest of not waiting any more, my instinct is to deploy the
first
JS-reliant version, and defer perfecting the implementation based on when patches get submitted. :)
I would prefer that we not get too much in the habit of accepting degradation of front-end performance and long term maintainability of our codebase in order to push features out the door more quickly -- especially where it concerns code that gets loaded on every pageview. Existing poor practices and problems are not a good reason for exacerbating the issue (and indeed setting a poor example will reduce our ability to set standards for others).
As you yourself say, site performance really matters, and that includes flashes of unstyled content and DOM changes that shouldn't be necessary. Moreover, JS cruft leads to maintenance burden down the road.
I'm very accepting of doing this when our objective is to learn whether something is working or not (cf. ACUX). But the moment we actually decide that a change makes sense, we should implement it at a reasonable level of quality instead of layering on cruft.
So if you want to make the decision now that this change makes sense based on the data we already have, please do a clean implementation first. It can't become someone else's problem to do so.
Thanks, Erik -- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation
Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
Olive - just because the Agora extension is designed to allow iterative tweaks doesn't mean all problems can be solved using iterative tweaks.
Roan and I could easily revive this patch from the dead in 2 hours. The questions is who's bringing the pizza?
- Trevor
On Wed, Nov 14, 2012 at 8:16 AM, Oliver Keyes okeyes@wikimedia.org wrote:
Would it be worth holding off on this for a bit and then putting it in the Agora extension when we've got it put together, then? The entire point of the extension (well, other than "stop increasing developer workload and long-term maintenance duties" and "don't make Roan cry by breaking protocol") is to allow us to make small, iterative tweaks structured in such a way as to avoid FOUCs.
On 14 November 2012 16:12, Erik Moeller erik@wikimedia.org wrote:
On Wed, Nov 14, 2012 at 5:47 AM, Steven Walling swalling@wikimedia.org wrote:
In the interest of not waiting any more, my instinct is to deploy the
first
JS-reliant version, and defer perfecting the implementation based on
when
patches get submitted. :)
I would prefer that we not get too much in the habit of accepting degradation of front-end performance and long term maintainability of our codebase in order to push features out the door more quickly -- especially where it concerns code that gets loaded on every pageview. Existing poor practices and problems are not a good reason for exacerbating the issue (and indeed setting a poor example will reduce our ability to set standards for others).
As you yourself say, site performance really matters, and that includes flashes of unstyled content and DOM changes that shouldn't be necessary. Moreover, JS cruft leads to maintenance burden down the road.
I'm very accepting of doing this when our objective is to learn whether something is working or not (cf. ACUX). But the moment we actually decide that a change makes sense, we should implement it at a reasonable level of quality instead of layering on cruft.
So if you want to make the decision now that this change makes sense based on the data we already have, please do a clean implementation first. It can't become someone else's problem to do so.
Thanks, Erik -- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation
Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
-- Oliver Keyes Community Liaison, Product Development Wikimedia Foundation
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
+1 to the philosophy. Making cataclysmic changes that are not on the roadmap and loading everything onto those events is a big risk. Small frequent changes done right from development and ux perspectives so we keep moving and gain momentum is critical to the time.
On Wed, Nov 14, 2012 at 8:23 AM, Trevor Parscal tparscal@wikimedia.orgwrote:
Olive - just because the Agora extension is designed to allow iterative tweaks doesn't mean all problems can be solved using iterative tweaks.
Roan and I could easily revive this patch from the dead in 2 hours. The questions is who's bringing the pizza?
- Trevor
On Wed, Nov 14, 2012 at 8:16 AM, Oliver Keyes okeyes@wikimedia.orgwrote:
Would it be worth holding off on this for a bit and then putting it in the Agora extension when we've got it put together, then? The entire point of the extension (well, other than "stop increasing developer workload and long-term maintenance duties" and "don't make Roan cry by breaking protocol") is to allow us to make small, iterative tweaks structured in such a way as to avoid FOUCs.
On 14 November 2012 16:12, Erik Moeller erik@wikimedia.org wrote:
On Wed, Nov 14, 2012 at 5:47 AM, Steven Walling swalling@wikimedia.org wrote:
In the interest of not waiting any more, my instinct is to deploy the
first
JS-reliant version, and defer perfecting the implementation based on
when
patches get submitted. :)
I would prefer that we not get too much in the habit of accepting degradation of front-end performance and long term maintainability of our codebase in order to push features out the door more quickly -- especially where it concerns code that gets loaded on every pageview. Existing poor practices and problems are not a good reason for exacerbating the issue (and indeed setting a poor example will reduce our ability to set standards for others).
As you yourself say, site performance really matters, and that includes flashes of unstyled content and DOM changes that shouldn't be necessary. Moreover, JS cruft leads to maintenance burden down the road.
I'm very accepting of doing this when our objective is to learn whether something is working or not (cf. ACUX). But the moment we actually decide that a change makes sense, we should implement it at a reasonable level of quality instead of layering on cruft.
So if you want to make the decision now that this change makes sense based on the data we already have, please do a clean implementation first. It can't become someone else's problem to do so.
Thanks, Erik -- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation
Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
-- Oliver Keyes Community Liaison, Product Development Wikimedia Foundation
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
On Wed, Nov 14, 2012 at 8:16 AM, Oliver Keyes okeyes@wikimedia.org wrote:
Would it be worth holding off on this for a bit and then putting it in the Agora extension when we've got it put together, then? The entire point of the extension (well, other than "stop increasing developer workload and long-term maintenance duties" and "don't make Roan cry by breaking protocol") is to allow us to make small, iterative tweaks structured in such a way as to avoid FOUCs.
As Trevor said: it's not a big amount of work, and I'm not really interested in creating dependencies where they don't already exist.
re: Erik's postion... Howie's email sums up the steps I'm going to take with S and Ori.
But I want to fundamentally reject a norm I think I am hearing here: that we should be working toward perfection upfront, rather than iteration. My philosophy is release something that is better than the current UI for the majority of users, then keep working until we feel good putting it in maintenance mode. You actually surface more and better feedback that way.
I'll also note we don't actually abide by the strictness of code and UI cleanliness we're talking about for browsers like IE6/7. For example, in testing it took about two seconds before the section edit link JS loaded. It took eight seconds or more for Vector's dropdown menus in the sidebar to close.
The experience of having a horde of people, most of whom are theoretically supposed to be enabling change, pile on a long overdue enhancement yet again is just depressing, and gives me little wonder why it takes so much effort to make even small improvements.
What Erik said. This should and probably can easily be implemented on the server-side; there is enough JS already, and we have to keep caring at least slightly about the poor souls stuck on a ten-year-old computer.
While we're at it, and since we're on the design list: may I propose an alternative design? These icons do not at all fit with the rest of the page; there are only two other icons on the entire page, and both are very discreet – the person icons next to "Log in" and the search icon. Additionally, the "Edit" is too large; it's even slightly larger than the body text!
And here's the alternative, live on pl.wikipedia for years, since – I think – 2006: https://pl.wikipedia.org/wiki/Soulside_Journey . The links are placed next to the heading (like in your design), but keep the brackets and are noticeably smaller than body text. When I first started editing pl.wiki years ago (before I started perusing en.wiki regularly), I though it's the default – it just looked right :)
As you can see, this also gives us a natural way of adding an editsection link for the zeroth (heading) section, which seems to be another thing you guys were (or are?) working on.
The code is implemented as a gadget and could probably be easily integrated into MW core (https://pl.wikipedia.org/wiki/MediaWiki:Gadget-modify-section-style.js + https://pl.wikipedia.org/wiki/MediaWiki:Gadget-modify-section-style.css), but, as I said, this really should be done server-side. I'm all for improving through iteration; but I'm also all for doing things right the first time.
-- Matma Rex
On Wed, Nov 14, 2012 at 10:31 PM, Steven Walling swalling@wikimedia.org wrote:
But I want to fundamentally reject a norm I think I am hearing here: that we should be working toward perfection upfront, rather than iteration.
I don't believe that's a fair characterization of what's been said. My main point is this: We need to take front-end performance and maintainability seriously, and it can't become someone else's problem. If the first deployment (or more accurately, the renewed deployment) of this feature causes some temporary degradation that is addressed a week later, fine. But let's please not just get it out the door just for the sake of it without addressing known issues. Once again, existing front-end performance issues are not a good reason to add new ones.
The experience of having a horde of people, most of whom are theoretically supposed to be enabling change, pile on a long overdue enhancement yet again is just depressing,
Actually, you've already gotten a free "pizza for labor" offer in this thread, pointers to concrete patches that address the issue, QA testing from yours truly on vacation, and lots of feedback on the existing implementation. Not a single person has objected to the change, and multiple people have expressed excitement about getting it out the door. I wouldn't call that a negative attitude towards change. I would call it lots of passion and energy in favor of making changes, and doing it right. Relax - we're all on the same team. :-)
Erik
On Nov 14, 2012, at 6:37 PM, Erik Moeller erik@wikimedia.org wrote:
On Wed, Nov 14, 2012 at 10:31 PM, Steven Walling swalling@wikimedia.org wrote:
But I want to fundamentally reject a norm I think I am hearing here: that we should be working toward perfection upfront, rather than iteration.
I don't believe that's a fair characterization of what's been said. My main point is this: We need to take front-end performance and maintainability seriously, and it can't become someone else's problem.
Forgive my boldness but here's a few points:
* We already ran the workaround js implementation 2 year ago. It works, it has proven successful in user testing and afaik the people from the Usability Initiative still believe so (Trevor, Roan, and co.)
* Wikia (not sure who was first with the idea) also did a similar thing. They also experienced a positive effect and went ahead to proceed to non-hacky implementation (altering the Skin and/or Parser to output the correct HTML, and add the relevant CSS to the skin stylesheet).
For example: http://southpark.wikia.com/wiki/South_Park#History They've had that for over a year now, no javascript involved (view source).
* Last year, as if it wasn't enough, we ran the js-hack experiment again on English Wikipedia for a while (with ClickTracking hooks on top of it). And once again, has proven successful.
So please, please, please. Stop discussing this hack. Yes, we could update that javascript module and deploy it once again (all it needs is to remove old references to ClickTracking again, the actual logic is still working fine. All it does is replace one link with a different link).
Instead start focussing on an acceptable implementation for the long term. PHP Parser tree markers, Skin output, edit section language fragmentation etc. those factors are relevant for discussion. Those factors are what held us back 2 years ago from doing that in the first place (because editsection links have a long history in MediaWiki PHP Parser, they're hard to change due to their language connection to user instead of content etc.). To become the default in MediaWiki.
This feature is not in need of javascript code. Any javascript, regardless of the shape or form, related to this feature is by definition obsolete and temporary. One could even argue and say this is outside the scope of the E teams. The usability team (which is sort of a 2009 E-like team equivalent) has already proven this. We've been there, done that. Now it is up to Platform to implement it for the long term in a way that doesn't break our servers. We no longer need event logging and what not, it'll be like any other native link in MediaWiki core.
-- Timo
Krinkle, 17/11/2012 20:09:
This feature is not in need of javascript code. Any javascript, regardless of the shape or form, related to this feature is by definition obsolete and temporary. One could even argue and say this is outside the scope of the E teams. The usability team (which is sort of a 2009 E-like team equivalent) has already proven this. We've been there, done that. Now it is up to Platform to implement it for the long term in a way that doesn't break our servers. We no longer need event logging and what not, it'll be like any other native link in MediaWiki core.
+1 Nothing to add, but a small point (à la wikitech-ambassadors?): as it's already been pointed out, most Wikimedia projects/big Wikipedias I remember have had something like that by default for years, so (when you're ready) please communicate the exact schedule for the deployment of the solution in MediaWiki core so that they can disable the custom JS in due time and avoid weird interactions. It will be wonderful to get rid of the custom JS!
Nemo
-- Ori Livneh ori@wikimedia.org
On Saturday, November 17, 2012 at 12:04 PM, Federico Leva (Nemo) wrote:
Krinkle, 17/11/2012 20:09:
This feature is not in need of javascript code. Any javascript, regardless of the shape or form, related to this feature is by definition obsolete and temporary. One could even argue and say this is outside the scope of the E teams. The usability team (which is sort of a 2009 E-like team equivalent) has already proven this. We've been there, done that. Now it is up to Platform to implement it for the long term in a way that doesn't break our servers. We no longer need event logging and what not, it'll be like any other native link in MediaWiki core.
+1 Nothing to add, but a small point (à la wikitech-ambassadors?): as it's already been pointed out, most Wikimedia projects/big Wikipedias I remember have had something like that by default for years, so (when you're ready) please communicate the exact schedule for the deployment of the solution in MediaWiki core so that they can disable the custom JS in due time and avoid weird interactions. It will be wonderful to get rid of the custom JS!
Nemo
My previous reply to the list bounced because I wasn't subscribed. Reproducing it here:
I made it perfectly clear from the outset that I consider a JavaScript implementation unacceptable, and went as far as saying I would not feel comfortable +2ing it. Not sure why I'm listed as a proponent of a hack. I'm in favor of releasing early and often, but outputting one form of markup and then shuffling it to be something else is not merely suboptimal -- it violates the basic guidelines for code tidiness that allow developers to move around a codebase as large as ours and be able to read and understand it.
I'm going to see to it that this gets implemented properly, either by reviewing the patch or writing it. I or someone from my team will coordinate deployment.
-- Ori Livneh ori@wikimedia.org
On Nov 17, 2012, at 9:04 PM, Federico Leva (Nemo) nemowiki@gmail.com wrote:
Krinkle, 17/11/2012 20:09:
This feature is not in need of javascript code. Any javascript, regardless of the shape or form, related to this feature is by definition obsolete and temporary. One could even argue and say this is outside the scope of the E teams. The usability team (which is sort of a 2009 E-like team equivalent) has already proven this. We've been there, done that. Now it is up to Platform to implement it for the long term in a way that doesn't break our servers. We no longer need event logging and what not, it'll be like any other native link in MediaWiki core.
+1 Nothing to add, but a small point (à la wikitech-ambassadors?): as it's already been pointed out, most Wikimedia projects/big Wikipedias I remember have had something like that by default for years, so (when you're ready) please communicate the exact schedule for the deployment of the solution in MediaWiki core so that they can disable the custom JS in due time and avoid weird interactions. It will be wonderful to get rid of the custom JS!
Nemo
Indeed. Though, I'm not sure if "most" and "default" is correct here. Would you be willing to work on a list of projects that have such a script (and while at it, note whether it is enabled by default and whether there is an opt-in/opt-out e.g. in form of a gadget).
-- Timo
On Nov 17, 2012 3:29 PM, "Krinkle" krinklemail@gmail.com wrote:
On Nov 17, 2012, at 9:04 PM, Federico Leva (Nemo) nemowiki@gmail.com
wrote:
Krinkle, 17/11/2012 20:09:
This feature is not in need of javascript code. Any javascript,
regardless of the shape or form, related to this feature is by definition obsolete and temporary. One could even argue and say this is outside the scope of the E teams. The usability team (which is sort of a 2009 E-like team equivalent) has already proven this. We've been there, done that. Now it is up to Platform to implement it for the long term in a way that doesn't break our servers. We no longer need event logging and what not, it'll be like any other native link in MediaWiki core.
+1 Nothing to add, but a small point (à la wikitech-ambassadors?): as it's
already been pointed out, most Wikimedia projects/big Wikipedias I remember have had something like that by default for years, so (when you're ready) please communicate the exact schedule for the deployment of the solution in MediaWiki core so that they can disable the custom JS in due time and avoid weird interactions.
It will be wonderful to get rid of the custom JS!
Nemo
Indeed. Though, I'm not sure if "most" and "default" is correct here. Would you
be willing to work on a list of projects that have such a script (and while at it, note whether it is enabled by default and whether there is an opt-in/opt-out e.g. in form of a gadget).
-- Timo
We've taken a first stab at such a list, and will share with Nemo et al if you want. Right it looks like quite a few of the top ten Wikipedias, for example, have changed to left aligned links.
Steven
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
Steven and I spoke about this yesterday. From a user persepctive, we don't want to implement something that degrades the experience on every page load, in the content area, for a not insignificant portion of users (IE 6 + 7 turns out to be a little less than 4% of our page views).
Steven is planning on touching base with Ori on this, and may have already. I can't speak to the amount of JS cruft/maintainability of our code base the JS hack would create, but I imagine Ori can, and perhaps work with Trevor on a long-term solution if that's what we want to do.
Howie
On Wed, Nov 14, 2012 at 8:12 AM, Erik Moeller erik@wikimedia.org wrote:
On Wed, Nov 14, 2012 at 5:47 AM, Steven Walling swalling@wikimedia.org wrote:
In the interest of not waiting any more, my instinct is to deploy the
first
JS-reliant version, and defer perfecting the implementation based on when patches get submitted. :)
I would prefer that we not get too much in the habit of accepting degradation of front-end performance and long term maintainability of our codebase in order to push features out the door more quickly -- especially where it concerns code that gets loaded on every pageview. Existing poor practices and problems are not a good reason for exacerbating the issue (and indeed setting a poor example will reduce our ability to set standards for others).
As you yourself say, site performance really matters, and that includes flashes of unstyled content and DOM changes that shouldn't be necessary. Moreover, JS cruft leads to maintenance burden down the road.
I'm very accepting of doing this when our objective is to learn whether something is working or not (cf. ACUX). But the moment we actually decide that a change makes sense, we should implement it at a reasonable level of quality instead of layering on cruft.
So if you want to make the decision now that this change makes sense based on the data we already have, please do a clean implementation first. It can't become someone else's problem to do so.
Thanks, Erik -- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation
Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
