-
In the midst of discussions about privacy, we were discussing the way the Local Moderator / Board Moderator group's badge is handled and the problems with it.
Which leads me to this topic, the general state of play as far as displaying user badges goes.
Some people just want to display the badge of the main group, some people might want to display the main group + local moderator badge if appropriate, some the main group's badge plus post count stars. Some people even want lots of badges (e.g. if you're a developer + artist + doc writer, say, you might want badges for all three)
Nao mentioned that it would probably be hard to write as a plugin - certainly currently that's the case because extending the display area is generally a pain, but we can certainly put something in place to make it easier.
So, I want some feedback on what you use, what you'd like. Tell me how you have your sites set up, whether you like that approach or not, and also whether you use the mods out there for such things like Stars and Badges. :)
-
We don't use the badges - if fact I don't know how they work :o But we do use the stars feature for their post-count related group.
One annoying thing is that the name of every membergroup that a member is in is displayed under their name on all their posts. I have had to create a group with a blank title to get around this. So my one request would be a membergroup option to display or not to display. (If this is outside the scope of your question then please ignore me :) )
-
A badge is the same thing as a star, just you use 1 of them and use a bigger picture, but in all other respects it's the same thing.
The name of only the primary member group and the name of the post count group are the ones displayed, and the post count group can be hidden if there's a primary member group assigned (this is basic SMF functionality) - if it's shoeing every group, you have a mod added.
This stuff, though, is exactly what I'm trying to figure out.
-
Thanks for the info :cool: Looking at it, when they join a group themselves it becomes their primary group - as you say this could be a mod, I don't want this to become a SMF support thread :wow:
-
I am for what would be possible to customize
what and how to display
whether one of the main group icon
whether the main icon, plus an additional
-
....how exactly would you use it?
This is the thing I *need* to understand. I can build anything that's desired, but I need to understand how people will actually, realistically use it because I guarantee you that if I build it how I think you'll use it, it'll be wrong.
-
badges for me should be motivation.
In our forum we concidered to use badges to say "well done" to members with desired behaviour:
If a member is greeting newcomers and makes them feel welcome gets the relevant badge, if it writes informative posts gets the relevant badge.
Other badges are used to show proficiency in some areas of interest and others are there to designate (usefull) past experience.
We also use some "badges" to show current emotional state like angry, sad, frustrated, tired etc (mood bears or mood stars).
Maybe that helps.
-
So, do you show multiple badges on people? How would you want to configure multiple badges?
-
Better late than never.
Yes multiple badges on people just like the multiple badges on a generals chest
-
-sigh- So how do you want to configure it?
-
A general with a chest full of medals is generally a moron, btw.
-
I can see uses for displaying multiple badges, mostly it depends on the forum. What I'd love to know is how people want to be able to do it, since I don't think they'd like me to make them have to fill in a textbox with a comma-separated list of the badges they'd want to show, in order.
-
ok so here is my view on badges concept !!!
Users do wish to have multiple badges assigned to them. But I personally dislike it (for the fact that it will look odd or ugly to display many badges in profile)
But somewhat like combining the badges may sound better. Just an idea boomed out :
Here is a rough figure for multiple badge. (I am not good at graphics) :D
Like, getting equal ratio of all assigned badges to combine one. If two badges are assigned, it will display 50-50 and so on
-
That's the thing, I don't know many sites that actually would implement it like that, especially seeing that the implementation would force us to make YOU have badges that are irregular, unusual and hard to make.
Remember: what we implement in the core is not what JUST YOU wants or needs, we have to implement things for everyone to use, and this is too complex for everyone to use as it stands.
-
Ok... So I've always wanted a better way to manage badges and have had many thoughts on what I thought I wanted some seemed logical others panned out to be overly complex. Here is where I am now:
I'd like to see a badge management system more like an award system. I like others do not like the idea of creating a ton load of groups just to display the badges. Being able to create a badge and assign to users (maybe it can be optional to assign to an existing group) with the option to display in addition to or in place of primary membergroup badge. Additional options to display below the info in the user area, above signature, or in user profile might be useful as well. I'd also go for being able to set a badge to expire in x days.
If a member is in more than one group that has a badge, maybe display their primary badge as usual and have secondary badges displayed below the info in user area or in their signature.... maybe a setting that a a max of 3 badges can be displayed above the user avatar and all other subsequently displayed in signature on be the info in the user area.
One setting I would love if no other is to hide the group name/title when a badge is available... ie: There is a badge for Moderator so I wouldn't need/want the name of the group displayed as well.
If any of that makes any sense.
-
That's the thing, I don't know many sites that actually would implement it like that, especially seeing that the implementation would force us to make YOU have badges that are irregular, unusual and hard to make.
Remember: what we implement in the core is not what JUST YOU wants or needs, we have to implement things for everyone to use, and this is too complex for everyone to use as it stands.
an idea just boomed out reading the replies here.... and I know what I provided is one such foolish thing and hard to make or implement.
But I deny with your view that not many sites use badges... So far I have been registered in forums, there is definitely some or the other badges assigned to special members (Staff, premium, etc)
-
But I deny with your view that not many sites use badges... So far I have been registered in forums, there is definitely some or the other badges assigned to special members (Staff, premium, etc)
-
Ok... So I've always wanted a better way to manage badges and have had many thoughts on what I thought I wanted some seemed logical others panned out to be overly complex. Here is where I am now:
I'd like to see a badge management system more like an award system. I like others do not like the idea of creating a ton load of groups just to display the badges. Being able to create a badge and assign to users (maybe it can be optional to assign to an existing group) with the option to display in addition to or in place of primary membergroup badge. Additional options to display below the info in the user area, above signature, or in user profile might be useful as well. I'd also go for being able to set a badge to expire in x days.
If a member is in more than one group that has a badge, maybe display their primary badge as usual and have secondary badges displayed below the info in user area or in their signature.... maybe a setting that a a max of 3 badges can be displayed above the user avatar and all other subsequently displayed in signature on be the info in the user area.
One setting I would love if no other is to hide the group name/title when a badge is available... ie: There is a badge for Moderator so I wouldn't need/want the name of the group displayed as well.
If any of that makes any sense.
I completely agree on this !!!
Posted: March 17th, 2012, 02:55 PM
But I deny with your view that not many sites use badges... So far I have been registered in forums, there is definitely some or the other badges assigned to special members (Staff, premium, etc)
-
I'd like to see a badge management system more like an award system. I like others do not like the idea of creating a ton load of groups just to display the badges.
Being able to create a badge and assign to users (maybe it can be optional to assign to an existing group) with the option to display in addition to or in place of primary membergroup badge.
Additional options to display below the info in the user area, above signature, or in user profile might be useful as well. I'd also go for being able to set a badge to expire in x days.
If a member is in more than one group that has a badge, maybe display their primary badge as usual and have secondary badges displayed below the info in user area or in their signature.... maybe a setting that a a max of 3 badges can be displayed above the user avatar and all other subsequently displayed in signature on be the info in the user area.
One setting I would love if no other is to hide the group name/title when a badge is available... ie: There is a badge for Moderator so I wouldn't need/want the name of the group displayed as well.
-
I'd like to see a badge management system more like an award system. I like others do not like the idea of creating a ton load of groups just to display the badges.
Being able to create a badge and assign to users (maybe it can be optional to assign to an existing group) with the option to display in addition to or in place of primary membergroup badge.
Additional options to display below the info in the user area, above signature, or in user profile might be useful as well. I'd also go for being able to set a badge to expire in x days.
If a member is in more than one group that has a badge, maybe display their primary badge as usual and have secondary badges displayed below the info in user area or in their signature.... maybe a setting that a a max of 3 badges can be displayed above the user avatar and all other subsequently displayed in signature on be the info in the user area.
:edit: loving the smart tag closer :cool:
-
A general with a chest full of medals is generally a moron, btw.
-sigh- So how do you want to configure it?
Reading the above messages makes me think that badges can just be a way to visualize groups. Just like adding tags to members or members to tags but with images. A legend is required somewhere and maybe a hover description.
-
A side matter to attend to: board moderator badges.
I've been thinking about this and I'm inclined to suggest two avenues of badge for it.
1) If the user has a badge already from their primary group, don't bother showing the board moderator one. (Of course, if they have no badge from their primary group but instead post count, use board mod)
2) Show board moderator as an additional badge instead of replacing whatever badge is there.
Which would you use?
-
I like #2
-
A side matter to attend to: board moderator badges.
I've been thinking about this and I'm inclined to suggest two avenues of badge for it.
1) If the user has a badge already from their primary group, don't bother showing the board moderator one. (Of course, if they have no badge from their primary group but instead post count, use board mod)
2) Show board moderator as an additional badge instead of replacing whatever badge is there.
Which would you use?
Mark
-
My suggestion would be to show Moderator badges for Moderators' posts in those Forums/boards they manage but show their primary group badge (and not a Moderator badge) elsewhere.
Notice here for example. My primary badge is not the admin group, so I get a moderator badge despite the fact that I have a badge, but having it override any other badge I have is... potentially awkward.
The reason I say that is because if you imagine someone posts here now, they'll probably assume that I'm just a local moderator - unless they look around elsewhere. The same thing happens on sm.org actually, if you go to simplemachines.org, and start from http://www.simplemachines.org/community/index.php?board=33.0 - you'll see Kindred making some posts in that board itself and he has a Marketing badge. But if you look at any post he's made in the Mambo or Joomla bridge boards, you'll see he has a local moderator badge. Doing so is potentially very misleading - hence the suggestion to display both together.
-
Here's a little bit of blue-sky wishfulness...
My (our) forum is part of our virtual airline (Flight Simulation... visit EuroHarmony VA(http://www.fly-euroharmony.com) if you want to learn more), and all pilots have Avatar images that are made automatically for them. They show rank, management level, and awards:-
(http://fly-euroharmony.com/site/assets/images/avatars/0654.png)
We use a PHP script to construct these from sub images.
Now, if we could do that sort of a thing (core or plugin) automatically as a badge, I'd be a pig in sh*t...
:eheh:
-
FYI, I'm *not* suggesting the above gets added to any feature lists or anything. Once there's a way for me to play with the code (and especially plugins), I'll look into this for myself.
While I can envision this being useful to other people in general (heck, to a far lesser extent, it's what the whole thread is about), the specifics of what I'd like to achieve make it far from practical.
:eheheh:
-
My suggestion would be to show Moderator badges for Moderators' posts in those Forums/boards they manage but show their primary group badge (and not a Moderator badge) elsewhere.
Notice here for example. My primary badge is not the admin group, so I get a moderator badge despite the fact that I have a badge, but having it override any other badge I have is... potentially awkward.
The reason I say that is because if you imagine someone posts here now, they'll probably assume that I'm just a local moderator - unless they look around elsewhere. The same thing happens on sm.org actually, if you go to simplemachines.org, and start from [url]http://www.simplemachines(http://www.simplemachines.org/community/index.php?board=33.0)…nity/index.php?board=33.0[/url] - you'll see Kindred making some posts in that board itself and he has a Marketing badge. But if you look at any post he's made in the Mambo or Joomla bridge boards, you'll see he has a local moderator badge. Doing so is potentially very misleading - hence the suggestion to display both together.
-
But I would prefer that provision be a decision the site's admin makes as he may have a very good reason for not wishing both to be constantly visible.
I'm not talking technical-side, I'll figure that out in due course. I'm speaking specifically about the user interface. It's already complicated enough, and this is a whole level of complexity on top that I'd like to solve definitively rather than vaguely. What SMF had in the past was vague and unprofessional, though certainly workable and no more unexpected than most mods end up with, but I certainly can't use that approach in the core.
(I cannot justify having a facility in the core whereby a single textbox is used by the admin to indicate what badges should be shown in what order. i.e. if a user is in groups 1, 4 and 10, which each have their own badges, and the admin puts in "1,10", it would show badges 1 and 10 for that user in 1/4/10. If I put that interface in, I'd get lynched.)
-
As far as the interface:
Add New Badge - Apply to Member/Group - Display/Hide (check-boxes)
Provide a field to enter the member's name and select boxes to select the groups to apply to.
Options to view/edit/remove the Badge.
-
How would users set the relative order of badges?
-
Manage badge section somewhere in the profile area.
Display all user badges, user selects which badges display above avatar (max 3 maybe), below user info, or signture. Up/down arrows to determine order in each section. :unsure:
-
How would users set the relative order of badges?
-
The easiest way for *you*, amongst the most difficult for *us* ;)
-
The easiest way for *you*, amongst the most difficult for *us* ;)
Lets talk about compromise.
Display a numbered preview of the badges and ask from the user to enter the sequense he/she wants.
In a textbox.
-
Personally, right now I'd be happy just with a setting to disable all textual membergroups and only show one badge per person... :^^;:
How can I say that?
Perhaps my number one issue with forums, and the more time passes the worse it gets, is that they're BUSY. They look busy, and they are. They show plenty of buttons and icons everywhere. It's always like the authors want their new features to be visible, but then they forget to hide their older, lesser used features. vBulletin is the prime example of that, I'd say... Every time I'm on a VB forum, I keep telling myself that, no, it's okay, I DON'T need a PhD to navigate through the board... But it certainly feels so!
-
This is the thing, I want to put that power in the admin's hands. If *they* want to make it complicated, fine, it's their forum.
As it is, we make a lot of decisions about how the core operates, both technically and practically. For something like this I'd prefer to give them some choice in how they present it, and while my gut instinct initially said 'plugin', I can't help but think we can do it faster and cleaner in core.
-
Put the necessary framework to do it in core, with a really basic management interface ("ordered list" of rows, top/up/down/bottom buttons styleee) and allow for more complex management UIs to be done as plugins. If folks want drag 'n' drool, let them write them :eheh:
-
...Looking at it, when they join a group themselves it becomes their primary group - as you say this could be a mod, I don't want this to become a SMF support thread :wow:
Are you still consulting us masses on this? Well just in case here are the results of the Farjo jury....
I think you've written elsewhere that the membergroups could be split into those that control permissions and those that control display (i.e. a badge or stars). For the board I admin we would have both types and one group would be both.
I see that Neo doesn't like the idea however we would have stars for the post-based groups plus badges from one or more groups of which they are members. We'd also like the choice of showing the group name or just the image(s). This is regardless of whether it is their primary group or not.
Visible Boards: for us it would be better to have access and deny here, maybe like the A / D / X elsewhere. This is just the way I set it up - when a member joins he has permission to see forum 1, which redirects to a page with information on how to join that membergroup, or details of its club and who to contact in order to join. When the member joins that group he gets permission to view and enter forum 2, and it would be nice, in a tidy way, if he were no longer able to see forum 1.
As above I don't understand the Visibility setting.
-
Sure we are. Nothing's been written on this so figuring out how it should best be approached, well now's the right time :)
I think you've written elsewhere that the membergroups could be split into those that control permissions and those that control display (i.e. a badge or stars). For the board I admin we would have both types and one group would be both.
I see that Neo doesn't like the idea however we would have stars for the post-based groups plus badges from one or more groups of which they are members. We'd also like the choice of showing the group name or just the image(s). This is regardless of whether it is their primary group or not.
Visible Boards: for us it would be better to have access and deny here, maybe like the A / D / X elsewhere.
When the member joins that group he gets permission to view and enter forum 2, and it would be nice, in a tidy way, if he were no longer able to see forum 1.
As above I don't understand the Visibility setting.
-
@Farjo> Right now, what I'm implementing is this (loosely related to your post):
- 'Hide post-based membergroups' is no longer a theme setting (I'm going to try and remove most of the theme settings, really -- they should be core settings IMHO, and as discussed elsewhere, theme settings should be things that really are theme-specific.)
- Instead, the Manage Membergroups settings page offers a new select box where you can select one of these:
- Show no membergroups at all
- Show all membergroups (normal + post-based)
- Show normal membergroups only
- Show post-based membergroups only
- Show post-based membergroups only if no normal membergroup is set (that's the equivalent to the original SMF option.)
I'm only adding these for now, but I guess we could also take rank images into account -- or instead get rid of my select box and allow for every new membergroup to be set differently: 'show this membergroup in addition to others', 'show this membergroup's badge in addition to others', 'hide this membergroup if another normal group is shown', 'hide this membergroup if any other group is shown', etc...
Only, it would possibly get complicated to set these up, so I went for the middle solution, my select box. We could also add a second selectbox in the same page that does exactly that, with rank images instead of membergroups.
Actually, I'm also doing this all to 'learn' (or rather, re-learn) how to properly implement new settings in the admin area. I hadn't done this kind of thing for several years...
-
I fear I killed the conversation with my above post. It wasn't so scary was it...?
So, I resumed work on this. I implemented the feature, re-enabled 'conditional post-based' like the original default, and figured that there are probably better ways for everyone to implement this.
I'm now considering this...
For EACH membergroup, if you create/modify them, Wedge could give you several additional options (that would be accessible only to group moderators and administrators, just in case we add the ability for everyone to create their own membergroups later.)
As follows:
- Visibility (it's already a feature, I'm just pointing out we have this.)
- Show group in user box?
- Always
- Only if it's the only one (<-- should be set by default for post-based groups?)
- Never (a bit like Visibility, but only for group text)
- Show rank image(s) in user box?
- Always
- Only if it's the only one
- Never (Hmm maybe not that option... User could set the thing to 0... Unless they find it confusing to do...)
Any opinions?
-
"It wasn't so scary was it...?" I was too tired to read it and then forgot to come back to it - sorry, will reply later.
-
Speaking of post groups.
How about doing like-based groups..?
You know, just for valuable members to automatically get a badge or something.
Could be perverted though...
-
Could be perverted though...
Speaking of post groups.
How about doing like-based groups..?
-
Yeah, post-count groups *are* perverted in some way, I myself am known for spamming some boards when I was close to getting into a 'good' post group, and even becoming silent when I was close to getting out of it :P
-
Well, I'd love to have such groups, where groups are based on different criteria (I've seen 'time based' and 'karma based' done as mods) Though doing it is not simple.
Mind you, the whole way post count groups is handled is very awkward and special, and has all sorts of interesting risks, namely that it is possible to get users who are true admins by misconfiguring or attempting to remove all the post count groups.
Then there's the matter of post group permissions. Or even like-count group permissions. Is that a route we'd want to go down potentially?
-
I don't know, I think that user-owned groups (for starters) will only get to modify a few of the settings -- basically, the first half of the settings in the membergroup edit page. They will also be able to edit their permissions, I guess, for their own user-created boards. It gets complicated, I know, but it makes sense as well to give users freedom... Otherwise there's no point in implementing blogs or anything. Because that's really what all other forums (except for Noisen but it's pretty much proto-Wedge anyway :P) do WRONG IMHO: they consider that blogs are only to be created by forum admins, or they provide blogs to their users but they're extremely limited, e.g. they can only have one blog, public viewing, etc... I haven't looked much into other forum+blog solutions, but they all seemed to be that limited.
Could you give your opinion on that post, btw..?
http://wedge.org/pub/feats/7108/badges-and-the-displaying-thereof/msg276657/#msg276657
-
User-owned groups is something else again on top of the other types of groups mentioned.
The post you linked, it does pretty much cover everything, I think.
-
"On top"? You mean, additional groups?
And my post doesn't cover what to do when the group is Additional or Primary, though... Ah ah.
-
We've managed to talk about several very very different things.
On the one hand, is user-created groups. A lot of that is UI fluff. I'd argue that the badges for these should never be shown (mind you I don't see that you'd ever have badges for them in the first place, eh)
On the other hand is groups based on other criteria that isn't assigned and isn't posts, e.g. likes. Or number of topics created. Or number of attachments posts. Or total time logged in. Or karma if we still had it. This is where it becomes painfully obvious that there are problems in the post count group setup, in terms of extensibility, usability and reliability. As I've alluded to, it's possible to make people admins *by accident* by screwing up the post count groups.
Which means, then, perhaps we want to rethink how post count groups are actually managed, and not make them groups in the current conventional sense. It does also suggest rethinking how such permissions are determined, too.
-
We've managed to talk about several very very different things.
On the one hand, is user-created groups. A lot of that is UI fluff. I'd argue that the badges for these should never be shown (mind you I don't see that you'd ever have badges for them in the first place, eh)
Perhaps it could be done, but I suspect through a plugin maybe. By default it really would be opening the door to abuse. e.g. I'll just create 30 groups with a badge and put myself into them :P
(Hmm, would be interesting to ensure that groups you create, you CANNOT join. Any access permissions given to it for your items are automatically given to you anyway, as you're the author...)On the other hand is groups based on other criteria that isn't assigned and isn't posts, e.g. likes. Or number of topics created. Or number of attachments posts. Or total time logged in. Or karma if we still had it. This is where it becomes painfully obvious that there are problems in the post count group setup, in terms of extensibility, usability and reliability. As I've alluded to, it's possible to make people admins *by accident* by screwing up the post count groups.
Eh, what am I talking about... No one would use that anyway. :PWhich means, then, perhaps we want to rethink how post count groups are actually managed, and not make them groups in the current conventional sense.
Perhaps what could be done, though, is to instigate a "minimum post count" setting that would be quite global to the forum. Anywhere you can set up a membergroup, you could also set up a minimum post count check that is done after the membergroup check. That setting could be kept either in a new field in most tables, or simply in a new table with a content_type field or something.
But, quite honestly, I think that id_post_group is... relatively well known now, and perhaps it would put off admins if we removed the system entirely. Like, it might give some users access to areas they previously didn't know about...
-
I'm now considering this...
- Show rank image(s) in user box?
- Always
- Only if it's the only one
- Never (Hmm maybe not that option... User could set the thing to 0... Unless they find it confusing to do...)
"How about Like based groups?" It would be cool to have a group for members who joined over x years ago, have at least y posts, and more than z time online as these would be old members who have stuck around and contributed.
But as Arantor hints it would be a bastard to set up and the support would be a never ending stream of user / set-up errors.
Thanks :)
-
There already are a lot of issues with users screwing it up, which means I'm inclined to simplify it, so that instead of the current approach, we actually don't have physical groups for post counts etc.
Instead, we have it such that rules are created:
* if user has 0-9 posts, show this badge/title
* if user has 10-100 posts, show this badge/title
Then we can start applying something similar to permissions - but tying it to the permission rather than the group. So for permissions, for example, permission to do X can be 'user in these groups, or has post count of at least X', similar to the power of the moderation filters system.
The only trick is doing it efficiently.
But it wouldn't be hard to stack post count badges with other badges with this set up.
-
I think I see. Reminds me of a quote (something like) "I spent a week on a ship with Albert Einstein who every day tried to explain his relativity theory, and at the end of the week I was convinced he understood it"
-
This is essentially it. I can tell you exactly how every part of the groups system works under the hood. And you'd be convinced I understood it. (You would be right, heh) But I doubt I could explain it sufficiently well to explain it to other people.
For example, as I mentioned, it's possible to screw up the post count groups such that a user could actually become an admin. I can tell you not only what circumstances cause this, I can tell you why those circumstances cause it. But if I were to do so, you'd look at me like I was some kind of loon.
But I do have to wonder whether that level of complexity is really necessary.
-
The only trick is doing it efficiently.
SMF's is not perfect, but it would be much worse I reckon.
We should probably stick to physical groups for now... And if we change that in the future, well... We can always add this to the update script.
-
Bump for this.
I'm currently in the process of reviewing my code for badges and went into rewriting loadMemberContext(). First of all I renamed $display_custom_fields to $full_profile because essentially custom fields are only shown in user boxes, i.e. Display and PM pages. Now I can use that to determine when I should hide or show a badge etc... (Because we're not always planning to show a badge, so why waste time calculating this?)
Problem is -- if I store badge settings per group, I have to: (1) retrieve the list of additional groups (in addition to the main one), (2) ensure groups are self-aware that they're primary or additional (after all, one may want to set badges to show only if the group is a primary one....), (3) load badge settings for every single group. --> this would certainly require a cache...?
The 2 first steps are okay, but the 3rd step depends on several things... Loading a cache in loadMemberContext() may be a bit overkill. Also, with custom group, we may end up with a very large group cache file.
Suddenly I'm not sure this is such a good idea... :^^;:I fear I killed the conversation with my above post. It wasn't so scary was it...?
So, I resumed work on this. I implemented the feature, re-enabled 'conditional post-based' like the original default, and figured that there are probably better ways for everyone to implement this.
I'm now considering this...
For EACH membergroup, if you create/modify them, Wedge could give you several additional options (that would be accessible only to group moderators and administrators, just in case we add the ability for everyone to create their own membergroups later.)
As follows:
- Visibility (it's already a feature, I'm just pointing out we have this.)
- Show group in user box?
- Always
- Only if it's the only one (<-- should be set by default for post-based groups?)
- Never (a bit like Visibility, but only for group text)
- Show rank image(s) in user box?
- Always
- Only if it's the only one
- Never (Hmm maybe not that option... User could set the thing to 0... Unless they find it confusing to do...)
Any opinions?
-
Well, loading additional data in loadMemberData is not a big deal (it's only one extra field at this point). The cache of fields/positions etc can be pulled from the membergroups table in probably a single query.
I'd argue that for the purposes of displaying multiple groups, you don't actually have to care about primary/secondary, but rely totally on the order specified in the membergroups themselves, for badges that shouldn't be displayed, store their position as 0, for all others store their position as 1+ to indicate the position, then just query the table WHERE position > 0 ORDER BY position, and you get that information pre-sorted too.
It wouldn't necessarily *require* a cache but I'd cache it.
-
That would make impossible to have badge display depend on other badges being shown or not....?
eg only show a post group badge if no primary group is set
or only show a post group badge if no other group is set
etc...
also, lmc() doesn't do the actual requests so it'd require doing an extra request, i think...
-
You could just as easily do all that extra processing when fetching it all, making that determination based on other settings, and it wouldn't be an extra query depending on how it was set up.
lMC does no requests itself, it's part of lMD to get the data, but that's no big deal really.
-
We'd need to do that in LMD then, but it's a tad harder to determine whether it's being called for userboxes or not. Well, could always add a flag for that too...
Hmm there's an impressive amount of calls to LMD with the default param, 'normal', sometimes I'm wondering if we shouldn't be able to specify just a list of fields we want to retrieve and parse... :P
Would be easier for hooks as well, wouldn't it..?
-
It would be better if the calls to lMD didn't indicate what they wanted per se, but indicated what they were calling for, and let lMD deal with that. Right now we have 'minimal', 'normal' and 'profile', but only the latter is really expressive of what you're actually doing there.
We have talked about it before, actually, to do exactly that - indicate what purpose the data is being called for.
-
So... I was trying to find inspiration, so I looked into sm.org and found a very old mod (multiple badges) that did a similar thing. I was wondering how it could 'optimize' the database request for these.
Well, it doesn't... It's even worse than what I had in mind -- it does a query per badge, lol.
At this point, I have only two solutions:
- either I insert a FIND_IN_SET(additional_groups) in the LMD function when it comes to the 'mg' table, and then I turn the group entry into an array with membergroup settings for each...
- or I simply give up, and use the code I wrote weeks ago and that I always stop myself from committing. i.e. the global setting in the membergroup settings page, determining whether to show the main group badge, the post group badge, or both, or none.
I'm wary of using FIND_IN_SET(), but OTOH it's also likely that we'll rewrite the additional_groups field to only contain 'public' groups, meaning we'll need to join with a new table to get a proper list of all groups one belongs to, so that would be less of an issue in this case.. (Except that I don't know that there's a point in offering users the ability to create a badge for a user group....?!)
'm a bit lost -- as usual... Hard to get back into the game after this hectic week.
-
Well, here's the thing, if you load all the groups as I indicated (using 0 to indicate a group whose badge will not be displayed), you do a single query, then fetch the additional_groups and do the processing PHP-side without extra queries or effort, and then when member-created groups get done, they also get a badge-position of 0 which means to exclude it.
Then you're done in all respects and don't even have to tackle FIND_IN_SET.
-
Hmmm... That's doable I suppose.
Maybe we could even mix the cache for membergroup colors (used in username links) with the one for badge stars...?
-
Makes sense to me to do that.
-
One of my concerns is that user groups *could* use custom colors and badges, but only in boards belonging to the user group owner. perhaps we should also cache a membergroup list per board...?
-
I wasn't going to get into that. I see little reason for user-created groups to have custom badges, honestly. Setting badges should be up to the admin, and only the admin IMO.
-
Same for colors?
-
Yup. User created groups would tend towards being secondary groups where the colour wouldn't inherit anyway.
Also, note to self: need to migrate the list of who likes a post to a proper popup rather than a tooltip, it doesn't work properly with people who have funny symbols in their names as the font Windows uses for tooltips does not include all fancy characters.
-
There's plenty of work left to do on likes... If anything: (1) add a permission to like own posts, (2) add the mini-menu I painstakingly rewrote to help with deploying on like buttons... (Heck, it still needs quite some work.)
Re: membergroup caching, I just realized that only groups with an actual color are cached -- I don't know if it's best to just cache all of them, making the coloring possibly slower, or just have two group caches: one for groups that have colors, and one for groups that have a badge to be shown.
Hmm... Probably two separate cache files... :-/
-
Re likes: I already outlined a bit back what configuration items are still outstanding, I just haven't gotten round to implementing them yet :P
Re caching, might as well make one cache with everything else. Post-count groups will have a badge (or badges) but probably no colour, non-post-groups will almost certainly have both a badge and a colour. And if we're ever looking at displaying both a badge for group and the stars for post groups (which would be neat, actually), we will need both anyway.
-
I don't know, I've thought it over and basically -- the badge stuff is not used in a lot of places. I might as well add a sub function that loads the membergroups where show_when (or whatever name the field will have) is !=0. This will/would save extra bytes being loaded on every page when we're on a page where only the membergroup colors are required.
I've already started implementing it that way, but I don't know, maybe I'm wrong...?
Here's the sample...
// Load cached membergroup badges (or rank images) and when to show them.
if (($member_badges = cache_get_data('member-badges', 5000)) === null)
{
$member_badges = array();
$request = wesql::query('
SELECT g.id_group, g.stars, g.show_when
FROM {db_prefix}membergroups AS g ON g.show_when != {int:never}',
array(
'never' => 0,
)
);
while ($row = wesql::fetch_assoc($request))
$member_badges[$row['id_group']] = array($row['show_when'], $row['stars']);
wesql::free_result($request);
cache_put_data('member-badges', $member_badges, 5000);
}
An array_diff can then be pushed to $user_info['groups'] (or the equivalent thing loaded through LMD or LMC or whatever), to build a list of badges that could be shown. Then we can go iteratively over the group list and keep the badge if show_when is set to 'always show', and delete it if set to 'only show when nothing else is shown' and there's at least one badge already being shown in the list. (Primary group being first priority in the list...)
Well, that's how I'm seeing it done at least. But I'm tired and may be wrong on all accounts.
Going to bed, so you can take time to think about this and tell me what you think is best...
Maybe cache_put_data should be a singleton... wecac::put() :P
Too bad that 'cac' sounds odd in French... (Our equivalent to the Dow Jones.)
-
Bump? Anyone?
-
This feature implementation is starting to get on my nerves...
It means a lot more rewrites than I hoped for. Well, I hoped, but I had little confidence, because I knew I was going to bump into problems with Wedge assuming that the 'group' entry in the context array is a string rather than an array...
As for performance, I don't think it has much influence though.
What about the show_when field? Right now I have these settings: 0 = never, 1 = always, 2 = only when no other badge is shown. Also, groups are sorted by ID so that admin and moderator groups have priority over the rest... I don't know if it's for the better?
-
The show_when field makes sense, and ordering by id will give priority to admin, global moderator, then moderator, then all the post count groups >_> May not be ideal, which is why I suggested an explicit ordering in the table.
-
The show_when field makes sense, and ordering by id will give priority to admin, global moderator, then moderator, then all the post count groups >_> May not be ideal, which is why I suggested an explicit ordering in the table.
- get all groups (id_group + additional_groups)
- sort them
- test against them
- then finally, test against the id_post_group
Which effectively makes id_post_group the lowest priority one...
Anyway -- it works overall, but it's really geared towards making badges...
For instance, in my local install, which has the default groups, my account is showing the Admin badge (which is 3 rank images), then the Junior badge (which is 1 rank image).
It should have been showing instead an 'Admin' badge and then the lone star...
I'm stuck on this. Couldn't figure out a way to properly do it.
Also, as stupid as it may sound, I totally forgot to deal with textual group names... Means a further rewrite ahead for me... Ah, well.
I also added a 'userbox' type for LMD, will probably become 'display' or 'topic' later. It allows me to get rid of several entries that aren't used in Display.php and take some processing time, such as member_ip... (Well, member_ip is normally used, but I don't know if it's worth it, for instance...)
Of course, the final generated page isn't any faster than the earlier ones. NO KIDDIN'. Well, at least it doesn't seem slower either...
-
Anyone?
Posted: June 6th, 2012, 10:16 AM
That's the problem these days. I'll start a larger project under suggestion from others, and then I'm on my own to finish it... :(
-
Which effectively makes id_post_group the lowest priority one...
Also, as stupid as it may sound, I totally forgot to deal with textual group names... Means a further rewrite ahead for me... Ah, well.
It should have been showing instead an 'Admin' badge and then the lone star...
I'm stuck on this. Couldn't figure out a way to properly do it.
I also added a 'userbox' type for LMD, will probably become 'display' or 'topic' later. It allows me to get rid of several entries that aren't used in Display.php and take some processing time, such as member_ip... (Well, member_ip is normally used, but I don't know if it's worth it, for instance...)
Of course, the final generated page isn't any faster than the earlier ones. NO KIDDIN'. Well, at least it doesn't seem slower either...
Posted: June 7th, 2012, 12:47 AM
That's the problem these days. I'll start a larger project under suggestion from others, and then I'm on my own to finish it... :(
-
Ah...HA! Finally proper support for multiple badges...
Example:
http://wedge.org/pub/off/7213/the-browser-you-loved-to-hate/msg275170/#msg275170
The admin can also determine whether the Moderator badge will show. Selecting to have it "never show", or "show only if there are no other badges" or "show only if it's a primary group" (which never is the case here) will hide it.
Well, the UI has yet to be written... But it's in progress locally.
Also, I'm not 100% sure I'm doing it right -- I'm actually adding id_group #3 to the list of additional_groups in the $user_profile variable at this point. I don't think that SMF did that at all. It makes sense to me that at least one area has a record of it for the duration of the page...I'd consider showing just the very first group's name, no point showing all the group names, but only the primary group's name - or post count group name if there isn't a primary group name, and nothing more than that.
- Badge system: set it up per-badge (per-group), on individual group pages.
- Group titles: Wedge will only show the primary group's name (if it exists), and/or the post-based group's name (if it exists), and then will determine which to show according to a setting in the Manage Membergroups > Settings page.
My only concern is that it ends up being too complicated for some admins... But OTOH, once they have it set up, they don't have to touch it again. And the default setup should be good enough. (Group title's default is the same as in SMF.)Got something I can see of the code?
Certain things aren't about speed, especially as you still have to do the extra query to get board moderators to be able to add the board moderator badge into the mix yet.
My problem is, I just see so much stuff there is to do and I have no idea where to pitch in to do any of it :(
-
So... What about these? Anyone happy or unhappy with them?
(Of course, to test these you need to touch the database manually... Sorry about that.)
-
Wow Im waybehind, I mentioned this in another recent topic, Ive used Johny B's Stars and badges mod on several sites and I'm glad to see the function implemented in Wedge.
-
What function?
-
Multiple badges
-
Oh... Well, I didn't even know there was already a mod for that...
Anything I write is my own code, not some idea I got somewhere else. Usually :P (There's UltimateProfile which I wanted to totally rip, but never got around to doing that...)
-
Yeah, there's a mod for it but it's not particularly nice and long since unsupported by its author.
-
Yeah the SMF mod has been abandoned for a long time, really sad with how popular it was. Not to mention how the community has been supporting the thread with tricks to keep it working.
I am glad to see it native in Wedge, it saves me from having to rip it and I'm sure its much cleaner then anything I can write. :)
I'm sure there are many in the Wedge community that would love to see many of the features from Ultimate Profile in Wedge too.
-
Well, it was abandoned because of the author having personal issues to deal with and he just disappeared after that.
I'm not sure that what we have right now is exactly the equal of Stars and Badges, but I'm not sure that's necessarily a bad thing. You don't have quite the flexibility that S&B gives, but there is enough for most cases.
-
Since I don't know about S&B at all, I only implemented the features *I* needed for wedge.org actually.
That's the difference between adding what you want, and adding what people tell you to add. ;)
As for U.P., I wouldn't know where to start.
Which is strange, considering that my original plan for Wedge was to have a "stock SMF that would have Aeva Media, Ultimate Profile and a blog system by default."
In the end, there's only a hint of a blog system, no UP at all, and AeMe is only there as a memento, I never added any features to it, except for the occasional code refactoring and addition of Foxy! features for free...
-
The big difference is that in S&B you just say what badges to display out of all of them and you set the exact display order.
-
And it's still using the regular rank system...?
Because even with my settings, I had to heavily mod it...
-
What you do with S&B is have a single textbox in the admin panel where you indicate what badges to be displayed. E.g. if a user is in groups 1, 4, 10 and 20 (4 being the post count group), you could indicate 1,10,20,4 in the admin panel to display those groups if users are in them.
-
Hmm.. Well, that means it's easily customizable indeed, but it's also less accessible to noob admins.
-
Yup. It's a mod, user interfaces by definition are less important, and really that's not the worst user interface I've ever seen.
I'm still not sure what our UI for this should look like.
-
So I spent some time experimenting, knowing how it was set up, knowing how it was implemented I made some changes to allow for configuration of order - that was earlier today.
Now the UI. Yes, this uses jQuery UI. If someone wants to write a smaller version of ui.sortable, fine, but I'm happy with this working the way it does.
The idea is this way you can configure the order by dragging the badges around, and you can set whether badges are visible all the time, or whatever.
-
SaaaaWEEEEEEEEEEET
Too many caps :eheh:
-
There's no rule on that stuff for posts, only topic titles ;)
But I *could* add it to posts too :whistle:
-
Looking good!! :D
-
Random question: should the membergroup legend use the same ordering? I'm thinking the answer should be yes.
-
I say yes as well
-
Nearly done with adding that.
In other news, I have absolutely no idea why the admin menu is broken on the above mentioned page. It just doesn't do any dropdowns (but the *main* menu does, so I'm really confused)
Posted: January 1st, 2013, 05:45 PM
Oh holy hell, why the hell is jQuery UI adding a shit ton of classes to ul.menu?
Posted: January 1st, 2013, 05:48 PM
OK, I figured this out. Turns out there's a really fun collision going on.
The generic menu has a .menu() function, which then gets overwritten by jQuery UI.
Given that I can see mod authors using jQuery UI for their own things, and that I don't see us rewriting it from scratch any time soon, I'm just going to rename the menu function caller in the generic menu code to wmenu for Wedge menu.