Personally I would urge much focus. Creating a beta feature with a "fixed header element that allows someone to report an issue on their current page" seems like overkill. It solves a problem the beta feature discussions forums already solve and I'm already stretched thin in what I am being asked to do.
The only real reason to have a beta feature here is if we plan on enabling mediawiki ui form elements everywhere, which is what I thought we were working for. This would be a super simple beta feature to knock up as currently it is only turning on a global variable, the only hard bit creating an image for it to show up on the beta features preference page. I worry that currently no one is looking at the website Matt setup, so I'd be keen to explore a way of getting this project more visibility and keep it moving whilst there is still momentum. On Thu, Aug 21, 2014 at 3:36 PM, Jared Zimmerman < [email protected]> wrote: > Yes, I agree completely, we need to do a lot of cleanup to what we have > before any major public release, and we also need a logical place to corral > things before a release that we can evaluate everything in tandem. We can > discuss whether this is a beta feature or a test server. > > > > *Jared Zimmerman * \\ Director of User Experience \\ Wikimedia > Foundation > M +1 415 609 4043 \\ @jaredzimmerman <http://loo.ms/g0> > > > > On Thu, Aug 21, 2014 at 3:28 PM, Steven Walling <[email protected]> > wrote: > >> >> On Thu, Aug 21, 2014 at 3:16 PM, Jared Zimmerman < >> [email protected]> wrote: >> >>> Steven, from the very beginning of Beta Features we acknowledged their >>> would be Beta Features that were only for experimenting and exploring, that >>> they wouldn't graduate. So this isn't a concern of mine. I think the only >>> way we'll be able to get a good solid review of the controls, both >>> internally and from users is to package it up as a beta feature and let >>> people use the real production site with all the new controls in place. >>> Matt's test instance is great but won't serve the same purpose. >> >> >> Having a new feature we want to try and test but then decide not graduate >> is one thing. Nearby for Desktop was a good example of this. But releasing >> a beta feature we definitely never intend to graduate is just silly and a >> waste of resources. We want everything to look and feel consistent, >> hopefully with the nascent mediawiki.ui style as the standard. We mostly >> definitely do want to graduate new button and form styles to all core >> forms. It's actually one of the main complaints from the community early on >> in the process, that we were doing things in a piecemeal fashion. >> >> Before we push out a production beta feature, we still have work we can >> and should do to clean up button and form styles in mediawiki.ui, which we >> can use Labs for. For instance, the crappy typography in the buttons which >> is off-specification, the lack of appropriate padding for buttons, the >> messy state of the wikitext edit form with mw.ui controls, the inconsistent >> style of placeholders, and lots more. >> >> -- >> Steven Walling, >> Product Manager >> https://wikimediafoundation.org/ >> >> _______________________________________________ >> Design mailing list >> [email protected] >> https://lists.wikimedia.org/mailman/listinfo/design >> >> > > _______________________________________________ > Design mailing list > [email protected] > https://lists.wikimedia.org/mailman/listinfo/design > > -- Jon Robson * http://jonrobson.me.uk * https://www.facebook.com/jonrobson * @rakugojon
_______________________________________________ Design mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/design
