Design polishing

[smacker]

The part about annotation is done by product team. We need to:

1. Align frontend with latest wireframes
2. Refactor FE to use CSS Grid layout
3. Deploy branch on staging for @ricardobaeta
4. Collect feedback from @ricardobaeta (as css/less)
5. Apply feedback

[ricardobaeta]

The part about annotation is done by product team

Not yet :) This is a team sport.

1. Align frontend with latest wireframes

Not by any means I want to be intrusive, but I would suggest to be on board on this one. Would love to jump on a call for you to explain me how are you handling the UI html/css structure.

2. Deploy branch on staging for @ricardobaeta

✨

(could we have disposable staging environments? would love to be able to build my own with a branch worked by me)

2.5 Invite Interaction Design to the party

It's all about behaviour. I believe before we move to visual design we should address the control over the all experience. The mediation of the collaboration between people and the machine. (extreme.e.g: A beautiful engineer woman, on question one clicks on Finish, what will happen?) Very agile user-jouneys will do the trick.

3. Collect feedback from @ricardobaeta (as css/less)

We'll do this as an experiment. I suggested to do visual design in the browser because I'm quick. Let's hope bootstrap4 handles React well soon, because I tend to fancy sass more. Nevertheless, we should keep in mind to evaluate if this method make us more productive. There are alternatives, like a style-guide for a start.

4. Apply feedback

✨

5. Test, test, test, test

:)

[smacker]

0. It’s delivered and approved :slightly_smiling_face: @mnovaes will formally announce it when he gets the swing of things! sounds like it's almost done (at least the first iteration which we can work with)

1. We will explain you everything, no worries. Maybe not me but @dpordomingo or @ricardobaeta All of us are partly frontend developers.

2. You can run it locally. (how to do that is explained in README and we will improve documentation soon) But in my opinion, we need to have staging anyway. In case somebody else want to take a quick look and give feedback (test! test! test! :-D) In my opinion it will be like you clone staging branch, apply changes. When you like it you push, it gets deployed, product team collects feedback, you apply changes. When you like it you push, it gets deployed, pro... and so on.

3. And 2.5. Don't really get what you mean. We will have staging. You can push your branch and it will be deployed to staging. You can show it to anybody, test and work on feedback. Is it Interaction Design? Anyway it's a long process on your side. But this task is for developer and it's out of scope for a developer. If you need to extend Backend: REST API #3 from product side (describe what particularly you need to do to provide us the final result) just create another issue and link it here!

4. Because you will provide css/less/jsx, this one is more about review from dev side and some help if any is needed.

[ricardobaeta]

0. at least the first iteration which we can work with

Precisely. The basilar asset for the creation of the UI, and it's called information design ==
the spacial placement of UI building blocks from the most atomic to the most generic & from the actionable to the informative, the building of a clear visual hierarchy and information correlation and the creation of a narrative - immature though - for the experience.

1. We will explain you everything, no worries.

✨

2. In my opinion it will be like you clone staging branch, apply changes. When you like it you push, it gets deployed, product team collects feedback, you apply changes. When you like it you push, it gets deployed, pro... and so on.

The concept of disposable staging environments:

###staging.code-annotations

staging.code-annotations.sourced.tech

The latest deploy from App Team, and everybody sees the same. Represents App Team latest iteration and it should be seen as the single source of truth that reflects the development stage. The story goes like "Vadim, check that last great thing on staging". It's the place where you have approved design & engineering proposals, for testing, and getting it shipped.

###staging-name-of-branch.code-annotations

staging-new-header.code-annotations.sourced.tech

The latest deploy from any of us, but the point is for me to be able to do it, and it's not every push but rather configurable ones. It's based on sharing amongst specific people, experimental changes that are subject to Management Assessment. The story avoids like "Maxim, can I use staging to show something to Marcelo?". Needless to say, we can run things locally but I've learned in the past that we move solid when we're able to expose an experience for evaluation in the most effectively integrated fashion.

3. Is it Interaction Design?

Interaction design per se is a different UX discipline. I would suggest for you to start understanding the Five Dimensions of Interaction Design

[smacker]

@ricardobaeta thanks a lot for educating me! I'm not very aware of most of terms you use 😅

about staging per branch, I like the idea. In my previous jobs, we called it showrooms and it was very useful! I think @bzz can help us to clarify is it possible to do here or not.

[bzz]

Let me look into that!

[dpordomingo]

@src-d/infrastructure discarded initially the idea of having as many hostnames as branches they could exist. I'm not sure if they could change their mind. (imho it would be really great!!!)

One alternative they proposed, was to have a limited number of them,
like: staging[1-10].code-annotations.sourced.tech
but we discarded it because it was not needed when we met about it.

I wouldn't say it would be really-really needed to have more than 3 envs.

• prod, the latest tag as currently done in web apps (or the tip of master if we're sure enough),
• dev, the tip of the release-candidate-v..., that contains already approved but not released features,
• staging, whatever we could have in staging branch, being used for testing/validation purposes.

Now, we only have prod and staging.

The rationale behind that agreements was recorded in the following two minutes:
landing-cd-workflow and enforcing-cd-workflow

[bzz]

Guys, sorry, so far this just an internal tool and investing effort in such automation seems preliminary.

We will have a single deployment for @ricardobaeta next week, progress on that could be tracked under #30

[bzz]

Initial work on design polishing is done, subsequent work is going to be tracked in separate issues