Talk:Environment Survey/MediaWiki Extensions/Results

The page says "The most commonly used icon sets look exactly like Microsoft Office" but the icons have been completed redesigned in the latest version of Wikia's rich text editor, so this is no longer the case. See this page for a working example. Angela 07:54, 13 March 2009 (UTC)[reply]

Seeing File:Extension-FCKEditor.png, I think there's been some confusion between what Wikia has and what the default FCKEditor has. Please make sure the correct thing is being tested here. You're missing out on more than 12 months improvements that Wikia has made to that. Angela 11:55, 18 March 2009 (UTC)[reply]

We are basing our evaluations on what's currently in the MediaWiki SVN / made available to us. Trevor Parscal 18:26, 18 March 2009 (UTC)[reply]

MediaWiki compatability

This is a misnomer as we are talking about MediaWiki software. What you refer to is compatibility to the latest version of MediaWiki running the English Wikipedia. This is very much a moving target. You cannot categorically state that compatibility is the case. You need to test again when MediaWiki is updated on en.wp AND you have to test with an installation that has the same revisions for the extensions as well. Thanks, GerardM 08:09, 18 March 2009 (UTC)[reply]

Our intention to capture this information has not changed, however the importance of showing it in a purely quantitative chart has been reconsidered. Trevor Parscal 18:34, 18 March 2009 (UTC)[reply]

1.15 compatibility should be irrelevant

When you compare the different tools, you compare functionality. The functionality that is the most usable should be selected and when it means that you have to upgrade the code, that is what you do. Thanks, GerardM 11:05, 18 March 2009 (UTC)[reply]

1.15 compatibility is listed as evaluation criteria for informational purposes, and it will not be treated as hard requirement. --Shuhari 16:39, 18 March 2009 (UTC)[reply]

What we're trying to capture with the information about MediaWiki compatibility is how much we would have to upgrade the code to make it work with the latest release. In a hypothetical situation where two extensions are equal in all areas, except one of them is compatible with the latest MediaWiki version and the other is compatible with 1.01, the preference would be to go with the version that is more up to date, because we would have to spend less time bringing up to date. For the time being we've removed Compatibility from the main evaluation table because it's covered in the Completeness category, but the information is covered in the details section for each extension. --Arash Boostani 20:10, 18 March 2009 (UTC)[reply]

"we compare with the version in SVN"

The notion that the software is in the Wikimedia Foundation's SVN is not necessarily correct. I have pushed for the UNIWIKI extensions to be in WMF SVN, but given that many of these tools are developed by other organisations it is wrong to expect that they are in the WMF SVN. It is well known that Wikia has its own SVN and it is a gotspe that we have to tell you that.. you renting room in their office ... Thanks, GerardM 21:12, 18 March 2009 (UTC)[reply]

In the case of FCKEditor, we will be basing our technical evaluation on the code here. If there are other versions in other places we should be made aware of, we hope people will provide those resources to us. Our survey cannot be conducted on code we cannot access.

That version does not include hundreds of hours of improvements that Wikia has made to it over the past year or more. Wikia's Rich Text Editor (Wysiwyg) code is at svn.wikia-code.com. I believe Wikia's devs are in contact with you about this, but if not, you are welcome to email me (angela@wikia.com). There is also a demo site at wysiwyg.wikia.com. Angela 08:11, 19 March 2009 (UTC)[reply]

Please take a look at the page, as we've made some changes based on some clarification we've received from you and other sources. Trevor Parscal 23:58, 19 March 2009 (UTC)[reply]

wikEd comments

"Users on slower internet connections may experience a very disturbing amount of load time as the icon images are synchronously fetched. Our average load time was a few seconds for all icons to appear. The primary issue here is that the images are loading one-after-another and are blocking all other page rendering and user interaction until they are finished. On some browsers this loading occurred once for each article, which depending on use often translated into every time the user navigated to an edit page."

As with every image on a web page, these have to be loaded once and are then kept in the cache. They should not load again for every edit page. Please could you provide more details about this image loading issue on the wikEd discussion / bug page so that it can be fixed.

"Because of performance issues, the syntax highlighting only occurs when loading the edit box initially, or turning the syntax highlighting off and the on again. Depending on the user's computer and the length of the article, syntax highlighting may take anywhere from a fraction of a second to a few seconds. Toggling between syntax-highlighted mode and plain wiki-text mode was nearly instant, unless you made a change while in plain wiki-text mode in which case you were subjected to the same syntax-highlighting wait time issue."

Syntax highlighting delays are usually only noticed on very long articles and it is automatically turned off in case it takes longer than 2 seconds. Also, the highlighting is currently being overhauled and will probably be considerably sped up.

"Completeness: Although the intended features of this software seem to be completely implemented and it's currently deployed on Wikipedia as a gadget that users can turn on through user preferences, it's lack of support for most browsers and number of known issues and incompatibilities hint that this software has a long way to go."

The incompatibility for MS IE depends only on their missing support for the standard range object, as soon as this is provided in an upcoming release, wikEd will work in this browser. Which "known issues and incompatibilities" are you talking about? Most of them are probably either design decisions, browser limitations, or can be fixed quickly if somebody points them out on the wikEd discussion page. There is also a description for how to make user scripts and gadgets that alter the standard textarea compatible with wikEd under http://en.wikipedia.org/wiki/User:Cacycle/wikEd#Making_scripts_compatible_with_wikEd.

"User Features: Although this software provides an extensive set of text manipulation features, none of the common wiki elements are abstracted by a user interface making it in most cases no better than a plain text editor."

wikEd just uses a different approach to what the commenter favorizes, but this approach is is clearly better than plain text as judging by the thousands of people using it. I and others simply consider most "abstractions" (i.e. popups or separate editing areas for every content-containing wiki code element) from the wiki text as worse than plain text ;-)

"Extendable : Although any JavaScript software naturally lends itself to extendability, there is no functionality for configuring individual components or documented API for developing such components."

Customization and extendability is described in detail on http://en.wikipedia.org/wiki/User:Cacycle/wikEd_customization and http://en.wikipedia.org/wiki/User:Cacycle/wikEd_development#wikEd_API. The full set of customizations and options can be found on top of the code. wikEd supports custom buttons and functions and is highly customizable.

"Themable: Although it's possible to change images and CSS style sheets, there's no functionality for configuring individual themes and some style information is embedded within the JavaScript code itself."

wikEd's supports alternative skins, themes, and CSS styling. Only the default/fallback configuration is bundled with the code.

Cacycle 04:27, 12 July 2009 (UTC)[reply]

Desktop publishing experience

As someone who actually has some desktop publishing experience, I would like to point out that most users don't' have desktop publishing experience. Most users have type writer experience. They will use the carriage return at the end of lines; know how to change the font (ribbon/disk) to get a different style of lettering. This is significantly different from desktop publishing where users create and apply styles that are simple and consistent throughout the interface. I would suggest reading "What you see is Wiki - Questioning WYSIWYG in the Internet Age" for an introduction to WYSIWYM. Dispenser 17:19, 24 July 2009 (UTC)[reply]

I am far from convinced by your article as to the superiority of WYSIWYM over WYSIWYG editors. In fact, a WYSIWYG editor with a well designed user interface can lead users to use the right (but hidden) markups : for example if the "title" button is more prominent than the "font-size" one, people won't be tempted to use big font-size and underlines to mark a title (like what usually happens in word). Also, being based on the wiki mark-up language, the editor won't allow pictures to be moved anywhere like in Word, they will remain in the standard place, unless the user find the right menu/button to do whatever he wants to do. The mark-up language ensures that what you Mean and what you Get stay the same.

On the efficiency front, editing a wiki useally leads to at least some degree of trial and error thus losing the time gained on not having to use buttons. Also, software like word allow a lot of keyboard shortcuts removing the time lost on buttons. And for the expert wiki users, nothing prevent a WYSIWYG editor from optionally displaying markups.

I'm not sure what you mean by "Most users have type writer experience" but in my 2009 world no one use a type writer anymore and every one has used at least once a Word-like software.--Ryk V 00:30, 4 October 2009 (UTC)[reply]

In my experience have seen users:

Use spaces to center text
Ignore the numbering and bulleting button (including a PhD student/professor also the adviser to the college newspaper)
Hitting Return multiple times to create a page break
Manually sorting lists

So more or less they're treating Word as a proportional typewriter with spellchecker (and not everyone likes the spellchecker).

Now a WYSIWYG means that markup is hidden, if it wasn't then it would be a WYSIWYM editor. The problem with hiding it is that users will never learn it. This is not unlike hiding keyboard shortcuts (like they were Easter Eggs) to "prevent" confusing users, that Microsoft did until Office 2007. Also, in versions before Office 2007 the style formatter was on the same prominence as the font size, but I still need to show users that it exists.

Now the point I was trying to make was the most users don't have desktop publishing experience. (PS: I have nothing against buttons, btw. <font color=orange size=5>) Dispenser 05:39, 21 October 2009 (UTC)[reply]