Improvements to Stream Records screen

[krogsgard]

I have a couple of recommendations for the Stream Records screen. Here's a screenshot of my records for reference purposes:
https://cloudup.com/cIRlYna-7MK

The "Author" column would fit better with WordPress standards if it were "User". Author is a role, User is a user.

The "ID" column is not necessarily clear that it's a Stream Record ID, vs a post ID. If a change was to a post, I could easily think that was the related Post ID. I'd change the column name to Record # or Stream ID or something with better context.

Under the "Authors" filter, there is a search input. Two defaults that would also be highly useful would be "Logged in users" and "Logged out users" to be able to bulk define a user set.

The title attribute to the magnifying glass on item hover, under the Summary column, says "View all records for this object". What is an object? It's unclear what the user is actually going to view when clicking the magnifying glass.

I changed an option in Yoast's WordPress SEO plugin to see what the record would look like. The "Context" column helps identify the plugin, but what if the plugin didn't use a clear prefix? How would I know where a change was made? If possible, perhaps some sub-text could provide greater context under the ""rssafter" setting was updated" section of my example could say something like "A setting change in the Yoast WordPress SEO plugin". Other non-core changes would therefore have more context than the context column itself.

Just some ideas based on my fresh-eyes perspective of Stream. Hope this is the best way to propose these changes.

[tnorthcutt]

Under the "Authors" filter, there is a search input. Two defaults that would also be highly useful would be "Logged in users" and "Logged out users" to be able to bulk define a user set.

I'd also suggest adding presets for common user roles (admins, editors, etc.).

[frankiejarrett]

These are all great suggestions!

Typically we would address each of these as individual issues, and work on each in their own feature branch forked from develop, with the intention of keeping the scope as narrow as possible.

So from here, I'll probably take a few of these suggestions, move them into separate issues and reference back to this original issue.