Forum:New edit window

Forums: Index → Watercooler → New edit window

Fandom's forums are a place for the community to help other members.
To contact staff directly or to report bugs, please use Special:Contact.

Note: This topic has been unedited for 5902 days. It is considered archived - the discussion is over. Information in this thread may be out of date. Do not add to unless it really needs a response.

Johncenaeditwindow — The save bar on the edit window.

Johncenapreview — The floating save bar on the preview page.

Wikia is always looking for ways to improve the editing experience and today we're happy to announce a change to the edit window that will make editing easier and save time for experienced users and make the save button more visible for new users. The improved edit window has been live on several wikis for the last week, including Pro Wrestling and Muppet Wiki. This Wednesday, we'll be rolling it out site-wide.

Edit page

On the current edit page, it's necessary to scroll to see the save button, which is located in the middle of a group of buttons. On a long page, this can mean a lot of scrolling. Veteran wiki contributors are used to it, but a brand new contributor who clicks edit for the first time may not see the save button on the page.

The improved edit page adds a save bar at the bottom of the screen, which includes the same information as before -- an edit summary field, save button, minor edit button and watch button. However, now the edit window automatically resizes to fit your browser and the save button is always visible. All the the stuff which was under the edit window before is still there -- just scroll down. But no need to scroll to save or preview. This change doesn't remove anything from the page; it just highlights the important pieces and makes them more accessible.

Preview page

When previewing, the improved save bar floats at the bottom of the screen so you can scroll down to see the change that you've made. If your edit looks good, you can hit the save button without having to scroll down past the preview and the edit window.

Feedback

We plan to roll this out site-wide this Wednesday. After giving it a try, if your community would still prefer the old version of the edit window, just send us an email at community@wikia.com. We can switch your wiki back.

If you have any questions or comments, please leave feedback below!

Compatibility question

Is this a Monaco-only feature (please say yes) or have you kludged it into my precious Monobook also? Has this been tested with AutoWikiBrowser? If it proves incompatible, how quickly will you be able to switch a wiki back to the normal edit box? -- Darth Culator ^(Talk) 23:44, 19 January 2009 (UTC)
- After testing it on the Pro Wrestling wiki, I conclude that it doesn't affect Monobook much. It only appears to affect the positions of the "Minor edit" and "Watch this page" boxes. --Michaeldsuarez ^{(Talk) (Deeds)} 23:56, 19 January 2009 (UTC)

Works with iPhone, nice!

I'm pleasantly surprised to discover it detects the iPhone safari window size correctly. Good job! (-: -Afker ^{All hail AliceSoft!} 23:57, 19 January 2009 (UTC)

Working a bit haphazardly in Skyfire. --LordTBT ^Talk! 05:28, 25 January 2009 (UTC)

Necessary?

Nice work and all, but it isn't a huge deal. Saving can be done by hitting ctrl+s and previewing with ctrl+p. Exlonox 00:05, 20 January 2009 (UTC)

It's designed especially for people inexperienced with MediaWiki software, IMHO. Some of them don't even know how to copy and paste without a mouse. So I think it is a big deal to surface and highlight the save button to help less computer-inclined people with being involved on a wiki. -Afker ^{All hail AliceSoft!} 00:24, 20 January 2009 (UTC)

Well, what about the edit summary? The changes will make filling that out, faster. Good job. WHLfan (talk to me!) 02:36, 20 January 2009 (UTC)

On some french wikia, anon often click a red link, write "LOL" or other things like that then save the page. And i just show my friend today that we can use the mouse wheel while holding CTRL to zoom... — Tulip Vorlax 13:35, 20 January 2009 (UTC)

Generic thumbs up

Looks like a good idea to me. --Sky (talk) 01:26, 20 January 2009 (UTC)

Agreed! SkyeNiTessine (talk · contr) 01:57, 20 January 2009 (UTC)

vertical size

Why is it vertically sizing the edit box to fill the big 2048x1152 screen i have and making me have to move the mouse a lot more when editing many pages ? See this screen capture on ImageShack : [1] — Tulip Vorlax 04:37, 20 January 2009 (UTC)

Plus, i cannot even scroll the page to get to the edit links under it with that unless i click and drag the browser scrollbar or move the mouse all the way across the page to the left side.

If this is done by JS, i will need to set the function that does the vertical sizing to null like i've done with licenses template previewing. — Tulip Vorlax 05:12, 20 January 2009 (UTC)

I should have said it earlier, the only thing i dont like is the vertical sizing. Otherwise i like how it looks like. — Tulip Vorlax 07:22, 20 January 2009 (UTC)

There's a minimum height for people with small screens, but there isn't a maximum height for people with really big screens, like you. I'm glad you brought this up! I'll look into setting a maximum height for the edit window. I'll let you know what I find out... Thanks for asking about this. -- Danny (talk) 16:30, 20 January 2009 (UTC)

Ho! Glad to read that. By the way, i'm now on IE8... — Tulip Vorlax 13:04, 21 January 2009 (UTC)

I discovered something.

If the edit window dont contain much (so it's scrollbar is disabled), i dont have any problem with the new vertical size because i can still use the mouse wheel to reach the publish button or the edit links at bottom faster. But this wont be usefull if editing a big page. Maybe adding some witespace at the right of the edit but i dont know; if we have to move the mouse there, the browser scrollbar is not so far then.

By the way, even though my screen is 2048x1152, i dont set the browser window to fill that space; i have trouble reading too long lines of text. On my previous screen wich was 1440x900, i would set up the browser around 1024 in width. But now i'm more around 1152 in width.

Big widescreen LCD are begining to multiply in the shops and houses (at least where i live; it's almost all you can buy in FutureShop and BestBuy now). Soon (in 5 or 10 years?), web designers will be able to "forget" about 800x600 and 1024x768 resolutions. There will still be need to accomodate iPhone browsing though. But i dont think there's many people who contribute to wikis from that kind of keyboardless devices. But there's also NetBooks...

Oh! Just found something while writing this; if i vertically resize my browser window, the edit window resize too. The blue bar want to stay at bottom of the window. So that's why peeple complain about the resize happening after the page load; shifting all content and making (fasts) users click the wrong thing. — Tulip Vorlax 11:06, 22 January 2009 (UTC)

texte on button

As we can see on the same screen capture than of previous section, the text on the publish button is not centered on every language. Also, shouldn't the button auto resize to the size of the text ? — Tulip Vorlax 04:37, 20 January 2009 (UTC)

summary and more

The summary edit box is far too short now, and it doesn't extend. The edit box covers up the edit box scroll bar if there is one and the window is resized to be smaller. The layout of the system messages below the edit box on monobook is a mess. I don't see any advantage to the change on either Monobook or Monaco (I use Firefox 3). --◄mendel► 16:38, 21 January 2009 (UTC)

Not showing up at all now

On the Vintage Sewing Patterns wiki, the edit screen now does not allow to save at all and the new floating bar is not showing up, e.g. [[2]]. Any idea what the issue might be? And if it does not work, can we switch back? tarna 21:05, 21 January 2009 (UTC)

Contact staff using Special:Contact --Ciencia Al Poder (talk) ^-WikiDex 21:20, 21 January 2009 (UTC)

I did in parallel, thank you.tarna 23:01, 21 January 2009 (UTC)

Hi, I'm really sorry about this -- turns out that the new feature caused a conflict with another extension called MultiEdit that was tested on 8 wikis a while ago. We turned MultiEdit off, so now the Edit window works again for Vintage Patterns, Devil May Cry, Witcher, Metal Gear and the other handful of wikis where it was broken today. I'm sorry about that; it's the kind of thing that you'd only notice when you turn something on site-wide. -- Danny (talk) 01:33, 22 January 2009 (UTC)

To small

I like the new features, but the height of the edit box is now smaller. Could this be fixed? WHLfan (talk to me!) 06:15, 22 January 2009 (UTC)

Poll

middle stuff

Whats the point of preferences -> Editing -> rows__ columns__ options? Here is a comparison (Btw i have it set to 30 rows) between muppets and wrestling wikis and there is a huge gap of space lost on wrestling because of automatic/configured msgs that are placed on top of pages while editing that can be tools or warnings. (and that are default for since the creation of the starter wiki that its a template for new wikis. and thats not counting the wikiwide messages that some wikis constantly use so half the window is lost and the other half is too little.
Ok, so mm looks like a great idea but... Where is the GNU Free Documentation License & Wikia's terms of use warning for every submit? other way people can say that they are the owners since they did not agree to publish it under the GDFL?
well the cancel i never use it but the editing help?

Dont take me the wrong side i see it as a great idea but needs more refinement. why not make it floating like facebooks application/messenger bar and just add more space at the bottom to compensate in case a user scrolls all the way down?

As a personal comment i would have preferred the save to the left, center for the summary and right for preview with the other extras, with a force preview for non-logged/autoconfirm users.

--Cizagna ^(Talk) 22:23, 20 January 2009 (UTC)

For #1 and 2 -- those are determined by MediaWiki messages that can be changed locally on a wiki. That top section on new pages is set by MediaWiki:Newarticletext, and the copyright warning is MediaWiki:Copyrightwarning. This feature doesn't affect any of those messages or their placement. You still see the copyright warning and GFDL message when you scroll down.

I agree that Newarticletext pushes the window down -- and a lot of wikis have stuff at the top of edit pages that they don't necessarily need there. We're going to be looking at this stuff soon, to see if we can clean up some of the MediaWiki messages. Meanwhile, if there's a message that you'd like to shorten or change on your wiki, check out Special:AllMessages -- that'll tell you where to find the pages that you can edit. -- Danny (talk) 22:49, 20 January 2009 (UTC)

mmm i did not notice the GDFL it i will need to find a way to make it more noticeable.

I need to double check but editingTipsToggleDiv and wmuLinkDiv has a margin-top of 20px.

But still my question of what will happen with the customization inside preference? where you can set a fixed height in the fashion of rows?

in retrospective to TulipVorlax issues could that be pick pick from users preference?

--Cizagna ^(Talk) 23:31, 20 January 2009 (UTC)

Monobook

The changes kind of messed up the position of certain templates in Monobook. MediaWiki:Copyrightwarning is showing up in a weird spot in Monobook. Please see Wookieepedia and Star Wars Fanon for example. --Michaeldsuarez ^{(Talk) (Deeds)} 14:50, 21 January 2009 (UTC)

Please disable this for non-Monaco skins. --Pcj (T•C) 15:06, 21 January 2009 (UTC)

The copyright template has been positioned awkwardly in Monobook. It also affects the Show Changes button and Editing Help and Cancel links. —^BLUER一番。 16:32, 21 January 2009 (UTC)

Thanks for fixing the earlier problem, but now the edit summary window totally disappeared in Monobook. Can you fix that please? --Michaeldsuarez ^{(Talk) (Deeds)} 17:37, 21 January 2009 (UTC)

Monobook is fixed now. Thanks. --Michaeldsuarez ^{(Talk) (Deeds)} 19:22, 21 January 2009 (UTC)

Yeah, that is great. --◄mendel► 20:43, 21 January 2009 (UTC)

Edit window resizing

The edit window now resizes to fill the screen. However, it doesn't if you decide to preview or show changes. Why don't we deserve a larger edit area in these cases?

Further, the change only occurs after the page has finished loading, causing significant visual disturbance as all the page elements reshuffle to accommodate the change. This can mean that something that you were going to click on suddenly moves to somewhere else, which, suffice it to say, is incredibly irritating. It's a shame that the programmers have not heard of domready, as this would have circumvented the problem. Perhaps it's not too late to integrate this? --BBilge 15:22, 21 January 2009 (UTC)

move the css changes

can we move the css changes into an external css file so that i can override the styles through my own css file? as it is the last css to be applied is the ones that are within the page so there's no way to alter it back to the way it was. Thanks :) — Morder 15:44, 21 January 2009 (UTC)

and by we i mean you :) since obviously i don't have access to move it — Morder 16:18, 21 January 2009 (UTC)

Messing up predefined sumaries

On wikis that use JS to add a box to choose between some predefined sumary strings, things are messed up. See this for an exemple. Put the mouse over it to see things move a bit (at least in ie8 in compatibility mode).

Surely there a way to alter the JS script that add that combobox but i dont know how to do it. My JS skills arent good enough yet. — Tulip Vorlax 17:59, 21 January 2009 (UTC)

http://img140.imageshack.us/img140/9963/25012009152238iz5.jpg

I fixed this myself. See User talk:TulipVorlax#New edit window. — Tulip Vorlax 21:49, 25 January 2009 (UTC)

Ok, now i have to revert the fix i made on fr.guildwars JS files because the feature has been deactivated there. Duh ! (Or is it just something in prefs ? I dont think because i see it everywhere else on Wikia.) — Tulip Vorlax 22:38, 29 January 2009 (UTC)

Yeah, it was disabled on fr.guildwars - I can reenable if you wish. Kirkburn talk contr 12:54, 30 January 2009 (UTC)

No it's fine. Thanks. If the community there ever grow and ask for it, maybe, but until then, it's no big deal. I already revert the CSS and JS changed for the auto-sumaries (commenting it).

It just that i never really asked to disable it but i think some users of fr.guildwars would not like that thing anyway. They didn't even care to reply to me in the forums there though.

This had some good; i found a way for the autosumary drop down to have a better layout by enclosing it in a p element. — Tulip Vorlax 16:28, 30 January 2009 (UTC)

Floating

The floating edit bar seems like more of a gimmick than an actual feature, particularly since the only benefit it offers is the ability to save the page without previewing all of it, which frankly defeats the point of a preview in most cases. For this to be of any use, the bar should include a button that takes you back down to the edit window, which at least can save a lot of scrolling, particularly on very long pages. --BBilge 18:06, 21 January 2009 (UTC)

Wtf? Was the save button below the preview if you had it displayed below? I am asking because I have Preview above the edit box, and the buttons are always right below the box, so all the fancy stuff is no improvement at all. --◄mendel► 20:09, 21 January 2009 (UTC)

That skip to edit box link sounds like a pretty good idea to me, I'll suggest it. Remember, previews don't only occur between edits - you might make a change near the top of an article and just want to check it looks okay before saving. Kirkburn talk contr 17:24, 29 January 2009 (UTC)

The floating edit bar does not work on first edit if show preview on first edit option is enabled in preferences. --BBilge 12:13, 23 February 2009 (UTC)

Edit summary textbox size

In general, looks fine. But for users like me that use the edit summary extensively, also adding things on undo autosummaries, is annoying that I can't see the full text of the edit summary. If I want to add something at the end, I must click, push the "end" key and start typing. --Ciencia Al Poder (talk) ^-WikiDex 20:14, 21 January 2009 (UTC)

This is eventually what I was going to say. Felix Omni 00:11, 22 January 2009 (UTC)

I have asked our engineers to look at the possibility of making it so the summary box scales with the edit window. It should be possible, but we may not be able to do it until the next version of the feature comes out. --KyleH (talk) 22:44, 22 January 2009 (UTC)

You can try to shorten MediaWiki talk:Undo-summary, that's what we're about to do. --◄mendel► 09:20, 23 January 2009 (UTC)

I just checked with our engineers, and it looks like we should be able to make it so that the summary box automatically expands depending on the size of the window. Expect that change early next week. --KyleH (talk) 19:14, 23 January 2009 (UTC)

This change is now live :) Kirkburn talk contr 17:18, 29 January 2009 (UTC)

But this is still happening when the page finishes loading, and not sooner, when the dom is ready, to prevent a sudden disturbance as the page elements shift to accommodate scripting changes. Due to this bug, I've even inserted boilerplate markup into the page by clicking one of the buttons above the edit window, without realising it, when merely trying to click anywhere within the edit window to begin typing.

I urge you to take this issue seriously, especially since it's not an time-expensive change to make for anyone who knows what they're doing. As I understand it, you use the YUI library for your scripting, which already has extensive support for domready, and even two other alternative approaches for dealing with similar problems. --BBilge 00:46, 18 February 2009 (UTC)

Editing glitch

See Forum:Editing glitch on account of new feature?.

Just so folks know: The glitch that Blue Rook is talking about on that forum page isn't related to the edit window -- it's a glitch with the new WYSIWYG editor, which Wiki 24 started using yesterday. Scott is talking to 24 about it... -- Danny (talk) 17:48, 22 January 2009 (UTC)

Sorry, the "Wikia-wide implementation of the new editing window feature" statement Blue Rook made confused me, especially since the FCKeditor is only being tested on a few selected wikis. --Michaeldsuarez ^{(Talk) (Deeds)} 18:41, 22 January 2009 (UTC)

User-preferences

My bad! I can't get used to the new position of the buttons and checkboxes. I want to disable it for me, but I couldn't find any option in preferences to disable it. Please, add a preferences option to let users disable it, not only in the wiki I contribute, but on ALL wikis. --Ciencia Al Poder (talk) ^-WikiDex 19:24, 22 January 2009 (UTC)

Thanks for the feedback. As you found out, right now it is not possible to turn it off in you personal preferences. I have added that to the specifications for a future release. --KyleH (talk) 22:47, 22 January 2009 (UTC)

specifications for a future release? This sounds like we have to wait months until we could disable it in preferences. This is bad, really bad. One change like this must be shipped with an option to disable it via preferences. So there's an option to disable it on a wiki by request, but not by preferences? Well, until I do a JS hack to fix it myself, it's time to switch back to Monobook... --Ciencia Al Poder (talk) ^-WikiDex 17:06, 23 January 2009 (UTC)

Still waiting to a per-user opt-out in preferences, like any other extension. --Ciencia Al Poder (talk) ^-WikiDex 20:16, 25 February 2009 (UTC)

Edit summary preview

What happened to the edit summary preview? It doesn't show anymore. If you don't give any option to disable this extension, at least don't disable the existing MediaWiki features. Again, bad. --Ciencia Al Poder (talk) ^-WikiDex 15:41, 24 January 2009 (UTC)

The edit summary preview is in the same place it's always been; scroll down past the edit window to see it. We're working on adding this to individual preferences; we'll have an update on that early next week. Meanwhile, if the feature continues to bother you, let us know; we can turn it off for the wiki that you're an admin for. -- Danny (talk) 22:29, 24 January 2009 (UTC)

Oh, it's so down in the page that I didn't see it. Anyway, I have restored the original apearance of the summary, buttons, etc to the old position using JavaScript. --Ciencia Al Poder (talk) ^-WikiDex 11:51, 25 January 2009 (UTC)

Can you help to fix this then ? The box to select predefined sumaries conflict with the new layout of things. — Tulip Vorlax 19:25, 25 January 2009 (UTC)

Thanks, maybe you gave me the hit in the butt that i needed to look into this myself and fix it (as mentioned on User talk:TulipVorlax#New edit window. — Tulip Vorlax 21:51, 25 January 2009 (UTC)

Bug at Post a comment

When you use the the MediaWiki feature "post a comment" the subject/headline box is little (same as if there where a summary box) --Cizagna ^(Talk) 23:37, 25 January 2009 (UTC)

This should now be fixed. Kirkburn talk contr 17:17, 29 January 2009 (UTC)

New edit page preview notice

I assume this big and red warning is a "evolution" of the new edit window, that appears when previewing... I don't like/dislike it, but where is the page title?. Please, return it back. The page title should be always visible. It's useful to select it to copy & paste to make a link without underscores.

Of course, this also seems like wikia don't want us to disable it via user preferences --Ciencia Al Poder (talk) ^-WikiDex 21:10, 4 March 2009 (UTC)

I also dislike the fact that this is affecting Monobook. All of the MediaWiki messages are covering the page's title. --Michaeldsuarez ^{(Talk) (Deeds)} 22:34, 4 March 2009 (UTC)

I notice the missing page title too and wanted to come here to ask it back.

But weirdly enough, on fr.guildwars the "new edit window" is deactivated but that red untranslated preview message still appear.

— Tulip Vorlax 01:20, 5 March 2009 (UTC)

Section title remain unaffected on preview... — Tulip Vorlax 01:21, 5 March 2009 (UTC)

On behalf of everyone in #wookieepedia, Monaco or Monobook users, please kill this with fire. -- Darth Culator ^(Talk) 04:15, 5 March 2009 (UTC)

I think I'm not speaking only for myself when I say that those on #wowwiki would like this to be removed, too. --Gourra (talk) 07:44, 5 March 2009 (UTC)

on top of that it doesn't really "work" when you show preview below the edit box...especially since it says "scroll down"...worthless — Morder 07:59, 5 March 2009 (UTC)

You know, I looked at this and thought, "Hey, that's okay", but then I noticed that the page title had gone missing. I'm not even asking for it to be removed...just make the title show up. Please? The 888th Avatar ^(Talk) 08:21, 5 March 2009 (UTC)

Same as you for me.

If the thing ca be altered by a mediawiki page for translation and some CSS, then i mostly have no problem with it as long as page title return. It's missing even when creating a totally new page with input box. — Tulip Vorlax 09:10, 5 March 2009 (UTC)

#siteNotice,
.firstHeading,
#siteSub,
#contentSub,
#mw-anon-edit-warning,
.mw-newarticletext,
.previewnote,
#user_masthead,
.usermessage { display: block !important; }

#new_edit_page_preview_notice { background-color:transparent;color:000;width:99%;margin: -8px -8px 2px -8px;text-align:center;font-weight:bold;font-size:1.1em; }

(color will depend on skin setting, width was pissing me off when it expanded and made pages scroll)
I more or less expected them to do something like this, I'm still working on making mediawiki pages so they don't replace them, like the last time they screwed the interface up. -- Sixorish 11:12, 5 March 2009 (UTC)

It does appear the techs changed it so it does not appear in monobook, not sure when they plan on merging those changes (e.g. so it goes live). --User? 18:44, 5 March 2009 (UTC)

Monobook is suffering more

lets hope for that because in monobook looks even worse like Michaelsuarez mention. I was expecting they will do something to compensate for the new edit window --Cizagna ^(Talk) ^Dofus » 18:48, 05 March 2009 (UTC)

Update from Wikia

Hi everyone,

Thanks for all the feedback. In our excitement, we released some changes before they were ready. I'm really sorry that they caught you by surprise. We're going to turn off the latest round of changes for all wikis that do not have the rich text (WYSIWYG) editor enabled, and continue working on them to get them ready for release. Once the features are ready, we will post an announcement with the details of all the changes, as well as how to customize them to best suit your wiki (or disable them completely).

Again, I'm sorry for the confusion. I will follow up with more information soon.

Thanks! --KyleH (talk) 23:26, 5 March 2009 (UTC)

Another follow-up: we've made some adjustments to the feature, will be releasing it tomorrow. You can read more about it here. --KyleH (talk) 22:23, 17 March 2009 (UTC)

New WYSIWYG Editor

Why isn't this enabled for other namespaces? I'm really happy with it, why limit it to just a handful of namespaces? :p IsabelC 00:46, 6 March 2009 (UTC)

For certain namespaces it's just not appropriate - for example, the MediaWiki namespace contains a lot of HTML and CSS, which a WYSIWYG editor would not help with a lot. Are there any specific namespaces you had in mind? Kirkburn talk contr 18:12, 19 March 2009 (UTC)

tables

thanks for the WYSIWYGish editor

can I insert a new table with this editor?

while I'm actually going to edit an existing table from another page so I could just cut/paste the commands and edit the content, I'd prefer to have the option to start a table from scratch

--justdave49@mchsi.com 17:51, 16 March 2009 (UTC)

Yes, that option exists - it's on the toolbar. Kirkburn talk contr 18:02, 20 March 2009 (UTC)

Feature Request: Nowiki + Template Display

<snipped>

Hmm... Did I post in the wrong thread?! --Ronga 17:45, 23 April 2009 (UTC)

See Forum:New Visual Editor: Problems and Suggestions :) Kirkburn talk contr 18:07, 23 April 2009 (UTC)