Brainstorming around...

[tiagostutz]

When working with our customer La Fiancée Noivas we found that a little pain they had is offering a good way to show dresses options to their customers (brides). You know, the bride is looking after the PERFECT dress and to find it she needs to browse a lot of dresses or filter the catalogue on a not sun fun way. One option that could be a little more fun and would cause a bit less anxiety is a Tinder approch, where the bride would matching dresses after dresses and the system would filtering the catalog in a "by example" interaction, based on the frequent features of the matched dresses.

A good inspiration is how the wedding planner website The Knot uses this approach:

[flaviostutz]

Great! So... what do you think... this will be a server/gui project or just a library for showing the options?
Like... will it show a GUI and then record the responses to a database (like Limesurvey) or will it provide just a Javascript library, or even a bunch of APIs?

[tiagostutz]

I think this could be designed as a full service, something like https://www.appcues.com/
This way, the service would have its own admin area and the user would "install" it by placing a JS snippet that would bring up a Widget.
The user would import its data to the application by importing an Excel or CSV file, for instance....

The widget could have some parameters to define how it will be rendered... it could be a modal, could be rendered inside a HTML component defined by passing its ID... etc.

What do you think?

[tiagostutz]

Looks like Youtube and Wix were reading this issue. This just appeared to me this pre-roll Ad:

XD

[tiagostutz]

So, for now we could create 2 repos:

1. stop-analyzing-api
2. stop-analyzing-widget

In the future we create other repositories for the customer area, landing page and so on

Any thoughts?

[flaviostutz]

Great!
What about a "demo" repo as a show case/example of usage of the service embedded to another website?

[flaviostutz]

Or the experience won't be integrated to any existing website?

[tiagostutz]

The demo project could have 4 quick-start websites using stop-analyzing to show that it is stack "agnostic":

1. React
2. Vue
3. Angular
4. Pure HTML/JS/CSS

Cool?

[flaviostutz]

Great... so we are going to deliver a bunch of backend APIs that runs in container, and we will have a bunch of widgets that are used to show those "surveys" integrated to any thirdy party website (that could be written in React, Vue, Angular, Vanilla etc), right?
It this is it, it "will" be cool!

[jairsjunior]

The demo project could have 4 quick-start websites using stop-analyzing to show that it is stack "agnostic":

1. React

2. Vue

3. Angular

4. Pure HTML/JS/CSS

Cool?

another option can be embed iframe link to use like youtube

[tiagostutz]

Excelent idea, @jairsjunior

So,we could built 2 frontends: one for the widget approach and the other for the embed. That’s awesome because there will be more Poppins projects for the community to work with.

Now, about the widget, whats a good Framework choice to build widgets? I haven’t done my research yet...

For the embed frontend, I think we could go with the god’ol ReactJS, but with Typescript 😉

For the API I think we could use Go with prisma.io/mongodb for the graphQL enable persistence API.

What do you think?

[tiagostutz]

I was checking some chat support providers widget and some of them uses an approcah of having part of the code injected in the HTML and inside of this code there's an iframe with the chat application. So, it looks like we could use any JS Framework we prefer in the widget because it makes sense to built it like an iframe.

So, Angular or Vue for this one?

I'm suggesting to use different web frameworks on the embed and the widget projects so we can offer more options for those looking for a Poppins project.

[jairsjunior]

Now we have a dilema:
Choosing Angular we will create less friction with our employees and choosing Vue we will create a oportunity to them learn something new. I was tempted to use Vue but i'm really concernead with the friction.

[tiagostutz]

Yeah, I was wondering about that too...

Well, I'm thinking about the community aspect in our decision and in the last Stackoverflow Developers Survey the second and third most loved web frameworks were React and Vue and Angular was the more dreaded.

So, based on this criteria, I vote for Vue.js.

https://insights.stackoverflow.com/survey/2020#technology-most-loved-dreaded-and-wanted-web-frameworks-loved2

https://insights.stackoverflow.com/survey/2020#technology-most-loved-dreaded-and-wanted-web-frameworks-dreaded2

[tiagostutz]

Also, thinking about that friction and the community aspect, maybe we could build the API in NodeJS.

What do you think?

[eabili0]

I was checking some chat support providers widget and some of them uses an approcah of having part of the code injected in the HTML and inside of this code there's an iframe with the chat application. So, it looks like we could use any JS Framework we prefer in the widget because it makes sense to built it like an iframe.

So, Angular or Vue for this one?

I'm suggesting to use different web frameworks on the embed and the widget projects so we can offer more options for those looking for a Poppins project.

Why React has not been considered?

[tiagostutz]

There will be two different Frontends: one that will be for embedding stop-analyzing (lime youtube video) and other for popping it as a widget (lime livechat widget).
The embeddable project will be built with React+Typescript. That’s already decided. The Widget project is the one we are deciding between Vue and Angular. Any opinions on this?

[eabili0]

Oh, I get it now. Although Vue.js is in a better trend, we shouldn't discourage the community to pursue Angular options.

I believe a Widget specification project would be welcomed. From there the community can create the repos in the languages/frameworks they desire. If anyone in the community finishes the specification in a specific language/framework, they can then send a PR do the specification project asking it to be listed as an official widget implementation (much like what is today possible in Big Brother's list of supported libs).

What do you think? Does it make sense in this situation?

[jairsjunior]

Vue has my vote!
About the API, NodeJS is a great option too but why not push a little bit more at this part?

[tiagostutz]

Vue has my vote!
About the API, NodeJS is a great option too but why not push a little bit more at this part?

Sure... and with Prisma.io on the play the API won't be that dramatic. It will even be a good option for beginners in Go. Nice, let's do it in Go then.

[tiagostutz]

Oh, I get it now. Although Vue.js is in a better trend, we shouldn't discourage the community to pursue Angular options.

I believe a Widget specification project would be welcomed. From there the community can create the repos in the languages/frameworks they desire. If anyone in the community finishes the specification in a specific language/framework, they can then send a PR do the specification project asking it to be listed as an official widget implementation (much like what is today possible in Big Brother's list of supported libs).

What do you think? Does it make sense in this situation?

I think the ideia is a bit different than I was thinking. The idea of the widget here is not to be a lib (or component) to be imported and used in the user's code. The ideia is to be a standalone widget enabled in the user's website by placing a JS snippet in the users website, much like those livechat solutions like Intercom, Crisp, Drift and so on... that's why I don't think we need a spec for it.

I think that there could be a demand for a lib in a near future and your proposal is a good big picture, but I prefer the spec by example approach instead of the spec and then example. So, instead of having the spec as the zero step, I think we could have an implementation as the zero step and then extract the spec from it, building this spec project and referencing this first implementation in the official list, as you proposed. But I think we can focus now in the Widget and iframe approach because they can be integrated in websites using Wordpress, Ghost, e-commerce platforms without needing big code intervention.

What do you think?

[eabili0]

I think the ideia is a bit different than I was thinking. The idea of the widget here is not to be a lib (or component) to be imported and used in the user's code. The ideia is to be a standalone widget enabled in the user's website by placing a JS snippet in the users website, much like those livechat solutions like Intercom, Crisp, Drift and so on... that's why I don't think we need a spec for it.

Oh ok. I misinterpreted then. Sorry for that!

but I prefer the spec by example approach instead of the spec and then example

Agreed.

With regards to the frameworks, maybe we should just add a note to the readme welcoming contributions towards Angular, Svelte, etc. Makes sense?

[tiagostutz]

With regards to the frameworks, maybe we should just add a note to the readme welcoming contributions towards Angular, Svelte, etc. Makes sense?

Totally! Waiting for this PR ;) hehehehehehe.

So, I'm going to create those projects now.

[rafamarts]

Very nice this idea of "stop analyzing" tools.

For the solution, I was wondering if we can make a little questionnaire for the customers (brides), asking about the height, weight, then the tool can match the biotype of models with the biotype of customer. This way the dresses could be better addressed to customers. Only to let it documented, because this is an issue to be discussed with the requisites.

Technically, my vote is to use Vue.js. But, I think that we can consider use Node.js, because a ton of projects inside BB is using Node.js. We need to define if our idea is give opportunity to community (employees) increase the experience in Node.js, so they could help in existing BB projects, or only give opportunity to learn a new technology?

[tiagostutz]

Technically, my vote is to use Vue.js. But, I think that we can consider use Node.js, because a ton of projects inside BB is using Node.js. We need to define if our idea is give opportunity to community (employees) increase the experience in Node.js, so they could help in existing BB projects, or only give opportunity to learn a new technology?

The goal here is to create a project that is friendly to open source beginners and help them to gather some experience in this type of project and interaction (like we are doing here), regardless of the technology we are using. So the open source experience is the main goal here. Also, the ideia is not to limit to Banco do Brasil staff. Now, as we are bootstraping, we are the only ones working on this project, but in a near future we are inviting some fellas from other companies that want to learn open source in practice to join those Poppins projects.

At the same time, we are used to explore new technologies in a hands on approach whenever possible in projects that are not timebox critical or needs heavy stability. So, I think those Poppins projects are perfect for this porpuse too - even thoug the main objective of them is not the technology learning itself. What we have to analyze is whether the technology choice can be a barrier for the open source learning experience. If its not, then it will be a good opportunity to bring open source and new technology to the same experience.

That's why I think we could stick to the Go lang for the API. Makes sense?

[rafamarts]

Yes, it makes sense. Let's do it! Very excited to start to develop!

[tiagostutz]

First project created and initialized:
https://github.com/bancodobrasil/stop-analyzing-embed

[flaviostutz]

So, let's sum it up to clear up things:

• Backend: Golang for API services + Prisma for data services
• Standalone UI: React Native + Typescript
• Widget UI Component: Vue.js as UI framework

Is it?