Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Topics - Nao
121
Features / Things to do before the Mayan apocalypse: membergroups
« on April 20th, 2012, 10:37 AM »
(Again, see the 'general' topic for more details on these Mayan topics.)
- Custom membergroups: this one is harder because it has so many ramifications. I'm going to try and address most of them. So, basically:
1/ Add an id_owner (id_member) field to the membergroups table.
2/ Add an interface for users to create membergroups. Very simply: take the admin interface for that, and remove the second half of the membergroup creation page. There are many options that shouldn't be available for non-admin members, and 99% of them are in the second half, very conveniently.
3/ Add more membergroup types. Things like 'hidden' and such are good, but the first membergroup a user creates should be considered their 'friend list' (what I call 'contact list'.)
4/ Add more membergroup fine-tuning. This is a thing I have in Noisen and am really fond of -- I can determine whether people can see all or part of my friends list. Some of my friends I chose to keep in a 'hidden' state so that they would benefit from being in my friends list, without being visible as one of my friends. Perhaps this could be 'simplified' (for code) into two groups: a regular 'friends' group and a hidden 'friends' group... I'd rather have an extra field for that, though. And it's just an example.
5/ Now for the hard parts...
(a) Write some UI for group selection in privacy settings. Not too complicated when it comes to setting privacy from the posting page, but I also want to be able to set privacy on the fly through a select box, like I'm doing on Noisen.com (although it's not a select box there, it's actually a rewrite of the icon selector). The difficulty is not in writing the thing, but in making it so that it's *easy* to understand and use.
(b) And the single most frightening thing for me... Dealing with the aftermath of being able to create membergroups for anything. Basically, from my experience on Noisen, I know that people aren't going to spend their days creating membergroups, but if they end up doing it, it could easily break Wedge if not handled correctly. Do you remember when Facebook had a limit on how many friends you could have? I think it was 5000. It was a lot though, and I doubt any forum would be penalized by having such a high limit on the number of friends. I'm still going to assume that 10k users are going to add Mike42 to at least one of their membergroups, and Mike42 is going to add 10k users to his own 'friends' group (reciprocal friend additions -- that'd be asynchronous in Wedge, i.e. not mandatory, unlike SMF.)
So, we have a members table where the additional_groups field for Mike42 contains 10k comma-separated group IDs... Which probably makes it even impossible to store additional_groups into a TEXT field. (I guess MEDIUMTEXT would do...)
Even then -- it's going to kill performance, whatever we do about it. So we need 3NF for membergroups too. We discussed it at length but, yet, nothing has come of it. I'm getting wary of it, Pete is getting wary of it... I even recently read an old discussion on sm.org where Pete (yes, you Pete :P) actually discussed how 3NF could kill performance if table joins were used everywhere.
Now we have 3 ways of dealing with this... Either we just set a (relatively) low limit on the number of people you can put into a custom membergroup, and/or number of groups you can be put into, in which case I guess staying with the current SMF way of doing things is all right, or we add 3NF and still keep the additional_groups field and up the limit (but not too much), or we do it entirely 3NF and get rid of additional_groups, get rid of any limits and scream at the performance issues later...
- Custom membergroups: this one is harder because it has so many ramifications. I'm going to try and address most of them. So, basically:
1/ Add an id_owner (id_member) field to the membergroups table.
2/ Add an interface for users to create membergroups. Very simply: take the admin interface for that, and remove the second half of the membergroup creation page. There are many options that shouldn't be available for non-admin members, and 99% of them are in the second half, very conveniently.
3/ Add more membergroup types. Things like 'hidden' and such are good, but the first membergroup a user creates should be considered their 'friend list' (what I call 'contact list'.)
4/ Add more membergroup fine-tuning. This is a thing I have in Noisen and am really fond of -- I can determine whether people can see all or part of my friends list. Some of my friends I chose to keep in a 'hidden' state so that they would benefit from being in my friends list, without being visible as one of my friends. Perhaps this could be 'simplified' (for code) into two groups: a regular 'friends' group and a hidden 'friends' group... I'd rather have an extra field for that, though. And it's just an example.
5/ Now for the hard parts...
(a) Write some UI for group selection in privacy settings. Not too complicated when it comes to setting privacy from the posting page, but I also want to be able to set privacy on the fly through a select box, like I'm doing on Noisen.com (although it's not a select box there, it's actually a rewrite of the icon selector). The difficulty is not in writing the thing, but in making it so that it's *easy* to understand and use.
(b) And the single most frightening thing for me... Dealing with the aftermath of being able to create membergroups for anything. Basically, from my experience on Noisen, I know that people aren't going to spend their days creating membergroups, but if they end up doing it, it could easily break Wedge if not handled correctly. Do you remember when Facebook had a limit on how many friends you could have? I think it was 5000. It was a lot though, and I doubt any forum would be penalized by having such a high limit on the number of friends. I'm still going to assume that 10k users are going to add Mike42 to at least one of their membergroups, and Mike42 is going to add 10k users to his own 'friends' group (reciprocal friend additions -- that'd be asynchronous in Wedge, i.e. not mandatory, unlike SMF.)
So, we have a members table where the additional_groups field for Mike42 contains 10k comma-separated group IDs... Which probably makes it even impossible to store additional_groups into a TEXT field. (I guess MEDIUMTEXT would do...)
Even then -- it's going to kill performance, whatever we do about it. So we need 3NF for membergroups too. We discussed it at length but, yet, nothing has come of it. I'm getting wary of it, Pete is getting wary of it... I even recently read an old discussion on sm.org where Pete (yes, you Pete :P) actually discussed how 3NF could kill performance if table joins were used everywhere.
Now we have 3 ways of dealing with this... Either we just set a (relatively) low limit on the number of people you can put into a custom membergroup, and/or number of groups you can be put into, in which case I guess staying with the current SMF way of doing things is all right, or we add 3NF and still keep the additional_groups field and up the limit (but not too much), or we do it entirely 3NF and get rid of additional_groups, get rid of any limits and scream at the performance issues later...
122
Features / Things to do before the Mayan apocalypse: floating topics
« on April 20th, 2012, 10:36 AM »
(See the 'general' topic for details on the purpose of these topics...)
- Floating topics: again that issue... It's something I was very adamant to do when I started work on Wedge. As a reminder: being able to specify a topic type that would be beyond just 'topic', such as 'gallery item'... I guess I kinda lost myself in it for two reasons.
The first is that I also wanted to (and actually started to implement, long ago) have boards be 'floating' as well... Meaning a board can be a blog (which is already done as you can see), or a website (I have yet to start work on this but basically the main difference with a blog is the message index). From that point on, topics change their nature based on what the board is. So at some point I considered simply adding 'gallery album' to the board types. Which absolutely makes sense when you think about it... And I kinda let go of my 'floating topics' concept in the meantime.
What happened after that, is that tumblr showed up, with their 'post types', and WordPress took their idea too. "Hey!", I thought. "That's my floating topic idea!"... Well, it's not like it was the most original idea in the world anyway (I have plenty of original ideas, many of which found their way into the Wedge codebase, but I'm not calling dibs on every single good idea :P), but at that point I started to wonder what was best... Which is possibly why I just left it aside. If I'm going to be 'realistic' in my targets, I think I should stick to 'floating boards' from now on. There are always ways to make a meta-board in the future (hey, that's a floating board item too :P) that would reunite all of its sub-boards' topics into the message index anyway...
- Floating topics: again that issue... It's something I was very adamant to do when I started work on Wedge. As a reminder: being able to specify a topic type that would be beyond just 'topic', such as 'gallery item'... I guess I kinda lost myself in it for two reasons.
The first is that I also wanted to (and actually started to implement, long ago) have boards be 'floating' as well... Meaning a board can be a blog (which is already done as you can see), or a website (I have yet to start work on this but basically the main difference with a blog is the message index). From that point on, topics change their nature based on what the board is. So at some point I considered simply adding 'gallery album' to the board types. Which absolutely makes sense when you think about it... And I kinda let go of my 'floating topics' concept in the meantime.
What happened after that, is that tumblr showed up, with their 'post types', and WordPress took their idea too. "Hey!", I thought. "That's my floating topic idea!"... Well, it's not like it was the most original idea in the world anyway (I have plenty of original ideas, many of which found their way into the Wedge codebase, but I'm not calling dibs on every single good idea :P), but at that point I started to wonder what was best... Which is possibly why I just left it aside. If I'm going to be 'realistic' in my targets, I think I should stick to 'floating boards' from now on. There are always ways to make a meta-board in the future (hey, that's a floating board item too :P) that would reunite all of its sub-boards' topics into the message index anyway...
123
Features / Things to do before the Mayan apocalypse: general
« on April 20th, 2012, 10:35 AM »
Okay, I was going through our to-do-lists and so on... And I'm a bit upset that there are so many things that I want to be done with, and are either barely implemented, or not at all...
I'm not going to list Pete's fave areas (plugins etc), so it's really just about the things I personally want to have for the Beta version (i.e. possibly post-alpha, but preferrably pre-alpha.)
- Blogs (1): need to implement tags (if I re-use my Noisen codebase, it's not going to take long but maybe it'd be better to have a 3NF implementation rather than my limited tag field in the topic table...),
- Blogs (2): need to finish the message index layout (currently it still looks too much like a topic index... needs to be closer to what I did at http://nao.noisen.com), things like that.
- Gallery: well, there's the delicate issue of using AeMe to handle attachments... Frankly, as I said before, this isn't going to be in beta, or even in gold, but I'm still considering it for Wedge 2.0, as long as I write a quick converter inside the admin area. This isn't my priority though... Heck, we could even 'get away' with implementing an attachment viewer inside the gallery area. :)
- Custom boards: ability for users to create their own boards, or blogs. This one shouldn't be hard to implement. It's already in the Noisen codebase and only needs some tightening... Mainly, separating the UI from the Admin area and move it to the Profile area (which would give us yet another opportunity to rename it to 'Account area'...)
I think I'm done for now... I may have forgotten stuff. I have two more items to discuss but they're so big, I'll create two separate topics
Please discuss any items you want in this list.
I'm not going to list Pete's fave areas (plugins etc), so it's really just about the things I personally want to have for the Beta version (i.e. possibly post-alpha, but preferrably pre-alpha.)
- Blogs (1): need to implement tags (if I re-use my Noisen codebase, it's not going to take long but maybe it'd be better to have a 3NF implementation rather than my limited tag field in the topic table...),
- Blogs (2): need to finish the message index layout (currently it still looks too much like a topic index... needs to be closer to what I did at http://nao.noisen.com), things like that.
- Gallery: well, there's the delicate issue of using AeMe to handle attachments... Frankly, as I said before, this isn't going to be in beta, or even in gold, but I'm still considering it for Wedge 2.0, as long as I write a quick converter inside the admin area. This isn't my priority though... Heck, we could even 'get away' with implementing an attachment viewer inside the gallery area. :)
- Custom boards: ability for users to create their own boards, or blogs. This one shouldn't be hard to implement. It's already in the Noisen codebase and only needs some tightening... Mainly, separating the UI from the Admin area and move it to the Profile area (which would give us yet another opportunity to rename it to 'Account area'...)
I think I'm done for now... I may have forgotten stuff. I have two more items to discuss but they're so big, I'll create two separate topics
Please discuss any items you want in this list.
124
Features / New suffixes for skin files...
« on April 18th, 2012, 11:41 PM »
So, as I suggested elsewhere, I (locally) added support for a few new suffixes.
I'm asking for feedback about the concept. Is it worth including in Wedge?
- index.admin.css: only gets added to the CSS file if viewer is an admin.
- index.mod.css: only gets added if viewer is a local moderator.
- index.custom.css: this one already existed, so it doesn't change anything... but I also added:
- index.local.css: (maybe 'index.custom-local.css'?) only gets added if the file is located precisely in the folder of the current skin, i.e. ignore it if showing an inherited skin.
The last one I felt was needed because one my want to customize a few graphics in a specific skin, and yet still be able to inherit it without having to reset the changes caused by the index.custom.css in yet another index.custom.css file...
What do you think?
I'm asking for feedback about the concept. Is it worth including in Wedge?
- index.admin.css: only gets added to the CSS file if viewer is an admin.
- index.mod.css: only gets added if viewer is a local moderator.
- index.custom.css: this one already existed, so it doesn't change anything... but I also added:
- index.local.css: (maybe 'index.custom-local.css'?) only gets added if the file is located precisely in the folder of the current skin, i.e. ignore it if showing an inherited skin.
The last one I felt was needed because one my want to customize a few graphics in a specific skin, and yet still be able to inherit it without having to reset the changes caused by the index.custom.css in yet another index.custom.css file...
What do you think?
125
Bug reports / Mark post unread
« on April 14th, 2012, 10:05 AM »
Bug: when clicking mark unread in a topic, it should mark the page as unread. Not the whole topic.
126
Bug reports / Pretty URL remarks
« on April 10th, 2012, 03:28 PM »
So... Support for pretty URLs is pretty solid, but I still had an issue with Wedge trying to re-parse URLs that were already parsed, and sometimes breaking them as a result.
This turned out to be due to the way I implemented my 'index.php' removal code (which, BTW, is an optional feature). Because $scripturl immediately ignores the filename, the pretty URL regex thus searches for any boardurl and will transform them.
I fixed it by instead doing the transform *after* pretty URLs are handled. (Currently it's done within the PURL code block but I'm not sure this should be associated with them -- one might want to just get rid of index.php without systematically transforming URLs...)
This adds a new problem. Because it's now done through a basic str_replace, I have no way to 'control' how index.php is removed from the page -- could be within a non-linked URL, for instance. Or whatever.
My belief is that if you want to remove index.php from your URL, you will want to remove it from ANY place on the page, even if it's not intended as being transformed. Making it a no-brainer to apply the technique I just devised.
I'd like some opinions on this.
This turned out to be due to the way I implemented my 'index.php' removal code (which, BTW, is an optional feature). Because $scripturl immediately ignores the filename, the pretty URL regex thus searches for any boardurl and will transform them.
I fixed it by instead doing the transform *after* pretty URLs are handled. (Currently it's done within the PURL code block but I'm not sure this should be associated with them -- one might want to just get rid of index.php without systematically transforming URLs...)
This adds a new problem. Because it's now done through a basic str_replace, I have no way to 'control' how index.php is removed from the page -- could be within a non-linked URL, for instance. Or whatever.
My belief is that if you want to remove index.php from your URL, you will want to remove it from ANY place on the page, even if it's not intended as being transformed. Making it a no-brainer to apply the technique I just devised.
I'd like some opinions on this.
127
Features / timeformat annoys me...
« on April 3rd, 2012, 01:56 PM »
Here are a few things I'm looking into...
- Looks like passing an %e to strftime() will return " 1" in case you're on the first of a month, instead of "1". I have no idea why PHP is adding the leading space. It's okay in most cases, but in French the number comes first, so if you show the date (like this), you will get ( 1 avril) instead of (1 avril). (Well, actually it should say "(1er avril)" to be proper French, and that's actually in the Noisen codebase, but I never got around to find a *QUICK* way to do it that would also be usable by other languages, rather than just French....)
- Speaking of timeformat(), it's called every time a date is calculated on the page. Meaning it's called a lot on most pages...
I was thinking, wouldn't there be a way to simply cache *for the duration of the page load* (e.g. a static variable) as much data as we can...? Because redoing the calculations is a bit silly if you ask me. Heck, we could even store the last calculated date, determine whether it has the same characteristics, and refuse its time format...
- Generally speaking, timeformat() is a real mess to begin with. It has so much code... I'm pretty sure there are simpler ways to implement this.
- Pete, what about your changes to the admin area...? I've been postponing the moving of admin files to their own folders because you told me you had something on the backburner... (Not that it's urgent or anything, though.)
- Looks like passing an %e to strftime() will return " 1" in case you're on the first of a month, instead of "1". I have no idea why PHP is adding the leading space. It's okay in most cases, but in French the number comes first, so if you show the date (like this), you will get ( 1 avril) instead of (1 avril). (Well, actually it should say "(1er avril)" to be proper French, and that's actually in the Noisen codebase, but I never got around to find a *QUICK* way to do it that would also be usable by other languages, rather than just French....)
- Speaking of timeformat(), it's called every time a date is calculated on the page. Meaning it's called a lot on most pages...
I was thinking, wouldn't there be a way to simply cache *for the duration of the page load* (e.g. a static variable) as much data as we can...? Because redoing the calculations is a bit silly if you ask me. Heck, we could even store the last calculated date, determine whether it has the same characteristics, and refuse its time format...
- Generally speaking, timeformat() is a real mess to begin with. It has so much code... I'm pretty sure there are simpler ways to implement this.
- Pete, what about your changes to the admin area...? I've been postponing the moving of admin files to their own folders because you told me you had something on the backburner... (Not that it's urgent or anything, though.)
128
Test board / Test topic...
« on March 29th, 2012, 06:49 PM »Hmm.
Even though it is definitely set to 'quoted=optional' in the database..]]>Test..
129
The Pub / Bloc Madness
« on March 29th, 2012, 11:25 AM »
Follow up to -- http://wedge.org/pub/6271/logo-madness/msg276613/#msg276613
(Splitting the topic because it evolved into a heated discussion with Bloc.)
Okay... Are you implying you're leaving for now, or leaving forever? I'm quite weary after all of the Bloc stories. (And you know how ridiculous it became after a while.)
*WHAT is it* with saying things like that every time someone challenges your thoughts?
Seriously. Get over it, guys. Pete is harsh, and I'm harsh. If we'd been "outta here" every time Pete or I refuted each other's arguments, I think that Wedge would have been abandoned 20 times over!
If I can't tell people what I think, then should I stop speaking at all??
This isn't what a "forum" is for. A forum is for talking. If you can't talk for fear of driving people into leaving, then you don't use the forum any longer.
If you think I'm too harsh, then say it clearly.
Anyway. Let me explain again, now that I'm on my PC... I settled for 'Consul-tant' even though it had more black letters than 'Wedge-ward'. It may not be obvious, but in my mind, the more black letters, the 'higher' the rank. I gave up on this concept to please you because you complained about the 'Co' thing and I couldn't find myself to go for Con or Cons. And 'Consu' could be seen as 'Consumate' or 'Consumer', which doesn't carry a nice meaning either way. So I went for 'Consul' which is basically an ambassador (for Wedge), and look at you -- getting pissed off because I'm asking you WHY it's STILL not good enough for you.
If you don't like your badge, I can remove it if you want. It's just a matter of putting your Consultant group as Additional instead of Primary group.
(Splitting the topic because it evolved into a heated discussion with Bloc.)
Okay... Are you implying you're leaving for now, or leaving forever? I'm quite weary after all of the Bloc stories. (And you know how ridiculous it became after a while.)
*WHAT is it* with saying things like that every time someone challenges your thoughts?
Seriously. Get over it, guys. Pete is harsh, and I'm harsh. If we'd been "outta here" every time Pete or I refuted each other's arguments, I think that Wedge would have been abandoned 20 times over!
If I can't tell people what I think, then should I stop speaking at all??
This isn't what a "forum" is for. A forum is for talking. If you can't talk for fear of driving people into leaving, then you don't use the forum any longer.
If you think I'm too harsh, then say it clearly.
Anyway. Let me explain again, now that I'm on my PC... I settled for 'Consul-tant' even though it had more black letters than 'Wedge-ward'. It may not be obvious, but in my mind, the more black letters, the 'higher' the rank. I gave up on this concept to please you because you complained about the 'Co' thing and I couldn't find myself to go for Con or Cons. And 'Consu' could be seen as 'Consumate' or 'Consumer', which doesn't carry a nice meaning either way. So I went for 'Consul' which is basically an ambassador (for Wedge), and look at you -- getting pissed off because I'm asking you WHY it's STILL not good enough for you.
If you don't like your badge, I can remove it if you want. It's just a matter of putting your Consultant group as Additional instead of Primary group.
130
Bug reports / BBCode trimming issues?
« on March 21st, 2012, 10:16 AM »
So, I've never been familiar with the 'trim' (trim_wspace in the database) parameter of bbcodes.
The Noisen codebase automatically trims whitespace before and after quotes, because I hate it when people don't insert any whitespace and we end up with quotes touching the rest of the text, so I trimmed everything out and added extra margins to compensate.
Now, with Wedge I didn't add this code because I'm trying to stay away from 'hacks'... After discussing with Pete, it seemed like the obvious answer was to change the trim_wspace value of quote tags from 'none' to 'outside' (meaning, 'trim any whitespace outside the tag').
So, I did that... And it still didn't work. Which brings us to 2 bugs.
1/
I managed to find out that whitespace was just ignored, because Aeva Embedding is active, which adds noae tags around quotes right when they're being processed. So it will see another tag around it, and will consider there are no extra spaces, which is wrong. Possible fixes:
a) account for being possibly there in the regex. This is what I'm doing for now. It seems to be working just fine, but I'm a bit worried it might make the regex slower. So, I added a ^ right before the noae test, so that it only does once, and ignores it if it fails. This should now make the regex actually faster than in SMF... Much faster, even, because it looks like the SMF code is actually looking for the entire rest of the string...?! Heck, this can't be possible, because that would be an awful bug. I just realized I'm not that well versed into BBC parsing these days. Used to be... But I forgot most of it.
b) Right when adding the noae tags, do the trimming at this instant. Because we know that a quote has to be trimmed, we can do that. However, if an admin decides that they don't want trimming, it'll still occur even if disabled in the BBC DB table... Hmm.
2/
Okay, I checked and double-checked, and can't seem to find the code that will trim outside spaces BEFORE the quote... There are two such tests, but it seems they both account for whitespace AFTER the tag... WTF?! If that's the case, then isn't it a bug, too...?
Also, I figured that it would also make sense to apply outside trimming to other 'special' block tags like code, and possibly media. What do you reckon[1]?
The Noisen codebase automatically trims whitespace before and after quotes, because I hate it when people don't insert any whitespace and we end up with quotes touching the rest of the text, so I trimmed everything out and added extra margins to compensate.
Now, with Wedge I didn't add this code because I'm trying to stay away from 'hacks'... After discussing with Pete, it seemed like the obvious answer was to change the trim_wspace value of quote tags from 'none' to 'outside' (meaning, 'trim any whitespace outside the tag').
So, I did that... And it still didn't work. Which brings us to 2 bugs.
1/
I managed to find out that whitespace was just ignored, because Aeva Embedding is active, which adds noae tags around quotes right when they're being processed. So it will see another tag around it, and will consider there are no extra spaces, which is wrong. Possible fixes:
a) account for being possibly there in the regex. This is what I'm doing for now. It seems to be working just fine, but I'm a bit worried it might make the regex slower. So, I added a ^ right before the noae test, so that it only does once, and ignores it if it fails. This should now make the regex actually faster than in SMF... Much faster, even, because it looks like the SMF code is actually looking for the entire rest of the string...?! Heck, this can't be possible, because that would be an awful bug. I just realized I'm not that well versed into BBC parsing these days. Used to be... But I forgot most of it.
b) Right when adding the noae tags, do the trimming at this instant. Because we know that a quote has to be trimmed, we can do that. However, if an admin decides that they don't want trimming, it'll still occur even if disabled in the BBC DB table... Hmm.
2/
Okay, I checked and double-checked, and can't seem to find the code that will trim outside spaces BEFORE the quote... There are two such tests, but it seems they both account for whitespace AFTER the tag... WTF?! If that's the case, then isn't it a bug, too...?
Also, I figured that it would also make sense to apply outside trimming to other 'special' block tags like code, and possibly media. What do you reckon[1]?
| 1. | I love this word. It's close to the French for "recognize", meaning that for years I misunderstood it... I think the first time I realized my mistake was when watching a Harry Potter movie with French subtitles and being surprised at the translation for the word. |
131
Features / Duplicate post detection?
« on March 20th, 2012, 04:22 PM »
Silly idea or not?
Instead of disabling the submit button we could check at post time the last post by the same author in the same topic or board. If it has the same contents, just skip posting it and return to the topic.
Would solve problems that occur when clicking submit and the server is down at that precise moment.
Instead of disabling the submit button we could check at post time the last post by the same author in the same topic or board. If it has the same contents, just skip posting it and return to the topic.
Would solve problems that occur when clicking submit and the server is down at that precise moment.
132
Features / Brave new world
« on March 16th, 2012, 12:43 AM »
So... A thing happened, and then another, and my plans to publish Wedge today were scrapped. So, I uploaded the website to a temp folder, installed it, fixed a few other bugs, then left it aside for now because it's unrealistic to expect the Wedge team to upgrade Wedge.org to Wedge precisely before going to bed, ah ah. We need to make sure it works for everyone.
It will STILL make it on March 15... Just that it will be March 15, *Hawaii time* :P
Ah well. If you just can't wait anymore, here's a little something to help you wait until next morning (if you're in Europe like us.) A small screenshot of the new default skin, Weaving. And yes, this is the first time it's made public.
Hope you like it! I'm off to bed. Deserved a good (but short) night's sleep.
It will STILL make it on March 15... Just that it will be March 15, *Hawaii time* :P
Ah well. If you just can't wait anymore, here's a little something to help you wait until next morning (if you're in Europe like us.) A small screenshot of the new default skin, Weaving. And yes, this is the first time it's made public.
Hope you like it! I'm off to bed. Deserved a good (but short) night's sleep.
133
Features / Multiple default skins?
« on March 15th, 2012, 08:55 AM »
Another minor feature that I've been thinking of for a few days, is the ability to allow for multiple default skins.
It's easy really.
- Default skin for guests
- Default skin for new members
Until now, easy to grasp... But even easier:
- Default skin for mobile devices
This would allow for Wedge to use the 'Wireless' skin by default on iPhones and company, and admins would be able to install Dragooon's Wedge4Mobile theme, and then choose his theme as the default mobile skin as a replacement for Wireless, if they think it's too limited in terms of usability.
I'm sure we could also think of other opportunities to set a different default skin, but for now let's focus on mobile.
Yesterday I went to sm.org, wondering if someone had already thought of it, and indeed emanuele posted a similar mod last month, so I thought it was worth mentioning, just in case I get accused of stealing an idea -- I did think of it by myself, but I also acknowledge that I'm now aware there's a working implementation at SMF :P
I was curious and looked at the detection code (wanted to see if it differentiated between iOS devices and used any tricks to retrieve resolution, such as Ajax polling or a small redirection via JavaScript -- not so much), it's an open-source external script that's being used, I'm just surprised that it can take 32 kilobytes just to detect a mobile device... Oh my :lol:
Wedge does it in a single line, but obviously it's certainly not as extensive!
It's easy really.
- Default skin for guests
- Default skin for new members
Until now, easy to grasp... But even easier:
- Default skin for mobile devices
This would allow for Wedge to use the 'Wireless' skin by default on iPhones and company, and admins would be able to install Dragooon's Wedge4Mobile theme, and then choose his theme as the default mobile skin as a replacement for Wireless, if they think it's too limited in terms of usability.
I'm sure we could also think of other opportunities to set a different default skin, but for now let's focus on mobile.
Yesterday I went to sm.org, wondering if someone had already thought of it, and indeed emanuele posted a similar mod last month, so I thought it was worth mentioning, just in case I get accused of stealing an idea -- I did think of it by myself, but I also acknowledge that I'm now aware there's a working implementation at SMF :P
I was curious and looked at the detection code (wanted to see if it differentiated between iOS devices and used any tricks to retrieve resolution, such as Ajax polling or a small redirection via JavaScript -- not so much), it's an open-source external script that's being used, I'm just surprised that it can take 32 kilobytes just to detect a mobile device... Oh my :lol:
Wedge does it in a single line, but obviously it's certainly not as extensive!
134
Features / The Regular Members group
« on March 15th, 2012, 08:47 AM »
I've always had a love/hate relationship with the Regular Members membergroup.
In fact, I was so wary of it for many years, that I had hardcoded the Register page to automatically put new members into a custom membergroup, so that I wouldn't have to deal with that group. Little did I know at the time that it was simply a convention for a virtual membergroup numbered '0'.
Now, because if you apply a primary membergroup to someone, they will lose their '0' group membership, they might lose permissions that were only given to regular members. This might be 'as designed', but it isn't terribly obvious in the permissions section that 'regular members' doesn't ENCOMPASS all other groups, and that instead it represents group 0.
So, I modified the Profile template to actually show a Help icon next to Primary Membergroup, with a popup explaining what it does and what happens if you assign something to it.
Now, I'll commit it this way because it took me half an hour of my time and I'm the doc doc, but I was thinking... How about we simply list Regular Members as a 'normal' membergroup, i.e. in Primary Membergroup we list "Regular Members (default)", and in Additional Membergroups we list the same, but hidden by default, and only shown if the Primary membergroup isn't 0...?
I'm sure we can add '0' to the list of additional membergroups, can't we...?
In fact, I was so wary of it for many years, that I had hardcoded the Register page to automatically put new members into a custom membergroup, so that I wouldn't have to deal with that group. Little did I know at the time that it was simply a convention for a virtual membergroup numbered '0'.
Now, because if you apply a primary membergroup to someone, they will lose their '0' group membership, they might lose permissions that were only given to regular members. This might be 'as designed', but it isn't terribly obvious in the permissions section that 'regular members' doesn't ENCOMPASS all other groups, and that instead it represents group 0.
So, I modified the Profile template to actually show a Help icon next to Primary Membergroup, with a popup explaining what it does and what happens if you assign something to it.
Now, I'll commit it this way because it took me half an hour of my time and I'm the doc doc, but I was thinking... How about we simply list Regular Members as a 'normal' membergroup, i.e. in Primary Membergroup we list "Regular Members (default)", and in Additional Membergroups we list the same, but hidden by default, and only shown if the Primary membergroup isn't 0...?
I'm sure we can add '0' to the list of additional membergroups, can't we...?
135
The Pub / Wap is that?
« on February 10th, 2012, 07:16 PM »
As we recently discussed, Pete and I -- we're considering removing Wap2 support from Wedge.
I already removed iMode and Wap1, and improved Wap2 a (tiny) bit by giving it more styles.
However, there are still issues with this:
- it's really a limited subset of a SMF/Wedge forum... Basically, you can only view posts and PMs, and answer them.
- Google might still crawl your mobile page and offer links to them instead of your desktop site, even on its regular version. Wedge improved that, but it's still not completely flawless.
The main advantages of Wap2 are:
- it's definitely faster than a regular page. The only other way to quickly view an entire topic is the Print link. (Which is arguably much better at that task.)
- it works on very old non-smart mobile phones. Like mine. But basically, the main point is that people who actually browse the web with their phone have LONG since purchased an iPhone or similar.
So we think it could go, but we're just not sure. It's time for Wap2 to speak, or you shall remain silent forever! :geek:
I already removed iMode and Wap1, and improved Wap2 a (tiny) bit by giving it more styles.
However, there are still issues with this:
- it's really a limited subset of a SMF/Wedge forum... Basically, you can only view posts and PMs, and answer them.
- Google might still crawl your mobile page and offer links to them instead of your desktop site, even on its regular version. Wedge improved that, but it's still not completely flawless.
The main advantages of Wap2 are:
- it's definitely faster than a regular page. The only other way to quickly view an entire topic is the Print link. (Which is arguably much better at that task.)
- it works on very old non-smart mobile phones. Like mine. But basically, the main point is that people who actually browse the web with their phone have LONG since purchased an iPhone or similar.
So we think it could go, but we're just not sure. It's time for Wap2 to speak, or you shall remain silent forever! :geek: