So I'm looking at how to make the user profile page prettier and more useful. I'm using the various social networking sites for ideas. Here are 3 sample pages in case you are curious: http://www.friendster.com/user.php?uid=1856275 http://360.yahoo.com/profile-9lciejI3aafX1stHPoIRNmkmv4EowQ-- http://levistus.1up.com/ The user profile page is actually quite simple. The rendering function [theme_user_profile()] accepts an associative array where a key is a 'category name' and a value is a hunk of HTML. The categories are defined by the modules which are active. The order of the categories is defined by alphabetical order of module names. Note that any module can inject content onto the profile page, not just profile.module. This is good. In order to make this more flexible, we want to give the admin the choice of which items to show and where to show them. And perhaps give the user the ability to customize his profile page. It turns out that we already have a great system for managing this - blocks. Ideally, I think we could reuse the block admin page for profile page admin. There, admin will decide which 'categories' appear where, and even reuse logic like whether a category may be enabled/disabled by a user. We would not use the feature of blocks to turn on and off by path since the profile page only has one path. I'm interested in your thoughts about how this could be implemented from a UI perspective. My inclination is to add a new page for profile admin which reuses code from block.module. I'm not inclined to move block code into a block.inc, especially because block.module is required. I'd like to reuse the blocks table. I'm not sure how this fits into the 'block regions' work in progress. It would be nice to have more regions than left/right. Even without more regions, this would be useful than our current 'single column' model. Perhaps chx or nedjo could comment on this. Also, I'm not sure that grouping profile items into 'categories' is useful in this model. We might be better off copying hook_block() and letting modules declare their own blocks instead of fitting their items into arbitrary categories. Lastly, there is a chance that all this work inhibits sites which implement their own theme_user_profile(). They are currently able to do whatever they want with categories but I'm not so sure we can preserve this using the block paradigm. Feedback welcome. I'm not planning on starting code on this immediately. In fact, I'd be pleased if someone else wanted to run with this.