+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