Just wondering if anyone was working on a function where users are able to choose what blocks to turn on and off. We're looking for something found in this screen shot:

On each block, there's a little "X" where users can turn off and on blocks. I was thinking more in the line of having an advanced feature where users can choose which blocks, among many choices, to show. Anyone know of anyone else working on this?

Otherwise, can anyone comment on what features users and webmasters would need for this type of function? If there's no one working on this, I'd like to explore making it for Xoops...

-d

I've suggested this type of functionality for the whole blocks administration, which then could be extended to the front-end as well. But AFAIK no-one is working on this concretely, yet. I do know that the discussion about this feature is held at the sourceforge.net forums: http://sourceforge.net/forum/message.php?msg_id=2528763 for instance. Since this feature potentially has a lot of consequences for the way XOOPS sites are managed, and since they're part of the core, this should be thought out carefully before implementing it But, if you have the time and creativity to take this opun you, please feel free to explore with the rest of us how this can best be done

Herko

Hi Herko,

uPortal, a Java based portal engine does this. Maybe we can take a look at the code to see how the Java folks do it? In terms of UI, do you have any idea on what the admin should see and what the users should see? Should this function be part of the user profile?

On a side note, i really think the user profile section should be revamped. For instance, I think there should be a section called "My Page" where users obtain latest updated forum, news, whatever module; and are able to control a vast amount of information. I really think the current function of subscriptions (inbox notices) is too much like email, and I think email is a real crappy interface to juggle different kinds of information.

An example is dslreports.com. They have a section called my page, where users see have their activities updated on a single page.

For example, if you post on the forums, then there is a tab where it shows you whether someone has replied to your post. This happens without even subscribing. It helps users keep track of posts without having to do an extra step.

Another example is the "Favorite Forum" section where users can choose a forum to add to their favorites list. Any updates that are on the forum get updated in the "Favorites" tab.

I was thinking we can modify BopComments to do this. Then, all we would have to do is build in the block customization (user side) into a tab for a "My Page" function in Xoops.

I don't have a clue how we would go about doing this in the admin panel, but I'd be happy to explore the turning "on-off" blocks feature in the next couple weeks. If enough users participate, I think we can start an Alpha planning process and begin building this sometime in June. Reason: my users and my supervisors are crazy about customizable blocks.

This sounds great. I like the idea, if it is not an administrational nightmare - so knock yourself out

Some of what you look for about the user page is in the user profile now (5 latest forum posts/news/anything with a search feature, I think) but I agree that it could be expanded.

Favourite forums should be a newbb feature, I think (but a good one)

This is great. I have been always looking for.

I would help with no hesitation if it is kicked-off

For starters, I think we should work on revamping the user profile page, then move onto customized blocks. Advanced user profile is more important than customzied block IMHO. This will allows module devs to do really great stuff.

Any thoughts on the user profile UI? Should it look like BopComments or should it look like dslreports.
Bopcomments:


Dslreports: the pics above - tabs within the profile page.

Here's a list of modules to support for the user profile:
1) All Core modules
2) Agenda-x
3) IPB

Any other modules to support? Or is there a better way to go about making the profile page?

Favorite Forums
For favorite forums, all we have to do is add a button to each forum/category and name it "FF" or "Add FF" or "+/- FF" Whatever works best. Adding a forum to a favorite forum automatically lists updated posts. User chooses to see how many posts they can per favorite forum. Maybe this can be done in conjunction with the newBB release?

Any thoughts?

Maybe check with Skalpa - he is working on (AFAIK - or at least has it planned) how to make the user profile extendable on-the-fly and maybe he has some ideas for this kind of thing.

It would be best if the solution is a plugin solution and doesn't require you to update it everytime a new module is released.

OK, two things here that we need to keep separated, at least for now.

1st: the block enhancements. This is a very powerful feature, because it will add the ability for users to customise the block positioning from a list of available blocks. This means that at the user level, people can show, hide, and position blocks on a site. In my opinion, it goes too far to do this at the module level, like the current blocks admin. If a user has admin rights on visible blocks, the edit or admin link should be visible.
At the admin level, everything should be configurable: which blocks can be moved by which groups of users, and what the range of the movement is. Also, what blocks can be made visible by what users, and where they are allowed to place them. And if it is even possible for users to manage this themself.

Personally, I would *love* this feature, but to do this right, would take a LOT of work. Thus, I propose a phased implementation. First, make this work in the administration area. This is easy, because every user that goes there has full rights (so no need to check that). Also, the blocks are set for every group (like the curent blocks admin), but then visually. Basically, the blocks admin page, but then shown like my.netscape.com. Since this doesn't require database changes, this can be implemented in 2.0.x, or if that is too soon, 2.2 is not an issue.
The next phase, is to bring this control to the user end. This requires a LOT more work, as every user will have it's own blocks setting. This means queries, speed, caching, access issues and the best OO way of doing this need to be resolved. This will require some discussion and testing first

2nd item: the user profile. The same basic issues as above apply here. This is a very powerfull feature that has been on many people's wishlist for a long time. Including mine, of course. To do this right it would mean that the user profile is infinately extendible with module generated, user specific information and feedback. Very much like the examples you have shown (talunceford recently released a personal links module that is a great first step), every user can create as complete a 'personal subsite' based on his/her preferences and activities. History, bookmarks, profile, memberships, messages, albums, rights and personal page settings are just a few of the possibilities on the user side.
On the admin side, configurable setting access (what does the user control him/herself, and what does the admin control... warnings can't be hidden, for example) are important. To make this work, the user profile needs an interface modules can access to extend the profile with it's own information. How modules do this, and what the interface controls, are things that still need to be figured out, let alone implemented.

Here I propose a phased implementation as well. The first phase would be to make the current user profile partly dynamic (only that part that isn't required by the system and some oft-used modules). Those fields can be changed, new fields added, etc. This is a slim version of what we'd really want to work on, but it will be a big step for the usability of the system already.
The extended version needs a lot of contemplation on how to implement this, without turning XOOPS into a slow, querysome monster.


For both features I think it would be good to make comparative studies with other systems that have implemented them, and/or sites that show them. We don't have to reinvent the wheel (again), but doing it the quick-and-dirty way isn't going to help anyone either.

These are my considered 2 cents.

Herko

I like this feature too. This is my proposal, albiet maybe too newbieish, for the user to open/minimize blocks on any page they're on.

Database
Add another field to the user table such as `hidden_blocks`. It will be a list of comma separated block_id's to hide

User login
during login, it will pouplate (eg: explode() the field) to $_SESSION['xoops']['hidden_blocks'] array list to avoid excessive DB access when checking which blocks to keep open or closed upon each page load.

theme.html
Add the X or [¯] img link next to the block's title, which points to <{$xoops_url}>/user.php?op=mod_block&choice=&blockid=<#>&from=

In addition, setup an <{if}> statement for which blocks to omit its contents (maybe do this in the SELECT statement?)

FROM
                
                <{foreach item=block from=$xoops_ccblocks}> <table align="center" cellpadding="0" cellspacing="2">
                  <tr> 
                    <td> <div class="blockTitle"><{$block.title}>div>
                      <div class="blockContent"><{$block.content}>div>td>
                  tr>
                table>
                <{/foreach}> 
                

TO
                
                <{foreach item=block from=$xoops_ccblocks}> <table align="center" cellpadding="0" cellspacing="2">
                  <tr> 
                    <td> <div class="blockTitle"><{$block.title}> 
                    <{* check whether to display the open or close icon *}>
                    <{if $block.hidden}>
                      <{assign var="open_close" value="open"}>
                    <{else}>
                      <{assign var="open_close" value="close"}>
                    <{/if}>
                    <{* uses &from= to send the user back to where s/he was *}>                    
                      <a href="$xoops_url/user.php?op=mod_block&choice=<{$open_close}>&blockid=<{$block.id}>&from=<{$xoops.server.PHP_SELF}>"><img src="<{$xoops_url}>/images/<{$open_close}>.gif" alt="<{$open_close}> block" />a>
                        div>
                    <{* check whether or not to display the contents *}>
                    <{if $open_close == "close"}>
                      <div class="blockContent"><{$block.content}>div>td>
                    <{if}>
                  tr>
                table>
                <{/foreach}> 
                

The above would, of course, be applied to every block area (left, lcenter, ccenter, rcenter, right)

user.php

Pseudo
case 'mod_block':
  Grab the $_GET['choice'] and $_GET['blockid']
  update the database with the choice (open/close)
  update the $_SESSION
  show the updating screen
  send the user back to &from (link in themes.html)
  break;

Having maintained only small sites, I am unsure of the performance hit this propsal would create with the amount of additional if statements when checking if a block should be closed or opened.

After this is all said and done, it would be nice to have an admin site survey area to find out which blocks are closed the most so we, as admins, know which blocks people don't like (or for just our [read: my] nosy curiosity).

Quote:
I don't see any idea in doing the filtering in the theme. It would undermine the idea of putting the hidden blocks in a session variable. Since we already fetch the hidden block id's from the session variable, we might as well add it to the block fetching code so that only the visible blocks are fetched - to improve performance.

Also, it wouldn't break existing themes, then.

A question, though, is how to set a block VISIBLE again.

I don't know much about the performance of session variables, but your idea has made me think about putting the user object and the user's groups into session variables as well, so we'll save those SQL calls on each page load. But that depends on how much a resource hit we'll see on the server, then.