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
1621
Features: Posts & Topics / Re: Moderation Filters
« on February 11th, 2013, 05:35 PM »
I know - and I still think I'd prefer that to be a core feature... along with having the @ feature trigger a popup on the client to find the right name (especially if there are fun symbols in the name)
1623
Features: Posts & Topics / Re: Moderation Filters
« on February 11th, 2013, 05:27 PM »
Well... I wouldn't personally do it through moderation filters. Aside from the fact that there's no option to notify someone, nor any practical place to store it, that is...
Notify based on content is not an administrative feature, it is a user side feature, and even though they may share common elements of UI and common places to occur in, it is not something I would do to that system.
I'd much rather do it as a proper standalone feature in its own right. A lot of people have been very enthusiastic about having @name to notify people in posts. I can see the validity of that, I can even see the validity of doing it with some kind of popup once typing @ to select the name and adding it as a hidden field when submitting a post to thoroughly do it that way.
Notify based on content is a feature in its own right too, with a different requirement set in the process. I wouldn't necessarily do it based on subscriptions, but I would bring it up as a feature in the user's profile area, as a list of words they'd list to be notified of, which would all be in a table listing user/word pairs and the entire table would be scooped/cached for use every page. It could get more exotic based on excluding boards or people, but I'd do it based on boards and just ignore people in the person's ignore list (but even that's getting nasty expensive)
Notify based on content is not an administrative feature, it is a user side feature, and even though they may share common elements of UI and common places to occur in, it is not something I would do to that system.
I'd much rather do it as a proper standalone feature in its own right. A lot of people have been very enthusiastic about having @name to notify people in posts. I can see the validity of that, I can even see the validity of doing it with some kind of popup once typing @ to select the name and adding it as a hidden field when submitting a post to thoroughly do it that way.
Notify based on content is a feature in its own right too, with a different requirement set in the process. I wouldn't necessarily do it based on subscriptions, but I would bring it up as a feature in the user's profile area, as a list of words they'd list to be notified of, which would all be in a table listing user/word pairs and the entire table would be scooped/cached for use every page. It could get more exotic based on excluding boards or people, but I'd do it based on boards and just ignore people in the person's ignore list (but even that's getting nasty expensive)
1624
Features: Posts & Topics / Re: Moderation Filters
« on February 11th, 2013, 05:02 PM »
Well, Dragooon's notifications plugin did stuff like that.
The notion of notifying someone when they are quoted, or when someone says their name would be useful enough for some.
As far as notifications based on set criteria, that could be very complicated, very quickly since it would expect to be done every post(!)
Seems to me that it might be a plugin contender instead, where the performance hurt is not a core problem.
The notion of notifying someone when they are quoted, or when someone says their name would be useful enough for some.
As far as notifications based on set criteria, that could be very complicated, very quickly since it would expect to be done every post(!)
Seems to me that it might be a plugin contender instead, where the performance hurt is not a core problem.
1625
Archived fixes / Re: sb refresh does not update scrollbar
« on February 11th, 2013, 05:01 PM »
Now, what about selectboxes whose content changes and .sb() is recalled? :angel: :P
1626
The Pub / Re: Infinite Scroll
« on February 11th, 2013, 04:55 PM »
Or even read the link I posted? ;)
1627
Archived fixes / Re: Codes appearing while viewing some topics.
« on February 11th, 2013, 05:57 AM »
Ah, thanks :)
OK, so I know what the problem is.
Display.template.php pushes the user menu (umme) to $context['footer_js'], while the other footer JS is pushed via add_js(). Trouble is for guests, and possibly some others, there's nothing being pushed via add_js already - so the script tag to contain it never gets output.
I don't see why Display.template.php can't push the umme and acme code to the footer through add_js, they're all going to be in the same place anyway... either that or footer_js needs to test whether it begins with a <script> and makes sure to add one otherwise.
I need to hit the sack in a minute or so, so I can't test it however... I can see one reason why it isn't added to add_js directly - and that's performance, stuff's being added in a loop. In which case it should go to a temporary variable and then pass that to add_js, would be better than directly injecting into $context['footer_js'] in the cases where there isn't already footer code.
OK, so I know what the problem is.
Display.template.php pushes the user menu (umme) to $context['footer_js'], while the other footer JS is pushed via add_js(). Trouble is for guests, and possibly some others, there's nothing being pushed via add_js already - so the script tag to contain it never gets output.
I don't see why Display.template.php can't push the umme and acme code to the footer through add_js, they're all going to be in the same place anyway... either that or footer_js needs to test whether it begins with a <script> and makes sure to add one otherwise.
I need to hit the sack in a minute or so, so I can't test it however... I can see one reason why it isn't added to add_js directly - and that's performance, stuff's being added in a loop. In which case it should go to a temporary variable and then pass that to add_js, would be better than directly injecting into $context['footer_js'] in the cases where there isn't already footer code.
1628
Archived fixes / Re: Codes appearing while viewing some topics.
« on February 11th, 2013, 05:48 AM »
That's... interesting. Weird, but interesting.
Can you view the source for that page and post it here please? I can't reproduce it myself - but I'm suspecting that's because I have permissions for other things.Quote Nope.
What's happening is, the code that generates the mini menu over the profile (which includes a given user's website) is being output in a manner in which it should not be. Please provide a copy of the view-source when you see it so I can try and nail down why this code is being output when it shouldn't be.
Can you view the source for that page and post it here please? I can't reproduce it myself - but I'm suspecting that's because I have permissions for other things.
Snooping around, this seems to have something to do with Arantor's profile.
What's happening is, the code that generates the mini menu over the profile (which includes a given user's website) is being output in a manner in which it should not be. Please provide a copy of the view-source when you see it so I can try and nail down why this code is being output when it shouldn't be.
1629
The Pub / Re: Infinite Scroll
« on February 11th, 2013, 03:14 AM »
No more so than clicking on the next page anyway.
That's the joy of it... if the browser can't do it (i.e. lower IE, search engines), no harm, no foul, they don't realise any different.
Literally just imagine it as if you're at the start of a very long thread, and when you get to the bottom you're pressing the next page button - the difference is your browser is doing it for you, and only when you get near the end of the thread anyway.
That's the joy of it... if the browser can't do it (i.e. lower IE, search engines), no harm, no foul, they don't realise any different.
Literally just imagine it as if you're at the start of a very long thread, and when you get to the bottom you're pressing the next page button - the difference is your browser is doing it for you, and only when you get near the end of the thread anyway.
1630
Features / Post count permissions
« on February 10th, 2013, 10:46 PM »
I haven't raised this issue lately mostly because I wasn't very happy with what I'd proposed for it. But here we go.
In an ideal world, I'd ditch post count groups entirely. There are advantages to them, though, e.g. for badges and the like and if you want to provide access to boards based on post count.
But they raise issues with respect to things like permissions. Not so much from a technical standpoint, there it's all very convenient, of course - but from a usability standpoint.
Previously you'll remember my somewhat inflamed commentary on setting up post moderation using post count groups, and that exemplifies what's wrong with post count permissions. What strikes me, then, is that we actually need to set up a situation whereby we're not using post count permissions through groups.
So here's my proposal. Instead, we present the user with a UI, whereupon we can set rules. For example, grant 'lock own topics' to users once they have > 100 posts. You'd select the permission from a dropdown, set the minimum number of posts, optionally limit it within a board or similar, job done.
Where this gets really clever is that if I built it correctly with proper support from other areas, we can cleanly provide additional permissions for additional systems without having to fart about with magic group changes.
I know in the past users have wanted to do groups (and by extension, permissions) based on time since registration, karma, and even topic count. I see no reason why we couldn't set these things up with this system if handled properly. (It would mean, for performance, having to track these things, but that's not exactly a hardship to set up)
What it would mean, though, is that we'd have a single UI that could do all this cleanly - and it wouldn't even trigger a performance hit under most circumstances because most of the time, none of this is even in use on most sites... so it's only a performance issue if you use it.
Does this sound sane? If it does, I'll go away and try building it.
In an ideal world, I'd ditch post count groups entirely. There are advantages to them, though, e.g. for badges and the like and if you want to provide access to boards based on post count.
But they raise issues with respect to things like permissions. Not so much from a technical standpoint, there it's all very convenient, of course - but from a usability standpoint.
Previously you'll remember my somewhat inflamed commentary on setting up post moderation using post count groups, and that exemplifies what's wrong with post count permissions. What strikes me, then, is that we actually need to set up a situation whereby we're not using post count permissions through groups.
So here's my proposal. Instead, we present the user with a UI, whereupon we can set rules. For example, grant 'lock own topics' to users once they have > 100 posts. You'd select the permission from a dropdown, set the minimum number of posts, optionally limit it within a board or similar, job done.
Where this gets really clever is that if I built it correctly with proper support from other areas, we can cleanly provide additional permissions for additional systems without having to fart about with magic group changes.
I know in the past users have wanted to do groups (and by extension, permissions) based on time since registration, karma, and even topic count. I see no reason why we couldn't set these things up with this system if handled properly. (It would mean, for performance, having to track these things, but that's not exactly a hardship to set up)
What it would mean, though, is that we'd have a single UI that could do all this cleanly - and it wouldn't even trigger a performance hit under most circumstances because most of the time, none of this is even in use on most sites... so it's only a performance issue if you use it.
Does this sound sane? If it does, I'll go away and try building it.
1631
The Pub / Re: Infinite Scroll
« on February 10th, 2013, 09:21 PM »
Or in fact, here's an even better solution - http://tumbledry.org/2011/05/12/screw_hashbangs_building
It still does the whole endless loading but still preserves everything else.
I could actually consider implementing this.
It still does the whole endless loading but still preserves everything else.
I could actually consider implementing this.
1632
Off-topic / Thoughts from Jeff Atwood
« on February 10th, 2013, 08:58 PM »
Very occasionally, I'll stop by Jeff's blog. Very occasionally, mind, because it's not something that usually occurs to me to do. Jeff, for those who don't know, is one of the founders of StackOverflow, and perhaps more relevantly to us, Discourse. I am still trying to get my head around the logic of some of the things Discourse is doing, and I'm not convinced that it's quite the 'next generation' of forums that he's pitching it as. I strongly dislike some of the directions taken.[1]
But he has some very interesting thoughts I'd like to add.
http://www.codinghorror.com/blog/2012/02/listen-to-your-community-but-dont-let-them-tell-you-what-to-do.html
I believe this is something we do, and I believe it's one of the problems SMF has had, and as far as I know still generally does have.
We try to invite all kinds of thoughts and suggestions. I don't promise to implement anything. But I promise we'll look at what's suggested, no matter who suggests it, and if it makes sense to us we'll build it.
And we don't go off and build huge systems for minor features. We won't go building huge major features unless we think the need for it is justified. That doesn't mean we won't build things, it means that if you want to see it implemented, give us a reason to do it. "Because it's cool" isn't really enough.
And yes, we will be honest about things we won't do. There's a lot of things I've made very clear I will not build myself, and that I won't allow into the core, and I'm pretty sure Nao has said the same.
The other nugget I want to share, is http://www.codinghorror.com/blog/2012/12/web-discussions-flat-by-design.html
We've had discussions about threaded topics, and putting aside the technical matters, there is a major usability aspect to it, and I believe it's partly why I avoid Reddit because I have no freakin' idea what the hell's going on at any given time >_<
But it's certainly food for thought. I'm going to just leave it here for now and let people have at it before I weigh in with my $0.02 on where I see it going.
But he has some very interesting thoughts I'd like to add.
http://www.codinghorror.com/blog/2012/02/listen-to-your-community-but-dont-let-them-tell-you-what-to-do.html
I believe this is something we do, and I believe it's one of the problems SMF has had, and as far as I know still generally does have.
We try to invite all kinds of thoughts and suggestions. I don't promise to implement anything. But I promise we'll look at what's suggested, no matter who suggests it, and if it makes sense to us we'll build it.
And we don't go off and build huge systems for minor features. We won't go building huge major features unless we think the need for it is justified. That doesn't mean we won't build things, it means that if you want to see it implemented, give us a reason to do it. "Because it's cool" isn't really enough.
And yes, we will be honest about things we won't do. There's a lot of things I've made very clear I will not build myself, and that I won't allow into the core, and I'm pretty sure Nao has said the same.
The other nugget I want to share, is http://www.codinghorror.com/blog/2012/12/web-discussions-flat-by-design.html
We've had discussions about threaded topics, and putting aside the technical matters, there is a major usability aspect to it, and I believe it's partly why I avoid Reddit because I have no freakin' idea what the hell's going on at any given time >_<
But it's certainly food for thought. I'm going to just leave it here for now and let people have at it before I weigh in with my $0.02 on where I see it going.
| 1. | For example the reputation aspect as being effectively a sort of power control, because it actually encourages elitism and cliquism than not. It's why I long since gave up on contributing to SO. |
1633
Archived fixes / Re: sb refresh does not update scrollbar
« on February 10th, 2013, 07:11 PM »
Also is it my imagination or does the scrollwheel no longer work with scrolling through the selectbox?
1634
Features / Re: New revs
« on February 10th, 2013, 07:10 PM »
(2 files, 1KB, it needed to be done, couldn't find anything more useful in the time right now.)
Revision: 1913
Author: arantor
Date: 10 February 2013 18:09:50
Message:
! Fix for PMs loading the wrong template for skellingtons. (PersonalMessage.php)
! Use the correct URL when a manual override has been indicated. (Admin.template.php)
----
Modified : /trunk/Sources/PersonalMessage.php
Modified : /trunk/Themes/default/Admin.template.php
Revision: 1913
Author: arantor
Date: 10 February 2013 18:09:50
Message:
! Fix for PMs loading the wrong template for skellingtons. (PersonalMessage.php)
! Use the correct URL when a manual override has been indicated. (Admin.template.php)
----
Modified : /trunk/Sources/PersonalMessage.php
Modified : /trunk/Themes/default/Admin.template.php
1635
Archived fixes / Re: Jumpy layout.
« on February 10th, 2013, 07:02 PM »
Can this be moved to fixed? It doesn't seem to be broken now...