Show Likes
This section allows you to view all posts where this member received or gave a like to.
1
rev 1953 -- fixing a mail bug. I think. I never touched that code before... Pure chance.
(5 files, 15kb) (argh, translations..?!)
! SMF bug (also in Elk and everything...): fixed a variable inversion bug that caused, I would venture to say, failed mails to be stored for further retries but said retries never undertaken. I'd say that's a big one... Which needs fixing everywhere else. I'll post the details somewhere if someone asks. (ScheduledTasks.php)
* Finished string to literal transitions. I think they're all done now, but I've probably missed hundreds of strings that aren't named the same as their literal value. (ManageLanguages.php, ScheduledTasks.php, Subs-BBC.php)
* Translation. The nightmare continues in... Translation II: Spell-checker. (ManageMail.french.php)
* Typoos. (ManageMail.english.php)
(5 files, 15kb) (argh, translations..?!)
! SMF bug (also in Elk and everything...): fixed a variable inversion bug that caused, I would venture to say, failed mails to be stored for further retries but said retries never undertaken. I'd say that's a big one... Which needs fixing everywhere else. I'll post the details somewhere if someone asks. (ScheduledTasks.php)
* Finished string to literal transitions. I think they're all done now, but I've probably missed hundreds of strings that aren't named the same as their literal value. (ManageLanguages.php, ScheduledTasks.php, Subs-BBC.php)
* Translation. The nightmare continues in... Translation II: Spell-checker. (ManageMail.french.php)
* Typoos. (ManageMail.english.php)
2
So, I've been noodling around with this, and nothing I'm happy enough with to provide screenshots of yet, but let me explain where I'm going and see what you think.
There are a great many issues with the permissions UI and structure.
First up, regular group permissions. I'm still working with what I proposed in http://wedge.org/pub/feats/7662/permissions-ui/ - namely a single big table with all the groups along the top, the permissions down the side, and all the permissions shown there.
There are several bits I'm not entirely sure about, like exactly how you set the permissions. I don't really want to present a minefield of buttons to the user, nor do I want to present a minefield of <state> <button to change> Maybe I'll have it click to change the permissions for a given group <-> permission, but that could get clunky if there's a lot of changes you want to make. Maybe it should be a dropdown for each one to select the state.
This makes me wonder other things. I'm not averse to exposing 'deny' permissions generally. However, what I am concerned about is the mentality. A/D/X is confusing. Elsewhere (board access) we use Yes/No/Never to represent that states, and we need to get a bit more consistent - I'd be happy dragging Yes/No/Never over to permissions too.
Another system I'm liking has two checkboxes, rather than radio buttons - one for allow, one for deny.[1] I'm not sure what I'm going to do yet, would appreciate thoughts.
Note that I'm looking to remove the 'default profile' being shown underneath the general permissions, but the whole nature of that I'll get to in a minute. I would also be tempted to remove some of the other stuff in the admin pages, like 'setting permissions for one group like another' - basically if you go to the permissions page, you get the list of groups, then some stuff below those groups for things you can apply to the groups; setting 1+ groups like a template, setting a single permission on each of the ticked groups. Seems to me that a single big ol' list would negate the need for that. Permission copying would be reasonably simple too.
There was a concern previously about fitting it all in - while this is not a huge deal for the most part (inherited groups wouldn't be shown either, to save space), I'm also looking at using http://fixedheadertable.com/ - you'd keep the group names and the permissions in view at all times and scroll across to fit.
I don't think there was any real objection, but I think now I'm looking at it again, I'm having second thoughts on the idea - but I also know I don't have anything better to solve the problems I want to solve. I don't want to get into huge scale re-engineering if the idea doesn't feel sound, and right now this doesn't.
Board permissions. Ah, yes, I couldn't forget this, could I? I've been looking at what SMF 1 did versus SMF 2, unique board permissions vs profiles and I think I might have a better solution but this is sort of off the cuff. If I said it came to me while I was sat on the toilet[2] you'll hopefully understand.
So, let's recap, first of all.
SMF 1, for those who never used it, had the notion of global versus local board permissions. You'd set the permissions for each group generally, and if you had a board whose permissions were different, you could indicate as such and get unique permissions for that board.
Conceptually that's fine, until you have two or more boards that need the same-as-each-other but unique-compared-to-everything-else permissions. Incidentally, sm.org has this very setup, there are boards that have different permissions to any other (namely showcase, but some of the internal boards have that going on too)
Meanwhile, SMF 2 has the idea of profiles. You have some template profiles (but one you can actually change despite the system telling you that you can't, which I'm still not sure isn't a bug in disguise), and you create new profiles to apply them to the relevant boards. Great for managing boards with a few tiers of boards where you only have a few sets of 'permissions'.
Then we have SimpleDesk. This did something a little bit different: permissions were expressly not tied to groups. You create roles, which are essentially groups of permissions, then you say 'these groups, have these permissions, in these boards'. For example you'd create a staff role, which had a bunch of permissions, and all the time they were in those boards, they had those permissions. It was a bit ropey in places because I abused the concept in two interesting ways.[3]
Two options present themselves, ultimately.
Firstly, I can take the SD route. The UI can be nicer this time because I don't need to pull stunts around 'non board permissions', I can safely have the UI abstract that stuff away. But I'm not sure how well the 'groups != roles' concept will get across and I'd hate to lumber us with 'how do I set this permission up' crap.
Secondly, and perhaps more confusingly in a way. I can sort of regress back to SMF 1 permissions. I'd envisage it being split between permissions and the board configuration area, or at least... mirrored that way.
See, what I'd envisage doing is giving a list of the board type permissions, and the groups again - like above. Only this time, with an extra dimension to it. For each permission, you'd select the list of groups who have it/don't have it, but there's an extra option: apply to all boards. If you say 'apply to all boards', all the boards the users can see would be able to have/not have that permission. For example, posting replies would typically be yes to any group who can see the board in question. So you'd just have that as 'all boards', and just set it to the groups who reply.
If you decided you didn't want it as all boards, I'm thinking that the list of boards could fold out underneath to indicate that permission for that board/group combination. I think it could be thoroughly ugly, but I think it would be more intuitive than the current permissions setup.
Then you could go into a given board and see how it is in that given board, and configure it that way too. It would be back to local vs global permissions but easier to configure for simple changes. Of course if you have a lot of boards, changing things is going to suck very, very quickly, which is where profiles win.
More importantly, newbie factor. Setting up roles is not the most obvious thing, especially if you want people to be able to dive in and just set up a forum quickly, though I guess if sane roles were defined out of the box, that might not be a bad thing and it would probably clue most of them in on how to do it. But seeing the confluence of boards/groups/permissions should be marginally easier to follow - and still more compact than the current reporting methodology (which could also go bye-bye in the process)
Note that all the things I have in mind down the road about other content types can slot into what we have here with little change on a purely technical level, so this is almost entirely a UI problem. UI says it must be so, everything else will be kicked into line.
I don't know. I honestly don't know what's best out of all this. I just know that I don't like how SMF does it and by extension how we do it. I've been wary for some time of making big changes because I've been frightened of creating a worse mess than we already have. But I'm also not sure it can be *that* much worse. So, over to you. I'd love some thoughts on this, even if it's only to tell me whether you like or dislike it. Remember: you're the people who are ultimately going to be *using* it.
Of course, I'm open to other ideas. If there's any other system you've seen that you like the look of, tell me and I'll see what I can do to find out about it, including figuring out what's good about it. I'm not averse to drawing on any system out there - if the system works, I want to see it :)
There are a great many issues with the permissions UI and structure.
First up, regular group permissions. I'm still working with what I proposed in http://wedge.org/pub/feats/7662/permissions-ui/ - namely a single big table with all the groups along the top, the permissions down the side, and all the permissions shown there.
There are several bits I'm not entirely sure about, like exactly how you set the permissions. I don't really want to present a minefield of buttons to the user, nor do I want to present a minefield of <state> <button to change> Maybe I'll have it click to change the permissions for a given group <-> permission, but that could get clunky if there's a lot of changes you want to make. Maybe it should be a dropdown for each one to select the state.
This makes me wonder other things. I'm not averse to exposing 'deny' permissions generally. However, what I am concerned about is the mentality. A/D/X is confusing. Elsewhere (board access) we use Yes/No/Never to represent that states, and we need to get a bit more consistent - I'd be happy dragging Yes/No/Never over to permissions too.
Another system I'm liking has two checkboxes, rather than radio buttons - one for allow, one for deny.[1] I'm not sure what I'm going to do yet, would appreciate thoughts.
Note that I'm looking to remove the 'default profile' being shown underneath the general permissions, but the whole nature of that I'll get to in a minute. I would also be tempted to remove some of the other stuff in the admin pages, like 'setting permissions for one group like another' - basically if you go to the permissions page, you get the list of groups, then some stuff below those groups for things you can apply to the groups; setting 1+ groups like a template, setting a single permission on each of the ticked groups. Seems to me that a single big ol' list would negate the need for that. Permission copying would be reasonably simple too.
There was a concern previously about fitting it all in - while this is not a huge deal for the most part (inherited groups wouldn't be shown either, to save space), I'm also looking at using http://fixedheadertable.com/ - you'd keep the group names and the permissions in view at all times and scroll across to fit.
I don't think there was any real objection, but I think now I'm looking at it again, I'm having second thoughts on the idea - but I also know I don't have anything better to solve the problems I want to solve. I don't want to get into huge scale re-engineering if the idea doesn't feel sound, and right now this doesn't.
Board permissions. Ah, yes, I couldn't forget this, could I? I've been looking at what SMF 1 did versus SMF 2, unique board permissions vs profiles and I think I might have a better solution but this is sort of off the cuff. If I said it came to me while I was sat on the toilet[2] you'll hopefully understand.
So, let's recap, first of all.
SMF 1, for those who never used it, had the notion of global versus local board permissions. You'd set the permissions for each group generally, and if you had a board whose permissions were different, you could indicate as such and get unique permissions for that board.
Conceptually that's fine, until you have two or more boards that need the same-as-each-other but unique-compared-to-everything-else permissions. Incidentally, sm.org has this very setup, there are boards that have different permissions to any other (namely showcase, but some of the internal boards have that going on too)
Meanwhile, SMF 2 has the idea of profiles. You have some template profiles (but one you can actually change despite the system telling you that you can't, which I'm still not sure isn't a bug in disguise), and you create new profiles to apply them to the relevant boards. Great for managing boards with a few tiers of boards where you only have a few sets of 'permissions'.
Then we have SimpleDesk. This did something a little bit different: permissions were expressly not tied to groups. You create roles, which are essentially groups of permissions, then you say 'these groups, have these permissions, in these boards'. For example you'd create a staff role, which had a bunch of permissions, and all the time they were in those boards, they had those permissions. It was a bit ropey in places because I abused the concept in two interesting ways.[3]
Two options present themselves, ultimately.
Firstly, I can take the SD route. The UI can be nicer this time because I don't need to pull stunts around 'non board permissions', I can safely have the UI abstract that stuff away. But I'm not sure how well the 'groups != roles' concept will get across and I'd hate to lumber us with 'how do I set this permission up' crap.
Secondly, and perhaps more confusingly in a way. I can sort of regress back to SMF 1 permissions. I'd envisage it being split between permissions and the board configuration area, or at least... mirrored that way.
See, what I'd envisage doing is giving a list of the board type permissions, and the groups again - like above. Only this time, with an extra dimension to it. For each permission, you'd select the list of groups who have it/don't have it, but there's an extra option: apply to all boards. If you say 'apply to all boards', all the boards the users can see would be able to have/not have that permission. For example, posting replies would typically be yes to any group who can see the board in question. So you'd just have that as 'all boards', and just set it to the groups who reply.
If you decided you didn't want it as all boards, I'm thinking that the list of boards could fold out underneath to indicate that permission for that board/group combination. I think it could be thoroughly ugly, but I think it would be more intuitive than the current permissions setup.
Then you could go into a given board and see how it is in that given board, and configure it that way too. It would be back to local vs global permissions but easier to configure for simple changes. Of course if you have a lot of boards, changing things is going to suck very, very quickly, which is where profiles win.
More importantly, newbie factor. Setting up roles is not the most obvious thing, especially if you want people to be able to dive in and just set up a forum quickly, though I guess if sane roles were defined out of the box, that might not be a bad thing and it would probably clue most of them in on how to do it. But seeing the confluence of boards/groups/permissions should be marginally easier to follow - and still more compact than the current reporting methodology (which could also go bye-bye in the process)
* Arantor does not normally want much in the way of external validation, but this is a *big* thing to get right and I want to involve everyone as much as possible because it's also one of the most fraught areas of setting up a system.
Note that all the things I have in mind down the road about other content types can slot into what we have here with little change on a purely technical level, so this is almost entirely a UI problem. UI says it must be so, everything else will be kicked into line.
I don't know. I honestly don't know what's best out of all this. I just know that I don't like how SMF does it and by extension how we do it. I've been wary for some time of making big changes because I've been frightened of creating a worse mess than we already have. But I'm also not sure it can be *that* much worse. So, over to you. I'd love some thoughts on this, even if it's only to tell me whether you like or dislike it. Remember: you're the people who are ultimately going to be *using* it.
Of course, I'm open to other ideas. If there's any other system you've seen that you like the look of, tell me and I'll see what I can do to find out about it, including figuring out what's good about it. I'm not averse to drawing on any system out there - if the system works, I want to see it :)
| 1. | If allow is ticked, it's A, if deny is ticked, it's D, if neither are ticked it's X, letters for our current parlance. Oh, and you can't have both ticked at once. It actually works rather well on Windows for file permissions. |
| 2. | And how much thinking really gets done there, eh? |
| 3. | Firstly, I created non-board permissions using the same concept, except for 'board 0' being the board in question. Secondly, there are implicit permissions embedded into the roles, for accessing the helpdesk, being staff and being a helpdesk admin, they were ingrained into the role 'templates' that you had to build from. Kludgy but it worked, in fact in hindsight I think it worked better than I guessed. |
3
...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.
4
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?
5
So, yeah, we're about 5 days in after finally moving wedge.org to actually running Wedge, and I'd like to take a bit of time to just go over how I (at least) see it.
First of all, thank you to everyone who's stopped by, especially if you've stopped by and really loved what Nao's done with the default theme. I had the joy of seeing it ahead of time, so the surprise wasn't quite as big on me, but it was really great seeing it, especially being able to watch it grow.[1]
Also, a big thanks to everyone that's put up with the bugs we've had. As you can probably imagine, Wedge is still a living breathing work, it's still growing, still changing, as you can see from the New Revs thread every time we commit.
Because of that, and because we'd never deployed it in a public way beforehand, there was a lot of stuff that had never been thoroughly tested. So it was a matter of a little disappointment for us that things were buggy - and the list has seemed to be pretty huge in some respects - but overall, I think it's turned out pretty well. The bulk of the bugs are more annoying than serious, and I don't believe any of them are privacy or security related, either, so that's something to be quite happy about, really.
The funny thing is that there's a lot of things that I doubt people have really noticed yet. The theme's the most obvious change, and the way there are icons and animations and things, but I would encourage people to dig a little deeper. There are all sorts of less obvious changes afoot. You might just be surprised at what you find ;)
As ever, if there's anything you like or don't like, tell us! We can't fix things if we don't know they're broken, and if there's a better way of doing something than we're currently doing, tell us that too - the end of it, we want to turn out something truly awesome, and while Wedge is a long way down that road, there's still plenty more to do yet.
Sadly, we have not yet turned the corner that marks the end of 'new features' which would otherwise put us on the road to public releases. Things are still a bit too raw for that, still too many things not yet polished, or finished or tested to destruction. But we've certainly passed the biggest milestone: we've finally moved our own site to our own platform. With that, the single greatest hurdle has been passed; we get to test things in a real environment, we got to thoroughly test the importer, and we get to properly share with you what we've been doing all this time.
So, really, thank you all for bearing with us while we got here, and while we deal with the immediate things we've seen from it - and you'll be able to see the rough edges get polished, things get tweaked, things get added or removed. It's been a long road thus far, and it's not nearly over yet - but you're certainly welcome to join us for the ride :)
First of all, thank you to everyone who's stopped by, especially if you've stopped by and really loved what Nao's done with the default theme. I had the joy of seeing it ahead of time, so the surprise wasn't quite as big on me, but it was really great seeing it, especially being able to watch it grow.[1]
Also, a big thanks to everyone that's put up with the bugs we've had. As you can probably imagine, Wedge is still a living breathing work, it's still growing, still changing, as you can see from the New Revs thread every time we commit.
Because of that, and because we'd never deployed it in a public way beforehand, there was a lot of stuff that had never been thoroughly tested. So it was a matter of a little disappointment for us that things were buggy - and the list has seemed to be pretty huge in some respects - but overall, I think it's turned out pretty well. The bulk of the bugs are more annoying than serious, and I don't believe any of them are privacy or security related, either, so that's something to be quite happy about, really.
The funny thing is that there's a lot of things that I doubt people have really noticed yet. The theme's the most obvious change, and the way there are icons and animations and things, but I would encourage people to dig a little deeper. There are all sorts of less obvious changes afoot. You might just be surprised at what you find ;)
As ever, if there's anything you like or don't like, tell us! We can't fix things if we don't know they're broken, and if there's a better way of doing something than we're currently doing, tell us that too - the end of it, we want to turn out something truly awesome, and while Wedge is a long way down that road, there's still plenty more to do yet.
Sadly, we have not yet turned the corner that marks the end of 'new features' which would otherwise put us on the road to public releases. Things are still a bit too raw for that, still too many things not yet polished, or finished or tested to destruction. But we've certainly passed the biggest milestone: we've finally moved our own site to our own platform. With that, the single greatest hurdle has been passed; we get to test things in a real environment, we got to thoroughly test the importer, and we get to properly share with you what we've been doing all this time.
So, really, thank you all for bearing with us while we got here, and while we deal with the immediate things we've seen from it - and you'll be able to see the rough edges get polished, things get tweaked, things get added or removed. It's been a long road thus far, and it's not nearly over yet - but you're certainly welcome to join us for the ride :)
| 1. | The only sad part for me was that we'd decided to keep it under wraps so even when there were screenshots of stuff I was working on, they were all using the existing 'Wine' skin, which you can use here if you want, just head to Profile > Skin Selector. |