In reply to adrasteia1 (msg # 50):

Database change is simple, I can just add a new field for "parent tab", or "thread priority".  Spry (not that I'd use a discontinued framework) will still have the issue I've mentioned -- if we're just switching visible regions on the page then I have to load (some or all) information for every thread tab/priority from the database.


Sure as heck wouldn't.. but then again there would be a performance impact if users now had to start loading different pages (tabs) more often.  Which is the lesser evil?

The simultaneous post detection wouldn't help as that only checks the thread you're posting to.

The only other method I can think of for loading one section of information for a page without loading all of it (thus cutting down on server load) might be frames. I don't like that idea.

I'm not sure what to suggest in the place of Spry. It's the only one I know and have used. I heard it got discontinued recently. There must be other alternatives that do the same thing.
This message was last edited by the user at 02:54, Thu 28 Feb 2013.

This is an absolutely brilliant idea and I'm delighted to see that it might be implementable without too much trouble. It also makes sense to incorporate all the existing tabs (scratchpad and the like) so everything uses the same basic layout and system. Even better that GM can change the tab headings. Overall I think this idea will keep rpol looking streamlined and minimal even in large games (which, frankly, currently do not present well on rpol).

Upon further reflection and research, doing the dynamic hide/show (that doesn't require a new page to be loaded) relies on javascript, so I'll forgo that idea and each tab will have to load a new page when the tab is clicked on.

So that means you're going to go ahead with it then? :)

Just because I've ruled out an option doesn't mean I'm forging ahead with another!  It's also too late to put into the current version, that's been in the final stages of getting ready since November.

To be honest I'd been thinking of ways to add subsections to a game, which would present differently to tabs but do much the same thing, though I was hoping to be able to give subsections the ability to have their own subsections.

... and that's even better !   Love that ! :>

I'm absolutely and completely fine with loading each section as you click on the tab/link ... to be honest I don't have that many Notices or OOC threads, so there won't be many on those pages when they load.

Couple of design questions:

1) Given the tabs/links will be named by the GM, will you have to make it a selectable GM preference which of the tab/links is presented first when the user first enters the game ?

2) Will 'thread type' (Notice, or other GM named tabs) be selectable from a drop down list when the GM creates a new thread ?  Can this be later Edited (in the same way you can change Group, it'd be great/wonderful/a must to be able to change thread type ... I'm thinking here that personally I'd create an "Archived" tab/link, and use that for old adventure paths where the threads are all closed, keeping only the current adventure path under my "Game" link ... which would minimise the threads in there and cut down on load time/server load.

Numfar ... do the dance of joy !

Might be getting a bit ahead of ourselves here... I'd really like to get the current version out before we start making such a large change (both programatically and visually).

If we are going to change the way threads are grouped together (notices and normal threads did do this, but there was only two tiers) then we should figure out which option is preferred, even though the tabbed layout is by far the favourite at the moment.

Hm, an accordian layout might be another option and it might only mean loading one page for the main game screen. It could hide all sections by default until they're clicked on and you could open more than one section at a time. It might not look as organised as tabs though. Just an additional idea.

Things to consider:

Tabs might run the risk of making it easier to miss stuff.  Don't open the right tab, and you don't see the post that's waiting for your reply.

Additionally, how do the tabs affect the main menu NMI?  If I open the OOC tab and read a thread, does that cancel the NMI on the main page, even if there are new messages in the other tabs?

Tabs or subsections would work by a thread being owned by a tab/subsection.  When we list the top 25 threads then it's be just that, but also where the owning tab/subsection/whatever equals the one we're on.  NMI indicators wouldn't change as the way posts are made to thread isn't changed, it's just how they're visible that's different.  A NMI wouldn't be cleared until you've read the newest thread, wherever it's hidden.

There'd had to be some way of notifying users of posts in other groups, which would involve the (hopefully small) overhead of checking grouping-mechanism you're not on, and then doing something like colouring or putting a number next to the grouping-mechanism.

Perhaps a similar way to Wordpress, where it puts a small number in a circle beside the tab or panel to show the number of new messages? Or would that inadvertantly complicate things? Highlighting it though would show there's something new to be found there, and might be easier to implement. I really don't know - it's beyond my knowledge to say 'how' at this stage.

Would this use PHP or something like Ajax?

Jase - Partially off-topic but related, PMs are exactly like the threads we're talking about, is there anyway to indicate how many messages are marked as UNREAD? That may help the missing of a thread for this discussion, and could also be useful for PMs (As a GM, I've missed the fact I have players in a discussion in a PM in the 'other' inbox, since it's buried towards the bottom, after all my NPCs inboxes.)

Having a method to know I have x unread threads marked would alleviate the issue across the board for both problems. Thoughts?

PMs aren't, though - they're apparently even coded differently.


The coloring is something we're all already trained for, so I think if the section's name just highlights in red while it has new messages in it, that should do it.  And if it is reloading pages everytime you go into a thread, I assume it could be checking those, also, each time.  How much impact this will have processing-wise I have no idea, except that I think Skald has a point - for the most part, people will be going into the main game area, and then maybe into the OOC.  Posting rates probably aren't going to suddenly jump sixfold, so the number-of-page-loads shouldn't go up that much either.

...Admittedly, in some games, I can see people sorting this by actual "areas in the game", which might have a different effect.  But I think most will either not really use this, or end up with the kinds of sections Skald first proposed.  At least, that's what my horoscope predicts.

Um.  Well.  Those weren't its exact words, but, you know.  Prophecy always requires some creative interpretation.


On a related note - right now if you click on that, it takes you straight to the Game Screen if it was red, and the Private Messages if it was blue-or-purple, if you click on the number instead of the game title.

Can that be preserved?  Would clicking on a red number take you straight to the tab/subsection that has a new message?  If so, how can that be prioritized?  When Skald had first written it I'd assumed we could just agree on the list, like, it could go Notices > Info > Game > OOC, but if the GMs can name them themselves, that makes this harder.  Just in the order they're set up on the screen, maybe?  Or do we need to give that up?  If you go into a game and there aren't new messages - say, you read them earlier and are now coming back to reply - which tab will it open?

I think that naturally, psychologically, people are going to want to put a "Notices" tab `in front' - so that it's farthest to the left - but whatever their "Game" tab is called is going to be where people will want to go most.  Could there be a chance to set one tab as Primary, and default to whichever is `first' if none are tagged for that?

Also - how will it interact with Thread Groups?  If a tab has only Groups that a player isn't part of, will they not see the tab at all?  (I'm going with "tab" because it's shorter than "subsection")

Ajax is client-side, and relies on javascript (that's what the j stands for) to dynamically render (or re-render) sections of the page.  It's reliance on javascript makes me reluctant to use it.  RPoL still works without javascript, albiet with slightly reduced functionality.  If we used Ajax then I'd probably have to create a completely separate site (fetching the same data) for the simpler hand-held devices, and that's not something I can do alone.  I want to improve the rendering for such devices, but a separate site is too much work for one person.

Ajax, being client-side, still requires something server-side to render the page in the first place; something like ASP, PHP, Perl or ColdFusion.

So your question doesn't actually make sense with the "or" there, it'd make more sense as an "and".

But the answer to your question is that section of RPoL is still in Perl, so it'd be in that.  Ajax, due to the fact I ruled out using javascript a dozen or so messages ago, wouldn't be used.

Anyhoo, wandering way too much off topic here.



Alas PMs aren't the same as the game threads.  Similar, yes, but not exactly like.  While I'm opening the index for game threads and looking through them it's not much extra overhead to fetch information on the threads in the other grouping-mechanism.  To grab how many private threads you have unread would require me to list every private thread you've got and compare them against your read/unread data; that doesn't have any real overhead when we're listing your PMs, we're already listing them, but to go through the PM list for each player every time they're on the front game screen is too much.


I think we're worrying too much about the polish without concern for the core functionality.

We've had a few alternate thread-grouping-mechanisms suggested, but everyone seems to be fixated on the tabbing mechanism.  Don't get me wrong, it's a great idea, but is there a better way to do it?  If we're going to go to all the effort of radically changing the way threads are grouped, shouldn't we make sure it's the best way?

With that in mind I'm going to continue to use "grouping-mechanism" instead of "tabs" until we can agree on the best grouping mechanism!


Good question.  A grouping-mechanism would be a way of doing exactly that, of grouping threads together.  Groups, as we currently use them, are a way of limiting who has access to the thread.  They do different things - Notices work fine with groups, and notices are a way of grouping threads together.  Imagine notices were on a different tab already, that's how it'd work.  There's nothing stopping a notice being only for group xx at the moment, that's how it'd work going forward.


One.. possibly large.. problem I've thought of is in the way the new message indicator works.  It compares the date of the last thread you can see compared with the most recent thread you have read.  That's how the NMI on the front screen (and stickylist) works.

Once you go into the game and are listing the threads it can do a more thorough investigation, and does that by comparing the cookies you have (plus the database record of the most recent thread you have read) to give individual read/unread indicators on each thread.

Now the simple and most efficient way to check threads within our other grouping-mechanisms would be to compare the newest thread post in each of those tabs and compare it to the most recent thread you have read.

However if you go into a game and there's new threads in five grouping-mechanisms, once you've read one of the threads in one of the grouping-mechanisms, the most recent thread you have read might now be greater than some or all of the newest threads in the other grouping-mechanisms, so the NMI indicators that were on for them would now be off, without you having read them.

In a nutshell -- once you read a thread in one of the grouping-mechanisms, the NMI indicator on the other grouping-mechanisms might turn off (will turn off if the thread you've read is newer than the most recent thread in each respective grouping-mechanism).

Could you have a notification flag for each group and say color the group name for instance, if unread messages within that group? Then check each of the group names to color the notification flag for the game?

I think for the game I co-gm a separate group for the notices would be sufficient. It would clear up enough threads so all active threads would be on the first page most of the time. Anything else would be ice cream.

---

What we could really use even more is a way to move pm's into groups say 1 group for each character(PC or NPC). That way after we can keep the number of pm's we have to troll through looking for new messages down to a more reasonable number. I was thinking of having both pm's as we get them now and a group that we could put them in but I'd take even changing the process so that each PC/NPC's pm's all went into their group as long as the group name would indicate a new pm message. Then we could easily scan the groups and spot those with the flagging, open or navigate into the group and find the message to read. Or, 3rd similar option, a way to expand and collapse the group of pm's as we have them now with some sort of flagging at the group level so that we could keep then collapsed by default, see the flagging for a new message for a character, open it up, read it, respond, and then collapse it again.

We could add a flag, but flags don't really work due to the ability for posts/threads to be deleted.  It really has to be a date comparison.  We could have a date record for each grouping-mechanism, but if we're allowing GMs to add/remove grouping-mechanisms, and also move threads between grouping-mechanisms, then that's going to have issues as well... not to mention require a blowout of the tracking data by # of grouping-mechanisms.


PMs could be reorganised... If something like tabs were used then we could have a private thread tab, which would take you to a list must like what's currently there, however we could then, using the same scheme, have tabs for each character (and hopefully (once I've considered the technical ramifications)) two more tabs; one for access requests and one for "other private messages".

Expanding/collapsing could also be done.. that would rely on javascript but it'd degrade nicely for those who didn't have it (or a device that doesn't support it).

H'mmm ... yes, I'm thinking you'd have to track date time stamp of most recently read thread in that group.

And you could have a notice thread (eg with character XP/HP details), OOC chat thread and game thread(s), not to mention PM threads, so that's four groups that might easily show NMIs, so there would definitely be more overhead than the current system.

The only other way I can see is if there was a sytem generated group called "New" or somesuch where all new threads were viewed, no matter what group they actually belonged to - so everyone would default to New to see any new game threads, OOC chatter, Notice updates or PMs, and once viewed they'd vanish from the New group and reappear under their correct group.

Initial date of last thread you can see vs most recent thread you have read check when you enter the game would determine which threads were to be identified as "New" and they'd stay "New" until read - ie reading a later thread wouldn't make earlier threads read as it does now.

And that way you'd only need to track NMI on the "New" group.

If you had no new threads to view then you'd just see all the group headers and would pick one to view the read posts.

I like that overall, but the access request usually ends up holding the bulk of character creation - which is often important later when you're talking to that person.  Having the RtJs grouped would be awesome, I think, for the mods, especially when they need to peek in on age verifications and whatnot - but as a GM, I'd much rather the RtJ still be grouped with the rest of that character's messages.

...Would it be possible, especially in this possible PM area, for a message to be available in more than one sub-group?  I suppose if a PM included multiple characters, this might already happen there -- so maybe you can make "RtJ" kind of like a character name flag that's automatically applied, behind the scenes, when somebody first creates an RtJ, so that that message shows up in the RtJ area and, once they have a character name assigned, there?  ...Assuming, of course, the technical ramifications all work out in the first place. grin


But that would have to somehow store it, on a message-by-message basis; at least for a short term, and possibly longer.  I think people would expect that to still exist if they exited the game and came back in.  Like, if you go into a game with ten new messages, read six of them, and then have to leave RPoL for a little while -- now it has to remember those four messages being New, plus adding anything that might come up new between then and the next time you log in... and I think ultimately this means adding a `read/unread' notice on each individual message for each individual player and that sounds like a lot.


How bad would it be if, once you went into a game, each sub-group was basically treated as a separate game?  The front-screen NMI could work just like it does now; then when you go into the game, the game-screen NMI's would work just like the front-screen NMI does now, but checking each sub-group in the game.  And then when you go into the sub-group, it would work like it does now when you go into the game itself?  If everything is like nested folders, where you have to basically `back out' to the Game Menu before going into a new Sub-Section, then I think that would even be `it'.  If it's more like tabs, where you can hop laterally, you'd probably need both processes happening when you went into a sub-group, so that it would read the one you're in now as it does now, but read the others as if they were separate games - matching the last time you read something in them with the last message posted, every time a page loads.

Hm.

What about the stickylist function?  That was developed just because it was somehow faster / easier to process than bringing up the whole main screen each time, wasn't it?  Is there something in that that might help here?

I'll admit I skimmed the last half a page, but this strikes me as a big deal.  If I get the gist of it, then...

I am in support of 'sub-forums' or 'folders' within a game.  Being able to post threads under the main game, OR create folders and put threads in those (or both), gets a big +1 from me.  I don't see the need for complicating that function any further.  How you visually determine how many threads and folders will display on the front game page, I don't know.  I do feel the need to be able to create threads without folders, just as the current system stands, if that was under question.  Likewise, any thread or forum should be 'sticky'-able.

If you were looking for a short-term fix, the new system as put forth in 1.9 works just fine.  Simply put stuff in a group no one is using, then filter to that group when you want it.  (If I understand those functions properly.)

Speaking of understanding functions, and reorganizing threads and games (and speaking of groups), how does the Archive function work exactly, and will it be needed/useful with this reorganization?  And on an unrelated note, I have wondered what the point of the Public group is, and how it differs from group 0.  But that's just me rambling about functions I don't see a use for.


In short, I support subforums/folders within games.

The Public Group can only be posted to by a GM, so it's handy for all those information threads (here's the game background, here's how to create a character, etc... ) that the GM wants people to be able to read, but doesn't want players posting in.

The Archive function locks the thread, and makes everything in it (including private lines) public.

Okay, so Public is exactly like Group 0 closed threads.  Seems redundant now, but if a restructure is in order, it might not be.  Food for thought.

Archives I can see a use for, cool.  Thanks for that, BBR.

In reply to jmkool (msg # 73):

No, public threads are visible by everyone, regardless of group membership.  Visitors can see public threads.

Group 0 threads are only visible to those players (and lurkers) with access to group 0.  Visitors can see group 0 threads.

Covered in the help - /help/?t=help&page=gamegroups.  Possibly to brush up on the information there so we don't continue to derail this.

Somewhere back there jase asked we consider the issue of how best to group threads, so without further ado ...

Tabs - obviously a few of us, and I'm including myself here, pounced on that option.  Probably cos we're all sitting using tabbed browsers so it was staring us in the face.

Links - exactly same functionality as tabs, just visually different - though perhaps more aesthetically pleasing as it fits in well with the rest of RPoL's layout.

Buttons - to my mind a bit chunky and still no different to tabs/links

Expandable - ie same as FAQ, click on a heading and those grouped messages appear below.  This one is growing on me, though sounds horribly hard to code (I'm sure fixed text as in the FAQ is a lot simpler !) though then again, perhaps actually loading everything at once but hiding bits of it will resolve other coding problems, as all messages will actually be on the same page ?

Over to the rest of you to brainstorm other options. :>

For what it's worth, and pending something thinging up something I like more, or the pointing out of the obvious flaws, my vote (in order, first best):

Expandable
Links
Tabs
Buttons

In order of preference:

Links
Tabs
Buttons
Just about anything else
Expandable

Links is a win, IMO, because it fits best with the style of most of the rest of the site.