Post by: Nao on May 4th, 2012, 04:32 PM
I haven't got around to dealing with the moderation checkbox and the Quick Edit button, though.
Still, I think it's a good time to determine what's best for a 'default' setup.
(1) TOP
Pros:
- It's what every SMF user is used to...
- Pretty much immediate recognition of the Quote button's position.
Cons:
- It makes it harder (much harder) to make the post header look good, as on smaller widths + longer titles it will breaks these titles, or make them warp on a small width which is even worse...
- Vertical positioning isn't easy. I had to resort to using CSS table emulation, which I'd rather avoid as much as possible...
(2) BOTTOM
Pros:
- It fits nicely into the 'Last edited' box.
- The quick edit button takes space anyway -- might as well use that space...
- Logic says that you're more likely to answer a post after you're done reading it, rather than before you read it (it's not always the case, i.e. very long posts in a two-man discussion, I tend to favor answering first), thus the Quote button would be more useful at the end of the post...
- It just looks better, layout-wise. Just like FluxBB's default layout, it feels a bit more organized. Better thought-out.
Cons:
- Seriously... I can't get the hang of it. It's been days, weeks, and I still have to look twice before I find that damned Quote button!
So... There's only one con that I can think of, but it makes it hard for me to actually commit my changes. Looking for opinions! Will add a poll, too...
PS: a freebie for teatime... How come if you edit a post in the middle of a topic, your Topic Summary has the last posts *before* that post, but if you quote the same post, the Topic Summary has the latest posts in the topic instead..? I understand the idea, I just don't know if it makes sense for the common man...
Post by: Arantor on May 4th, 2012, 04:42 PM
Familiarity isn't always a boon, either, I'd honestly rather have things at the end where they would naturally fall in how people read posts and reply to them. If you're replying without reading first, there's always the reply button at the top of the thread anyway...
PS: a freebie for teatime... How come if you edit a post in the middle of a topic, your Topic Summary has the last posts *before* that post, but if you quote the same post, the Topic Summary has the latest posts in the topic instead..? I understand the idea, I just don't know if it makes sense for the common man...
Post by: NeobeatIKK on May 4th, 2012, 05:50 PM
Post by: nolsilang on May 4th, 2012, 05:54 PM
Post by: Nao on May 4th, 2012, 06:30 PM
Familiarity isn't always a boon, either, I'd honestly rather have things at the end where they would naturally fall in how people read posts and reply to them.
I wasn't too sure because you were confused at first, and thought it was an error on my side, instead of encouraging me to 'keep' that error online ;)
If you're replying without reading first, there's always the reply button at the top of the thread anyway...
If you're editing a post in a topic, you want to see what came up to that point (as presumably you're not editing it with the knowledge of later, but only for is applicable up to that point) but if you hit quote, you're replying to that, and would likely want to take the rest of the thread into account. Always made sense to me.
One of the things that confuse me is, I think, the Like button... I'd probably like for the ability to push it to the Plus button, actually. This is because over the years I've been so used to clicking the first button in the list to reply, it just became a no-brainer... Now I have to be more careful (although it's not too bad since at worst I can simply unlike a post.)
Perhaps we should give users the ability to choose what buttons they want inside and outside the action button... I don't know. It could be something we store in the generic data field.
Post by: Arantor on May 4th, 2012, 06:35 PM
I wasn't too sure because you were confused at first, and thought it was an error on my side, instead of encouraging me to 'keep' that error online
Except that doesn't quote... Answering posts without reading their actual contents is what politicians and zealots do, not normal people
One of the things that confuse me is, I think, the Like button... I'd probably like for the ability to push it to the Plus button, actually. This is because over the years I've been so used to clicking the first button in the list to reply, it just became a no-brainer... Now I have to be more careful (although it's not too bad since at worst I can simply unlike a post.)
Perhaps we should give users the ability to choose what buttons they want inside and outside the action button... I don't know. It could be something we store in the generic data field.
| 1. | Currently not an option but I want to make it one in the future. |
Post by: Nao on May 4th, 2012, 08:56 PM
How about... We move Last Edited to the top next to the posting date, and we use that spot for a left-aligned Like button? Problem is, Like button + list of people who like this is going to overflow very quickly... (perhaps give just the number, and show who likes it in the title hover or with an Ajax click?)
Post by: Arantor on May 4th, 2012, 09:09 PM
I like the idea of the positioning you've mentioned, it sounds like it should work but until we try it, I suspect we won't know for sure.
Post by: Aaron on May 5th, 2012, 12:34 AM
As for the quote button's position: why not swap the Like and Quote buttons? (I see three buttons on most posts, including the 'more' menu.)
While we're on the subject: I guess post headers can be narrowed down a bit now, by aligning the date next to the post subject. Not sure whether that'd look good, though; on my own forums, I usually separate posts quite visibly — see the attachment for an illustration. (And yes, I actually had plans to move the action buttons, sometime, haha!)
Post by: Nao on May 5th, 2012, 01:09 AM
The 'x likes this' mention is shown in small print, but eventually I think I'll move it to a popup, and replace it with a <span class="note">NUMBER OF LIKES</span> (and class="warn" if you liked it, yourself. Isn't it a good idea? :P)
Post by: Arantor on May 5th, 2012, 01:14 AM
There is a value to not hiding it too much.
Post by: Aaron on May 5th, 2012, 01:55 AM
Few nit-picks: the like-link isn't horizontally aligned with the text in the post above it (alignment is important!). More importantly, it doesn't really look like a link anymore – to me, it looks like it's just a prefix now; mostly because of the text colour being the same as the link colour, I think.
Post by: godboko71 on May 5th, 2012, 03:28 AM
Post by: Arantor on May 5th, 2012, 04:18 AM
Quick mockup using Chrome, see the lower-down post.
Posted: May 5th, 2012, 04:12 AM
Or it would if the attachment system wasn't breaking the file for some reason, it is very firmly a working PNG before upload.
Posted: May 5th, 2012, 04:16 AM
I don't have a hex file editor installed and I'm a bit too drunk to investigate but I'll post the pic to the gallery and investigate when I sober up a bit.
Posted: May 5th, 2012, 04:17 AM
 |
Post by: live627 on May 5th, 2012, 05:31 AM
You know, I think it might be better if the like button were actually a button in the style of the other buttons
Post by: godboko71 on May 5th, 2012, 06:06 AM
Too many borders and lines. I like it more minimalistic like how it is now.Quote You know, I think it might be better if the like button were actually a button in the style of the other buttons
Post by: live627 on May 5th, 2012, 06:58 AM
Post by: Nao on May 5th, 2012, 11:22 AM
I agree. It fits in better minimalist, though I like the text color (blueish) of unlike better then the color of Like and Quote & More.Quote from live627 on May 5th, 2012, 05:31 AM Too many borders and lines. I like it more minimalistic like how it is now.Quote You know, I think it might be better if the like button were actually a button in the style of the other buttons
The reason why the buttons don't share the same link color is only due to the fact that I was trying to set an opacity on the icons, and the button text is inside the same stuff so basically they also inherit the opacity, so I had to decrease their brightness to keep them readable. Which OTOH makes them very dark once you hover them... There isn't a "good" solution to fix these, I just like the opacity play too much to get rid of it... :-/
Post by: MultiformeIngegno on May 5th, 2012, 11:27 AM
Post by: Nao on May 5th, 2012, 12:07 PM
- I turned the two notice classes, 'note' and 'warn', into three classes: note (orange -- neutral, like New posts), notewarn (red -- requires immediate attention), and notenice (green -- neutral but as in 'good'). I'm not sure about the name/purpose of notenice, but I wanted to make your own likes clearly stand out in a positive way. I also used that in the main menu where new PMs are concerned, but I'm not sure whether it's best to use a warning or 'nice' note for PMs -- I use warnings for admin errors, and neutral for new media items, and I still haven't made a decision for new PMs.
- If you can't like a post and it hasn't received any likes, you won't see anything.
- If you can't like a post and it has received likes, you'll see the Thumbs Up icon, and a neutral (orange) notice with the number of likes.
- If you can like a post and it hasn't received any likes, you'll see the Thumbs Up icon and a "Like" link.
- If you can like a post and it has received likes, you'll see the Thumbs Up icon, a neutral notice with the number of likes, and a "Like" link.
- If you can like a post and you likes it, you'll see the Thumbs Down icon[1], a 'positive' (green) notice with the number of likes, and an "Unlike" link.
I'm working on having the whole area show who liked the posts on hover, but I don't know what's best: a minimenu where clicking that popup will then load the full list of likes, or a non-clickable popup with just the main names, or a non-clickable popup with the full list of likes (loaded through Ajax, obviously.)
Some of the new style was unconsciously, although I realized quite early in the process but that's okay, quite inspired by Facebook's compact way of showing likes.
Fishing for opinions now :)
| 1. | Which is totally illogical at this point... I'm thinking of getting rid of it? |
Post by: Nao on May 5th, 2012, 03:59 PM
Well, I guess I'll follow my instinct and go for a minimenu then... Where I'll be able to show the main voters, a link to show them all, Unlike icon (in case you already liked the post, I think it's best to hide the Unlike text away from view...), and perhaps things like 'silently like' which could mean 'say I like this, but anonymously'... Dunno.
Post by: Arantor on May 5th, 2012, 05:35 PM
A lot of this stuff is going to be based on how it looks when we actually try it, you know. As long as the like button can just be clicked without having to hover or wait or anything, it'll probably work out OK to have unliking be less prominent.
Bump for attachment broken issue.
Post by: Nao on May 5th, 2012, 05:51 PM
The 'silently like' option will require a schema and query change.
(We could also simply add a single field with a serialized array of options, like in the members table...)
I think it might be an interesting thing to do, though. I never discussed it before, but see it this way: let's say you want to Like a NSFW picture and your boss is on the same forum as you are... You won't "like" it because you'll be afraid he finds out you liked it. So, hiding your name from the Like list seems okay to me...
Apart from that -- well, we could also have an option to Like something without showing it in your user news stream (or wall, or whatever), and that's a one-time function so it doesn't need a database entry.
A lot of this stuff is going to be based on how it looks when we actually try it, you know. As long as the like button can just be clicked without having to hover or wait or anything, it'll probably work out OK to have unliking be less prominent.
I'm still not 100% sure about whether or not I'll keep the note classes with likes number etc... But at least it's a solution that would be perfect on mobile. (Perhaps I should just show the 'You like this' text next to it, and then hide it entirely on a media query test.)
Bump for attachment broken issue.
Post by: Arantor on May 5th, 2012, 06:13 PM
I think it might be an interesting thing to do, though. I never discussed it before, but see it this way: let's say you want to Like a NSFW picture and your boss is on the same forum as you are... You won't "like" it because you'll be afraid he finds out you liked it. So, hiding your name from the Like list seems okay to me...
Schema change yes -- adding a new field where you store whether the user wants to remain anonymous, but that's all..?
I'm not sure, there is such a thing as having too much stuff.
I'm still not 100% sure about whether or not I'll keep the note classes with likes number etc... But at least it's a solution that would be perfect on mobile. (Perhaps I should just show the 'You like this' text next to it, and then hide it entirely on a media query test.)
Very oddly -- it seems like your file is done like this: it's missing the first 30893 bytes of the original file, then you get the rest of the file, then at the end, it adds another 30893 bytes which seem to be repeated from offset 52078 of the original file (i.e. it adds them again)... Make what you want of it, but I'm at a loss myself.
Post by: godboko71 on May 5th, 2012, 11:51 PM
Post by: Arantor on May 6th, 2012, 12:15 AM
Post by: godboko71 on May 6th, 2012, 12:22 AM
Post by: NeobeatIKK on May 6th, 2012, 01:28 AM
Could be a good idea, similar to the thought behavior.
Post by: Arantor on May 6th, 2012, 01:37 AM
Note that all suggestions of 'silent like' are completely different to what you're suggesting.
Post by: Nao on May 10th, 2012, 06:08 PM
I'm not sure, there is such a thing as having too much stuff.
Try it :)Quote I'm still not 100% sure about whether or not I'll keep the note classes with likes number etc... But at least it's a solution that would be perfect on mobile. (Perhaps I should just show the 'You like this' text next to it, and then hide it entirely on a media query test.)
I uploaded it, saw it was corrupt, removed it, reuploaded it and still corrupt (the same way). Very weird. But I didn't find any of the normal PNG block indicators, I couldn't find the IHDR sector end when downloading the file again...
Back on topic -- I rewrote the minimenu CSS/JS code to fix a detail that bothered me at low-res (iPhone etc) -- if a minimenu overlaps another minimenu's parent entry (like the Actions button overlapping the following post's author name), the parent entry has priority z-index so it shows up on top of the menu. This is because of a complex implementation to ensure the parent entry wouldn't be 'hidden' by the menu showing up behind it.
I tried to fix it by doing a reverse walkthrough of all umme/acme tags, like this:
(function () {
var zindex = 1;
$.fn.reverse = [].reverse;
$('.acme, .umme').reverse().each(function () { $(this).css('z-index', zindex++); });
})();(Isn't this some cool JavaScript? :P)
I would then create the minimenus dynamically to use the parent item's z-index minus 1. Worked perfectly, but I noticed it didn't look great on my iPod -- most notably the menus tended to disappear and then reappear as they were animated. Possibly due to the great amount of processing power this requires... (Yay for mobile devices.)
So I threw away that solution, and instead decided to .clone() the parent into the minimenu and position it on top of the parent. Fixing all z-index issues immediately, meaning I didn't have to specify them any longer (which makes it easier to style stuff, too.)
And again -- it works nicely. Well, it didn't at first, but then I got rid of the padding animation implied by .show() (by replacing it with a longer .animate() call[1], but thanks to gzipping it's actually much shorter than the original code). Except for my iPod, again.....!!!
Now, the animations work correctly, but I can't seem to get the font sizes right. I can fix it by setting paddings and sizes manually in the index.iphone.css file, but it also means that some other devices are bound to show issues with this...
So, two possible fixes:
- Finding a 'correct' way to clone the parent entry perfectly. (This would *probably* imply setting the minimenu to be a child of the parent, rather than a child of the body. I'll try this next but it's like that it's going to create other issues.)
- Getting rid of the current minimenu style. Instead, implement them to look just like the 'normal' menus, i.e. an arrow below the item, and nothing surrounding it. Basically, doing what John did in the first place when he suggested re-using our menu style but I wanted to look into more animation styles.
I need opinions.
| 1. | I should also point out that because of the lack of padding animation, it doesn't 'feel' as nice an animation as it used it, but at least it's clean. This can probably be fixed by animating the list items at the same time as the parent ul... But I'm lazy for now. |
Post by: Arantor on May 10th, 2012, 11:01 PM
Post by: Nao on May 10th, 2012, 11:28 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?
Post by: Aaron on May 10th, 2012, 11:32 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...)
Post by: Arantor on May 10th, 2012, 11:36 PM
Post by: Nao on May 11th, 2012, 12:05 AM
Not as good looking but... At least it works...
Post by: Arantor on May 11th, 2012, 12:15 AM
Post by: Nao on May 11th, 2012, 08:58 AM
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!
Post by: live627 on May 11th, 2012, 09:34 AM
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'd like for more opinions from other users, too... you CAN post, you know!
Post by: godboko71 on May 11th, 2012, 10:27 PM
Post by: Nao on May 12th, 2012, 12:01 AM
It looks pretty nice and adds a closing animation. Still having bugs though. Will upload here tomorrow hopefully.
Post by: godboko71 on May 12th, 2012, 05:22 AM
Post by: Nao on May 12th, 2012, 04:43 PM
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?
Post by: Arantor on May 12th, 2012, 04:53 PM
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)
Post by: Nao on May 12th, 2012, 06:01 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.
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...
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)
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.
Post by: Nao on May 12th, 2012, 07:33 PM
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...
Post by: Nao on May 12th, 2012, 08:49 PM
Got it done.
It's a bit annoying overall. The extra JS for bug fixing amounts to a hundred gzipped bytes which isn't exactly a victory to me, even though the final JS is still about 220 bytes shorter than the current version.
Also, I had to get rid of the current way I'm showing user names in posts. Currently, it's h4 { overflow: hidden; text-overflow: ellipsis } followed by h4:hover { overflow: visible }, to simplify.
In the new version, it's going to simply be h4 { word-wrap: break-word }, which is an IE proprietary CSS rule that is also working on all modern browsers (the most recent browser that doesn't support it is Opera 10.10, which is like 2 years old anyway). The CSS group renamed it to overflow-wrap or something, but right now everyone uses word-wrap and I don't see it taking off anyway. My main issue with word-wrap is that although it does work (showing long user names on two lines), it also has a 'clear' effect in that it shows the text at the beginning of the next line, rather than to the right of the Online icon. Meh, I'm not a big fan of this way of doing things...
Opinions please. Do you like the new version, or not?
Will upload ASAP. Just compare to your SVN version if you have it installed somewhere. For non-consultants, well... Use your memory :)
Post by: Nao on May 12th, 2012, 08:51 PM
Click the Like button if you like better than the old style, lol, it's a mini-poll in itself ;)
:edit: Added screenshots of the 'old' style. Also, do tell me if it doesn't work in a browser... Only tested on Opera 11.64.
Post by: Nao on May 12th, 2012, 11:12 PM
Post by: godboko71 on May 13th, 2012, 05:49 AM
Post by: Dragooon on May 13th, 2012, 05:51 AM
Up... and running :)
Click the Like button if you like better than the old style, lol, it's a mini-poll in itself ;)
:edit: Added screenshots of the 'old' style. Also, do tell me if it doesn't work in a browser... Only tested on Opera 11.64.
Post by: live627 on May 13th, 2012, 06:57 AM
Post by: Nao on May 13th, 2012, 08:51 AM
Dragooon, was typing faster yesterday...?
Post by: Dragooon on May 13th, 2012, 08:54 AM
Post by: Nao on May 13th, 2012, 07:12 PM
Posted: May 13th, 2012, 06:15 PM
So I fixed that, but I'm still at a loss why User menus aren't working on my iPod while Action menus work just fine... They're using the same code pretty much -- same JS except for a test, where I tried to remove the differences to no avail, and some CSS where I don't see how it's going to make a difference... Safari doesn't report any errors...
Maybe it can be reproduced on a desktop browser. Anyone? Try hovering my user name on the left... You know, 'Nao', if you need the help ;)
Post by: Arantor on May 13th, 2012, 07:52 PM
Post by: Nao on May 13th, 2012, 09:32 PM
.mimenu
position: absolute
Action menu works, user menu fails to show.
.mimenu
position: relative
Both menus work, but of course as they're relatively positioned, the animations will push other elements aside.
GRMPF...
Reminds me of that IE8 issue I'm having with main menus.
Post by: Nao on May 13th, 2012, 10:09 PM
Meh...
I'm not a big fan of positioning according to the offset. I already met many problems with this when I implemented Zoomedia. Although it's not something that's unthinkable... I kinda like the 'simplicity' of Wedge's current menu positioning. (i.e. set 'right' to 0 to make it scroll from the right, etc.)
Post by: Arantor on May 13th, 2012, 10:15 PM
Post by: Nao on May 13th, 2012, 10:19 PM
What do you think of this, generally...?
Post by: Arantor on May 13th, 2012, 10:23 PM
Going back to the overall topic, I really like how the Like button works now, took a little while to get used to it. Making that work via AJAX shouldn't be too problematic (I don't think you did that already?) but I do find it a bit complicated as to how we would display a list of the people who like something, not that I could ever figure out how the list should look when we do get it (as I'm not entirely sure we should use the popups as they stand, but I'm not entirely we shouldn't either)
Also, have you changed the font lately? Either that or my browser is rendering text weirdly.
Post by: Nao on May 13th, 2012, 10:37 PM
I like the look, and the experience attached to the animation but it's gone over my head as far as figuring out how to fix it. I've always taken the view that I make it work, but don't necessarily make it pretty.
Well, right now the action menu doesn't really work, it's not even the same version as in my local test but it's worse there actually... So I'll leave it as is right now, don't worry I'll fix it.
Going back to the overall topic, I really like how the Like button works now, took a little while to get used to it.
Making that work via AJAX shouldn't be too problematic (I don't think you did that already?)
but I do find it a bit complicated as to how we would display a list of the people who like something,
not that I could ever figure out how the list should look when we do get it (as I'm not entirely sure we should use the popups as they stand, but I'm not entirely we shouldn't either)
Also, have you changed the font lately? Either that or my browser is rendering text weirdly.
Thing is, this setup is ONLY for admins (and you're one, now!), I'm thinking maybe I should add support for things like member IDs in the css suffixes, so that you don't have to cope with my design tests...
Post by: Arantor on May 13th, 2012, 10:42 PM
You mean, the notice number? I don't know...
I think you added support for that. There's definitely a placeholder for it in the template.
Would have to be on a click. I'm envisioning my mini-menus as popups that can be put anywhere (and I'll definitely do it this way), so I'll add a mini-menu to the Like button as I said, with the names of the first likers etc, and then a link to view more, which'll open a popup or something with all names. (And dates? Do you store dates?)
You'll see, it'll work well.
Yeah, sorry, forgot to ask you if you didn't mind... The header font is Helvetica Narrow (which I'm downloading off somewhere, and it's totally a non-free font so it'll never be in Wedge or even on Wedge.org for guests or members), and the text font is Calibri. Since you're using Win7 like me, you should have the nice Calibri as well, and Helvetica is downloaded so it's okay.
Post by: Nao on May 14th, 2012, 01:18 AM
I like it, works pretty well.Quote You mean, the notice number? I don't know...
I did, yes, though I didn't get as far as actually writing the JS for it.
Yes, dates are stored, in the likes table. The only think about using minimenus there is that you'd be getting a menu with a single item, since I think I'd rather the main like button but a one click without menu interaction.
- Who liked (if there's no like, show "Be the first to like this", the usual one...), with a link to the popup
- a separator
- a Like button, or Unlike button, depending on the status
- maybe things like "Last liked on May 12th..."
Anyway, it doesn't have to be a *menu*, it could very simply be a mega-menu type item, i.e. a regular div with some styling in it.
Oh, I don't mind :) I was wanted to be sure I wasn't seeing things. Don't worry about member ids in the suffixes, I think that's complexity that isn't really needed in this case. (And I like the design experiments, it's nice to see someone experimenting with something cool)
BTW, I have yet to find the problem with the absolute positioning and stuff.
But it 'barely' works by simply removing the position:relative from .umme (.acme works fine with it and doesn't work without it), so I did that... I HATE doing a hack that I don't understand in the first place, but I have only so much time I can devote to a single problem at a time.
Please test on other browsers whether action & user menus work...
:edit: Wireless + Opera 11 = user menu still works, but isn't proper under the user name. Meh...
Post by: Arantor on May 14th, 2012, 01:25 AM
I'm thinking about moving the number to *after* the 'Like' text, though...
Oh there'd be more than one item...
- Who liked (if there's no like, show "Be the first to like this", the usual one...), with a link to the popup
- a separator
- a Like button, or Unlike button, depending on the status
- maybe things like "Last liked on May 12th..."
Anyway, it doesn't have to be a *menu*, it could very simply be a mega-menu type item, i.e. a regular div with some styling in it.
My experiments are often failed ones... Anything I commit is usually the results of quite some time of use on my side, resulting in a situation where I felt comfortable going for a commit
Both menus work here currently (Chrome beta, desktop)
Post by: godboko71 on May 15th, 2012, 06:04 AM
Post by: live627 on May 15th, 2012, 09:20 AM
I don't like the underlines on the links in the username menu. It doesn't fit with the rest of the menus.
Post by: Nao on May 15th, 2012, 10:20 AM
Indeed, Chrome (if that's what you're using) seems to be showing underlines. This is probably because it applies the :hover element to all its children, so when you hover the user name, it gets underlined (as dictated by my CSS), and creates a mini-menu which is set as a child of it, now I have to determine which browser is doing things 'correctly', and how to fix it. And yes, I don't like having underlining either, at least not on a theme where underlining is shown only on hover. So, basically, I'll try to remember how I did it in the main menus, where the hover effect is a background color, and it seems to apply correctly everywhere (i.e. hover on the parent item, AND only on the currently hovered child.)
Of course, the alternative would be to do it like I used to do before the big commit: attach the mini menus to the body element instead, so they never inherit their parent's style. It also forces me to set their position absolutely, although it also fixes some other issues... But it just doesn't feel 'right', and I'd rather not resort to this hack again.
@John> Yep, I know :) And one of my goals is to harmonize these looks... But I love them both. I may even, I don't know, try to look into using my minimenu styling on main menus, although I probably won't keep that... Main menus need to be stylish and very neutral, because they're used a lot. Mini menus can be more daring, I'd say. Right now I love both, so it's going to be interesting trying to do something out of these.
@Pete> I guess I'm going to have to benchmark both the current solution (i.e. doing file_exists on all possible filenames and suffixes) and the glob solution (i.e. doing a single glob() call and getting all files from the generated list.) Come to think of it, I do so many file_exists permutations (because of the growing number of suffixes and the fact that even the default stylesheet already has at least 3 potential files or more, index, sections, custom...), if it wasn't cached already it would be quite slow to do on every page... Actually it's best that PHP doesn't cache it and the OS does it -- at least it can be cached over several sessions and page loads ;)
Post by: Arantor on May 15th, 2012, 10:42 PM
Posted: May 15th, 2012, 10:34 PM
OK, just wanted to tackle something in this topic (back earlier on the original part of it)
I really think the whole 'number at the end of likes' structure would work better. As it stands you get the number before the Like wording and you get the extra space underlined when hovering because it's all part of the link.
Converting it to [icon] Like ( number ) means the thumb icon + wording can be the action itself with the number being the popup. The UI aspect gets covered, there's somewhere to put the popup invocation and it deals with the underlining that looks weird otherwise.
Post by: live627 on May 16th, 2012, 01:02 AM
@John> Yep, I know :) And one of my goals is to harmonize these looks... But I love them both. I may even, I don't know, try to look into using my minimenu styling on main menus, although I probably won't keep that... Main menus need to be stylish and very neutral, because they're used a lot. Mini menus can be more daring, I'd say. Right now I love both, so it's going to be interesting trying to do something out of these.
Sorry for the nitpicking. Both my brother and my mother are graphic designers for our family book publishing company and I think it's rubbing off onto me.
Post by: Nao on May 16th, 2012, 11:01 AM
Therein lies the problem, getting it to purge the cache does also imply having it able to purge other things, like when folks use memcache or whatever, which the current cache doesn't deal with either.
I really think the whole 'number at the end of likes' structure would work better. As it stands you get the number before the Like wording and you get the extra space underlined when hovering because it's all part of the link.
However, there's the minor problem of what the text should say. Which is why I haven't tackled it yet...
(like icon) (empty) Like
Pressing Like.
(unlike icon) (1) Unlike
It sort of implies, "1 person unlikes this"...
So, it should say:
(like icon) (1) Like/Likes whatever you want that is positive...
And on hover, have the mini-menu open with a "(unlike icon) Unlike" link among other things.
Converting it to [icon] Like ( number ) means the thumb icon + wording can be the action itself with the number being the popup. The UI aspect gets covered, there's somewhere to put the popup invocation and it deals with the underlining that looks weird otherwise.
Actually, I did notice it and I hate that kind of thing -- it can be fixed very easily by simply duplicating the link and adding a space in between...
The main thing I don't like about the mini-menu is it's too crowded. The recent restyling helped on that front since the borders are gone.
Some extra padding in between the links would help as well.
The hover state would look better without the underline, and it might also look better if the background changed color, not the text.
Do you remember our blog style on wedge.org when I was using the Noisen codebase...?
If not, open an account (or use it if you already have one) at noisen.com, go to http://nao.noisen.com/ and check out the "Action" button on the upper right of any post... This is something of an innovation (SMF-wise) that I strived not to reproduce in Wedge, but the more I played with my layouts, the more I felt compelled to go there... And pretty much unaware, because I only recently realized that even the word 'Action' was from there. (It's how the More button is called in Mobile mode... And will probably even be renamed to Actions everywhere once I decide to go ahead and merge the Modify link and the Quick Edit button together into a Quick Edit button with a mini-menu to open a full edit version...)
Sorry for the nitpicking. Both my brother and my mother are graphic designers for our family book publishing company and I think it's rubbing off onto me.
Heck, Pete knows quite well that I'm constantly struggling with my bad taste -- he has to cope, along with me, with numerous style changes to Weaving that I'm applying to admins only (custom.admin.css, yay!), so right now we both have Calibri as our main font in Wedge and it'll probably change again before you know it... :P
Posted: May 16th, 2012, 10:29 AM
(And just to be clear: too many fonts in the kitchen!! I'm aware of that!!)
Posted: May 16th, 2012, 10:34 AM
Now, here's the thing...Quote The hover state would look better without the underline, and it might also look better if the background changed color, not the text.
(Forgot to be clear on this...)
Post by: Arantor on May 16th, 2012, 02:51 PM
Do you mean the clear cache function doesn't clear non-file cache alternatives...?
However, there's the minor problem of what the text should say. Which is why I haven't tackled it yet...
(like icon) (empty) Like
Pressing Like.
(unlike icon) (1) Unlike
It sort of implies, "1 person unlikes this"...
So, it should say:
(like icon) (1) Like/Likes whatever you want that is positive...
And on hover, have the mini-menu open with a "(unlike icon) Unlike" link among other things.
Actually, I did notice it and I hate that kind of thing -- it can be fixed very easily by simply duplicating the link and adding a space in between...
/mehas nothing to add to the rest of the post...
Post by: Nao on May 17th, 2012, 10:34 AM
Correct. I believe SMF has patched it as best possible given the nature of the caches though.Quote Do you mean the clear cache function doesn't clear non-file cache alternatives...?
What should I do? Because I liked the idea of caching this... (Or at least I should do some benchmarking.)
I get what you're saying but I don't think it's that big a deal to be honest. How about we try it and see how people react?
Re: topic, I'm pissed. I just discovered that my iPod is having the hidden user menu bug AGAIN... I had it fixed yesterday. Then it didn't work correctly in Opera and Safari (wrong positioning.) So I rewrote the code to use the main menu technique, and it worked... Except I didn't test in my iPod. And it fails exactly the same way. >_<
Posted: May 17th, 2012, 10:22 AM
Ugliest hack ever... (thankfully, for iOS stylesheets only)
h4 .mime
position: absolutePost by: Nao on May 17th, 2012, 02:59 PM
Yup, as far as I know it was patched in their Git repo, along with the fact that the cache level and type are now globals and not in $settings. (So that the settings table can actually be cached and read properly from cache, regardless of which cache we're talking about)Quote After SMF 2.0 you mean?
Your posts make me feel like it's a bad idea to use the file cache for... pretty much anything?!
Re: topic, so I've made a working prototype that uses the parent's offset position to show the element, rather than relative+nested absolute positioning (which always had my preference).
Pros:
- it will work everywhere... hopefully...
- it's relatively easier to understand what it does
- no, or less, esoteric hacks that even I can barely understand
Cons:
- if you resize the window while the menu is open (e.g. in Opera if I press F4 to show or hide the sidebar that holds my tab list), it'll be repositioned somewhere else (usually not under the parent item!)
- if you modify the CSS layout or HTML structure while a menu is open, the same will happen...
- and it does the same even if the menu isn't open, unless you store the parent's coordinates on all mouseenter events (which is what I'm doing right now, it's probably a tad slower too...)
- it's not as cool.
- it takes a bit more JS code (~20 bytes...)
- did I say more code..?
- and more code, too.
I could apply this to the main menu, too... This would avoid similar issues with IE8, although I fixed them with an odd hack as mentioned in the other topic.
I'm not exactly sure at this point, which way I should follow...
Posted: May 17th, 2012, 02:48 PM
Oh... Also: absolute positioning makes it harder to work in non-JavaScript environments, unless I'm very careful. Basically, I'd need to add position:relative to the parent in CSS, and remove it through JS to allow for positioning relative to the document. Meh...!
Post by: Nao on May 17th, 2012, 04:54 PM
(Trying to keep this on-topic... Just that I don't want long posts about the cache stuff to kill the action button discussion ;))
Oh BTW, I'm trying to go back to relative positioning and figure out why exactly it fails in iOS etc...
Will answer your post once I'm done!
Post by: Nao on May 17th, 2012, 05:00 PM
But it seems to work when I do it that way... Meh.
Post by: Arantor on May 17th, 2012, 05:15 PM
Post by: Nao on May 17th, 2012, 08:46 PM
Post by: Arantor on May 17th, 2012, 09:41 PM
It feels like it's just a meaningless term.
Post by: Nao on May 17th, 2012, 11:00 PM
But for example in the context of margins, what does 'default' mean, exactly?
It feels like it's just a meaningless term.
Anyway. So, I did my commit...
You'll mainly notice two hacks that I couldn't get rid of -- namely for IE8 and iPhone, in their respective stylesheets.
I'd really like to know if anyone manages to remove these hacks without breaking anything. ESPECIALLY on the iPhone, because AFAIK, Safari Mobile is a decent browser, unlike IE, and I don't get why it's not following my queries regarding positioning... :-/
Post by: live627 on May 18th, 2012, 01:09 AM
Well... Zero?Quote from Arantor on May 17th, 2012, 09:41 PM But for example in the context of margins, what does 'default' mean, exactly?
Post by: Arantor on May 18th, 2012, 01:10 AM
At first brush, all looks good to me, will test more properly later on.
Post by: Nao on May 18th, 2012, 07:23 AM
But then what would happen if the browser default for a margin on a particular tag (<p>) isn't zero?
Post by: Nao on May 18th, 2012, 12:15 PM
Back to square one...
Anyway, I've saved about 10 gzipped bytes by keeping to the on-the-fly creation thingy, which is better than nothing...
OTOH, I've added an extra 10 bytes to script.js just to filter correctly the click event on main menus.
Remember how someone complained that clicking the top-level item in the profile menu would close the menu and clicking it again would do nothing...? Well, the goal wasn't to close the menu, but to close any menu after a click was made, to give a feeling of responsiveness, i.e. "I've registered your call, I'm processing it." However, in the profile menu, there's no link in the top-level item, so it just closes it and does nothing... I had two solution: either I added a filter (for an extra ~10b) or removed the entire click event (to save a whopping ~20 bytes). In the end, I decided to use the filter (.filter(':has(>a,>h4>a)')), because I really like the responsiveness thing... But it also wastes 30 bytes in total, eh.
So, my solution to this...
Well, it's pretty elegant if you will... Although it's totally unrelated :lol:
I 'simply' moved we_avatarResize() to a new file. This function is ~150 bytes gzipped, and it's not used by default (one has to enable a feature in the admin area, "resize with JavaScript" or something.)
That's it... New script file is now 120 bytes smaller, ahah, I love my cache system.
Totally OT now...
A quick poll... I'm thinking of doing a small rewrite to $context['javascript_files']. Instead of adding strings to the array ( [] = 'script.js' ), you would add an indexed array ( ['script.js'] = true ), where 'true' means 'add the filename to the final filename' while false would ignore it.
While it isn't useful right now, I can imagine that some modders would like to be able to add their files to the main script, *and* not have them pollute the final filename. Right now, it's not possible to do it because the list of ignored filenames (custom, sbox, theme, and now avasize) is hardcoded into our source files...
Since it makes the javascript_files array a bit harder to understand than just using a simple list of files, I'd rather ask because there's always a fine line between customizability (English??) and complexity.
Posted: May 18th, 2012, 11:38 AM
A quick poll... I'm thinking of doing a small rewrite to $context['javascript_files']. Instead of adding strings to the array ( [] = 'script.js' ), you would add an indexed array ( ['script.js'] = true ), where 'true' means 'add the filename to the final filename' while false would ignore it.
Except for the fact that the $ignore_files flag now acts differently in both add_js_file and add_css_file... Meh!
Post by: Nao on May 18th, 2012, 07:21 PM
I'd like to add mini-menus to more buttons.
Let's see if we can set something up that would make sense and improve usability?
- Like: I already mentioned it, there are several links that could be added to it...
- Quote: main link points to the default setup...? Opening it in a new tab points to full quote either way. Additional links: disambiguation -- Quick quote, Full quote.
- Modify: main link points to quick edit, but opening it in a new tab points to full edit. Additional links: disambiguation -- Quick edit, Full edit.
What do you think...?
Also, should the Modify button be placed where it is, and the Quick Edit button removed entirely? Or should the Modify button be placed to the right of More? (Renaming More to Actions...?) Or should both buttons stay?
Post by: NeobeatIKK on May 18th, 2012, 07:42 PM
Personally I like to have all actions in one place. Edit, quick edit, report should be in the More menu.
Post by: Nao on May 18th, 2012, 07:45 PM
Post by: NeobeatIKK on May 18th, 2012, 07:51 PM
Post by: Nao on May 18th, 2012, 07:53 PM
(Hmm, here's wondering if we should add some kind of warning that although edits are allowed, the threshold for 'last modified' has expired...)
Post by: NeobeatIKK on May 18th, 2012, 07:59 PM
Post by: Nao on May 18th, 2012, 08:58 PM
Okay, another set of questions...
I'd like to add mini-menus to more buttons.
Let's see if we can set something up that would make sense and improve usability?
- Like: I already mentioned it, there are several links that could be added to it...
- Quote: main link points to the default setup...? Opening it in a new tab points to full quote either way. Additional links: disambiguation -- Quick quote, Full quote.
- Modify: main link points to quick edit, but opening it in a new tab points to full edit. Additional links: disambiguation -- Quick edit, Full edit.
What do you think...?
Also, should the Modify button be placed where it is, and the Quick Edit button removed entirely? Or should the Modify button be placed to the right of More? (Renaming More to Actions...?) Or should both buttons stay?
Post by: Nao on May 22nd, 2012, 04:46 PM
http://wedge.org/pub/feats/7420/rewriting-the-skin-file-parser/
(Please note that a few mentions about the action menus are moved there, and a few mentions on file caches are left here -- this is because of posts that mix them up together, obviously.)