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
646
The Pub / Re: Looking for volunteers to test the Wedge private alpha!
« on May 18th, 2013, 03:12 AM »
In case it's not clear to anyone why I sighed, let me explain. Again. For at least the fifth time.
Firstly, it is wise to actually answer the questions asked.
Secondly. People who come here and sign up with just a few posts aren't really what we're looking for. We can test Wedge ourselves quite happily, and someone who's only been here long enough to make a few posts probably isn't interested in testing it very heavily.
If you're interested in testing, you'll be hanging around, seeing what's going on, what we've done, what we're doing going forward and you'll be all enthusiastic and motivated to be a part of that. If you come here, make a few posts then request early access, I'm going to conclude you're only interested in getting some cool stuff and not actually help with anything useful.
I'm cynical, sure. I'm negative, sure. I've been bitten too many times with crap like this before now. Where people get all enthusiastic and tell me that they're all fired up to test something I'm making and when they get the keys to the kingdom, it's almost like they don't care any more because they got what *they* came for and don't give a damn about the poor folk who actually made the damn thing who wanted help in the first place.
The reality is that we don't need alpha testers. We need people who are interested in shaping Wedge. Testers imply they're interested only in testing something and finding bugs, but that's not really what we need right now. Further down the line, sure, when the key features are all in place and we're just shaking out the bugs but that's not where we are yet.
I'm actually tempted to lock this thread, to be honest.
Firstly, it is wise to actually answer the questions asked.
Secondly. People who come here and sign up with just a few posts aren't really what we're looking for. We can test Wedge ourselves quite happily, and someone who's only been here long enough to make a few posts probably isn't interested in testing it very heavily.
If you're interested in testing, you'll be hanging around, seeing what's going on, what we've done, what we're doing going forward and you'll be all enthusiastic and motivated to be a part of that. If you come here, make a few posts then request early access, I'm going to conclude you're only interested in getting some cool stuff and not actually help with anything useful.
I'm cynical, sure. I'm negative, sure. I've been bitten too many times with crap like this before now. Where people get all enthusiastic and tell me that they're all fired up to test something I'm making and when they get the keys to the kingdom, it's almost like they don't care any more because they got what *they* came for and don't give a damn about the poor folk who actually made the damn thing who wanted help in the first place.
The reality is that we don't need alpha testers. We need people who are interested in shaping Wedge. Testers imply they're interested only in testing something and finding bugs, but that's not really what we need right now. Further down the line, sure, when the key features are all in place and we're just shaking out the bugs but that's not where we are yet.
I'm actually tempted to lock this thread, to be honest.
647
Off-topic / Re: Oh, I meant to share this a while ago
« on May 18th, 2013, 01:12 AM »
Because, apparently, vB 5 is a 'built from scratch', meaning that instead of evolving vB 4, they trashed it and started over, like they did with vB 4 after vB 3.
There are some legitimate reasons you might do that, in terms of code cleanliness perhaps, but otherwise it's generally an admission that what you had before is so bad it can't be fixed.
In this case, they started from fresh, didn't have the memberlist code and decided they weren't going to write it. Notice the lack of 'it will be added in future versions', almost conspicuous in its absence, unlike the warnings system which is merely a 'shit, we ran out of time' moment because they rushed it in an attempt to get it out the door prior to the lawsuit wrapping up. Unfortunately it may have cost them more dearly than the meagre (by all accounts) sales they did manage to get out of that exercise.
Mind you, phpBB 4 is in a similar situation to that, they're not going to upgrade phpBB 3.x, but phpBB 4 is a 'from scratch', not that phpBB doesn't need a serious overhaul or anything ;) Though it's a bit different when you're talking about a group of volunteers making something vs a company pushing out a paid product.
:edit: vB 4 was not 'from scratch' entirely because vB 3 was a trainwreck that couldn't be fixed, it was that the code was perceived to be creaking from being too powerful and too tightly woven and they wanted to uncouple things somewhat. That, in itself, is fair enough reason to do so, only it needed to have been done properly, something which Internet Brands wasn't willing to pay for. XenForo, effectively, is what vB 4 would have been had Kier and Mike been allowed to build it their way rather than outsourcing coders and letting head office 'quality check' (which is what happened with vB 4 and that was a buggy POS when it landed, but nothing on the scale of vB 5)
There are some legitimate reasons you might do that, in terms of code cleanliness perhaps, but otherwise it's generally an admission that what you had before is so bad it can't be fixed.
In this case, they started from fresh, didn't have the memberlist code and decided they weren't going to write it. Notice the lack of 'it will be added in future versions', almost conspicuous in its absence, unlike the warnings system which is merely a 'shit, we ran out of time' moment because they rushed it in an attempt to get it out the door prior to the lawsuit wrapping up. Unfortunately it may have cost them more dearly than the meagre (by all accounts) sales they did manage to get out of that exercise.
Mind you, phpBB 4 is in a similar situation to that, they're not going to upgrade phpBB 3.x, but phpBB 4 is a 'from scratch', not that phpBB doesn't need a serious overhaul or anything ;) Though it's a bit different when you're talking about a group of volunteers making something vs a company pushing out a paid product.
:edit: vB 4 was not 'from scratch' entirely because vB 3 was a trainwreck that couldn't be fixed, it was that the code was perceived to be creaking from being too powerful and too tightly woven and they wanted to uncouple things somewhat. That, in itself, is fair enough reason to do so, only it needed to have been done properly, something which Internet Brands wasn't willing to pay for. XenForo, effectively, is what vB 4 would have been had Kier and Mike been allowed to build it their way rather than outsourcing coders and letting head office 'quality check' (which is what happened with vB 4 and that was a buggy POS when it landed, but nothing on the scale of vB 5)
648
Off-topic / Re: Oh, I meant to share this a while ago
« on May 17th, 2013, 08:44 PM »
Oh, I'm not saying it doesn't have a use. Simply that we (spoogs and I, can't vouch for anyone else) don't have a lot of use for it.
649
Off-topic / Re: Oh, I meant to share this a while ago
« on May 17th, 2013, 08:37 PM »
Sure it does in the database.
There is no technical reason why one could not have been added easily. Just that they didn't.
I'd note that XenForo has altered how they present the memberlist, so that it can be disabled entirely, they discuss it in http://xenforo.com/community/threads/more-assorted-things.50098/
There is no technical reason why one could not have been added easily. Just that they didn't.
I'd note that XenForo has altered how they present the memberlist, so that it can be disabled entirely, they discuss it in http://xenforo.com/community/threads/more-assorted-things.50098/
650
Off-topic / Re: Oh, I meant to share this a while ago
« on May 17th, 2013, 08:16 PM »
Quite easily. I don't remember the last time I looked at the member's list here...
(not defending vBulletin, just saying the member's list isn't necessarily a huge deal)
(not defending vBulletin, just saying the member's list isn't necessarily a huge deal)
651
Features / Re: New revs
« on May 17th, 2013, 04:54 AM »
(5 modified, 2KB)
Revision: 2120
Author: arantor
Date: 17 May 2013 03:54:02
Message:
! Indentinazi (ManageMemberOptions.php)
! Don't do the permissions check on custom field visibility on memberlist if you're an admin, because there's no need. (Memberlist.php)
! DIE OLD SIDEBAR CODE. (Subs-Menu.php, ManageMemberOptions.php, Profile language file)
----
Modified : /trunk/Sources/ManageMemberOptions.php
Modified : /trunk/Sources/Memberlist.php
Modified : /trunk/Sources/Subs-Menu.php
Modified : /trunk/Themes/default/languages/Profile.english.php
Modified : /trunk/Themes/default/languages/Profile.french.php
Revision: 2120
Author: arantor
Date: 17 May 2013 03:54:02
Message:
! Indentinazi (ManageMemberOptions.php)
! Don't do the permissions check on custom field visibility on memberlist if you're an admin, because there's no need. (Memberlist.php)
! DIE OLD SIDEBAR CODE. (Subs-Menu.php, ManageMemberOptions.php, Profile language file)
----
Modified : /trunk/Sources/ManageMemberOptions.php
Modified : /trunk/Sources/Memberlist.php
Modified : /trunk/Sources/Subs-Menu.php
Modified : /trunk/Themes/default/languages/Profile.english.php
Modified : /trunk/Themes/default/languages/Profile.french.php
652
Features / Re: Permissions UI, latest experiment
« on May 17th, 2013, 12:38 AM »
Yes, really. Most of the people I've spoken to are confused about the very existence of deny permissions because it's off by default. Thus permissions are a simple yes/no checkbox, not even the three radio buttons.
Thing is, even back to SMF 1.1.x, deny permissions are off by default so there is a whole heritage of 'it's just yes/no tickboxes' to deal with.
The reality, though, is that I haven't seen a single forum system doing it the way I proposed, they all do either yes/no or A/X/D triad (except XenForo in one specific circumstance but that's a battle for another day)[1]Quote Well, it all came about because of the very fact that Disallow and Deny seem awfully close together. Hell, even just renaming it to Yes/No/Never would be an improvement.
Yup, Windows did it the way proposed, and it was in fact a guy who does a decent amount of Windows sys-admin that suggested it to me (you know who you are), and it makes sense.
I tell you what though, my instincts on this are simply that *I* wasn't that convinced by it, which is why I posted it here under the label of 'experimental' because I'm not entirely convinced it's the way forward. It's *a* way forward, and the split is roughly 60/40 against judging by all the comments. It's probably better than what we have to an objective observer.
But I keep coming back to the objection Aaron raised - which comes down to the concept of form-follows-function. And he's right, even with UI hinting, even if I disable one checkbox when the other is ticked, it doesn't change the fact that it isn't what checkboxes are really for. It's not form following function.Quote Until you meet my mother who is blue-green colour blind ;)
Thing is, even back to SMF 1.1.x, deny permissions are off by default so there is a whole heritage of 'it's just yes/no tickboxes' to deal with.
The reality, though, is that I haven't seen a single forum system doing it the way I proposed, they all do either yes/no or A/X/D triad (except XenForo in one specific circumstance but that's a battle for another day)[1]
It certainly makes sense from a developer's standpoint, but the average joe sixpack will see the "X" as superfluous.
Yup, Windows did it the way proposed, and it was in fact a guy who does a decent amount of Windows sys-admin that suggested it to me (you know who you are), and it makes sense.
I tell you what though, my instincts on this are simply that *I* wasn't that convinced by it, which is why I posted it here under the label of 'experimental' because I'm not entirely convinced it's the way forward. It's *a* way forward, and the split is roughly 60/40 against judging by all the comments. It's probably better than what we have to an objective observer.
But I keep coming back to the objection Aaron raised - which comes down to the concept of form-follows-function. And he's right, even with UI hinting, even if I disable one checkbox when the other is ticked, it doesn't change the fact that it isn't what checkboxes are really for. It's not form following function.
make it bluish green for the color blind
| 1. | Specifically, they set up a default permission profile for boards that isn't tied to any one board, then each board is allow/disallow/deny/inherit from the default profile. But it's still radio buttons. |
653
Off-topic / Re: Oh, I meant to share this a while ago
« on May 16th, 2013, 10:32 PM »
I dunno, vB 3 justified its price tag to me. But vB 5... nah.
654
Off-topic / Re: Oh, I meant to share this a while ago
« on May 16th, 2013, 08:50 PM »
I wouldn't be on that either >_<
655
Off-topic / Oh, I meant to share this a while ago
« on May 16th, 2013, 08:42 PM »
You guys all know vBulletin 5 is a train wreck, right?
If you didn't, here's the proof: http://www.vbulletin.com/faq/
For those who aren't interested in clicking on links etc, I'll share the truly WTF ones. I swear I'm not making any of this up, and you can look at the FAQ yourself.Quote Quote Quote Quote Quote Quote Quote And this is a supported product, or something.
If you didn't, here's the proof: http://www.vbulletin.com/faq/
For those who aren't interested in clicking on links etc, I'll share the truly WTF ones. I swear I'm not making any of this up, and you can look at the FAQ yourself.
Q: I was in the AdminCp and received an error message.
A: A number of features in the Admin CP no longer work. These can return error messages. Open a Support Topic or Ticket for further assistance.
Q: Where is the Member's List?
A: There is no member's list in vBulletin 5.
Q: Where is the FAQ system?
A: The FAQ System is not supported in vBulletin 5.0. It will return in a future version.
Q: Where is the infraction system?
A: The infraction system is not supported in vBulletin 5.0. It will return in a future version.
Q: What happened to the CMS and all my articles?
A: The CMS/Article System is not supported in vBulletin 5.0. It will return in a future version. Your articles are being kept safe in a hidden channel and will return when the CMS is released.
Q: There is no place for my users to purchase Paid Subscriptions
A: Paid Subscriptions are not supported in vBulletin 5. They will return in a future version.
Q: I tried to import a custom language and received a database error.
A: We do not support localization at this time. This will be available in a future release.
656
Features / Re: New revs
« on May 16th, 2013, 08:19 PM »
(19 files, 13KB)
Revision: 2117
Author: arantor
Date: 16 May 2013 19:18:38
Message:
! Forgot to commit this previously, more global variables not used in the templates. (ManagePaid.template.php)
! Oops, wrong variable. (ManageInfractions.php)
! Guests should never be shown infraction status of a user, no matter what. (Profile-View.php)
! Who's Online could return exciting and incorrect values for viewing in the profile. E.g. user 1 is viewing their own profile, user 2 is viewing user 1's profile, user 2 would see 'Viewing User 2's profile' because the user id is not otherwise available. (Profile-View.php, Who.php)
! No more of this 'enabling deny permissions'. They're always enabled now. $helptxt['permissions_deny'] might still be useful though, so leave it around for now. (wedge_api.php, Load.php, ManagePermissions.php, Reports.php, Subs-Post.php, ManagePermissions.template.php, ManagePermissions language file)
! Custom field data wasn't loaded for loadMemberData(...., 'userbox') but it's kind of important that it is. (Load.php)
! Custom fields now have controls for group visibility and editability. Note that the system is designed in a funky way in case people have funky needs like wanting to create a field that a user can edit but that won't be visible to them on their summary (owner + respective groups have "can edit", those who should be able to see it have "can see", so there's no magic greying out of textboxes) (install.sql, Load.php, ManageMemberOptions.php, Memberlist.php, Profile.php, Admin.template.php, ManageSettings language file)
----
Modified : /trunk/Sources/Load.php
Modified : /trunk/Sources/ManageInfractions.php
Modified : /trunk/Sources/ManageMemberOptions.php
Modified : /trunk/Sources/ManagePermissions.php
Modified : /trunk/Sources/Memberlist.php
Modified : /trunk/Sources/Profile-View.php
Modified : /trunk/Sources/Profile.php
Modified : /trunk/Sources/Reports.php
Modified : /trunk/Sources/Subs-Post.php
Modified : /trunk/Sources/Who.php
Modified : /trunk/Themes/default/Admin.template.php
Modified : /trunk/Themes/default/ManagePaid.template.php
Modified : /trunk/Themes/default/ManagePermissions.template.php
Modified : /trunk/Themes/default/languages/ManagePermissions.english.php
Modified : /trunk/Themes/default/languages/ManagePermissions.french.php
Modified : /trunk/Themes/default/languages/ManageSettings.english.php
Modified : /trunk/Themes/default/languages/ManageSettings.french.php
Modified : /trunk/other/tools/wedge_api.php
Modified : /trunk/root/install.sql
Revision: 2117
Author: arantor
Date: 16 May 2013 19:18:38
Message:
! Forgot to commit this previously, more global variables not used in the templates. (ManagePaid.template.php)
! Oops, wrong variable. (ManageInfractions.php)
! Guests should never be shown infraction status of a user, no matter what. (Profile-View.php)
! Who's Online could return exciting and incorrect values for viewing in the profile. E.g. user 1 is viewing their own profile, user 2 is viewing user 1's profile, user 2 would see 'Viewing User 2's profile' because the user id is not otherwise available. (Profile-View.php, Who.php)
! No more of this 'enabling deny permissions'. They're always enabled now. $helptxt['permissions_deny'] might still be useful though, so leave it around for now. (wedge_api.php, Load.php, ManagePermissions.php, Reports.php, Subs-Post.php, ManagePermissions.template.php, ManagePermissions language file)
! Custom field data wasn't loaded for loadMemberData(...., 'userbox') but it's kind of important that it is. (Load.php)
! Custom fields now have controls for group visibility and editability. Note that the system is designed in a funky way in case people have funky needs like wanting to create a field that a user can edit but that won't be visible to them on their summary (owner + respective groups have "can edit", those who should be able to see it have "can see", so there's no magic greying out of textboxes) (install.sql, Load.php, ManageMemberOptions.php, Memberlist.php, Profile.php, Admin.template.php, ManageSettings language file)
----
Modified : /trunk/Sources/Load.php
Modified : /trunk/Sources/ManageInfractions.php
Modified : /trunk/Sources/ManageMemberOptions.php
Modified : /trunk/Sources/ManagePermissions.php
Modified : /trunk/Sources/Memberlist.php
Modified : /trunk/Sources/Profile-View.php
Modified : /trunk/Sources/Profile.php
Modified : /trunk/Sources/Reports.php
Modified : /trunk/Sources/Subs-Post.php
Modified : /trunk/Sources/Who.php
Modified : /trunk/Themes/default/Admin.template.php
Modified : /trunk/Themes/default/ManagePaid.template.php
Modified : /trunk/Themes/default/ManagePermissions.template.php
Modified : /trunk/Themes/default/languages/ManagePermissions.english.php
Modified : /trunk/Themes/default/languages/ManagePermissions.french.php
Modified : /trunk/Themes/default/languages/ManageSettings.english.php
Modified : /trunk/Themes/default/languages/ManageSettings.french.php
Modified : /trunk/other/tools/wedge_api.php
Modified : /trunk/root/install.sql
657
Features / Re: Permissions UI, latest experiment
« on May 16th, 2013, 05:28 PM »
Hmm, yes, I can see what you mean.
So, deny permissions are needed, then.
So, deny permissions are needed, then.
* Arantor goes back to thinking.
658
Features / Re: Permissions UI, latest experiment
« on May 16th, 2013, 05:18 PM »
Wouldn't you instead grant that access by giving it just through the higher groups?
Or even just set a minimum and/or maximum post count for a given permission?
Or even just set a minimum and/or maximum post count for a given permission?
659
Features / Re: Permissions UI, latest experiment
« on May 16th, 2013, 04:52 PM »
Well, the A/X/D part could be, but one of the big things I did - and damn it was subtle - was flattening the way own/any permissions worked.
In SMF and Wedge, you can quite happily grant/revoke own/any permissions separately, though the cases should be fairly rare that you'd ever need to. In SD, though, the permission choice doesn't exist like that.
A normal permission in SD is 'allow/disallow', an own/any permission in SD is 'allow own/allow any/disallow either' without any option for denying, on the basis that if you have 'any', you implicitly have 'own' as well.
Now, history has shown that my call on that made sense for SD: because own/any in SD terms made sense, the permission model made it feasible and approachable to build inclusive setups without getting into a need for deny permissions. If everything is off by default for everyone you have to give them things.
SMF's more general permissions are a lot more inclusive by default, so there is a sort of need to make things more exclusive through deny permissions, plus of course cases like the aforementioned troublemaker group.
That said... I'd actually probably be more inclined to extend the warning system and do it *that* way rather than juggling permissions. After all... why do people normally create deny groups in the first place? What purpose do deny groups actually solve?
Well, they're for excluding people from doing things they would normally otherwise be able to do. So the question then becomes: why are they not allowed to do what they're otherwise able to do?
The logical answer to me about that is warnings/punishments/<insert terminology of choice>. So if you tie it into the warning system instead of the general permissions system, you don't actually *need* deny permissions, right?
In SMF and Wedge, you can quite happily grant/revoke own/any permissions separately, though the cases should be fairly rare that you'd ever need to. In SD, though, the permission choice doesn't exist like that.
A normal permission in SD is 'allow/disallow', an own/any permission in SD is 'allow own/allow any/disallow either' without any option for denying, on the basis that if you have 'any', you implicitly have 'own' as well.
Now, history has shown that my call on that made sense for SD: because own/any in SD terms made sense, the permission model made it feasible and approachable to build inclusive setups without getting into a need for deny permissions. If everything is off by default for everyone you have to give them things.
SMF's more general permissions are a lot more inclusive by default, so there is a sort of need to make things more exclusive through deny permissions, plus of course cases like the aforementioned troublemaker group.
That said... I'd actually probably be more inclined to extend the warning system and do it *that* way rather than juggling permissions. After all... why do people normally create deny groups in the first place? What purpose do deny groups actually solve?
Well, they're for excluding people from doing things they would normally otherwise be able to do. So the question then becomes: why are they not allowed to do what they're otherwise able to do?
The logical answer to me about that is warnings/punishments/<insert terminology of choice>. So if you tie it into the warning system instead of the general permissions system, you don't actually *need* deny permissions, right?
660
The Pub / Re: {coders} Dont forget the rtl languages support
« on May 16th, 2013, 04:19 PM »waiting for aproval