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 - Arantor
5041
Off-topic / Re: Doctor Who
« on January 21st, 2012, 10:50 PM »
It's deliberately ambiguous but I always thought it was the Doctor himself in there, much as the whole Dream Lord thing - "only one person hates me that much"
5042
The Pub / Re: Logo Madness
« on January 21st, 2012, 01:30 PM »Yeah, it's a pretty good logo really. I tried it as Worg's footer logo yesterday and it worked just as well as the current minilogo (which is hard to unseat!)
Oh, Worg is the codename for the new skin, it's just 'Wedge.org'...
It's the same font, Helsinki. You can look it up Fontsquirrel. It's definitely a bit tilted to the right -- not just the E, all letters.
What matters here is that... How to say it. I think Wedge needs a font that's both 'original' and 'classic'. Most successful logos try to distantiate themselves from Helvetica & co fonts, yet remain very basic to be both readable and not stand out too much. (Why does my spell-checker complain on the word 'distantiate'....? Doesn't that word exist in English? What should it be? Push themselves further away, or something...?)
I currently focus my work on Lato, which I found on Google Fonts. See the attached pic.
(Distantiate isn't a word. The word you're after here is 'distance', which is one of those awesome words that's both a verb and a noun.)
But yeah, I see what you're getting at.
Definitely not good. (And 21, either.)
I made something in between 18 and 20 -- what do you think? Also went for 'as sober as possible' by getting rid of the nice little gradient effects, and choosing a more primary color. Maybe a bit too 'strong', though...
And another font I like... Sansation Bold. I realize it's a bit small to distinguish the letters and all, but you can always look it up
'Sober' is definitely carried through on both 22 and 23 and I'm getting the 'wedge' vibe from it, but more from 22 than 23; the brown just doesn't quite have the weight to it that the blue does.
5043
The Pub / Re: Logo Madness
« on January 20th, 2012, 11:06 PM »
16 I like. The boldness of the text seems to counter my usual 'block of stone' view of densely package capitals. Colouring is nice, it's not overstated.
17 I like too, though to decide if the first E looks like it's tilted slightly, it seems out of line compared to the other letters.
18 is nice. Carries the effect of the wedge. Not sure about the green, and I'm getting a slightly 'vague' feeling about it. It's as though it's not wanting to commit to things a bit (like how I feel right now)
20 I'm not so keen on. There's too much background, not enough foreground and it just looks like two triangles in a big space; there's no 'wedge' feeling about it.
17 I like too, though to decide if the first E looks like it's tilted slightly, it seems out of line compared to the other letters.
18 is nice. Carries the effect of the wedge. Not sure about the green, and I'm getting a slightly 'vague' feeling about it. It's as though it's not wanting to commit to things a bit (like how I feel right now)
20 I'm not so keen on. There's too much background, not enough foreground and it just looks like two triangles in a big space; there's no 'wedge' feeling about it.
5047
So, what you're saying is that I should always sjove A, B, C though even if the current user is on the list anyway, just on the off chance that they unlike it, as opposed to just updating the list on return?
Eh, no thanks. Don't like shoving more content through than necessary.
Eh, no thanks. Don't like shoving more content through than necessary.
5048
It doesn't matter. You can't just magically wave your hand at the DOM and deal with data you simply do not have.
As standard, let's say you display 3 names of likes plus a total for everyone else. For things you haven't liked yet, that means you have 'A, B, C and X others like this'.
Now, we can handle liking this content in the DOM and convert it to 'You, A, B and (X+n) others like this' where we fix the X+n part to be a live count.
The problem comes when we try to unlike the content. 'You, A, B and X others like this' needs to become 'A, B, C and X others like this' - but you don't have C in the DOM!
As standard, let's say you display 3 names of likes plus a total for everyone else. For things you haven't liked yet, that means you have 'A, B, C and X others like this'.
Now, we can handle liking this content in the DOM and convert it to 'You, A, B and (X+n) others like this' where we fix the X+n part to be a live count.
The problem comes when we try to unlike the content. 'You, A, B and X others like this' needs to become 'A, B, C and X others like this' - but you don't have C in the DOM!
5049
No, not for 'you' but for the other names.
Unless you're going to assume that no-one else has liked it in the interim between you opening the page and you pressing like, in which case you only need return the new number of likes, put 'You' in front of it and lop off the last name on the list (which should be achievable client-side). Of course, when you unlike a post, you presumably want to return back to having three names that aren't your own... so you HAVE to return the names with colours.
Unless you're going to assume that no-one else has liked it in the interim between you opening the page and you pressing like, in which case you only need return the new number of likes, put 'You' in front of it and lop off the last name on the list (which should be achievable client-side). Of course, when you unlike a post, you presumably want to return back to having three names that aren't your own... so you HAVE to return the names with colours.
5050
The Pub / Re: Logo Madness
« on January 20th, 2012, 01:01 AM »I have no idea who likes what at this point, and for what reasons
The new two you've posted look good, though I think the background might not have quite enough contrast to the left logo (but then again, I'm no artist and my best attempt didn't exactly light anyone's fire)
I noticed the first three username on the vote for the current logo, "Alanthar and Arantor". Are you three planning on doing a gig?
5051
It does make me wonder about an option F, actually: don't have any of it in the core and make it a plugin. That way we immediately stop worrying about some of the performance issues (then I'd primarily look at option 2 with a dash of 4 anyway)
The other thing is that option 4 is kind of implied in option 2 anyway, though not directly. You still have a master log table of likes so that you can query for 'the number of times my stuff has been liked'[1] but other than that you have a list of ids - nothing says you have to pull all the ids in question, just the first ones that need to be queried, and everything else can just be totalled up with count().
Means I think I might be able to tackle this one tomorrow (implementing option 2 primarily)
The other thing that occurs to me is that when content is liked, we need to return the new like content AJAXively so that we can transform 'X and Y like this' to 'You, X and Y like this'. I still don't think there's a nice way to trigger the colouriser buffer change, is there?
The other thing is that option 4 is kind of implied in option 2 anyway, though not directly. You still have a master log table of likes so that you can query for 'the number of times my stuff has been liked'[1] but other than that you have a list of ids - nothing says you have to pull all the ids in question, just the first ones that need to be queried, and everything else can just be totalled up with count().
Means I think I might be able to tackle this one tomorrow (implementing option 2 primarily)
The other thing that occurs to me is that when content is liked, we need to return the new like content AJAXively so that we can transform 'X and Y like this' to 'You, X and Y like this'. I still don't think there's a nice way to trigger the colouriser buffer change, is there?
| 1. | And if we have aspirations about displaying that on post view, we should similarly cache that in the members table. |
5052
The Pub / Re: Logo Madness
« on January 19th, 2012, 12:52 PM »
Now, with the bigger variant, the blue doesn't take anything away from the writing so it works. Not a fan of the ! variant (both in terms of having the ! and the font it uses), the slightly serif version above it, also not keen on - the font doesn't quite work for me, and I'd rather have the lowercase version, because it's more readable and more interesting.
The variant on brown I don't like much - the font is the same one as the ! one (and I'm not keen on it for the same reason) but I think the brown takes something away from the brown in the main logo.
Of all the ones posted there in big, the one in the lower left is easily my favourite.
Of the smaller logos (10 and 11), I prefer the fact that 11 has more space round the writing but I prefer the emblem in 10.
The variant on brown I don't like much - the font is the same one as the ! one (and I'm not keen on it for the same reason) but I think the brown takes something away from the brown in the main logo.
Of all the ones posted there in big, the one in the lower left is easily my favourite.
Of the smaller logos (10 and 11), I prefer the fact that 11 has more space round the writing but I prefer the emblem in 10.
5053
The Pub / Re: Logo Madness
« on January 19th, 2012, 11:52 AM »
They weren't there when I posted ;)
Lower case text works better (for a variety of reasons, but most importantly because it's actually easier to read), and the lighter blue background certainly works better than the darker one but I still think it's taking something away from the text itself.
Lower case text works better (for a variety of reasons, but most importantly because it's actually easier to read), and the lighter blue background certainly works better than the darker one but I still think it's taking something away from the text itself.
5054
The Pub / Re: Logo Madness
« on January 19th, 2012, 11:02 AM »
Hmm, I'm less enthused by those two than the previous ones. The blue seems to suck the life out of the text somehow.
5055
So, we've talked about this one but all the time up to now I've been putting off implementing it because I was never thoroughly sure how to efficiently handle doing likes.
The idea of doing a big (and potentially expensive) query on thread display never appealed to me but after sitting down and examining XenForo (which does it as a core feature) and seeing how they did it, I find myself unable to find a better way of doing it.
Specifically, their method is to embed an array of entries into the posts table, in a blob[1] and pull that out as display time.
Oddly enough, that actually contains the username as well so there's no extra performance hit there, but I imagine the change of display name is expensive if that person did a lot of likes.
So, for the programmers out there, what do you reckon?
As I see it, there are four options:
1. Just store the likes/post relationship and query it at display time (optionally with caching). Smallest in the DB, no additional maintenance, but it does mean there's an extra query - and we do have to run through that query in its entirety, it's not like we can stick a limit in, because you can't do a limit per criteria: you can't get "3 rows of that criteria, 10 rows of that", so we have to evaluate all the likes on the page at once.
2. Store the list of ids who like a post into the post table, and add that list of people into the main loadMemberData call (or do a second, smaller one just for minimal since we only need the names at that point). Much quicker and more efficient, but there's still extra work being done to handle the overhead of gathering names etc. (though of course we only get the right number of names, the first 3 or so actual names and just bundle the rest together)
3. Store the list of ids and names in the post table. Consumes a lot more space than either of the other two options, however it means there's no extra effort involved other than parsing the extra item (which need only be an unserialize call, or even a json_decode call, bearing in mind that we only need the first 3 or so rows, and can discard the rest after), and of course adds to the maintenance work if a user changes their display name.
4. We store just the count of likes in the post table, and fetch the list (using the same table as in 1) AJAXively if someone asks. Much lighter than the others, but far less nice IMHO.
Thoughts?
The idea of doing a big (and potentially expensive) query on thread display never appealed to me but after sitting down and examining XenForo (which does it as a core feature) and seeing how they did it, I find myself unable to find a better way of doing it.
Specifically, their method is to embed an array of entries into the posts table, in a blob[1] and pull that out as display time.
Oddly enough, that actually contains the username as well so there's no extra performance hit there, but I imagine the change of display name is expensive if that person did a lot of likes.
So, for the programmers out there, what do you reckon?
As I see it, there are four options:
1. Just store the likes/post relationship and query it at display time (optionally with caching). Smallest in the DB, no additional maintenance, but it does mean there's an extra query - and we do have to run through that query in its entirety, it's not like we can stick a limit in, because you can't do a limit per criteria: you can't get "3 rows of that criteria, 10 rows of that", so we have to evaluate all the likes on the page at once.
2. Store the list of ids who like a post into the post table, and add that list of people into the main loadMemberData call (or do a second, smaller one just for minimal since we only need the names at that point). Much quicker and more efficient, but there's still extra work being done to handle the overhead of gathering names etc. (though of course we only get the right number of names, the first 3 or so actual names and just bundle the rest together)
3. Store the list of ids and names in the post table. Consumes a lot more space than either of the other two options, however it means there's no extra effort involved other than parsing the extra item (which need only be an unserialize call, or even a json_decode call, bearing in mind that we only need the first 3 or so rows, and can discard the rest after), and of course adds to the maintenance work if a user changes their display name.
4. We store just the count of likes in the post table, and fetch the list (using the same table as in 1) AJAXively if someone asks. Much lighter than the others, but far less nice IMHO.
Thoughts?
| 1. | Eh, could be a text, can't think of any overwhelming differences, other than that it's harder to get a blob in a table, you have to prance around doing CAST() to get at it. |