mozilla / testpilot

Test Pilot is a platform for performing controlled tests of new product concepts in Firefox
https://testpilot.firefox.com/
251 stars 123 forks source link

Add News Feed #2420

Closed johngruen closed 7 years ago

johngruen commented 7 years ago

How it works

Spec

Main Feed: https://mozilla.invisionapp.com/share/3SBLDS9Z4 Main Feed with expanded article: https://mozilla.invisionapp.com/share/N3BLHU5QP Feed filtered by experiment: https://mozilla.invisionapp.com/share/SGBLHUA8T Feed filtered by experiment with details expanded: https://mozilla.invisionapp.com/share/YUBLI6J9D

Measures

Coming Soon

lmorchard commented 7 years ago

Each post sounds like it needs a type / tag marking it as "news", "major feature", "change" - which might serve as a filter for alerts in #2419, assuming we don't want every post pushed in the alert / carousel system

lmorchard commented 7 years ago

Thinking out loud through a rough schema of a "post":

Is that it? Missing anything? Expecting to include additional images in intro / detail HTML sections? We had a pretty cookie-cutter content pattern for experiment pages that we threw out almost immediately, so would like to avoid that here 😁

lmorchard commented 7 years ago

Also, as we've discussed a little bit in meetings, it might be nice to re-purpose an existing system (e.g. WordPress) to handle content management rather than continue to re-invent wheels.

Some benefits there include:

We've also not had the best time (ab)using Pontoon and the L10N community to translate big hunks of content in our YAML files. So, it might be interesting to see how a CMS like WordPress handles localizing blog posts.

lmorchard commented 7 years ago

But, if we don't use WordPress... It's not infeasible to have a per-experiment directory of little YAML-front-matter-and-markdown-content files like Jekyll, keep more images in the repo, and tie news updates to Test Pilot sprints. Maybe we could do l10n with directories named for locales

lmorchard commented 7 years ago

Slept on this: Wondering if maybe a whole WordPress instance is overkill, unless we have a ready-to-go ops thing available?

Could just keep going with our static site generator approach, start a new directory of YAML-with-content files, and maybe just accept deploying more often with just cherry picked news posts? (That is, assuming we have more than a post every 2 weeks)

chuckharmston commented 7 years ago

Is a move to Jekyll (or similar) off the table? Its collections give us the CMS-y feel we want, without the need for an admin.

lmorchard commented 7 years ago

Is a move to Jekyll (or similar) off the table?

Personally, I'd hesitate to add it to our build and make things even more a Rube Goldberg machine. At least we only have to real with JavaScript & node right now. What I'm thinking of so far is just another gulp task or two.

youwenliang commented 7 years ago

Updated Spec Link:

(including expand/collapse view, and all updates page v.s filtered page) https://mozilla.invisionapp.com/share/RGBO0IRXJ

All the news feed related measurements can be found here: https://www.dropbox.com/sh/ludnt78ky7ttrwq/AACh3mXB8FsxMxbRpGs34Repa?dl=0

ghost commented 7 years ago

clouserw: investigate l10n on mozilla's current wordpress blogs

lmorchard commented 7 years ago

Another question - what about pagination? Or, do we just not show items past a certain number / age?

meandavejustice commented 7 years ago
Is a move to Jekyll (or similar) off the table?

Personally, I'd hesitate to add it to our build and make things even more a Rube Goldberg machine. At least we only have to real with JavaScript & node right now. What I'm thinking of so far is just another gulp task or two.

@lmorchard

There are plenty of other statically built blog engines that only use javascript/node if we do want to go that route.

meandavejustice commented 7 years ago

@johngruen @lmorchard @clouserw I have a couple of questions/suggestions here:

  1. Can we have a static single post page that can be linked to? Although it is doable to link to a specific post within the feed and expand it via a query string or some other indicator, It might get messy. Also it will slow down page loads. Whenever I personally look at a post/blog sort of thing I always want to be able to look at it outside of the feed, and link to only that piece of content.
  2. Should we include an installed experiments filter?
  3. Should we include an uninstalled experiments filter?
  4. What should the default filter set be when the user first lands on the page, and should we try and persist their filter state?
meandavejustice commented 7 years ago

@lmorchard @chuckharmston As far as using something like wordpress for this, I vote for whatever will have the quickest setup with the lowest amount of maintenance on our end. I'm happy to have a discussion here, or in a etherpad about the pros and cons of our options. Lemme know if yall wanna setup a little vidyo meeting to discuss sometime this week.

This seems to be the one decision that will hold up development, so I'm happy to make myself available for whatever times work best for yall

ghost commented 7 years ago

The wordpress install Mozilla hosts doesn't do L10n.

Figuring out the technical sides of L10n are complex enough, but we haven't talked about the logistical side at all. How are we guaranteeing the strings are translated before they go live? We don't always land patches early enough for that, and users (including localizers) aren't going to like it if we're shipping incomplete translations.

L10n aside, this kind of just sounds like a twitter feed. I'd definitely rather use an existing tool than write our own.

I can schedule a meeting for this. (edit: done, Thursday, on the public calendar)

pdehaan commented 7 years ago

Unpopular opinion here, but do we need to localize the blog? Or can we say that en-US is good enough? Do we localize graduation reports?

If we do want to localize (and are writing our own basic blog tool) what about the legal-docs repo style of just every blog post is just a directory with locale files in it. So something like /blog/hello-world/en-US.md (with some markdown front matter) and then localizers can add full translations as time permits. We'd only ever merge the PR when the translations look complete on a post-by-post basis.

I vaguely recall looking at a Node based static blog generator by chilts which may be useful (although I'm not sure how/if it handles any potential l10n, if required): https://github.com/chilts/seagull

lmorchard commented 7 years ago

Yeah, the thinking I keep falling back to (technically speaking) is Jekyll-style markdown-with-YAML-front-matter posts under content-src/news/{locale}/{date or title}.md.

Logistically speaking, this at least gets us a structure that accepts pull requests. I suspect trying to leverage Pontoon for this longer-form stuff just generates angst. Instead, we could get contractors to localize posts, convince contributors to help, etc.

As for ensuring things are translated before going live: We could hold back en-US posts in a pull request until localizers has had a chance to contribute commits with translated news posts. Also, we could go live and show en-US posts until there's a matching file in another locale.

ianb commented 7 years ago

How about experiments can have an RSS feed? You can host on wordpress.com or wherever, Test Pilot still has to read and process the RSS, but doesn't have to implement any other content management features. This doesn't work great with Twitter, but I guess there are options.

lmorchard commented 7 years ago

We already have a static site generator - I don't think we need to graft another one on.

We're also talking about WordPress, which clouserw just mentioned doesn't do L10n - at least insofar as the already-setup instances we have available at Mozilla

All of this to say - the technology isn't the main problem. Logistics are.

johngruen commented 7 years ago

@lmorchard per our meeting a minute ago, i think the schema should be something like:

johngruen commented 7 years ago

WRT pagination, I don't think we'd need any on the experiment page, i think we could time band stuff so only stuff w/in the last month gets shown, or possibly cap at 4 items

lmorchard commented 7 years ago

(FWIW, notes on the meeting "Let's talk about the News Feed" in test-pilot-coordination etherpad. Being lazy and not copypasta'ing here)

ghost commented 7 years ago

I agree, we don't need pagination at all.

I don't know that we need "post type" either.

Are we using markdown anywhere already? If not, I think we could make do with whatever we already have (or nothing, if that's what we're doing now - we don't need this to be anything beyond text at launch).

It was also discussed that we should close this issue completely since it (and the mockups) are a bit misleading now since we're no longer having the long-form text on the test pilot site. Any further questions or reasons to leave this one open?

pdehaan commented 7 years ago

Are we using markdown anywhere already?

We use both react-markdown and remarkable in /frontend/tasks/pages.js.

lmorchard commented 7 years ago

Are we using markdown anywhere already?

Yup, for the legal pages.

We use both react-markdown and remarkable in /frontend/tasks/pages.js.

Hmm. Looks like we used to use remarkable - and we still create an instance of that Markdown processor. But, we switched to using the react-markdown component - and it uses commonmark under the hood. So, I think we can get rid of remarkable.

ghost commented 7 years ago

We talked in triage. We'll close this and move the other three issues into on deck

lmorchard commented 7 years ago

I don't know that we need "post type" either.

We need post type if we want to filter just for news alerts related to feature changes (#2419), but not other items like small news updates