Show Likes
This section allows you to view all posts where this member received or gave a like to.
1
...And 2 months, and 2 days.
Okay, maybe not 2 days, more like 6, but apart from Pete and I, you weren't there to count in the beginning, were you? ;)
Just in case you aren't aware yet, I finally managed to put the finishing touches to a 'usable' version of Wedge, and released it early this morning to early beta testers.
In order to download it, you'll have to request access in the relevant topic, but since this is still a private alpha, we're going to be giving access mostly to those of you who've been following us for some time (and posting along), anyone who seems serious about Wedge and testing it.
Our plans are to release a public alpha before the end of the year (well, just in case the Incas were right). We're going to try and keep Wedge in frozen mode, so we won't be adding any new (major) features, although we do have a few outstanding features (or bug fixes) which we plan to ship before we go public. And who knows, maybe we'll have a good week at some point and will even be able to go gold before the end of the year...? Naah, can't be.
Okay, maybe not 2 days, more like 6, but apart from Pete and I, you weren't there to count in the beginning, were you? ;)
Just in case you aren't aware yet, I finally managed to put the finishing touches to a 'usable' version of Wedge, and released it early this morning to early beta testers.
In order to download it, you'll have to request access in the relevant topic, but since this is still a private alpha, we're going to be giving access mostly to those of you who've been following us for some time (and posting along), anyone who seems serious about Wedge and testing it.
Our plans are to release a public alpha before the end of the year (well, just in case the Incas were right). We're going to try and keep Wedge in frozen mode, so we won't be adding any new (major) features, although we do have a few outstanding features (or bug fixes) which we plan to ship before we go public. And who knows, maybe we'll have a good week at some point and will even be able to go gold before the end of the year...? Naah, can't be.
2
Why would you give comments to an album, out of interest?
I can see the logic of album-level default tags but I'm not sure it would be that useful. (FWIW, I don't recall it ever being asked for before)
What would you use these things for? (I'm not interested in how hypothetically these might be useful to the community at least, I'm interested in how, assuming you had the facility, how exactly you would use them. How you intend to use a feature specifically is a different thing to explaining its benefit generically. ;))
I can see the logic of album-level default tags but I'm not sure it would be that useful. (FWIW, I don't recall it ever being asked for before)
What would you use these things for? (I'm not interested in how hypothetically these might be useful to the community at least, I'm interested in how, assuming you had the facility, how exactly you would use them. How you intend to use a feature specifically is a different thing to explaining its benefit generically. ;))
3
... there was a smf community member that replies to every tech related question about smf in about 5 or 10 minutes. :)
I've posted a simple question 30 minutes ago, when will I have a reply? :eheh:
P.S. - Off course: thank you Arantor for all the support you gave me in smf forum in the past. :)
I've posted a simple question 30 minutes ago, when will I have a reply? :eheh:
P.S. - Off course: thank you Arantor for all the support you gave me in smf forum in the past. :)
4
So... It's been a few days/weeks since I moved the action bar from the top of a post to the bottom.
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...
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...
5
OK, so I took a bit of time out to work on this today.
So far I have the core like behaviour set up, though there's no permission check (any non-guest can like content), and there's a bunch of housekeeping that isn't being carried out either. I have also got the AJAX callback set up as well, so it can AJAXively update and return the new 'x, y, whatever likes this' string.[1]
Anyway, still to do:
* tie up the AJAX stuff so it's called AJAXively and updates as such
* implement some kind of permission
* implement caching
Here's the thing. I did some studying of what goes on elsewhere, and I found that in reality getting the like data is actually going to be very awkward, not to mention unhelpful in other respects.
As it stands, we get the message ids, the poster ids and the post times early on, but bulking that query out to fetch a text field is going to make it expensive, especially if I subsequently throw all the extra ids into the loadMemberData queries, doubly so when you consider that in most cases the names you're loading probably won't be ones you need anything for except the name.
So my plan instead is to cache the list based on a page's worth of messages - I get all the like data I actually need for a page's worth of messages, and cache that as a single unit, so I can reload it as-is. So right now all there is, is the one extra table that stores likes, and nothing else. The overhead is not actually that significant especially since it looks like it's being indexed meaningfully.[2] The only need for caching is simply because it will be queried in its entirety and the information digested appropriately, but the whole point of caching will fix the side issues with that.
So far I have the core like behaviour set up, though there's no permission check (any non-guest can like content), and there's a bunch of housekeeping that isn't being carried out either. I have also got the AJAX callback set up as well, so it can AJAXively update and return the new 'x, y, whatever likes this' string.[1]
Anyway, still to do:
* tie up the AJAX stuff so it's called AJAXively and updates as such
* implement some kind of permission
* implement caching
Here's the thing. I did some studying of what goes on elsewhere, and I found that in reality getting the like data is actually going to be very awkward, not to mention unhelpful in other respects.
As it stands, we get the message ids, the poster ids and the post times early on, but bulking that query out to fetch a text field is going to make it expensive, especially if I subsequently throw all the extra ids into the loadMemberData queries, doubly so when you consider that in most cases the names you're loading probably won't be ones you need anything for except the name.
So my plan instead is to cache the list based on a page's worth of messages - I get all the like data I actually need for a page's worth of messages, and cache that as a single unit, so I can reload it as-is. So right now all there is, is the one extra table that stores likes, and nothing else. The overhead is not actually that significant especially since it looks like it's being indexed meaningfully.[2] The only need for caching is simply because it will be queried in its entirety and the information digested appropriately, but the whole point of caching will fix the side issues with that.
| 1. | Though because I'm doing it through the action=like handler rather than anything else, it got... upset... I had to expressly detect for and start the gzhandler buffer otherwise the browsers all cacked themselves at the content being incorrect. |
| 2. | The table structure is four columns: id-content, content-type, id-member, like-time. This way, likes can be extended to media or whatever else with little real effort in the DB. The trick here is that content-type is a fixed width field, currently 6 characters, which should be enough to be at least representative of content, currently only 'post' is supported but there's the foundation for hooks to be able to extend it arbitrarily. But because it's fixed width rows, with a primary key of id-content/content-type/id-member, and queried that way, it should be pretty lean. |
6
So... A thing happened, and then another, and my plans to publish Wedge today were scrapped. So, I uploaded the website to a temp folder, installed it, fixed a few other bugs, then left it aside for now because it's unrealistic to expect the Wedge team to upgrade Wedge.org to Wedge precisely before going to bed, ah ah. We need to make sure it works for everyone.
It will STILL make it on March 15... Just that it will be March 15, *Hawaii time* :P
Ah well. If you just can't wait anymore, here's a little something to help you wait until next morning (if you're in Europe like us.) A small screenshot of the new default skin, Weaving. And yes, this is the first time it's made public.
Hope you like it! I'm off to bed. Deserved a good (but short) night's sleep.
It will STILL make it on March 15... Just that it will be March 15, *Hawaii time* :P
Ah well. If you just can't wait anymore, here's a little something to help you wait until next morning (if you're in Europe like us.) A small screenshot of the new default skin, Weaving. And yes, this is the first time it's made public.
Hope you like it! I'm off to bed. Deserved a good (but short) night's sleep.