Talk:Beta Features/Archive

Please share your feedback about Beta Features.

Nice
Letters are quite clear and that's really good, and the picture feature rocks--Kalogeropoulos (talk) 10:37, 22 November 2013 (UTC)

Good balance of new and old
It is necessary to keep and save the traditional functions to compact with the habit of the old users.117.35.130.95 05:29, 24 November 2013 (UTC)

Good Idea
The new approach to Beta software is really a good idea. 1) it lets users KNOW that there's official beta software to try. Previously most editors would be unaware of what's going on until a large-scale opt-out deployment unless they happened to follow pretty obscure backwaters of WMF wikis. 2) have a single spot for the discussion closely associated with the software is a huge boon. There's been software on Wikipedia where the discussion isn't centralized at all and that's extremely confusing and inefficient. 3) It just feels more of a social, communal approach for introducing new features. Thumbs up. Jason Quinn (talk) 21:54, 25 November 2013 (UTC)

How to channel feedback?
I think that the intention is to gather as much quality feedback for the particular features as possible. Therefore we should promote links to feature descriptions, talk pages but I think we should also point to BugZilla components where some issues can be quickly filed; also a link to BugZilla existing issues isn't a bad idea either.

But below introductory text we have links that says:

About Beta Features | Leave feedback

I think we should get rid of them or at most embed them into the introductory text (for those who want more about WMF initiative). I believe we should be promoting particular features, not a particular WMF programme, which is irrelevant to 95% of users. We probably don't want feedback accumulating on Talk:About Beta Features.

Also when I read on About Beta Features "Can you help us test Beta Features in coming days?" I have some trouble guessing is it about some features du jour we are testing right now (Formulae, etc.) or is it about Extension:BetaFeatures as a little supporting tool?

For example right now I am much more concerned with getting the preferences page and translations right and much less about actual features to be deployed and tested.

« Saper // talk » 00:16, 2 November 2013 (UTC)


 * Thanks, Saper. We wanted to get some immediate feedback about the whole 'Beta features' program, though your point is well taken that over time we could move these general links to a less prominent place, to invite more feedback on the features themselves. Fabrice Florin (WMF) (talk) 03:09, 12 November 2013 (UTC)

Name
Horrible, end-user-unfriendly name. We are scratching our head already how to translate it not to scare anybody with the IT slang. « Saper // talk » 23:30, 30 October 2013 (UTC)


 * What would be better name? Experimental features? I don't think that it's a unfriendly name, but translating maybe can be hard for some languages (e.g. if they don't have suitable word for beta). --Stryn (talk) 10:42, 1 November 2013 (UTC)
 * We have Gadgets, so may be Experiments ? « Saper // talk »  13:20, 1 November 2013 (UTC)
 * Experiments was the original name, it was changed due to possible confusion with "Labs" which is a separate project.—
 * Jaredzimmerman (WMF) (talk) 22:58, 1 November 2013 (UTC)
 * Didn't know that, honest! Still much better name than the current one. I dislike the word "beta" going mainstream (I think it was Google's fault:). I had also some other ideas, like testing ground (or similar) that that should be easy to convey to other languages/cultures (Poligon in Polish for example). Are we soon going to run out of words to describe tinkering? I hope, not! « Saper // talk »  23:09, 1 November 2013 (UTC)
 * I am sure "Experimental features" would not cause confusion with Labs (although "experiments" would), and I think translating that is easier than translating "Beta Features" (unless we consider "beta" to be a word in all languages, but that's just not true). "Experimental" describes the features better than "Beta", since that they are in beta is only relevant to developers (and may in fact not even apply to all of these features) while that they are experimental is what is relevant to users. -- Rastus Vernon (talk) 21:47, 2 November 2013 (UTC)
 * I'm sure the same applies to German. German users will not confuse "Experimental" and "Labs". I think "Beta" could be confusing because we already had "Beta" stuff in the past years that's not included here. For example [ the wikieditor toolbar stuff] is still called "wpusebetatoolbar" in the source. --TMg 12:27, 6 November 2013 (UTC)
 * User:Matma Rex filed 56537 for this. « Saper // talk »  13:05, 4 November 2013 (UTC)


 * Dear Saper, Stryn, Rastus Vernon and TMg: Thank you all for your good insights about the name of this program. We understand that 'Beta Features' is harder to translate than we had anticipated, and we appreciate all the good work of our volunteer translators in finding solutions to address this issue. As Jaredzimmerman (WMF) pointed out, we already considered 'Experiments' and 'Labs' as alternate names, but this would have created more confusion, due to the fact that we have other programs in place that already use these names. At this stage, it would be difficult for us to change the name in the middle of our worldwide release, since so many people have translated it already -- and we don't have enough resources to do a complete rebranding and overhaul in coming weeks. But we would be open to revisiting this next year, if it is a serious issue for a lot of users. Note that whatever name we use has to be short, so it doesn't take too much space in our user interface. Thanks for your understanding :) Fabrice Florin (WMF) (talk) 03:09, 12 November 2013 (UTC)
 * Speaking of the user interface. I really hope the "Beta" link at the top is only a test here at the MediaWiki wiki and will not be included in the Wikipedia wikis. This stuff belongs to the "Preferences", next to the "Gadgets" tab, nowhere else. Two different links at the same place that link to the same preferences are superfluous, confusing and will be threaded as disturbing by the users. Disable this please, when you deploy this. Thanks. --TMg 09:52, 12 November 2013 (UTC)


 * Don't translate! Since "beta" is immanently Greek, does not actually "mean" anything but a letter, has been used in this way in multiple environments to denote "hopefully working software", this word simply cannot be "translated", otherwise it would already have been incorporated into e.g. the English language as "the Greek letter β", but it has not.
 * It may have diminished to a symbol for something "unready", but symbols do not translate, either.--91.63.219.84 22:58, 26 November 2013 (UTC)
 * in French, 'bêta' means 'a little dumb', which is not very nice ;) --Hsarrazin (talk) 18:34, 6 January 2014 (UTC)

Checkboxes
…were originally imagined to be on a white background (beta features wasn't in prefs at that point) so it wasn't explicitly called out that they should actually have a white fill in all states, without the white fill they don't really look like controls (hover state would probably help too)— Jaredzimmerman (WMF) (talk) 23:02, 1 November 2013 (UTC)
 * I did not like them as they are inconsitent with the rest of the interface. « Saper // talk »  23:29, 1 November 2013 (UTC)
 * Saper, I'm sorry you don't like the check boxes, they are a first pass at the check mark in the new Mediawiki.ui controls that are in development currently. While they feel out of place now, when the rest of the controls are done they will feel more consistent.
 * Jaredzimmerman (WMF) (talk) 10:58, 19 November 2013 (UTC)
 * Jaredzimmerman, using "consistent" as an argument is odd. The most consistent look and feel is the default one. Every user knows how checkboxes look like in his browser. They look the same almost everywhere, Facebook, Twitter, you name it. What's the benefit of coming up with a design that's different from every other website? Why reinventing the wheel? --TMg 17:08, 19 November 2013 (UTC)
 * TMg, rarely do we get people suggesting we be more like facebook or twitter, but i understand what you're saying. The problem is that using the system default isn't actually consistency, a check box will look different if you're on a mac, or a pc, or linux, on ios, android, or windows phone. Our goal is a truly consistent UI experience across all devices and OSs, to do this we have to do something custom. It also allows us to have a consistent look and feel that matches the site, and can adapt to changing screen sizes to be just a usable on desktop with a mouse, or on a touchscreen device where you are using your finger.
 * Jaredzimmerman (WMF) (talk) 09:56, 20 November 2013 (UTC)
 * Again, I find these arguments odd. How many users have a Mac next to their PC or vice versa? Don't get me wrong. I understand how important the touch argument is. I actually like the current styles of the checkboxes and the search field. But if a styled UI element becomes completely unusable for some users, it's a no-go. Please focus on consistency that matters to the users: consistency across apps and websites on the same device. Consistency across devices mainly matters to designers and marketeers, much less to users. --TMg 11:47, 20 November 2013 (UTC)
 * TMg everyone cares about different things, and we get a lot of feedback about the visual design of the site (that it needs to be improved, modernized) we're not just making these changes out of the blue. Thank you for finding and bringing up the Opera 12 issue, and as mentioned below, we're in the process of fixing it right now. There will be some turbulence while we build out the new control library, where things look inconsistent in some places while we make updates. I'm glad you like the search button, Its getting closer, even if its not 100% there yet.
 * Jaredzimmerman (WMF) (talk) 12:08, 20 November 2013 (UTC)

In Opera 12 the checkboxes do not respond. I have to click them ten or twenty times to mark them. What's this? I don't see an error in the console. --TMg 00:33, 6 November 2013 (UTC)
 * It's a bug in Opera! It doesn't like it when you change the state of a hidden checkbox. I encountered it myself and I have already submitted a workaround to this that was merged, but it's not yet deployed. (Mark promised me it will be before the wider deployment on Thursday.) Matma Rex (talk) 09:31, 6 November 2013 (UTC)
 * Cool. Thanks! You know, I love my Opera 12 so much. --TMg 11:20, 6 November 2013 (UTC)

While I much prefer the default checkboxes, please at least make them as good as the default. Make it possible to see whether it is focused; make it respond to mouse down (and why not also hover). Wikimedia sites shouldn't be touch-only. Skalman (talk) 17:21, 22 November 2013 (UTC)

The checkboxes are still broken in Opera 12. Sometimes they are displayed but they always disappear when scrolling the page. @Matma Rex: Can you tell me what the problem is and what your patch did? --TMg 18:16, 10 January 2014 (UTC)
 * My patch apparently didn't do much. This is clearly an Opera bug, I didn't investigate it much. The checkboxes get toggled when you click them, but the visual state is not updated. Matma Rex (talk) 22:06, 10 January 2014 (UTC)
 * I played around with the CSS and found that setting the border to  fixes the problem in Opera 12. Solid colors make the background disappear. Same for every non-null radius. A very simple solution would be to remove the border completely and embed it into the background image. It's a fixed width and height image anyway. Using the sprite technique you can avoid having two images. --TMg 14:02, 13 January 2014 (UTC)

Thumbnails
I wanted to test the "VisualEditor formulae editing" feature but couldn't tell from preferences page what it does. I think this can be fixed by changing the description (remove the "remember" stuff and describe what it does instead) and the image ([//bits.wikimedia.org/static-1.23wmf2/extensions/VisualEditor/betafeatures-icon-VisualEditor-formulae.svg this one]). I suggest to make the image more realistic. The Σ bigger and darker and a popup like the one that opens when using the Σ in the editor. --TMg 12:18, 6 November 2013 (UTC)


 * Thanks, TMg, you make a good point that better descriptions and more realistic thumbnails would make it easier for people to understand what each feature does. I am passing on your recommendation to our design and development teams. Much appreciated. Fabrice Florin (WMF) (talk) 03:09, 12 November 2013 (UTC)


 * TMg, since many of the beta features will be more about behaviors that look & feel changes, I don't know that realistic screenshots will be particularly useful, especially shrunk down to such a small size. Your point about clarity in writing for beta feature description, we're trying to be brief, clear about what changes, and write in a language that is understandable by all users, not just highly technical ones.
 * Jaredzimmerman (WMF) (talk) 11:09, 19 November 2013 (UTC)
 * Jaredzimmerman, I think this is quite simple: Either the images are supposed to be screenshots or not. Either make them recognizable or don't make them look like screenshots. About what you call "technical": The current description is neither "brief" nor "clear about what changes":
 * Add experimental support [...] Superfluous information. Everything in the Beta tab is experimental.
 * to VisualEditor for creating and editing of mathematical formulae [...] I expected a "Visual formulae editor" like the Equation Editor in Word.
 * for testing, ahead of general release. [...] Again, superfluous. This is a description of what the Beta features are, not a description of the "formulae" feature.
 * Please remember to always review your changes before saving when using experimental features." This applies to everything you do with the Visual Editor. It's not specific for the "formulae" feature and does not help to understand what it is, what it does and how it works.
 * --TMg 16:28, 19 November 2013 (UTC)
 * TMg I didn't write the copy for the VE formula beta features but I'm happy to work with the team who did to clarify, The last point really is VE specific as most of the other Beta Features don't edit content. To your point about the icons, they are just that icons, they are symbolic representations of the feature, they aren't trying to show exactly what changes but give users an idea of what to look for when the feature is enabled. We really do appreciate your feedback on both the icons and the body copy for the beta features, And I'll work with the teams to get it to a place where it is clear and concise.
 * Jaredzimmerman (WMF) (talk) 09:38, 20 November 2013 (UTC)
 * As I said that's what I expected: give an idea of what to look for. The icon suggests there is a Σ in the toolbar but it is not. You have to click "More" and look for something entitled "LaTeX". If you click it, nothing happens. I still find this very confusing. At least use the same name everywhere. Either use "LaTeX" or "formulae" everywhere. Don't mix it. --TMg 11:27, 20 November 2013 (UTC)

In the beta features tab the thumbnails are low contrast. There is light grey text on light grey background. This is counter-intuitive; the big fat icons don't help to distinguish the entries they are for. Smaller (64x64) icons, were they properly coloured, would have been more helpful. --Gryllida 03:48, 25 November 2013 (UTC)

Enable all features
I was confused by the first tickbox, "Automatically enable all new beta features". I didn't read that properly and simply assumed that, being at the top, it allowed one-click activation of all the available features. Provide another option for this? Thanks. --Elitre (WMF) (talk) 13:54, 4 November 2013 (UTC)
 * I wasn't confused by this, but may be it should be called "subscribe to ... " or something like this? In a translation I am working on I say "I would like to participate in new experiments; enable new features as soon as they get installed." (rough translation). « Saper // talk »  14:01, 4 November 2013 (UTC)
 * I was confused about this as well, I think it should be clarified TheDJ (talk) 09:38, 5 November 2013 (UTC)
 * Same here. I don't think it should be clarified though -- it should just be what people intuit it to be. That is, enable all beta features, and automatically enable all future beta features. equazcion � 08:58, 8 Nov 2013 (UTC)
 * +1 to Equazcion's suggested solution. –Quiddity (talk) 21:49, 9 November 2013 (UTC)
 * +1. I was confused too. Helder 14:12, 8 November 2013 (UTC)


 * Dear Elitre, TheDJ, Equazcion, Quiddity, Helder and Saper: Thanks for pointing out this confusing feature and suggesting possible solutions! I also find this feature confusing, as I would expect it to enable all the current features right away, not just future ones -- for the reasons you mention above. My recommendation to the development team is to change both the functionality and the wording to say something like 'Automatically enable all current and new beta features'. This would match user expectations more closely than the current solution. It's a pleasure to be working with you all to improve this tool together :) Fabrice Florin (WMF) (talk) 03:09, 12 November 2013 (UTC)

A few questions

 * 1) Will the Beta word get highlighted, or will a number appear nearby, to let users know when there are new features they might want to test?
 * 2) Can the interface in each project please specify that other projects might have more features to test, and which ones, if not all the projects are getting all the features? Thanks! --Elitre (WMF) (talk) 15:05, 11 November 2013 (UTC)
 * Hi, Elitre (WMF) There is no plan for there to be a highlight or a number count on the Beta link right now, but the roadmap does talk about some ideas for alerting users as to when new features are available, such as popups (guided tour framework) and/or echo notifications
 * Not totally sure what you mean? all beta features will be available on all projects as long as they are relevant (e.g. if a site doesn't have any location based information associated with articles like wiktionary, the nearby feature won't be on that wiki) Beta Features are on mediawiki.org right now for testing purposes prior to being rolled out to all wikis.
 * Jaredzimmerman (WMF) (talk) 09:48, 20 November 2013 (UTC)
 * Thanks Jared, your example fits my question. If I primarily edit Wiktionary, I might still want to know that other wikis have Nearby as a feature (it's cool!) and might want to go elsewhere to try it. One of the reasons why I think BF is going to be awesome is that it will raise consciousness of how many features, tools and software are being built by WMF among all the communities because that work might be hardly seen. --Elitre (WMF) (talk) 09:58, 20 November 2013 (UTC)
 * At the moment there is no "master list" of beta features that is shown irrespective of the site you are on, but its an interesting request. I'm a little hesitant to list features you can't use on a specific project with the disclaimer you can "go to another project" to try them out but we'll think about a way to do it that makes sense, suggestions welcome.
 * Jaredzimmerman (WMF) (talk) 10:02, 20 November 2013 (UTC)
 * Along with text that carefully explains what's going on, we might actually provide a direct link to that other wiki where one can test the feature (so you might decide whether you'd like to have the user redirected to mw.org or anywhere else). --Elitre (WMF) (talk) 10:08, 20 November 2013 (UTC)
 * Interesting Elitre (WMF), but the problem is that now we're showing disabled features on some wikis, which feels a little annoying to users for me.
 * Jaredzimmerman (WMF) (talk) 11:16, 20 November 2013 (UTC)


 * FWIW, Nearby is enabled on sv-wikt. I was quite confused by it, since we don't have any location info... Skalman (talk) 17:26, 22 November 2013 (UTC)


 * Another question: When are updates to the beta functions pushed to the wikis? On the Talk pages to the features there are bug reports answered with "is already fixed in the code". Yeah, super, nice, but this doesn't solve the bug on my language.wikipedia.org. --2003:63:2F00:D800:1425:4F00:BFE7:16A6 08:45, 23 November 2013 (UTC)

Link in personal tools
Do we really need that ? It's getting a bit busy up there and hitting the right link after initial page load can be like a game of whack a mole, with many of them being loaded after the initial DOM. TheDJ (talk) 07:10, 12 November 2013 (UTC)
 * Isn't the "Beta" link at the top only a test here at the MediaWiki wiki? It doesn't make sense to have two identical links to the preferences. I really hope this is a misunderstanding and such a developers feature will not be deployed to all Wikimedia wikis. --TMg 10:14, 12 November 2013 (UTC)


 * 2 Notes.
 * See an identical discussion at m:Meta:Babel.
 * See also the related Beta Features proposal for a Compact Personal Bar.
 * HTH. –Quiddity (talk) 23:40, 17 November 2013 (UTC)
 * Another related discussion is which I've filed ages ago. —The preceding unsigned comment was added by  Matma Rex (talk • contribs) 17:56, 24 November 2013‎ (UTC)

Żadna w nowych funkcji nie spełnia oczekiwań.
Wypróbowałem nowe funkcje: Przeglądarka multimedów, Typography refresh, Near this page i Edycja wzorów matematycznych za pomocą VisualEditora. Zadna z nich, według mnie nie nadaje się do uzycia. Poza tym cały opis jest w obcym jezyku. Radek68 (dyskusja)  16:33, 25 December 2013 (UTC)


 * [en] Sorry that you did not like each of these Beta Features. If you have feedback about them, it would be hugely helpful if you could give it to those projects on their pages. When you say "nie nadaje się do uzycia" do you mean you don't think these are interesting, or not high quality enough, or something else?
 * [pl] Przykro mi, że nie lubisz każdej z tych funkcji Beta. Jeśli masz opinię na ich temat, byłoby to niezwykle pomocne, jeśli możesz dać go do tych projektów na swoich stronach. Kiedy mówisz "nie nadaje sie do uzycia" to znaczy, że nie sądzę, to ciekawe, czy zbyt niska jakość, czy coś innego?
 * Jdforrester (WMF) (talk) 06:04, 10 January 2014 (UTC)

Mechanism to mark a feature as depending on another
Beta Features might need to have a mechanism to describe a feature as depending on another. The VisualEditor Formula feature, for example, depends on the VisualEditor feature being enabled on wikis where it is opt-in. One solution is to prevent the user from enabling a feature before all the features it depends on are enabled, and another is to automatically enable the features required, with or without notifying the user that the other features have been enabled. Yet another is to put the features that depend on a feature under the feature they depend on and to indent them to show this. -- Rastus Vernon (talk) 21:57, 2 November 2013 (UTC)
 * Hey Rastus, on Test wiki I do see a red warning in my Preferences, "This feature requires the following feature to be enabled: VisualEditor". Do you think this is not enough? Thanks, --Elitre (WMF) (talk) 13:45, 4 November 2013 (UTC)
 * Aaand... it's gone (I can't see it anymore today). --Elitre (WMF) (talk) 13:25, 5 November 2013 (UTC)

HTML
This is ugly (taken from my experimental deployment):

w3m for example does not really get it. […] There is lots of classes and metadata but simple spaces between "information" and "discussion" are missing, not sure why we have  twice; lots of paragraphs which we don't want. « Saper // talk » 23:29, 1 November 2013 (UTC)
 * For the matter of the labels, we have one that's the "styled" checkbox (so it makes sense why you wouldn't see that), and the other which is the existing text label. Both are fairly necessary, unless you can think of a better way to do this...I guess if we're assuming JavaScript for the styled checkboxes anyway, we could add the chrome around them in JS itself, but I didn't see much need for that. I could revisit that decision fairly easily. --MarkTraceur (talk) 01:13, 22 November 2013 (UTC)

"Automatically enable all new beta features" not working (?)
This is not related to the fact that it does not do what people expect. At the start of the month, I enabled the then-available features (I think) and clicked the "Automatically enable all new beta features" checkbox. A few days ago, after a few new features were added (I think), and after checking the beta features page and adding them, I realized that they were not automatically added. Unfortunately, this is hard to test and reproduce due to the scarcity of new beta features. Fixefox, Windows 7:Jay8g (talk) 04:15, 24 November 2013 (UTC)
 * I expected "enable all new beta features" to enable the already existing features, not just ones introduced in the future. But that doesn't seem to be how it works - is that intended? a bug? Not clear. (If intended, I'd argue that's a design flaw - anyone bold enough to opt into unknown future features almost certainly also wants to opt into the known set of features, no?) -LVilla (WMF) (talk) 00:55, 4 December 2013 (UTC)
 * That is true, and has been discussed before. However, it seems to not be working at all, even the way it was designed for (automatically enable later features). Jay8g (talk) 01:39, 4 December 2013 (UTC)

Automatically enable all new beta features

 * It seem "Automatically enable all new beta features" doesn't work!--Emara (talk) 13:13, 5 December 2013 (UTC)

Table Controls
I would like to see functionality to add columns and rows to tables. Timboliu (talk) 08:17, 8 November 2013 (UTC)
 * Hey Timboliu, are you perhaps suggesting that this feature is made available in VisualEditor? In this case, this is a common request - and you can follow updates via this tracking bug. --Elitre (WMF) (talk) 10:46, 8 November 2013 (UTC)

Crosspost list from German Wikipedia
At de:Wikipedia:Umfragen/Technische Wünsche the German community is currently preparing a giant list of "Beta features" they "would like to see". A few currently top voted features are: --TMg 10:40, 12 November 2013 (UTC)
 * Cross-wiki watchlist.
 * Search in the category tree, in old versions, in logfiles and histories, search for colors in images and much more.
 * Preview of  while editing sections (5984).
 * Real possibility to move files to Commons.
 * Less JavaScript bulk users don't really need.

suggestions based on Tamil Version
I would like to bring these suggestions to your attention based on my experience based on Tamil wikipedia. More over these are generic suggestions. --Neechalkaran (talk) 01:10, 22 November 2013 (UTC)
 * Dead links should remain in same color(red). If found dead interlinks are visible in blue color
 * Need transliteration features for non english versions

Thank You, no
I am satisfied with everything in the existing functions. Why you need to clutter up the editing of the new, purely ornamental, functions? Lesless (talk) 08:26, 22 November 2013 (UTC)

Some (typography) seem to be harmless, others ("media viewer") are not just irritating, they are ... insurmountable? You've added an extra screen in between wikipedia and commons (instead of one click), and the "take me where I wanted to" "button" is set in five-pixel typeface. Screen loupe and batteries not included. Brilliant. I suppose that when this thing goes live and mandatory, the only way to navigate between wikipedia and commons will be cut-and-pasting filenames. Retired electrician (talk) 10:03, 22 November 2013 (UTC)

After testing "typography" and "Media viewer" I agree with the colleagues above. New typefaces do not make the text look any better than before, the media viewer prevents me from going directly to the commons, where I typically want to read the original description of the file and/or the licence. Gżdacz (talk) 19:21, 22 December 2013 (UTC)

New gallery support by default
A while ago, new gallery support was introduced, but only when specifically added to a page. As a step on the way to possibly making a new mode (probably "packed") the default, it could be made default as a beta feature. (It could also be changed through a standard preference.) Jay8g (talk) 00:25, 24 November 2013 (UTC)

Mark
In Spanish Wikipedia's preferences, cannot mark the beta features, to use them.--Diamondland (talk) 08:35, 10 January 2014 (UTC)