Newsfeed system for the notification center

[tsullivan]

PR: https://github.com/elastic/kibana/pull/49579/files

Part of Meta issue: #34397

Design and link to prototype: #34397

The requirements:

UI

@YulNaumenko

1. Add an envelope icon (Newsfeed icon) in the notification center (the upper right corner of Kibana chrome). The icon will have an "unread" style when a data request has yielded items not marked as read in browser local storage.

   • Has unread:
     
   • None unread:
     
   • The items will need to be automatically fetched in the background in order to know if there are unread items
   • When the user clicks the icon to view the items, we will render the items that have already been fetched.

2. Clicking the Newsfeed icon will have a sidebar pop out, listing the pre-fetched items as separate newsfeed items. Each newsfeed item will have some clickable content or call to action.

   • If it is an external link (e.g. blog article) it should open in a new window
   • Will we allow linking internally to Kibana (e.g. particular Advanced Settings or featured app)?

3. The hash strings of each item viewed will be preserved in browser local storage, so that the "unread" state of the envelope icon can be corrected after viewing the items.

   • Based on the design, there doesn't seem to be a way to clear or dismiss items
   • We can use a comma-delimited string in local storage for this. It would be safe to just store the beginning of the hash, as they will probably all be unique up to the first 8 characters or so.

4. There will be a new Advanced Setting for toggling off/on the the Newsfeed feature.

   • If toggled off, the Newsfeed icon will not show in the notification center (upper right of Kibana)

5. There won't be a kibana.yml setting to toggle off the Newsfeed feature for the entire instance.

Fetching for Newsfeed items

@tsullivan

• As linked from the meta issue, the newsfeed service is accessed at: https://feeds.elastic.co/
• The request paths to that URL are to route to a pre-built JSON file, where a "product keyword" is a prefix, and version is a suffix of the path.
• For our requests, we will use the path /kibana/v{major.minor.patch}.json
• This means news items will only show for the single version of the Kibana instance!
  • However, the newsfeed system seems flexible, and it seems in the future we can add more advanced requesting by tweaking the JSON file builds.
• The JSON data representing each item has meta-fields that need to be handled in the poller for news items.
  • language
  • expiration
• We will leave the fetched newsfeed items in browser memory to avoid re-freshing on every click of the Newsfeed icon.
• We will not "sweep" items in memory to clear out any past their expiration date. They will be dropped off at the time of next refresh.

Questions:

• How often do we re-request to refresh the news items? - @tsullivan
  • In order to not flood a network with these requests, they should be throttled to once per day.
    • We'll need a local storage key and value to track the last time newsfeed items were refreshed.
    • The code should avoid sending the same request as a newsfeed request already running, even though unlikely
• Why does the design show version "tagging" for each news item? We expect there to be only 1 version in a set of news item data. - @YulNaumenko

[elasticmachine]

Pinging @elastic/kibana-stack-services (Team:Stack Services)

[ryankeairns]

Glad to hear this is getting picked up!

Regarding the version 'tags', we had discussions on whether the news should be tailored according the current version of Kibana that you are running. I don't recall that we nailed down all the requirements here, but coloring of the tags was one way of indicating that a particular news item relates to a version newer than the one you are currently working from.

I'm not clear if the current news feed supports this information, but we can discuss options and alter the design for the initial release.

Thanks!

[alexfrancoeur]

Regarding the version 'tags', we had discussions on whether the news should be tailored according the current version of Kibana that you are running.

I like it and get it, but probably a nice to have for 7.5. Newsfeed does support version though (https://github.com/elastic/newsfeeds).

[tsullivan]

I think @YulNaumenko and I have found all of our Newsfeed service questions answered now :)

And I'm glad to see this issue getting conversation, because I put a lot of assumptions into the description, so we have something to work from.

[tsullivan]

From the description:

5. There won't be a kibana.yml setting to toggle off the Newsfeed feature for the entire instance.

We found it is necessary to add config settings for this new feature, in order to have a flexible environment to develop with. Here are the settings I am adding:

{
  newsfeed: {
    service: {
      urlRoot: string; # Default: https://feeds.elastic.co
      pathTemplate: string; # Default: /kibana/v{VERSION}.json
    };
    defaultLanguage: string; # Default: en 
    mainInterval: number; // how often to check last updated time. Default 2 minutes
    fetchInterval: number; // how often to fetch remote service and set last updated. Default: 1 day
  };
}

[tsullivan]

@alexfrancoeur @ryankeairns I think we're very clear on the "happy path" experience for viewing the news items.

@YulNaumenko and I are wondering if we need any mockups or content written for the error handling cases:

1. What to show if the request to fetch items is still pending when they view the sidebar?
2. What to show if the last time fetching for news, the request failed?
3. Do we want to have a "Refresh" button available for any reasons?

[alexfrancoeur]

Yeah, it does feel like we need answers to all of these. We may even need a general "empty state" as well. My initial thoughts are below, but maybe it makes sense to touch base tomorrow as a group to hash out quickly.

What to show if the request to fetch items is still pending when they view the sidebar?

This feels like a loading indicator would be required here. We have the loading bar, the indicator when a visualization loads and some sort of bouncing K I believe 😄 But if there is data loading, it feels like we should acknowledge that

What to show if the last time fetching for news, the request failed?

A nice "whoops something went wrong" image feels good to me. I do have a question related to this though. For air-gapped deployments, I recall there being some discussion around not showing the news feed if we couldn't detect an internet connection. This is different than intermittent connection issues. Did we still plan automagically hide the news feed in those cases or are we explicitly having users remove via advanced settings?

Do we want to have a "Refresh" button available for any reasons?

I don't think it could hurt, but it doesn't feel necessary in the first iteration. Maybe it is available specifically for when there is an issue making the request in the above scenario? It feels like a persistent refresh icon might be overkill.

[tsullivan]

Did we still plan automagically hide the news feed in those cases or are we explicitly having users remove via advanced settings?

We can. It is possible, but I’d be a little worried we’d get caught by intermittent network hang ups. There is something of a retry mechanism in the logic that will make the newsfeed data correct itself if it didn’t work initially, or just didn’t work at some point while on the page and trying to refresh data from the service. There will be a kibana.yml setting to disable the feature: `newsfeed.enabled: false` - it merits a manual test to make sure it works.

[ryankeairns]

I'll post a couple of mockups here for the empty, error, and loading states.

[ryankeairns]

@alexfrancoeur @tsullivan I've created two states, a generic empty state that could also cover the error state and another for the loading state.

For the former, I think it's best to minimize negative connotation. After all, it's unlikely that Kibana has erred in this case, rather the environment lacks internet access. Given that case, I've also included some text hinting that this feature can be disabled in the event they see this message too often. I'm not certain if we can support (or want to in v1) the ability to manually retry, but I've included a button for if/when we do.

Technically speaking, both solutions use the EuiEmptyPrompt component. For the loading state, we would have to put the loading graphic into the body of the empty prompt and not set an icon (in other words, the loading indicator cannot be passed in through the iconType prop).

Let me know if you have any edits.

Empty state

Loading state

cc:/ @gchaps to help with copy

[gchaps]

Here are some recommendations.

Empty state

No news?

If your Kibana instance doesn’t have internet access, ask your administrator to disable this feature. Otherwise, we’ll keep trying to fetch the news.

Retry now

Loading state

Getting the latest news...

[alexfrancoeur]

We can. It is possible, but I’d be a little worried we’d get caught by intermittent network hang ups. There is something of a retry mechanism in the logic that will make the newsfeed data correct itself if it didn’t work initially, or just didn’t work at some point while on the page and trying to refresh data from the service.

@tsullivan yeah, I felt the same way, but remember hearing this idea tossed around in earlier discussions.

@ryankeairns @gchaps those look good to me!

We'll be putting together a process for actually adding content to this feed as well, likely to be followed up on in another issue. Stay tuned!

[gchaps]

Also, +1 to keeping the title simple, What's new, with no explanatory text underneath it (as this widget will be text heavy given its nature).

[alexfrancoeur]

It's worth noting that Cloud is also introducing a newsfeed. Given the 7.5 push, we'll beat them to the implementation, but it feels like while not completely necessary - we should try and be consistent with titles / descriptions where possible. I'm walking through their implementation later today so will see what they've chosen and what it looks like.

…

On Fri, Nov 1, 2019 at 10:46 AM gchaps ***@***.***> wrote: Also, +1 to keeping the title simple, What's new, with no explanatory text underneath it (as this widget will be text heavy given its nature). — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#49539?email_source=notifications&email_token=AGAD472DROAKRFNSEFY4UK3QRQ6K7A5CNFSM4JGAQZ6KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEC3D5WY#issuecomment-548814555>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AGAD476S4OAFXBSAB5FRVRTQRQ6K7ANCNFSM4JGAQZ6A> .

[gchaps]

@alexfrancoeur I watched the Cloud video. It showed very simple titles (Documents, Training, Webinars, and Blogs) and no description. It occurred to me that the newsfeed will be for more than just announcing new things. Would something like "Kibana news" or "What's up in Kibana" be a better title?

[alexfrancoeur]

@gchaps the content will not be Kibana specific, but instead news for all of Elastic. Webinars, blogs, release notes, free training notifications, security vulnerabilities, etc. "Kibana news" or "What's up in Kibana" sound to be too Kibana specific. Is "News feed" or "News" too generic? I'm not sure how much I like those either. I feel like "What's new" still works for the most part, most of the content will be new, especially to a user. But I wonder, do we even need a title?

[ryankeairns]

But I wonder, do we even need a title?

Given how the flyout component works and for the sake of consistency, we should display a title.

[gchaps]

The title helps set context. I agree with @alexfrancoeur that "What's new" is a title that users are familiar with.

Another fun title that Renu suggested is "Latest and greatest".

[alexfrancoeur]

+1 to "What's new" for now unless other have objections.

Great suggestion by Renu! I like it a lot, and I could probably go either way. I feel like I've seen "What's new" more often and may resonate more with our users.

[ryankeairns]

+1 for What's New and its built-in familiarity. I'm less certain how well "Latest and greatest" would be interpreted by non-native English speakers and in other languages.

[alexfrancoeur]

I think we're good to close this now yeah?