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.
Topics - Arantor
106
Plugins / Attachment errors
« on December 23rd, 2012, 11:37 PM »
For some reason, attachment handling is broken. If I upload an attachment, I have all sorts of issues afterwards with topics failing to be made because I have attachments still in session, even though they're not in the temporary area.
E.g.
Code: [Select]
I don't know if that's solely due to the multi attach plugin but it's damned irritating.
E.g.
stat failed for /.../attachments/post_tmp_2367_1 in /.../Plugins/Multi-Attach/plugin.php on line 36I don't know if that's solely due to the multi attach plugin but it's damned irritating.
107
The Pub / Viewing IP addresses and banning
« on December 17th, 2012, 01:49 AM »
So I ran into a headache with bans.
In Wedge[1] viewing of IP address is its own permission. This is, generally, a good thing because of all the people who want to hide IP addresses every which way.
But banning is a separate permission. Now, while it's somewhat unlikely, I can envisage the situation where someone has the power to ban but no ability to see IP addresses, which means it's somewhat dangerous giving them IP addresses as a ban target since they won't have that information.
This leads me to one of three things:
1. Requiring both view-any IP and ban permission to actually ban. (Seems to me it will cause support topics)
2. Making it so the ban UI doesn't allow them to create/edit IP/hostname bans if they don't have the power to see IP addresses. (Complicated)
3. Not having the IP visibility permission at all and tying it to the ban permission.
See, here's the thing. I have no idea what the point of having IP addresses visible anywhere is (not even in the likes of track IP or even moderation log) if you can't do anything with it. Seems to me that the only thing that actually really makes use of it is banning, and if you can ban, you can see all IP addresses - and if you can't ban, you can't see them. I'm struggling to envisage any case at all where you would need IP addresses but not the power to ban, more importantly what can you do with an IP address if you *can't* ban anyway?
In Wedge[1] viewing of IP address is its own permission. This is, generally, a good thing because of all the people who want to hide IP addresses every which way.
But banning is a separate permission. Now, while it's somewhat unlikely, I can envisage the situation where someone has the power to ban but no ability to see IP addresses, which means it's somewhat dangerous giving them IP addresses as a ban target since they won't have that information.
This leads me to one of three things:
1. Requiring both view-any IP and ban permission to actually ban. (Seems to me it will cause support topics)
2. Making it so the ban UI doesn't allow them to create/edit IP/hostname bans if they don't have the power to see IP addresses. (Complicated)
3. Not having the IP visibility permission at all and tying it to the ban permission.
See, here's the thing. I have no idea what the point of having IP addresses visible anywhere is (not even in the likes of track IP or even moderation log) if you can't do anything with it. Seems to me that the only thing that actually really makes use of it is banning, and if you can ban, you can see all IP addresses - and if you can't ban, you can't see them. I'm struggling to envisage any case at all where you would need IP addresses but not the power to ban, more importantly what can you do with an IP address if you *can't* ban anyway?
| 1. | SMF doesn't do it this way, it ties the permission to moderate_forum. |
108
Off-topic / GMail domains
« on December 16th, 2012, 08:23 PM »
Can people give me a complete list of official GMail domains that can receive email, including GoogleMail domains? I kind of need this and I can't find it online thus far.
So far I have:
gmail.com
googlemail.com
gmail.de
Domains that are not GMail domains:
gmail.ru
I'm not actually expecting much more, just want to make sure I get the right ones.
So far I have:
gmail.com
googlemail.com
gmail.de
Domains that are not GMail domains:
gmail.ru
I'm not actually expecting much more, just want to make sure I get the right ones.
109
Off-topic / Programming styles, and does it really matter?
« on December 15th, 2012, 04:55 AM »
So, I've been reading up on vB 5, mostly out of the trainwreck mentality, and a bit of curiosity about how it's shaping up[1] and one of the things I've seen is commentary from developers doing a sort of peer review.
It also brings to mind a conversation I've had in the last couple of days, about coding style, where I said that a fair chunk of Wedge's code is written 'SMF style', which is a completely fair assessment from my perspective; Nao and I spent so long writing for/with SMF that it's not really surprising that it has shaped how we do things. There are some more modern things - there are more classes and things like exceptions in the newer code, but it doesn't change the fact that it's still carrying a lot of SMF structure and mentality to it.
Now, there are some interesting debates about OOP and procedural coding out there (and we are more OOP than the past) but my real point is... does it actually matter?
The only people who are going to see the code are the people who are going to modify the code, either directly or through a plugin - and of course us, in development and bug fixing. Whether something uses OOP or not should not be a concern for most people - and even for the people who do have a concern because they use the code, I'm not entirely sure most of them understand all the ramifications - heck, I'm not entirely sure I do some of the time.
Having classes to bundle functionality can be important. But it doesn't have to be as important as some of the pundits and reviewers say it is.
What I do know, and believe in, is using the right tool for the job. OOP is a tool, nothing more, but a lot of the 'but it isn't OOP' stuff seems to drift into the realms of 'when all you have is a hammer, every problem looks like a nail'. There's good OOP, there's bad OOP, just as there's good and bad procedural code, and we have a strange mish-mash, some of which we've inherited and some of which we've fixed.
But how many people care? As long as it works, does it actually matter that much?
/discuss
It also brings to mind a conversation I've had in the last couple of days, about coding style, where I said that a fair chunk of Wedge's code is written 'SMF style', which is a completely fair assessment from my perspective; Nao and I spent so long writing for/with SMF that it's not really surprising that it has shaped how we do things. There are some more modern things - there are more classes and things like exceptions in the newer code, but it doesn't change the fact that it's still carrying a lot of SMF structure and mentality to it.
Now, there are some interesting debates about OOP and procedural coding out there (and we are more OOP than the past) but my real point is... does it actually matter?
The only people who are going to see the code are the people who are going to modify the code, either directly or through a plugin - and of course us, in development and bug fixing. Whether something uses OOP or not should not be a concern for most people - and even for the people who do have a concern because they use the code, I'm not entirely sure most of them understand all the ramifications - heck, I'm not entirely sure I do some of the time.
Having classes to bundle functionality can be important. But it doesn't have to be as important as some of the pundits and reviewers say it is.
What I do know, and believe in, is using the right tool for the job. OOP is a tool, nothing more, but a lot of the 'but it isn't OOP' stuff seems to drift into the realms of 'when all you have is a hammer, every problem looks like a nail'. There's good OOP, there's bad OOP, just as there's good and bad procedural code, and we have a strange mish-mash, some of which we've inherited and some of which we've fixed.
But how many people care? As long as it works, does it actually matter that much?
/discuss
| 1. | The answer is badly. Even fresh installs are taking 60+ queries to do simple pages. |
110
Features / Purging users pending approval, and some other stuff
« on December 14th, 2012, 10:07 PM »
So, working on the whole nature of is_activated spawns a few ideas.
1) Purging users pending approval
One of the things that I hear regularly from other forum software is that users tend to delete users who haven't approved their email in a couple of days. To me, this makes a fair amount of sense, if a user hasn't activated their account within a day or so of signup, odds are they're not going to. So, it also makes sense to me, then, that after a day or so, we could automatically purge that for admins.
I don't see this causing significant extra load anywhere, nor do I see it causing any other problems at this time, but I'm opening the floor to discussions and thoughts on the subject.
2) User re-agreeing to agreement (required re-agreement)
This is something I've wanted to add for a while, and I mentioned it in my other topic. Mechanically all you'd do is take any user that already got approved (is_activated state 1) and update it to a new state (provisionally state 6) when the details change to force them to agree to it again, and since it's wired in at account level, they'd *have* to do it to continue.
The problem with this is the case of users who are not currently state 1, all the little fringe cases where their account is somewhere else:
* state 0 - user has signed up and in the time between signing up and approving their account, the terms changed
* state 2 - user is a current member but has changed their email address
* state 3 - user is waiting for admin approval, much like state 0, it's possible the terms changed between their registration and admin approval
* state 4 - user is waiting for account deletion, probably not a problem!
* state 5 - user is waiting for COPPA approval, this is probably the most likely problematic, a user subject to this is very likely going to have to wait some time to actually get their account approved as they would have to send the form through the post, and that makes it more likely to have changed
Actually now that I really think about it, all we really need to do is track their registration time against the time the agreement was last edited, and if they registered before the agreement changes, move their state to 6 rather than to 1. In fact, if we do it as a 'last change to status' column in general, that problem goes away in its entirety. Talking it through really does work!
3) We could drop the Location profile field and make it a custom profile field.
It's not a thing I've seen that much, dropping from the core and making it a CPF means it's not cluttering up the members table, and it's only in use if someone actually wants it on their forum, rather than being on by default and only able to softly disable it.
1) Purging users pending approval
One of the things that I hear regularly from other forum software is that users tend to delete users who haven't approved their email in a couple of days. To me, this makes a fair amount of sense, if a user hasn't activated their account within a day or so of signup, odds are they're not going to. So, it also makes sense to me, then, that after a day or so, we could automatically purge that for admins.
I don't see this causing significant extra load anywhere, nor do I see it causing any other problems at this time, but I'm opening the floor to discussions and thoughts on the subject.
2) User re-agreeing to agreement (required re-agreement)
This is something I've wanted to add for a while, and I mentioned it in my other topic. Mechanically all you'd do is take any user that already got approved (is_activated state 1) and update it to a new state (provisionally state 6) when the details change to force them to agree to it again, and since it's wired in at account level, they'd *have* to do it to continue.
The problem with this is the case of users who are not currently state 1, all the little fringe cases where their account is somewhere else:
* state 0 - user has signed up and in the time between signing up and approving their account, the terms changed
* state 2 - user is a current member but has changed their email address
* state 3 - user is waiting for admin approval, much like state 0, it's possible the terms changed between their registration and admin approval
* state 4 - user is waiting for account deletion, probably not a problem!
* state 5 - user is waiting for COPPA approval, this is probably the most likely problematic, a user subject to this is very likely going to have to wait some time to actually get their account approved as they would have to send the form through the post, and that makes it more likely to have changed
Actually now that I really think about it, all we really need to do is track their registration time against the time the agreement was last edited, and if they registered before the agreement changes, move their state to 6 rather than to 1. In fact, if we do it as a 'last change to status' column in general, that problem goes away in its entirety. Talking it through really does work!
3) We could drop the Location profile field and make it a custom profile field.
It's not a thing I've seen that much, dropping from the core and making it a CPF means it's not cluttering up the members table, and it's only in use if someone actually wants it on their forum, rather than being on by default and only able to softly disable it.
111
Features / Changes to banning
« on December 14th, 2012, 06:20 PM »
This is more of a FYI and note in case it spawns bugs (it might introduce issues from the converter, I guess, as well as any place I didn't already catch)
I originally planned to overhaul is_activated in a different way, a long time ago, but I realised that it's sort of unnecessary (and not as performant as I'd hoped), so here's the plan for what is_activated means going forward. (There are so many fringe cases in SMF/Wedge around this >_<)
0 - user has registered, waiting for email activation
1 - user has registered and is active
2 - user has previously registered and is active but has changed their email address
3 - awaiting admin approval
4 - user is pending deletion
5 - awaiting COPPA approval
10 -> 19 - as 0 - 9 but with 'discourage' (i.e. Annoy User)
20 -> 29 - as 0 - 9 but banned on top
In other words, all I've done is move what was previously 10+ being banned to being 20+, with 10-19 being the new annoy facility. I also believe this is the only complete list of what all the states in SMF do for is_activated, I don't believe anyone previously actually figured it out (not even me, my original topic mentioning the changes I had originally planned didn't note states 2, 3 or 5, and until today I wasn't actually sure what state 2 did)
It is also possible additional statuses will be added, I'm likely going to add status 6 to mean 'user has to re-agree to the user agreement' but not just yet ;)
I originally planned to overhaul is_activated in a different way, a long time ago, but I realised that it's sort of unnecessary (and not as performant as I'd hoped), so here's the plan for what is_activated means going forward. (There are so many fringe cases in SMF/Wedge around this >_<)
0 - user has registered, waiting for email activation
1 - user has registered and is active
2 - user has previously registered and is active but has changed their email address
3 - awaiting admin approval
4 - user is pending deletion
5 - awaiting COPPA approval
10 -> 19 - as 0 - 9 but with 'discourage' (i.e. Annoy User)
20 -> 29 - as 0 - 9 but banned on top
In other words, all I've done is move what was previously 10+ being banned to being 20+, with 10-19 being the new annoy facility. I also believe this is the only complete list of what all the states in SMF do for is_activated, I don't believe anyone previously actually figured it out (not even me, my original topic mentioning the changes I had originally planned didn't note states 2, 3 or 5, and until today I wasn't actually sure what state 2 did)
It is also possible additional statuses will be added, I'm likely going to add status 6 to mean 'user has to re-agree to the user agreement' but not just yet ;)
112
Yeah, I was going to do this sometime or another, partly to test the bbcode integration in the plugin manager and partly to test the hook changes with the wedit class, neither of which I've done in a while.
It's fairly pedestrian, it just adds a simple button, but I've found two bug fixes and a minor enhancement to be added as a result, so it was worth it ^_^
It's fairly pedestrian, it just adds a simple button, but I've found two bug fixes and a minor enhancement to be added as a result, so it was worth it ^_^
113
Plugins / Posts Per Day
« on December 5th, 2012, 04:56 AM »
Hot on the heels of Word Count Limits - I mean, it's about 60% the same code - is Posts Per Day. Technically, it's Posts In The Last 24 Hours, but for most people the difference really won't matter much.
Same deal as before, you can tie it to any other rules you care to name, so you can limit it to certain post counts, or certain groups or even within certain boards. In fact, you could even be really bizarre and limit it so that a user can't post in a given board if they haven't made enough posts elsewhere that day. Not sure why you *would*, but you *could*.
Note that this doesn't allow you to pick which boards those posts came from, so the count of posts in the last 24 hours is total posts in the last 24 hours. It doesn't allow for moderated or deleted posts at this time, it just assumes they're to be counted as well. There's no reason why it couldn't be altered if it really needed it.
Also, it is up in the plugins area for beta testers. Same as the comments for Word Count Limits; the warning message for prevented-post is not meaningful. Maybe this will encourage me to fix it heh.
Same deal as before, you can tie it to any other rules you care to name, so you can limit it to certain post counts, or certain groups or even within certain boards. In fact, you could even be really bizarre and limit it so that a user can't post in a given board if they haven't made enough posts elsewhere that day. Not sure why you *would*, but you *could*.
Note that this doesn't allow you to pick which boards those posts came from, so the count of posts in the last 24 hours is total posts in the last 24 hours. It doesn't allow for moderated or deleted posts at this time, it just assumes they're to be counted as well. There's no reason why it couldn't be altered if it really needed it.
Posted: December 5th, 2012, 04:55 AM
Also, it is up in the plugins area for beta testers. Same as the comments for Word Count Limits; the warning message for prevented-post is not meaningful. Maybe this will encourage me to fix it heh.
114
Plugins / Word Count Limits
« on December 5th, 2012, 04:02 AM »
OK, so I ported my old Word Count Limits plugin to Wedge[1], and I did some overhauling in the process.
The idea of the plugin is to limit posts that are either too short or too long, and do something about it. In this case, it hooks into the moderation filters stuff, so you can make moderation systems as flexible as you like.
Want to enforce a minimum of 5 words on every post? Easy.
Want to enforce a minimum of 100 words on every new topic (not just replies), but only in a certain board? Almost as easy. (Moderation Filters > New Rule > Prevent the post when... a new topic is started... where board is <given board> and the number of words in the post is less than 100 words)
Yup, moderation filters is damn awesome, even if I do say so myself haha. Screenshot of this feature is attached.
Also, I made it so it could be both words and individual characters (where a complex accented letter or other multi-byte character is counted as 1) could be handled, through the same facility.
There is one caveat: right now moderation filters has one major flaw, in that the 'prevent the post being made' message is not very helpful - it just says 'The post contained content that is not permitted on this forum'. I know about that, I just don't know yet how best to fix it - I've been wrestling with it since I added mod filters months and months ago. The problem is that the combination of rules that could be causing a post to be denied is extremely complicated and potentially multiple rules could all cause the same result.
Imagine a rule that says the post will be prevented if the word 'fuzzlewuck' is in the post, but only if it's in the posted in certain boards, and they have less than 100 posts. How best to convey that to the user? (But the moderation filters can trivially enough create that set of rules.)
Anyway. I digress. Have at it. (It's in the plugin area for beta testers)
Also, the API for extending moderation filters needs cleaning up. I know live627 kind of hinted at that, but damn it is ugly. When I figure out the above problem, I'll clean up the API while I'm at it, it'll probably need it.
The idea of the plugin is to limit posts that are either too short or too long, and do something about it. In this case, it hooks into the moderation filters stuff, so you can make moderation systems as flexible as you like.
Want to enforce a minimum of 5 words on every post? Easy.
Want to enforce a minimum of 100 words on every new topic (not just replies), but only in a certain board? Almost as easy. (Moderation Filters > New Rule > Prevent the post when... a new topic is started... where board is <given board> and the number of words in the post is less than 100 words)
Yup, moderation filters is damn awesome, even if I do say so myself haha. Screenshot of this feature is attached.
Also, I made it so it could be both words and individual characters (where a complex accented letter or other multi-byte character is counted as 1) could be handled, through the same facility.
There is one caveat: right now moderation filters has one major flaw, in that the 'prevent the post being made' message is not very helpful - it just says 'The post contained content that is not permitted on this forum'. I know about that, I just don't know yet how best to fix it - I've been wrestling with it since I added mod filters months and months ago. The problem is that the combination of rules that could be causing a post to be denied is extremely complicated and potentially multiple rules could all cause the same result.
Imagine a rule that says the post will be prevented if the word 'fuzzlewuck' is in the post, but only if it's in the posted in certain boards, and they have less than 100 posts. How best to convey that to the user? (But the moderation filters can trivially enough create that set of rules.)
Anyway. I digress. Have at it. (It's in the plugin area for beta testers)
Posted: December 5th, 2012, 03:58 AM
Also, the API for extending moderation filters needs cleaning up. I know live627 kind of hinted at that, but damn it is ugly. When I figure out the above problem, I'll clean up the API while I'm at it, it'll probably need it.
| 1. | http://custom.simplemachines.org/mods/index.php?mod=2117 if you're wondering. Though this is better, even if the underlying detection for word count is much the same. |
115
The Pub / Documentary Videos
« on December 5th, 2012, 03:08 AM »
I've been thinking about doing some videos about Wedge's features - not unlike the 'Have You Seen' board in XenForo's main community forum.
Partly it lets me showcase some of the things we do have, and partly it lets me explain things in a way that I just can't with a conventional forum post.
Thoughts? I don't want to automatically jump at GoogleTube because I think they're just as bad as anything else going on in the Google Tentacly Monster. But I'm not sure any of the others are any better.[1]
Partly it lets me showcase some of the things we do have, and partly it lets me explain things in a way that I just can't with a conventional forum post.
Thoughts? I don't want to automatically jump at GoogleTube because I think they're just as bad as anything else going on in the Google Tentacly Monster. But I'm not sure any of the others are any better.[1]
| 1. | GooTube gives effectively free bandwidth, with ads. Vimeo... Vimeo actually sucks. Plus would be ideal but for videos that 'promote', that would be the much more expensive Pro account. Mind you, that didn't seem to stop XenForo... guess it depends on the difference between promotion and discussion. |
116
Archived fixes / Per language caching is broken
« on November 29th, 2012, 03:17 AM »
So I switched the language for the upcoming language pack I'm working on and things were broken. That's actually irrelevant, because it's also broken when I use French too.
For example, http://localhost/wedge/js/topic-1351888249.js.gz doesn't get generated while topic-french-<timestamp>.js.gz does, though topic-french isn't the one that's loaded. Same deal for other languages too, including <is top secret> language pack.
For example, http://localhost/wedge/js/topic-1351888249.js.gz doesn't get generated while topic-french-<timestamp>.js.gz does, though topic-french isn't the one that's loaded. Same deal for other languages too, including <is top secret> language pack.
117
Features / Converting media to use the same internals as other admin pages
« on November 28th, 2012, 02:07 AM »
This is more a braindump than anything else.
I can fully understand keeping the admin settings entirely separate when it was still an SMF mod - because it's a big and complex mod with dozens and dozens of settings - but now it's in Wedge, not only should it adhere to the same UI as everywhere else (or everywhere get adjusted to how Aeva did it, I'm amenable either way as long as it's consistent), it should reuse as much of the same logic as possible.
Unfortunately, given this, we're almost closer to being a rewrite of the admin logic rather than being a simple set of changes - since the original logic is set up to serve the three different pages from a single function. (I'm only talking about Admin > Media > Settings and its subitems at this point, nothing else yet)
What I'm also thinking of doing is pulling the EXIF data out of being its own page and making it a single item with collapsible selector, much like Admin > Members > Registration and Login > Settings > Notify administrators when a new member joins is - we get to save a page and admins only touch it if they need to. And we then only have a single settings entry that contains everything rather than a separate entry per item - and we can do away with the 'display meta data' item, because if the list of metadata items is empty, they didn't want to show anything.
The other thing about converting it to use the standardised methods is that it can be adapted easily to be searchable as well.
I guess the only real question starts turning into how much work it is to remove wedge_media_settings and fold it into the core settings without breaking anything, whether that's feasible/practical/desirable or not. From an admin point of view, I'd say it would tend to be better if it were done that way.
I haven't ruled out any other changes yet, e.g. breaking up the current Configuration page into several smaller pages, e.g. General Configuration, Files and Folders (for the paths, file types and stuff), Previews.
I'm also not entirely sure about the list of file types. It just seems to me that we could possibly do it better than that, perhaps providing a list of default file types we know about and letting users select/deselect. See attachment.
I can fully understand keeping the admin settings entirely separate when it was still an SMF mod - because it's a big and complex mod with dozens and dozens of settings - but now it's in Wedge, not only should it adhere to the same UI as everywhere else (or everywhere get adjusted to how Aeva did it, I'm amenable either way as long as it's consistent), it should reuse as much of the same logic as possible.
Unfortunately, given this, we're almost closer to being a rewrite of the admin logic rather than being a simple set of changes - since the original logic is set up to serve the three different pages from a single function. (I'm only talking about Admin > Media > Settings and its subitems at this point, nothing else yet)
What I'm also thinking of doing is pulling the EXIF data out of being its own page and making it a single item with collapsible selector, much like Admin > Members > Registration and Login > Settings > Notify administrators when a new member joins is - we get to save a page and admins only touch it if they need to. And we then only have a single settings entry that contains everything rather than a separate entry per item - and we can do away with the 'display meta data' item, because if the list of metadata items is empty, they didn't want to show anything.
The other thing about converting it to use the standardised methods is that it can be adapted easily to be searchable as well.
I guess the only real question starts turning into how much work it is to remove wedge_media_settings and fold it into the core settings without breaking anything, whether that's feasible/practical/desirable or not. From an admin point of view, I'd say it would tend to be better if it were done that way.
I haven't ruled out any other changes yet, e.g. breaking up the current Configuration page into several smaller pages, e.g. General Configuration, Files and Folders (for the paths, file types and stuff), Previews.
I'm also not entirely sure about the list of file types. It just seems to me that we could possibly do it better than that, perhaps providing a list of default file types we know about and letting users select/deselect. See attachment.
118
Features / Really petty, but I got to ask
« on November 28th, 2012, 01:44 AM »
So, here's me reworking the admin panel. Many of you will be familiar with the checkboxes that are used to indicate on/off status, which is fine. This is how SMF does it.
Some of you will be aware that Aeva and the integration of it into Wedge do something slightly different; they use a dropdown with yes/no in them.
A few of you might be aware how IPB and MyBB do things - any yes/no option is done with two radio buttons. If you're not, I've attached a picture of how IPB does it. MyBB's is similar but uglier.
On top of that, a fourth option occurs to me - using something similar to how iOS does it - effectively a slider with two states, on/off, where it is not merely differently coloured but also differently shaped (the widget is on the other side of the slider, though in practical use it is not a slider but simply a button that looks like a slider)
I'm curious - which would be easiest for you to use?
Some of you will be aware that Aeva and the integration of it into Wedge do something slightly different; they use a dropdown with yes/no in them.
A few of you might be aware how IPB and MyBB do things - any yes/no option is done with two radio buttons. If you're not, I've attached a picture of how IPB does it. MyBB's is similar but uglier.
On top of that, a fourth option occurs to me - using something similar to how iOS does it - effectively a slider with two states, on/off, where it is not merely differently coloured but also differently shaped (the widget is on the other side of the slider, though in practical use it is not a slider but simply a button that looks like a slider)
I'm curious - which would be easiest for you to use?
119
The Pub / Merge topic - notify the user
« on November 27th, 2012, 02:07 AM »
This one is more a speculative idea rather than a concrete plan.
As you probably know (or at least may have read), when you go to move a topic, you can elect to send a notification to the topic starter via PM to let them know their topic has been moved (and is off by default if the person moving the topic is the topic starter)
So, this makes me wonder about merging topics and whether it should do the same. It gets tricky because you have two topic starters, and potentially anyone who has replied to the topic might possibly deserve to be notified.
Assuming we accept the idea of sending notifications like this, I'm thinking that we'd offer to send messages to the following:
* the topic starters
* the topic starters and anyone who replied to the topic
* the topic starters and anyone who is set to be notified on replies (note that their notifications will be synced anyway)
* no-one
Note that I don't see any practical way to send the same message (e.g. with a reason) to everyone, because the tone and so on would likely be different, e.g. you'd have "Your topic <xyz> has been merged with..." plus "The topic <xyz>, which you've replied to" and "The topic <xyz> that you're watching..." so the messages would be pre-set.
This seems like a reasonable and practical compromise to me.
As you probably know (or at least may have read), when you go to move a topic, you can elect to send a notification to the topic starter via PM to let them know their topic has been moved (and is off by default if the person moving the topic is the topic starter)
So, this makes me wonder about merging topics and whether it should do the same. It gets tricky because you have two topic starters, and potentially anyone who has replied to the topic might possibly deserve to be notified.
Assuming we accept the idea of sending notifications like this, I'm thinking that we'd offer to send messages to the following:
* the topic starters
* the topic starters and anyone who replied to the topic
* the topic starters and anyone who is set to be notified on replies (note that their notifications will be synced anyway)
* no-one
Note that I don't see any practical way to send the same message (e.g. with a reason) to everyone, because the tone and so on would likely be different, e.g. you'd have "Your topic <xyz> has been merged with..." plus "The topic <xyz>, which you've replied to" and "The topic <xyz> that you're watching..." so the messages would be pre-set.
This seems like a reasonable and practical compromise to me.
120
Archived fixes / Thoughts usability on tablets
« on November 26th, 2012, 04:20 AM »
Firstly, this isn't strictly a bug report, and secondly I am being specific to tablets as most of them are effectively desktop capable in terms of resolution and space but using touch.
My beef is that it isn't obvious at all on a tablet that you have to touch the thought to bring up the options like reply, there's no UI cue or anything.
On a side note, you have to tap the actual text of the thought, you can't tap the empty space in the thoughts' row.
My beef is that it isn't obvious at all on a tablet that you have to touch the thought to bring up the options like reply, there's no UI cue or anything.
On a side note, you have to tap the actual text of the thought, you can't tap the empty space in the thoughts' row.