Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Messages - Nao
8431
The Pub / Jump box and its stupid Go button
« on July 16th, 2011, 05:22 PM »
Pete isn't the only one who gets to remove features from SMF :P
I'm currently reworking the board jump box code.
Here are two things that I've been starting to rewrite, and then figured I'd ask for opinions before committing them.
1/ I'm rewriting URLs (through Pretty URLs) before showing the board list. This allows users to jump directly to said board using its official URL, rather than see a "?board=1.0" in the URL.
Pros: well, concealing board= URLs is always nice.
Cons: the XML file you request through Ajax is a bit bigger, obviously. (Only if Pretty URLs are enabled. Otherwise it's the same.)
An alternative way of doing it, would be to have Wedge redirect to the proper board as soon as it gets an URL with '?board=' in it. Actually I thought it already did that, but apparently not... Probably due to my internal rewrite where it no longer relies on htaccess. Of course it requires an extra roundtrip to the server...
Opinions plz?
2/ I want to get rid of that stupid 'OK' button. The only (only!) point of this button is to allow you to jump directly to the current board's homepage. Thing is -- topic pages already have a link to said board, in the linktree. There's a copy at the bottom, right above the jump box... Once you click the select box, simply selecting another board will load it directly. The Go button can... go. A simple rewrite would be to have the jump box say: "Jump to: [Select board]". Then you click the "Select board" and it opens up a list of boards. The default selected board will be changed to the current one. Problem fixed, and better usability without that button IMHO.
Again: opinions plzkthx?
Thanks :)
I'm currently reworking the board jump box code.
Here are two things that I've been starting to rewrite, and then figured I'd ask for opinions before committing them.
1/ I'm rewriting URLs (through Pretty URLs) before showing the board list. This allows users to jump directly to said board using its official URL, rather than see a "?board=1.0" in the URL.
Pros: well, concealing board= URLs is always nice.
Cons: the XML file you request through Ajax is a bit bigger, obviously. (Only if Pretty URLs are enabled. Otherwise it's the same.)
An alternative way of doing it, would be to have Wedge redirect to the proper board as soon as it gets an URL with '?board=' in it. Actually I thought it already did that, but apparently not... Probably due to my internal rewrite where it no longer relies on htaccess. Of course it requires an extra roundtrip to the server...
Opinions plz?
2/ I want to get rid of that stupid 'OK' button. The only (only!) point of this button is to allow you to jump directly to the current board's homepage. Thing is -- topic pages already have a link to said board, in the linktree. There's a copy at the bottom, right above the jump box... Once you click the select box, simply selecting another board will load it directly. The Go button can... go. A simple rewrite would be to have the jump box say: "Jump to: [Select board]". Then you click the "Select board" and it opens up a list of boards. The default selected board will be changed to the current one. Problem fixed, and better usability without that button IMHO.
Again: opinions plzkthx?
Thanks :)
8432
Features / Re: New revs
« on July 16th, 2011, 12:10 PM »
rev 873
(8 files, 10kb)
* Turned media banning's findmember into an auto-suggest. More to come. (ManageMedia2.php)
! Media banning language string fixes. (Admin.language.php, ManageMedia.language.php, ManageMedia.template.php)
! Javascript trimmer was being incorrectly implemented, should have been $.trim($()), not $().trim(). Hey, what did you expect. (script.js)
* Moved .windowbg/2/3 background colors to $winddow_bg/2/3 variables. (index.css)
(8 files, 10kb)
* Turned media banning's findmember into an auto-suggest. More to come. (ManageMedia2.php)
! Media banning language string fixes. (Admin.language.php, ManageMedia.language.php, ManageMedia.template.php)
! Javascript trimmer was being incorrectly implemented, should have been $.trim($()), not $().trim(). Hey, what did you expect. (script.js)
* Moved .windowbg/2/3 background colors to $winddow_bg/2/3 variables. (index.css)
8433
Plugins / [Naming poll] Re: Packages
« on July 16th, 2011, 10:12 AM »
Just checking here... Even though I still respectfully disagree with the opinions posted here, what matters is the outcome of the poll. At 62%, I think add-on is a clear winner and I'll try to refrain from asking that question again :lol:
8434
Features: Theming / Re: JavaScript caching
« on July 16th, 2011, 10:10 AM »
This particular problem is fixed now because I didn't actually need to include menu.gif again because it was already registered as the background for h4 tags (a slight oversight.)
I'm still of the opinion that micro-optimizations aren't a waste of time, more like a way to train oneself to determine what's important to optimize, and what's not.
I don't really know what can't handle gzip, honestly, but I'm sure there are clients that can handle gzip content, but can't handle files with a gz extension. I mean, Safari itself doesn't, I had to do this annoying htaccess/MIME trick for it. (Uh.)
I'm still of the opinion that micro-optimizations aren't a waste of time, more like a way to train oneself to determine what's important to optimize, and what's not.
I don't really know what can't handle gzip, honestly, but I'm sure there are clients that can handle gzip content, but can't handle files with a gz extension. I mean, Safari itself doesn't, I had to do this annoying htaccess/MIME trick for it. (Uh.)
8435
Development blog / Re: Now with 97% more visuals!
« on July 16th, 2011, 12:08 AM »
New pic!
http://media.wedge.org/item/43/ for a full description of what should be of interest.
From now on, I'll try to focus on interface elements, new features etc, anything that doesn't require a fullscreen screenshot.
 |
http://media.wedge.org/item/43/ for a full description of what should be of interest.
From now on, I'll try to focus on interface elements, new features etc, anything that doesn't require a fullscreen screenshot.
8436
Features / Re: New revs
« on July 15th, 2011, 11:39 PM »
rev 872
(7 files, 32kb)
- AeMe code was still using reqWin(this.href). Although technically still all right, we don't need to specify the ".href" anymore... (Aeva-Gallery2.php, ManageMedia2.php, Media.template.php)
! Applied youtu.be fix to thumbnail retrieval. (Aeva-Embed.php)
* Rewrote title retrieval code for help popups. Now works on all of the help links I could think of. I'm not going to test them all, eh... Hopefully we'll rewrite this mess of an admin area later. (script.js)
* Serious update to the help popup language files. Hardcoded titles were removed. Quote entities changed to double quotes. Double spaces made single again. Updated SMF and simplemachines to Wedge where expected. Rewrote time_format and custom_mask help popups to be actually usable, and to fix many inconsistencies in the descriptions. Fixed some "users" to users' or user's. (Someone was having problems with their English grammar.) (Help.english.php, Help.french.php)
(7 files, 32kb)
- AeMe code was still using reqWin(this.href). Although technically still all right, we don't need to specify the ".href" anymore... (Aeva-Gallery2.php, ManageMedia2.php, Media.template.php)
! Applied youtu.be fix to thumbnail retrieval. (Aeva-Embed.php)
* Rewrote title retrieval code for help popups. Now works on all of the help links I could think of. I'm not going to test them all, eh... Hopefully we'll rewrite this mess of an admin area later. (script.js)
* Serious update to the help popup language files. Hardcoded titles were removed. Quote entities changed to double quotes. Double spaces made single again. Updated SMF and simplemachines to Wedge where expected. Rewrote time_format and custom_mask help popups to be actually usable, and to fix many inconsistencies in the descriptions. Fixed some "users" to users' or user's. (Someone was having problems with their English grammar.) (Help.english.php, Help.french.php)
8437
Features / Re: New revs
« on July 15th, 2011, 05:01 PM »
rev 871
(6 files, 14kb)
+ Added ability to position message user boxes to the right of the post, instead of the left. Defaults to the right for now (opposite the sidebar.) (Display.php, Display.template.php, sections.css)
* Improved AeMe image embedding styling. (media.css)
* Repositioned down arrows in the main menu a pixel further down, because it felt a bit misaligned. Only a bit really. Also saved a few bytes by not re-including menu.gif, which was already included for h4 tags. (index.css)
* Some profile options had finishing periods, when surrounding options didn't. (Profile.english.php)
(6 files, 14kb)
+ Added ability to position message user boxes to the right of the post, instead of the left. Defaults to the right for now (opposite the sidebar.) (Display.php, Display.template.php, sections.css)
* Improved AeMe image embedding styling. (media.css)
* Repositioned down arrows in the main menu a pixel further down, because it felt a bit misaligned. Only a bit really. Also saved a few bytes by not re-including menu.gif, which was already included for h4 tags. (index.css)
* Some profile options had finishing periods, when surrounding options didn't. (Profile.english.php)
8438
Development blog / Re: Now with 97% more visuals!
« on July 15th, 2011, 02:49 PM »
Ah, Pete, I *will* be forced to add a few settings for that anyway... I'm thinking the ability to show the sidebar on the left or right... Would be a minimum. Then the user boxes would be shown opposite the sidebar. Hence my extra code to enable both directions.
8439
Development blog / Re: Now with 97% more visuals!
« on July 15th, 2011, 02:23 PM »
Nah, more complex than that!
8440
Development blog / Re: Now with 97% more visuals!
« on July 15th, 2011, 01:54 PM »I like that, possibly more than the one currently in SVN. The one thing I'm not sure about is the fact the userbox items are all right aligned when I'm so used to seeing them left aligned - but again I think it's simply a case of being *so* used to left aligned that right aligned is just change I'm not used to (and hence all the psych consequences of resistance to change)
The reason I right-aligned them is because if they remain left-aligned, suddenly it feels more 'crowded' in the vicinity of the post itself. When you reach the end of the line in a post, you find yourself in close contact with the beginning of the text in the user box.
A solution would be to increase padding between elements, but that could end up reducing the message width too drastically. Of course, a workaround for that would be to decrease the font size, but then the effect would be lost.
I'm just not sure about the best solution to apply here.
(And I'm glad we're now going to be able to ask users for feedback :P)
8441
Development blog / Re: Now with 97% more visuals!
« on July 15th, 2011, 12:44 PM »
Bit obsessed with the topic layout (especially after some traumatizing comments :lol:), so here's the alternative version (not committed yet though.)
http://media.wedge.org/item/33/
Which do you prefer?
 |
http://media.wedge.org/item/33/
Which do you prefer?
8442
Development blog / Re: Now with 97% more visuals!
« on July 15th, 2011, 12:18 PM »
How strange :P
8443
Development blog / Re: Now with 97% more visuals!
« on July 15th, 2011, 11:47 AM »
So... Is everyone happy with the colors, font choices and things like that.......? :^^;:
8444
The Pub / Re: Menu hover concerns
« on July 15th, 2011, 11:42 AM »Thanks for the menu explanation. My only problem with the SMF menus is that it does not go away immediately when you move the mouse away. It stays there.
Does it do that in all browsers?
URL?
Blocking access to where you really want to go. For example, if I move my mouse across a menu on the way to the menu I really want to get to, the first one pops open and when I get the mouse to the menu I want to open it won't open because the other one is still open. Drives me crazy.
It's been a pet peeve of mine for some time. I do use a Mac though. Maybe it doesn't do it with Windows. Or maybe I'm just stubborn in that I want to have to click it for it to pop open. I'll keep an open mind about it though. :eheh:
And yes, I'm not perfect, but I'm serious about what I do. :)
8445
Features: Theming / Re: JavaScript caching
« on July 15th, 2011, 10:55 AM »
I need to answer that post at some point..... :^^;:
Just a quick example on the issues of gzip compression.
index.css, background image for the selected menu item.
Code: [Select]
Given that .arrows is defined as such:
Code: [Select]
Now, this css file weighs in at 74.548 bytes.
Replace the first block with this:
Code: [Select]
This will duplicate menu.gif (we're talking about base64 encoding, so we get the actual data twice). That particular file is 150 bytes.
The resulting index.css is 74.721 bytes, i.e. 173 bytes more, which makes sense.
Now, let's gzip both files...
Results:
First file: 74.548 -> 30.432 bytes
Second file: 74.721 -> 30.430 bytes
So, the question would be: what's best, a short CSS file, or a short gzipped CSS file?
Obviously it depends on what your users are receiving. If their client can't receive gzipped data, they're better off with the first file. Otherwise, the second file is best.
As it happens, the difference is too small (2 bytes) to justify thinking too much about it. It's a very slightly noticeable improvement for a very, very small share of the community, and a negligible negative difference for the larger majority. I'll take the first version because, really, I like my inheritance system.
But it's a real annoyance that I can't find a way to improve gzipping on the first test case...
Just a quick example on the issues of gzip compression.
index.css, background image for the selected menu item.
h4:hover extends .arrows, h4.hove extends .arrows
background-color: #5a6c85
background-position: 98% -28pxGiven that .arrows is defined as such:
.arrows
background-image: url($images/menu.gif)
background-repeat: no-repeatNow, this css file weighs in at 74.548 bytes.
Replace the first block with this:
h4:hover, h4.hove
background: #5a6c85 url($images/menu.gif) no-repeat 98% -28pxThis will duplicate menu.gif (we're talking about base64 encoding, so we get the actual data twice). That particular file is 150 bytes.
The resulting index.css is 74.721 bytes, i.e. 173 bytes more, which makes sense.
Now, let's gzip both files...
Results:
First file: 74.548 -> 30.432 bytes
Second file: 74.721 -> 30.430 bytes
So, the question would be: what's best, a short CSS file, or a short gzipped CSS file?
Obviously it depends on what your users are receiving. If their client can't receive gzipped data, they're better off with the first file. Otherwise, the second file is best.
As it happens, the difference is too small (2 bytes) to justify thinking too much about it. It's a very slightly noticeable improvement for a very, very small share of the community, and a negligible negative difference for the larger majority. I'll take the first version because, really, I like my inheritance system.
But it's a real annoyance that I can't find a way to improve gzipping on the first test case...