Action buttons: positioning
Poll

Where do you like your action buttons best?

At the top of my posts, like it used to be.
0 (0%)
Below my posts, like now.
16 (72.7%)
Either way is fine to me.
2 (9.1%)
Either way is awkward to me, at least for now.
1 (4.5%)
I think they should be located on planet Mars, where at least with a good telescope I might be able to notice them.
3 (13.6%)
Total Members Voted: 20

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Keyworks in the URL + SEO
« Reply #30, on May 10th, 2012, 11:01 PM »
I think it's because without seeing it it's not like we can judge the visual effect and as for the code consequences, it's like I can't visualise the consequences without trying to make use of it later, you know?
When we unite against a common enemy that attacks our ethos, it nurtures group solidarity. Trolls are sensational, yes, but we keep everyone honest. | Game Memorial

Nao

  • Dadman with a boy
  • Posts: 16,079
Re : Re: Keyworks in the URL + SEO
« Reply #31, on May 10th, 2012, 11:28 PM »
Oops, I posted my bump in the wrong topic... Lol :)
Quote from Arantor on May 10th, 2012, 11:01 PM
I think it's because without seeing it it's not like we can judge the visual effect and as for the code consequences, it's like I can't visualise the consequences without trying to make use of it later, you know?
Sure... But I'm still unsure what's best. Forget about touch devices..?

Aaron

  • Posts: 356
Re: Action buttons: positioning
« Reply #32, on May 10th, 2012, 11:32 PM »
Quote from Nao on May 10th, 2012, 06:08 PM
(Still working a lot on Wedge, it's just that I'm so overwhelmed by the amount of changes to commit, that I'm postponing my next commit every time...)
To be frank, that really sounds like you should really give Git a try sometime soon. It allows you to commit files partially — it interactively asks you which parts you want to stage (and commit). Plus, the entire versioning process is done locally — you just push changes to a central repo/server from time to time, if you like. Probably saves you a lot of headaches in the long run!
"The entire British Empire was built on cups of tea … and if you think I'm going to war without one, mate, you're mistaken."

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re : Re: Keyworks in the URL + SEO
« Reply #33, on May 10th, 2012, 11:36 PM »
I don't think we can really forget touch devices, and if anything the action menu is more important on them, too, because surely more will be hidden into menus on mobile devices?

Nao

  • Dadman with a boy
  • Posts: 16,079

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278

Nao

  • Dadman with a boy
  • Posts: 16,079
Re: Action buttons: positioning
« Reply #36, on May 11th, 2012, 08:58 AM »
It's exactly the same, except that the frame doesn't encompass the hovered item :P
Plus, the item is no longer clikable when the menu is opened. I'm not sure why, because there are no z-indexes involved any longer...
I'll try to get done with that, and my huge commit, today.

I'd like for more opinions from other users, too... you CAN post, you know!

live627

  • Should five per cent appear too small / Be thankful I don't take it all / 'Cause I'm the taxman, yeah I'm the taxman
  • Posts: 1,670
Re: Action buttons: positioning
« Reply #37, on May 11th, 2012, 09:34 AM »
Quote
Plus, the item is no longer clikable when the menu is opened. I'm not sure why, because there are no z-indexes involved any longer...
My only guess is that the margin is in the way.
Quote
I'd like for more opinions from other users, too... you CAN post, you know!
I like it moved as well... not more nor less than with it encompassing the original item.
A confident man keeps quiet.whereas a frightened man keeps talking, hiding his fear.

godboko71

  • Fence accomplished!
  • Hello
  • Posts: 361
Re: Action buttons: positioning
« Reply #38, on May 11th, 2012, 10:27 PM »
I like it seems less bulky then what is currently here, though I never thought of it that way until I saw the screenshot.
Thank you,
Boko

Nao

  • Dadman with a boy
  • Posts: 16,079
Re: Action buttons: positioning
« Reply #39, on May 12th, 2012, 12:01 AM »
My current local version now sports an arrow like in the main menu. When you open an entry I mean.
It looks pretty nice and adds a closing animation. Still having bugs though. Will upload here tomorrow hopefully.

godboko71

  • Fence accomplished!
  • Hello
  • Posts: 361

Nao

  • Dadman with a boy
  • Posts: 16,079
Re: Action buttons: positioning
« Reply #41, on May 12th, 2012, 04:43 PM »
Okay, I've fixed the biggest bugs I met while doing my rewrites...

The good:
- It looks nice. I'll upload the results on wedge.org before tonight.

The 'I don't know'...
- Whether or not it looks as good as the current version is up to you guys. I have a small preference for the current one, but honestly it adds so many potential issues... When the 'new' version is much shorter in code (nearly 300 bytes saved in topic.js.gz!), as well as closer in concept to the main menu, meaning I can easily look into using the menu code for it later on.

The bad:
- The last remaining bug wasn't a bug of mine, it was a jQuery bug. Actually, the only reason I managed to fix it, is because I read the .stop() documentation on jQuery.com, and found out about the 'bug' they mention about stopping toggler animations. Basically, they're saying that to fix it, you have to switch to jQuery 1.7... Yay.

So, I was thinking... Maybe it's not too bad to add a recent version with 4 extra kilobytes of code to download, because recent versions are likelier to get cached on other sites... But (1) jQuery is not actually used on my 'important' websites, especially not the Google CDN version... (2) even on 'big' sites that use it, they don't always keep up. Heck -- just look at jquery.com, it's referencing version 1.4.2!!! (1.4 is my favorite in terms of size vs feature set, btw, with 1.5 a close second, but 1.4.2 is not even the latest version of the 1.4.x branch!)

So... I don't know, really.
If I don't make the switch, the bug remains, but I suppose one can live with it -- it makes the animations visible when you're quickly hovering a menu parent while not intent on using that menu (e.g. you're moving from one link to another, and that menu happens to be in the way of your mouse cursor...). In jQuery 1.7, the animation stops and disappears as soon as you hover it. In jQuery 1.5, the animation stops then the menu is opened entirely, and it starts to quickly disappear with a hide animation. This is because if I don't open it entirely, it'll lose the toggle state and thus if you come back to the menu, there's a chance it won't open at all as it considers it to be shown already...

Suggestions?

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Action buttons: positioning
« Reply #42, on May 12th, 2012, 04:53 PM »
I'd stick with 1.4 or 1.5 than 1.7 to be honest - I'm not convinced that a lot of sites are using bleeding edge anyway, but stick with what works with the code they have. Having a baseline in Wedge means that everyone has a version that's consistent and will likely work better with plugins as a consequence.

As for the other issues, do you feel they're likely to be more or less complicated to fix? (i.e. is it going to be a significant amount of time/effort to fix or would it be better to spend that time elsewhere)

Nao

  • Dadman with a boy
  • Posts: 16,079
Re: Action buttons: positioning
« Reply #43, on May 12th, 2012, 06:01 PM »
Quote from Arantor on May 12th, 2012, 04:53 PM
I'd stick with 1.4 or 1.5 than 1.7 to be honest - I'm not convinced that a lot of sites are using bleeding edge anyway, but stick with what works with the code they have.
Pretty much, yeah... The only point in going for 1.7 IMHO is the use of .on() and .off() instead of .bind() and .unbind(), which makes it a bit shorter in terms of compression, but OTOH I'm not ready to add 4KB to our main JS requirements just to save a few bytes off the other files... The only argument for it, would be that v1.7.2 is widespread enough to guarantee it's in the cache. Which we can't.
In fact, you mentioned v1.4 which is what we originally had in Wedge (it was the bleeding edge when we started the project), and I think we went from 1.4 to 1.5 after doing tests in 1.6 and noticing a few issues (that were fixed in 1.7)...
At the time, we were expecting later versions to be too big and settled on 1.5 because it didn't feel as 'dated' as 1.4 was... but in reality, 1.4 was never that 'dated', it's actually after 1.4 that it went downhill and into bloatware territory. Starting with the Ajax object rewrite that I really don't need (and frankly, do you know a lot of people who use the deferred object and things like that...?), etc, it sort of became a habit of theirs to add things because they wanted to move on.

Well, it's a bit like CoffeeScript doing some smart things to help with JavaScript notation (like, replacing prototypes transparently with classes, for those who don't know about prototyping, or using "->" for functions), and then adding more things that actually make it more complicated to follow... (like, using => instead of -> to get a cache to 'this'... Okay how's that NOT hacker stuff at this point?! And what about these object definitions where if you define a multi-dimensional array, you have to add a new line between them that is *exclusively* a single comma? How ugly...)

Anyway!!

jQuery 1.4.2 = 24KB
1.4.4 = 26KB, but these 2KB are put to good use. (Some things I actually use like automatic HTML5 data loading, others are speed improvements to things I use a lot.)

1.5.0 = 29KB, adds the Ajax changes which I don't care about, and severe speed improvements for .children(), .prev() and .next(), which I make use of. (It should be noted that they're about 2x faster in 1.5, except for Chrome where they're like 10x faster, but then again speed really matters only on slow devices, like mobile...)

1.5.1/2 = 29KB, mostly fixes bugs... Also from 1.4.4?! Why didn't they release a 1.4.5... :(

So I don't know, we could even go back to v1.4.4 if we wanted, we'd just have to check for extra bugs to fix...
Quote
Having a baseline in Wedge means that everyone has a version that's consistent and will likely work better with plugins as a consequence.
Yup, but that would be an argument (only argument, if anything) for the use of v1.7.x, instead of 1.4 or 1.5...
Quote
As for the other issues, do you feel they're likely to be more or less complicated to fix? (i.e. is it going to be a significant amount of time/effort to fix or would it be better to spend that time elsewhere)
I don't know... I'll look into it again.
Posted: May 12th, 2012, 05:58 PM

Just noticed that even 1.7 has a bug...
If you cut off an animation and restart it in the other direction, it'll work (as opposed to 1.5), but next time it opens, the box shadow gets cut off (probably because of a dynamic overflow:hidden added by jQ somewhere in the process.)
I don't remember seeing this happen in 1.5... Meh.
Re: Action buttons: positioning
« Reply #44, on May 12th, 2012, 07:33 PM »
Just FYI -- the bug I mentioned that is half-fixed in v1.7 is documented here:
http://bugs.jquery.com/ticket/8685

As they say, the 'only' way to fix it prior to 1.7 is to do away with any animations that use 'show', 'hide' and 'toggle' keywords, i.e. .animate({ something: 'show' }), .show(xxx), .hide(xxx), .slideToggle(), .fadeToggle(), .fadeIn(), slideUp(), etc...
Or, simply not use .stop() on them, or use .stop(true, true) instead of .stop(true)... This is what I did in sbox.js (using .stop(true, true), that is), although at the time I wasn't aware it was a jQuery bug and I implemented that only as a basic workaround.

So, in the end, what I'd need to do to fix it, is get the dimensions, and then call a clear .css() then a clear .animate() setting the dimensions instead of using .show() and .hide()... Let's just say I'm not a big fan of this.

Or I just forget about it, use .stop(true, true) and use .hide() instead of an animated one when the animation is stopped during execution. Meh...