[02:02:57] Hello. Would there be any objection to having the logo scale on the client side? [02:04:45] (If so, what would be the best way to approach this issue?) [02:09:21] roberthl: so bad? [02:09:59] Hmm? [02:11:30] I think you can do whatever you want on client side [02:12:00] that doesn t effect the official look of wp.... so go for it [02:12:57] Well I mean in the published stylsheet. [02:13:12] By client side I mean in pure CSS. [09:36:03] hi RoanKattouw [09:36:18] Good morning [09:38:36] you still haven't pushed out the change in widening the search box right? [09:41:35] No [09:42:03] can you stage the change on the prototype? [09:42:09] I can [09:42:14] I'd have to code it first, but that's probably triival [09:43:00] as i communicated over the weekend, widening will decrease the frequency of problematic behavior [09:45:51] You mean the ... behavior? [09:46:50] you disabled ellipsis already [09:47:17] now the end of the sentence is cut-off [09:47:28] so we are no better either way [09:48:22] Right [09:50:49] so i was hoping that you staged the new width and coordinated the testing with calcey, but i guess not ;) [10:00:32] No, very sorry about that, I've been busy with school [10:00:48] Seriously though this doesn't really need serious testing, except maybe for different browser sizes [10:00:54] It's just adjusting the width rule in the CSS [10:07:35] right [10:07:46] -> browser testing [10:08:22] but to do window size testing for ten different variation can take time, and i thought calcey can reduce your time [10:08:28] but we can share browser testing [10:09:08] let me know when it is ready [10:09:26] we'll divide the work to verify the layout on various window sizes [10:10:02] we need to make sure that tab overlapping doesn't happen regardless the size [10:35:48] nkomura: OK I'm gonna play with this now, I expect to have something within 10-15 mins [10:35:55] great [10:41:00] nkomura: You wanted +20% , right? [10:41:26] right [10:41:35] i can look-up exact ratio [10:42:01] i wanted to follow W3C's recommendation on the number of characters fit in the search field [10:42:29] wait [10:42:35] it's more than 20% [10:44:26] it is recommended 25 characters and we currently have 16 character-wide [10:44:28] Current width is 9em, Monobook's search box is 10.9em [10:44:30] OK [10:44:32] so it is actually 50% more [10:44:45] 25/16*9 ~ 14 [10:44:48] right, but the monobook search suggestion expands [10:44:48] So I'll use 14em [10:44:56] Yes, because there is space to the left [10:44:58] *right [10:45:16] let's see how that fits [10:45:21] OK I'm gonna prototype this on prototype now [10:45:27] thanks [10:45:38] You can test it on any other wiki by adding this line to [[User:Yourname/vector.css]]: [10:45:51] #simpleSearch input#searchInput { width: 14em; } [10:47:43] it brings back the two old buttons [10:48:04] No [10:48:09] Shouldn't do [10:48:13] just copied the suggested css to ja.wp [10:48:26] jawp doesn't have SimpleSearch yet [10:48:29] That's another thing [10:48:35] k [10:48:41] We never enabled SimpleSearch or CollapsibleTabs as part of any beta [10:48:48] *CollNav [10:48:55] you mention other languages [10:49:02] i guess you meant on prototype ;) [10:49:06] It was requested we enable at least CollNav and possible SS as well in beta mode on all wikis [10:49:13] I actually meant enwiki and commons, sorry for the confusion [10:49:34] But I think the request to make SimpleSearch and CollNav part of the beta for non-(enwiki, commons) wikis makes sense [10:50:10] did you update the prototype? [10:50:12] i don't see it yet [10:51:07] Not yet, on it [10:55:35] OK the prototypes are updating no [10:55:36] *now [10:55:39] en should have it alraedy [10:55:52] thanks [10:55:59] *nkomura goes to a conf room [10:56:21] Oh it's 7 already [10:56:25] *RoanKattouw grabs headset [10:58:43] shoot.... I cannot register to voip.wikimedia for any reason... [11:04:20] http://prototype.wikimedia.org/en.wikipedia.org [11:04:58] http://commons.wikimedia.org/wiki/Talk:Wikipedia/2.0 [11:05:14] stevertigo has a done a good mockup [11:11:41] RoanKattouw: we having the usability meeting? if so what number are you guys on? [11:12:42] 2002 [11:13:43] ugh, I am missing it again :/ [11:24:09] [[commons:File talk:Wikipedia_in_Arabic_script_languages_in_KACST_Office.svg]] Some very good discussion about arabic text going on here. [11:45:55] ugh [12:17:15] nkomura: When do you want to push the widening of the search box? [12:45:33] hey RoanKattouw [12:45:40] just getting back to my desk [12:48:44] enhydra, do you have easy access to Medeyko ? [12:49:14] cary, not sure [12:49:23] cary, he has his phone published at [[ru:user:Drbug]] [12:49:34] enhydra, he just needs to respond to a certain letter I sent him. [12:49:54] Oh, he is Drbug... /me doesn't know why I got confused. [12:51:00] howie: will you validate the layout with the extended search box in safari? [12:51:01] http://prototype.wikimedia.org/en.wikipedia.org/Second_Battle_of_Swat [12:51:18] and in German: http://prototype.wikimedia.org/de.wikipedia.org/Biennale_di_Venezia [12:52:24] i'm going to test in IE on Windows [12:52:40] RoanKattouw: we should be ready in 10-15 minutes to deploy the change [12:52:51] testing now [12:53:06] *nkomura goes to switch to Windows, be back in 10-15 minutes [12:53:10] OK [12:53:17] Give me the green light when you're ready [12:54:09] will do [12:54:14] RoanKattouw: pressing enter with a search term defaults to the search page, correct? [12:54:19] No [12:54:24] It defaults to the "Go" action [12:54:38] If there is a page by that exact name (modulo capitalization), go there [12:54:43] If not, go to the search results page [12:55:03] hmmm [12:55:14] To get the search page you need to click the "Containing..." thingy, which we don't have right now because SimpleSearch is disabled [12:55:27] (That's another point of criticism, the Search action is kinda gone right now) [12:55:30] ok [12:59:30] the extended search bar looks good on safari [12:59:43] i haven't uncovered any issues [13:01:21] I can hardly imagine there being any issuees [13:01:27] All I did was change 9em to 14em in the CSS [13:04:00] Hm I was just thinking we'll want to expand to the other side in RT+L [13:04:08] So to the left in LTR and to the right in RT+L [13:04:15] Because presumably the search box will be on the left [13:05:58] pdhanda: here is erik zachte's browser distribution: http://stats.wikimedia.org/wikimedia/squids/SquidReportClients.htm [13:06:05] he doesn't have by project tho [13:06:18] but he did email me the distribution by project for one day in november [13:06:43] but that's probably too short of a timeframe to be worth publishing [13:18:12] howief thanks, I was jus t pulling data out of that [13:18:23] anyone knows what the source of this document is http://spreadsheets0.google.com/ccc?key=tnad4SJbFA8eEj8DKj0TxcA&hl=en [13:19:02] i know they came from the squid logs, but do we know how we did the alanysis [13:24:44] *nkomura is back [13:24:52] Vista is slow... [13:24:56] hew [13:24:58] phew [13:25:43] so 800x600 with the extended search field in IE8, Chrome 4, and Opera on Windows Vista looked good [13:27:57] Good [13:28:06] RoanKattouw: i wanted to verify it on german language especially [13:28:18] as the change will affect german beta users [13:28:18] Ah yes [13:28:40] Ah, actually [13:28:49] SimpleSearch isn't enabled on dewiki (yet) [13:29:06] Or rather [13:29:06] left nav either... [13:29:10] Exactly [13:29:19] that's a separate discussion [13:29:23] That's something I want to change, but I wanted to get your approval for that first [13:29:38] if it is not impacted immediately, our deployment is simpler [13:29:57] I think dewiki should not be impacted by my change [13:29:57] let's discuss updating all betas separately [13:30:00] Yes [13:30:41] we are good to go pushing the change to widen the search field to 25 characters long i.e. 14em [13:33:03] please deploy [13:33:59] Just a miniute [13:45:00] nkomura: Done [13:45:13] Search box should now be 14em on enwiki and Commons [13:45:13] cool thanks! [13:45:50] will you purge server side caching? [13:47:14] Did that [13:47:28] It might not show up for anons immediately [13:47:34] But that's something I can't do anything abuot [13:47:42] flipzagging: is it possible to deploy the "help bubbles" on the prototype, or is it too early? [13:48:10] As a logged-in user you should see it immediately [13:48:12] RoanKattouw: we can live with that ;) [13:48:56] looks good [13:49:18] awesome! [13:49:22] only checked with FF and Chrome on Ubuntu [13:49:32] howief: will you check with safari? [13:49:40] looks good so far [13:51:10] this is very exciting [13:51:22] i'm getting many more characters in the autosuggest [13:51:34] how many characters was the monobook search box? [13:51:39] nkomura: are we meeting at 1:30? [13:51:45] howief: like 10 [13:51:53] take it back [13:51:56] 15 or so [13:52:03] but the suggestion expands [13:52:10] guillom: yes :-) [13:52:18] ok [13:52:21] Monobook: 10.9em, standard Vector: 9em, Roan-improved Vector: 14em [13:52:24] i'm hoping to grab lunch before then, which may be a challenge [13:52:51] so we've increased the size by ~30% compared to monobook [13:53:12] close to 50% i think [13:54:26] Close to 50% relative to standard Vector [13:55:04] but compared to monobook, it's about 30% if my math is right: (14-10.9)/10.9=28.4% [13:55:49] but why do you compare to monobook? they function differently :-) [13:56:06] true [13:57:12] guillom: sorry, didn't see your q until now [13:57:26] guillom: I probably could deploy them [13:57:43] ok [13:57:59] I'd like to play a bit with them before our meeting (if possible) [13:58:09] ok, working on it now [14:01:47] thanks! [14:03:20] Here's the update i'm going to post [14:03:24] The width of the search box has been increased by approximately 56%, which also increases the width allocated for the auto-suggestions. We're still working on some different treatments of the auto-suggestions to better handle very long article names. [14:04:24] any issues with that? [14:05:35] Sounds perfect [14:17:01] nkomura: I have made it so the suggestions box expands to the left up to twice the width of the search box, and staged it on prototype [14:17:08] Ah strike that [14:17:13] Am staging it on prototype [14:17:58] awesome, will have a look later [14:18:14] will be in the meeting in a few [14:23:36] <{cary|lunch}> http://lists.wikimedia.org/pipermail/wikipedia-l/2010-May/031253.html from the barely used list [14:24:14] so link and table dialogs work on IE 7 and 8 correct? (for english wikipedia) [14:25:46] mdale: once again, I'm having issues with JS2Support and symlinks. This time updating commons.prototype -- that is also set up with symlinked extensions [14:26:03] mdale: I think we're going to have to solve this in some better way [14:26:32] flipzagging: ... yea its kind of a trunk issue... webStart.php uses $IP = realpath( '.' ); [14:26:59] mdale: right now, I'd be happy if JS2Support defined URLs in the normal MediaWiki way, as Special pages or maybe its own namespace [14:27:00] if you can set getenv( 'MW_INSTALL_PATH' ); to something you can use .. it will defer to that [14:27:08] it does [14:27:14] oh... [14:27:19] flipzagging and guillom: is it a good time to meet? [14:27:24] or do you need more time? [14:27:34] mdale: I mean, didn't do its own "entry point" [14:27:37] nkomura: sure [14:27:37] flipzagging: ...I could add an api entry point i guess .. but it will be very slow [14:27:48] mdale: I'll take "works" over "slow". [14:28:01] like two orders of magnitude slower [14:28:13] we have R5, i suppose [14:28:19] see you there [14:28:24] I'm in R5 [14:28:43] but happy to give people the option [14:28:50] mdale: unfortunately MediaWiki does URL to file mapping at the PHP level, not at the Apache level. Sucks to be us. [14:29:32] mdale: I don't agree that caching is the responsibility of JS2. [14:29:34] RoanKattouw: i like the search expansion you deployed on the protoype [14:29:38] pretty groovy [14:29:47] Oh and [14:29:49] It has tooltips [14:29:59] If you hover over an ellipsized entry [14:30:05] It'll show a tooltip with the full name [14:30:12] <{cary|lunch}> I have a message from a man whose scroll isn't working on Wikipedia. Could you fix his scroll? [14:30:14] We've had this feature forever but never enabled it for some reason [14:30:22] {cary|lunch}: Define "scroll not working"? [14:30:24] Roan: I have fancy tooltips I'm using for UploadWizard, perhaps we should use a common lib. [14:30:25] flipzagging: as mentioned its pretty easy to add an api or special page entry point register .. it will just be about 100 times slower [14:30:29] i don't see tooltip [14:30:33] will play with it some more [14:30:33] <{cary|lunch}> RoanKattouw, I'll send you the message, you can call him back [14:30:37] got to run [14:30:38] ttyl [14:31:04] mdale: I can make it 10000000 times faster if you remove the requirement for it to actually work [14:31:12] hehe [14:31:29] oky... I will add the option in there ;) [14:33:41] flipzagging: will have to add it later today since finishing up some stuff ... it already reads the environmental variable if you want to use that in the meantime [15:32:15] http://wikimania2010.wikimedia.org/wiki/Submissions/A_Search_Box_that_Follows_You :D [15:39:33] RoanKattouw: I'm gonna add a little css tweak to your left expansion work [15:39:43] is it optional, or on by default? [15:40:59] It's on by default, but that's easy to change [15:41:04] What's the CSS tweak? [15:41:13] Border or something? [15:44:26] yeah border top, and negative margin on the top so it looks like it used to [15:45:01] OK [15:45:05] Go bonkers then [15:45:11] will do [15:45:20] Also [15:45:30] There was one gaping obvious RTL issue in there that I fixed [15:45:41] Or rather [15:45:53] It was working properly for RTL but not LTR :D [15:46:10] in the css? [15:46:28] We're making it expand to the left in LTR, but obviously that needs to be toward the right for RTL, hence the 'expandToLeft' parameter that's set to !$('body').is('.rtl') [15:47:03] You can turn off expansion entirely by setting 'maxExpandFactor': 1 [15:47:08] (Default value is 2) [22:11:42] *Jamesofur whines about the _