Better empty text for 'all', 'posts' 'documents' and 'polls' tab.

How about "Nothing to see here yet!"

We could even prompt them to create some content.

+1 "Prompt to create some content"

It makes sense to provide custom text for all the content types we ship with; coming up with a generic one for all is more difficult because it has to be shorter, e.g.
"Nothing to see here yet! Create content if you've got something to share."

All tab: "Nothing to see here yet! Got something to share? Write something!"

Posts: "No posts here yet. Write a post if you've got something to say."

Wiki: "No wikis here yet. Start a wiki if you want to collaborate on a document with others."

There's action phrases for each content type defined in the "post" drop down.

One approach would be to re-use those phrases like so:

Be the first to [linked action text].

Action phrases:

• create a poll
• create a post
• ask a question
• list an event

+1 for #4

+1 for #5

+1 for #4

+1 for 5 .... now we are tied

We need a tie breaker!

Ha! Let's go with #5 since it's a little more elegant.

The full list is based on the prototype

• Be the first to create a post
• Be the first to ask a question
• Be the first to start a wiki
• Be the first to create a call for ideas
• Be the first to list an event
• Be the first to create a poll

Screenshot from prototype
http://invis.io/UHBT1DYX

I looked into implementing this a little further...

We defined what users who can post should see, but we also need to consider users who cannot post. For this, we could follow the lead that Wiki's and Q&A have.

No **plural content type name** have been added to this group.

The technical problem we need to work through is this:

The no results text is the output of a view, and we do not have a dependency on the PHP text format. We cannot use conditional logic directly in the no results text field.

The path of least resistance would be to go with the text format that Wiki's and Q&A use (as defined above).

The other option would be to create replacement tokens that could be used in the no results text field. We should probably discuss it a little more considering this post before anyone spends time going down this path.

Thoughts?

Well the path of least resistance sounds good. I'm not sure this would make a difference, but I would think that it would be best to avoid having to use tokens because of things like this Entity tokens duplicates field tokens created by token module, and this token types are not defined but have tokens: taxonomy_term