User talk:Yair rand/adddefinition.js/archive
Add topicAppearance
Latest comment: 14 years ago by Msh210 in topic [1]
The following discussion has been moved from the page User talk:Msh210.
This discussion is no longer live and is left here as an archive. Please do not modify this conversation, but feel free to discuss its conclusions.
Does clicking on a spot to place the definition not do anything, or is the way to add definitions not clear enough? --Yair rand (talk) 21:30, 13 September 2010 (UTC)
- Well, both: I thought that clicking on spot was the thing to do, but that wasn't quite clear enough — and then it didn't work. (In fact, I couldn't do anything on that page except click a link, and the address bar had 'died' too. I had to follow a link to get rid of the definition adder.)—msh210℠ 19:21, 14 September 2010 (UTC)
- What browser? --Yair rand (talk) 03:07, 16 September 2010 (UTC)
- Firefox 3.6.9.—msh210℠ 19:08, 16 September 2010 (UTC)
- Strange, I checked that browser a number of times and it worked. --Yair rand (talk) 18:15, 17 September 2010 (UTC)
- Firefox 3.6.9.—msh210℠ 19:08, 16 September 2010 (UTC)
- I believe that most of that is the intended behavior; that is, the intended behavior is a bit broken. Once you've clicked "Add definition", you can't close the definition-box or move the focus away from it (even to the address bar) until you click on an ordered-list. This should be fixed. But the only part of your description that seems like unintended behavior is the implication that it doesn't even work to click on an ordered list? —RuakhTALK 03:30, 16 September 2010 (UTC)
- I thought the intended behavior was okay. How would you have it? --Yair rand (talk) 03:52, 16 September 2010 (UTC)
- The intended behavior isn't bad, but the problem is that not everyone who clicks on "add definition" will actually mean to add a definition; they may have thought it would open the edit-page, or they may have meant to click on a different link, or they're just curious what it is, or maybe they really did mean to use it but then they change their minds (for whatever reason). But after you click "add definition", you can't do anything until you tell it where you want the definition to go, after which point you can choose to undo. I think it would be much better if, when the definition-box loses the focus, it simply disappeared. Any text in there should still be remembered (in a JS variable or the like), and restored if the user then clicks "add definition" again. —RuakhTALK 19:02, 16 September 2010 (UTC) Update: Yair has made the change I described, and it seems to work perfectly. Thanks, Yair! —RuakhTALK 15:24, 17 September 2010 (UTC)
- By the way, I think the interface is really cool when it is what the user wants. I hope the problems do get resolved, so the script can be restored. :-) —RuakhTALK 19:04, 16 September 2010 (UTC)
- I agree completely with Ruakh (19:02, 16 September 2010 (UTC)).—msh210℠ 19:08, 16 September 2010 (UTC)
- Well, except his first six words.—msh210℠ 19:09, 16 September 2010 (UTC)
- Re the "Update" (Ruakh, 15:24, 17 September 2010 (UTC)): Yes, thanks for fixing that. Some points: (1) The definition must be placed after it's typed. Allowing either first would be nice. (That's a feature request, not a bug report.) (2) Allowing the definition to be placed anywhere in the list, not just last, would be helpful. (That's also a feature request, but one which is more important IMO.) (3) I didn't try it with sub-<ol>s, which a number of our entries have; does it work? (4) If you choose to (or, for some reason, must necessarily) ignore #2, so the definition can only be added to the end of the list, can, at least, clicking anywhere in the list put it at the list's end? Currently, there's a very small area of screen that will allow the definition to be placed, and the little line that appears when that area is mousovered is hard to see, so it's very hard to see where to place the definition. (5) Perhaps there should be a little note "Type in your definition, drag it to where it should be placed, and click there to place it." or something, to clarify. OTOH maybe most users are savvier than I. (6) IMO when adding a new sense of an existing word-POS combination, one should pretty much always add a usex, so as to distinguish the sense from existing senses. (Technical definitions like the topological sense of foliation may be an exception.) This feature should thus allow the addition of usexes also.(Again, that's just a feature request, but I think it's an important one. Note that someone who wants to add a usex needs to re-edit the page, wasting an edit and making the script as it is now useless (for him).)—msh210℠ 16:27, 17 September 2010 (UTC)
- (1) I'm not sure how that would be workable, since something needs to activate the preview, and I'd rather not require an extra click if avoidable. (3) It can't insert definitions into sub-<ol>s, and I'm not even sure if it's necessary that it does. (I'm pretty sure that's not even allowed by policy, and I don't think we have more than a couple entries with them.) (4) That's actually been there since the beginning. (5) That's a good idea, but I'm not sure where it could be placed. Maybe above or below the input box? (6) If User:Yair rand/editor.js ("Add expandable editing options side box next to definitions" in PREFS) is enabled at the same time as adddefinition.js, it does add the definition side box that can be used to add usexes to the newly added definition. I don't expect it to be on by default anytime soon, but it makes it seem rather redundant to specifically add a usex adder to adddefinition.js. --Yair rand (talk) 18:15, 17 September 2010 (UTC)
- (4) Didn't work for me. (5) That's what I was thinking. That's one line of text, not a lot of space. (6) Good point.—msh210℠ 14:50, 19 September 2010 (UTC)
- (1) I'm not sure how that would be workable, since something needs to activate the preview, and I'd rather not require an extra click if avoidable. (3) It can't insert definitions into sub-<ol>s, and I'm not even sure if it's necessary that it does. (I'm pretty sure that's not even allowed by policy, and I don't think we have more than a couple entries with them.) (4) That's actually been there since the beginning. (5) That's a good idea, but I'm not sure where it could be placed. Maybe above or below the input box? (6) If User:Yair rand/editor.js ("Add expandable editing options side box next to definitions" in PREFS) is enabled at the same time as adddefinition.js, it does add the definition side box that can be used to add usexes to the newly added definition. I don't expect it to be on by default anytime soon, but it makes it seem rather redundant to specifically add a usex adder to adddefinition.js. --Yair rand (talk) 18:15, 17 September 2010 (UTC)
- The intended behavior isn't bad, but the problem is that not everyone who clicks on "add definition" will actually mean to add a definition; they may have thought it would open the edit-page, or they may have meant to click on a different link, or they're just curious what it is, or maybe they really did mean to use it but then they change their minds (for whatever reason). But after you click "add definition", you can't do anything until you tell it where you want the definition to go, after which point you can choose to undo. I think it would be much better if, when the definition-box loses the focus, it simply disappeared. Any text in there should still be remembered (in a JS variable or the like), and restored if the user then clicks "add definition" again. —RuakhTALK 19:02, 16 September 2010 (UTC) Update: Yair has made the change I described, and it seems to work perfectly. Thanks, Yair! —RuakhTALK 15:24, 17 September 2010 (UTC)
- I thought the intended behavior was okay. How would you have it? --Yair rand (talk) 03:52, 16 September 2010 (UTC)
- What browser? --Yair rand (talk) 03:07, 16 September 2010 (UTC)