New homepage for authenticated users

Other than the ugly-ass guy next to the "Distributions Summit in San Diego" post, I love the look and simplicity of the "What's new in your groups" page. The only concern that I have is although this page is very useful, we are hiding the status updates in the lower right hand corner of the page. What I really miss in Commons is the Homebox-like approach where users could select the elements of their homepage. I feel that the look you proposed should be maintained, however the user should choose which items are in the main content area and displayed above the fold, such as the activity streams. This would satisfy all use cases on a user by user basis, however I understand that this would add some technical complexity and change the overall paradigm of how Commons is currently constructed. Just throwing it out there, though.

Great work, Lisa!
~Chris

It would also be useful / interesting to get some community feedback on how many people take advantage of the Featured Content block. We did it initially "because we could." But in practice, I've never seen us use it much here at Acquia; I just don't know how much _others_ use it.

I for one don't really use featured content.

Perhaps it's missing the site 'notices' though unless there's just not any on your example?

What's the reason for the redesign? i.e. what is it supposed to improve?

ezra, what do you think about moving the Featured Content block to the bottom of the left column?

Moving it to the bottom of the *right* column makes sense to me.

I also discussed with lisarex, and we're going to add to this comp the existing "Notices" block from the current homepage.

Note the current group homepage showcase display is actually made up of 2 displays of the homepage_group_showcase view connected in views-view-fields--homepage-group-showcase--block-1.tpl.php - The new view should probably eliminate this template in favor of http://drupal.org/project/views_field_view so that the homepage doesn't break when displayed without commons_roots.

Note: The comp here shows the "Stream" primary nav as being active, when in fact we intend to keep the dedicated /stream page - This comp is about the site homepage.

For the revised stream presentation in this comp, we run into a themeing limitation of Activity log that the result of storing markup in the database: #1421998: Customized presentation of Activity log. My sense is that adding another stream type and the resulting configuration permutations that would apply to every Activity log rule are not worth the added complexity for site builders and we should instead keep the current stream presentation for this block.

IceCreamYou, Essentially, the existing homepage wasn't showing content relevant to the current user, and that documents they are interested are difficult to find. We determined this through usability studies and feedback from Commons users. Happy to share the usability study with you.

I'd be interested to see that. Usability is an interesting topic. In this case I'm particularly interested in what kinds of things people are actually looking for. I suspect that the trouble here is that on intranets, documents are relevant for longer than they stay on the activity stream. So I'm interested in how you got from the problem to this solution, in part because I don't see how things are sticking around longer. My other thought about this is that it looks like you're trying to separate different content types, and I wonder whether people really make the distinction between different kinds of content in their heads or whether it's all just content to them.

While I don't see that the frontpage homepage comp separates content types, rather that it separates groups... I do see where you're coming from in terms of the group homepage menu.

I quite like the idea of users being able to arbitrarily (is that the right word) construct their own group menu system, such that menu headings might be subjects rather than content types. So a document on the subject of say Geography could be posted into the Geography section, as well as blogs, polls etc relevant to that section. But that's probably more relevant to #1419150: As a Commons user, I would like a more useful default group landing page than here.

Where it is relevant to here is perhaps that the homepage should be more focussed on enticing new users, i.e. by having less by way of authenticated-user-centric content and more public content.

Primarily, notices perhaps should be at the top of page content, rather than in a block (because if a site owner posts a public notice, they'd probably want it to have pride of place on the front page).

Secondarily, perhaps there should be section beneath the notices which promotes other public user content and public content in open groups. This might both encourage new anonymous users to join, and authenticated users to join groups they weren't previously a member of.

And then perhaps actual feed content should be of tertiary significance to the front page (since we already have the stream), and should dominate instead much of the right sidebar for authenticated users (so that authenticated users don't forget the stream is there), with a site-signup block for anonymous users.

Just flagging this issue up because it's relevant here... @jsibley wanted a separate front page for anonymous/authenticated users #1414106: How is the menu controlled in Commons?

My other thought about this is that it looks like you're trying to separate different content types, and I wonder whether people really make the distinction between different kinds of content in their heads or whether it's all just content to them.

@IceCreamYou, I agree with you here. There are overlapping content types in Commons.

For example: Both discussions and blog posts are non-ephemeral content types with comments enabled for discussion. The only way I'm aware that they are functionally different from one another is that each has an identical but separate page for listing content, which means that users have to go to 2 places to look for content, eg:

/content/discussions
/content/blogs

Ultimately the solution here is to reconsider the product/users' goals and reduce overlapping content types -- Something that's better done in a new major version (eg Drupal 7) rather than within 6.x-2.x where we want to keep the basic site structure the same for existing sites.

Where it is relevant to here is perhaps that the homepage should be more focussed on enticing new users, i.e. by having less by way of authenticated-user-centric content and more public content.

Great point. The comp doesn't really describe the homepage for anonymous users. @lisarex - Care to comment here :)?

Primarily, notices perhaps should be at the top of page content, rather than in a block (because if a site owner posts a public notice, they'd probably want it to have pride of place on the front page).

I agree that notices should be more prominent.
My sense is that if notices are going to occupy such prime real estate, they should be dismissable so that this space can return to showing dynamic content, versus notices which I see as changing less frequently than, say, new content in a group. It's always tough to draw the line between "enhance D6 version more" and "get D6 good enough and start amazing new D7 version."
I'd happily review patches to make notices dismissable, but from the point of view of the Acquia Commons team, we're excited about implementing the improvements here and starting to collaborate with you on Drupal 7!

Here's an in-progress patch to implement the comp + the lisarex' revisions.

Some notes:

- the home context now requires the user to be authenticated. The home_anon context provides the previous Commons homepage for anonymous users.
- We no longer manually set the context in code in commons_homepage since...Context can respond to a path for us.

By including the Activity stream block in the homepage, we make commons_status_streams a dependency of commons_home. This seems acceptable as it seems like the majority of sites will have both enabled anyway.

- We no longer intercept requests for the frontpage and redirect to 'stream' by default (see commons_status_streams_auth_frontpage).

- The "What's new in your groups" view for authenticated users users views_field_view, rather than connecting these views in the theme layer per my comment in #7,

- the user_picture_meta Imagecache preset is increased from 30x30px to 50x50px to make avatars recognizable througout the site. Activity log contains css that resizes these images after they're served on the page (.activity-log-picture img {. We should either patch Activity log to not do that, or override in the Commons_roots css.

Todo:

- Themeing
- Investigate adding views_content_cache to the authenticated frontpage
- Add views_field_view to the Commons Drush make file
- Remove (or commit in a separate issue) the Quant changes that got included in this features reroll

And, of course, test :).

The previous patch accidentally added the new_your_groups view to both commons_home and commons_core, causing a conflict. This patch has them both in commons_core.

Activity log contains css that resizes these images after they're served on the page (.activity-log-picture img {. We should either patch Activity log to not do that, or override in the Commons_roots css.

It's actually more than that:

.activity-log-picture {
  float: left;
  margin-right: 10px;
  width: 30px;
}

.activity-log-picture img {
  width: 100%;
  height: auto;
}

I don't remember writing that, which means it probably snuck in as part of moving Jesse's changes over. It's a lazy approach and I am happy to accept a patch to remove it -- but right now it looks like the relevant images aren't served using ImageCache so just getting rid of the rule will show images that are too big.

----

Also, I can get behind the idea of breaking content out by group on the home page if the idea is to focus all the site activity in groups; that's the same as a tacit admission that the friend/follow model doesn't work in an organization. So that means that the home page basically becomes a funnel to your groups. That probably makes sense for intranets, and it's been clear for awhile that in the current design it takes too many clicks to get to your groups.

But redesigning the home page this way doesn't solve the problem of showing documents for as long as they're relevant / making it easy to find specific items. It seems to me that the issue is having to click on 5 different group-home-page tabs to find the content you're looking for once it has scrolled off the activity stream. If it were me, I'd get rid of all the tabs across the top of group pages and just have two tabs: Stream and Discussions, where the Discussions tab showed a simple table of select node types with title, date, author, node type, # comments, and a search box (ordered by last modified / last commented). To me, the difference between a Blog post, Discussion, Document, Poll, and Wiki is just semantic (Document just sounds official, more people have permission to change a Wiki, and a poll is just a field).

I'm not here to defend activity streams per se. But tangentially, I'd also like to point out that there is an option to use the Radioactivity module to make the content in activity streams more relevant. Basically it would cause content that is being actively viewed/discussed to float to the top of the stream instead of just scrolling off the end within a day.

Hi IceCreamYou,

Thank you again for taking the time to share your thoughts and this information in detail. I really appreciate it! I hope we can continue this close collaboration when we start designing for Drupal 7 in the next month or so :).

f it were me, I'd get rid of all the tabs across the top of group pages and just have two tabs: Stream and Discussions, where the Discussions tab showed a simple table of select node types with title, date, author, node type, # comments, and a search box (ordered by last modified / last commented).

Have you seen #1419150: As a Commons user, I would like a more useful default group landing page? That's very similar to what lisarex proposed there.

To me, the difference between a Blog post, Discussion, Document, Poll, and Wiki is just semantic (Document just sounds official, more people have permission to change a Wiki, and a poll is just a field).

Again, I totally agree with you there, and ultimately the best solution is to refactor these content types in Commons for Drupal 7. As a stopgap, I suggested grouping content types that are sufficiently similar in blocks on the group homepage. Eg, "Discussions & Blog posts", "Documents & Wikis", etc. However, in the short term we ultimately decided to go with the design in #1419150.

I'm not here to defend activity streams per se. But tangentially, I'd also like to point out that there is an option to use the Radioactivity module to make the content in activity streams more relevant.

That seems like a great option. We've discussed including radioactivity module before. Realistically it seems unlikely to be prioritized within our team in Drupal 6, however I would absolutely review and commit a patch to add this functionality into Commons.

Sorry to join late, but I just noticed this discussion. Was there a final decision that this homepage redesign will focus on what will be most useful for authenticated users? I would support that.

I think there are 3 major categories of Commons sites.

• public sites (much content available without logging in)
• private sites (no content visible without logging in)
• hybrid sites (some content visible without logging in, but largely private)

Sites that are largely public (some groups might be private) and sites that are totally private wouldn't seem to me to have as strong a need for a front page to entice users to sign up, except for, possibly, a splash screen for private sites.

I look forward to seeing the final result.

Was there a final decision that this homepage redesign will focus on what will be most useful for authenticated users?

Yes - We're leaving the existing homepage in place for anonymous users.

Here's a revised patch. Changes since #15:

- Refactored the new_your_groups view to display the group title in this view, rather than new_groups_field.
- Added dependencies to Drush make
- Initial themeing for the homepage view that gets us close, though this needs a bit more work to match the comp. Using views_field_view in Views 6.x-2.x is definitely interesting! With Views 3.x, we can better target the elements we want to style. Currently, we have 2 types of elements with the class views-field.title that need separate styling.
- Added Views content caching
- Added empty text inviting the user to browse the groups listing a join a group when she is not a member of any groups.

Leaving as "needs work" pending additional themeing.

Note, one side-effect of changing the user-picture meta Imagecache preset from 30x30 to 50x50 is that the "submitted by" area now looks broken.

https://skitch.com/ezra-g/g6pac/i-think-i-cleared-the-cache-cn1

It would be great to remove the grey background, remove the border and adjust the spacing so that this fits better.

By the way, for the future, I can think of at least one other Commons website scenario.

Multi-tiered levels of membership (e.g., silver, gold, platinum) where different levels (I assume this would be managed through roles) might have different levels of read and write access to various content types. This might lead to different homepages for different roles.

In terms of architecture, would the Front page module be the recommended way to manage different homepages or might this be incorporated into Commons at some point (or would there be a different solution)?

Includes patch from #19 with theming to bring it inline with the issues mock plus the issue from #20.

All rolled into one.

After further testing with dummy content I realized that groups that have no content (arguably an edge case) still display their titles in the new_your_groups) - it would be ideal to hide the group titles if there are no posts in those groups.

I also want to verify better that Views_content_cache is in fact clearing the cache when we expect it to.

This is also missing the activity stream block.

Some other design feedback via lisarex:

- Latest notices: Just view all, no pager.
- "new" highlight should go after title
- Visually distinguish title and group name in featured content
- Don't show pagers, just link to page view
- In Featured content, don't show group name

Here's a patch that revises:
- Views Content Cache rules for the homepage view
- Date formatting
- CSS tweaks

Note, I wrote #1430246: Filter on # of posts within the group, which got committed, but I'm including the patch in our Drush make file until we can reconcile the Commons patches to OG_Statistics that await review and ideally, help dereine push towards a new release.

Here's what the homepage looks like for me:
https://skitch.com/ezra-g/g98ym/home-cn2

I discussed #24 with lisarex and we agreed that having the "Welcome" block display for anonymous users was sufficient.

This is ready for review.

Revised patch includes the bullet image that I accidentally left out of 26, some formatting improvements and now we link to the full aliased note paths in all cases.

The upgrade path from 6.x-2.4 needs testing.

I revised the upgrade path and caching rules after some troubleshooting. I think this is RTBC but will test on a site upgrade first.

This is committed. Thanks, everyone!

http://drupalcode.org/project/commons.git/commit/4f63c54

...and one small typo fix http://drupalcode.org/project/commons.git/commitdiff/8e6c3f8?hp=4f63c54a... ;).

I accidentally overwrote #1412084 with my initial commit here, resulting in the followup commit: http://drupalcode.org/project/commons.git/commit/90169d6.

I have a fairly new installation of Drupal commons (about two weeks old) and when I upgrade the commons module, the view that runs my new homepage (which should be showing all the acitivities within my groups) only shows the group titles. When i click through to the view and look at the fields that are chosen to be shown, I see three options and the third one is called "Broken/missing handler".

Anyone else experience this issue?

@psykomf, So that we can provide better assistance, please open a new support request for this issue and specify which versions of Commons you are upgrading between and the location from which you downloaded the Commons tarball. Thanks!

remove inline image