Eval moving Pocket pages to Protocol

[glogiotatidis]

If we did that, how applicable is Protocol to Pocket-branded web experiences? Does it provide

• immediate substantial value
• immediate minimal value
• value only with small investment or
• value only with major investment? Or
• something else?

[hoosteeno]

from @craigcook:

now that we have theming we can add Pocket as a third brand theme. So making Pocket-flavored Protocol is doable, but leads to the question of "what does a Pocket-flavored Protocol look like?" I don't know if there's a current Pocket brand guide, if it has any strong defining traits or if we're pretty free to figure it out. looking around I see some recurring distinctive colors, there's the red in the logo but also the green and a blue used in buttons. I'm finding a few different fonts in use but not a ton of consistency with them, but we can sort that out. if the pages we're building end up being very Protocolish anyway (boxes, cards, etc) then it might make sense to do a light skinning of Protocol vs bespoke, so I guess I'd rather understand the problem before I offer a solution. I don't know anything right now about scope or content so it's hard to say. what we get from Protocol is a bunch of pre-defined variables for spacing, font sizes, breakpoints, etc, plus all the Sass functions and mixins that make writing CSS easier. Even without using any components it's still a very useful CSS framework (we have plenty of pages on mozorg with no components already).

[hoosteeno]

In light of the above, I think any deep integration with Protocol should not be in scope of the initial move. If it's helpful in some way to include Protocol, to get some features, that's fine.

[glogiotatidis]

Thanks for the update @hoosteeno. I'll close this issue since we're not doing protocol. When we scope phase two we'll create new issues.