Update Facebook-status UI

For the record, it shouldn't be too bad getting it back to (a) -- basically those changes weren't committed back to FBSMP on d.o from the Commons version because they didn't cover every case (e.g. they only worked correctly if just the Picture and Link plugins were enabled).

It's more than just CSS; the markup is different too.

Do we really want facebook style status messages in our group homepages?

With two types of content (status/node) my site was becoming a mess with two places and two forms information could be held in... I actually think commons.acquia.com is becoming a mess for the same reason.

You can still have a facebook-style microblogging UI for group homepages using custom node forms... that's what I ended up doing, screenshots in http://drupal.org/node/1322322#comment-5204162.

With custom forms and QuickTabs module my UI is sort of a mixture of c/d.

I think the activity stream model is simpler and more familiar to users than the complex dashboard that we had before. People can still search and find things they are looking for.

So, I see two separate issues.
1) do we want a simple microblog to share links, images and other attachments as an additional content type along with blogs, documents, polls, events, and discussions?
2) Do we prefer a simple activity stream page to the complex dashboard we had before.

People can still search and find things they are looking for.

A search will not turn up content that's in an FBSS status message.

So, I see two separate issues.
1) do we want a simple microblog to share links, images and other attachments as an additional content type along with blogs, documents, polls, events, and discussions?
2) Do we prefer a simple activity stream page to the complex dashboard we had before.

I still want both (and still do have both) - microblog and activity log streams.. I just don't see exactly why Commons is using FBSS statuses on group homepages instead of nodes, apart from the speed improvements we get from them being a lot 'lighter'. I don't see what they do that's sufficiently better than nodes and therefore worth the disadvantages in this context, which are mainly that they're not fully integrated with Drupal as nodes are.

OG groups are supposed to be areas that composite information in an effective way, it's difficult for them to do this if they have two competing content forms... one will win over the other. Nodes have to win, for the time being at least!

Agreed, the fact that FBSS messages don't show up in searches is bad.

Agreed, the microblog should create nodes equivalent to the other content types.

If that were the case, I would not mind the microblog showing up on the streams page or the group page as a "default" way to create a quick post, especially if people just want to put up a quick message (status) or share a link or photo (why make them create a blog post for that).

Agreed, it is confusing to have both. I think something that looks like the activity stream (which looks like facebook) is a better initial interface to content than the dashboard panels concept in earlier releases.

That said, it would be preferable if the activity listing could be filtered by content type, group, tag, etc.

I think the hard part is trying to figure out the best way to combine the activity stream stuff (Fred joined this group, Joe and Sally are now friends, etc.) with node and other content creation (Jim added the [content type] [node name] in [group]).

It would be best if we could create the same "wall" type effect with a filterable view that treated microbogs and other content the same by putting short summaries right in the "stream" AND had activity updates interspersed.

Apples and oranges as far as drupal is concerned--difficult to implement--but I think it would fit what users expect in a wall/stream.

@david.moore.ipg

If that were the case, I would not mind the microblog showing up on the streams page or the group page as a "default" way to create a quick post, especially if people just want to put up a quick message (status) or share a link or photo (why make them create a blog post for that).

This is exactly what I've configured Commons to do... by chopping the blog node form into three portions.

@ezra-g

The reason I posted in this issue is that I believe that work on improving the FBSS UI for group status messages might be work in the wrong direction. I don't think having the FBSS/FBSMP UI is a good thing to have at all in the group stream. It's better to replicate it with a custom node form and use that instead (like I say, by chopping up the blog_node_form).

That said I do already have an issue open #1322322: Status messages are replacing nodes and will leave this one alone :)

Attached is the patch giving the functionality described in case 'C' in comment #1.

Also attached are the 2 new images used incase the diff --binary does not work.

Updated patch removing unnecessary comments.

+++ b/modules/features/commons_status_streams/fbss_custom/fbss_custom.js
@@ -0,0 +1,6 @@
+Drupal.behaviors.fbss_custom = function (context) {
+  $('.facebook-status-text-main').one('focus', function() {
+    $('.fbsmp-wrapper-outer').show();
+    $('.facebook-status-submit').show();
+  });
+}

Use $('selector', context) instead of $('selector') to only apply this to the HTML the behavior is currently supposed to operate on. This is important when markup is loaded onto the page via AJAX (as FBSS does). Also you need to make sure only to show the buttons near the status update form you're focusing on; otherwise your code will do unexpected things when multiple status update forms appear on the same page. As an example, this commit does basically the same thing you want, but for status comments (note that it uses $(context).find('selector') instead of $('selector', context), but it's the same thing).

Attached patch has all the updates suggested.

The last patch was against a patched version of FBSMP and not the dev version that commons uses.

Sorry for the mixup, the attached version should be better.

+++ b/modules/features/commons_status_streams/fbss_custom/fbss_custom.js
@@ -0,0 +1,9 @@
+Drupal.behaviors.fbss_custom = function (context) {
+  var ctxt = $(context);
+  ctxt.find('.facebook-status-text-main').each(function() {
+    $(this).one('focus', function() {
+      $(this).parents('.facebook-status-form').find('.fbsmp-wrapper-outer').show();
+      $(this).parents('.facebook-status-form').find('.facebook-status-submit').show();
+    });
+  });
+}

I would do this:

+Drupal.behaviors.fbss_custom = function (context) {
+  $('.facebook-status-text-main', context).one('focus', function() {
+    $(this).parents('.facebook-status-form').children(':not(.facebook-status-textarea-wrapper)').show();
+  });
+}

That will take care of the Private checkbox and anything else that might get added below the status update box. (I haven't tested this, you might need to tweak it a little.)

Oh, also, you shouldn't set those form elements to display: none; in the CSS or people who have JavaScript disabled won't be able to save statuses. Hide them in JavaScript instead by doing something like this: $('.facebook-status-form', context).children(':not(.facebook-status-textarea-wrapper)').hide();

They are only hidden when JavaScript is enabled. It uses the js class Drupal sets on the HTML element when js is detected.

Attached patch hides the private checkbox until text area has focus.

Sorry for the constant bombardment of patches. i found a bug when submitting multiple messages without page reload. the attached patch includes all previous fixes and fixes this new issue.

hoping this is the last patch for this issue.

Clicking on the "Share" button has no effect because the block administration control is above it

That one's actually my fault. Committed fix to FBSMP dev.

Attached patch has css fix for styling issue introduced by FBSMP update.