I am done with the project set up in my local system and also gave good time to understand the UI. What are the initial things that I have to focus on in order to improve the UI?

Some of the feedback from my side
1- We can use Material UI or ANT design for better component support. These components are highly customizable and we will get proper structures to display our information.
2- We can follow a proper project structure where we can distinguish between the presentational and container components.
3- Taking the points mentioned in the feedback we can separate the information on our landing page into different components, which are currently present in the landing page folder.
Can you please give your views on this @lbrabec

Some of the feedback from my side
1- We can use Material UI or ANT design for better component support. These components are highly customizable and we will get proper structures to display our information.

Using Material UI or ANT design is a possibility, but I would consider using one of these as last resort. I'd rather stick with bootstrap as there is official Fedora theme which is used by many Fedora apps (to name a few: Pagure itself, Bodhi, Blockerbugs, Packager Dashboard). This way, all the apps look and feel the same.

2- We can follow a proper project structure where we can distinguish between the presentational and container components.
3- Taking the points mentioned in the feedback we can separate the information on our landing page into different components, which are currently present in the landing page folder.

Refactoring the code and splitting components is definitely something that has to be done. Do you have any particular approach in mind? If so, try to provide some examples.

Thanks!

My approach is as follows:

We can divide our project structure into components and containers. The components folder will contain the reuseable components such as the navbar, card component which can be re-used for different sections of the landing page. This card component will have the functionality to disable and enable itself, which will prove to be more user-friendly as in the current implementation user has to click on a different button to show the disable, enable options. In this component folder, we can have other reuseable components such as buttons, input boxes (if needed), etc.

Containers will use these components and each container will have a separate reducer, actions for better functioning, and separation of concern. To give an example of a Container, currently, we have one container i.e Home page. If we decide to add more pages they can go into the container section. Like splitting the timeline meeting schedule/ view and blockers/FE's on different routes.

Apis(fetch request) will come into the API folder where we can document them better and use those API in our actions present in respective containers.

So the src folder will look somewhat like the following:

@lbrabec, Can I work on improving the UI of the wizard page up next?
The collapsible used here is rendering the component below all three entries.
I think it'll better to show the opened section just below each section.
Also to mention that the click to close doesn't work as of now.

Dummy folder structure:
src
- api
-- api.users.js
- components
-- navbar/
-- meetings/
-- blockers/
-- footer/
- containers
-- landingpage/
--- action.js
--- reducer.js
--- index.js
- errors
- assets
- utils
- index.js
- app.js
- configstore.js
- reducer.js
kindly give your feedback over this @lbrabec

@lbrabec, Can I work on improving the UI of the wizard page up next?
The collapsible used here is rendering the component below all three entries.
I think it'll better to show the opened section just below each section.
Also to mention that the click to close doesn't work as of now.

Sure, we can try this and see how it looks.

But ultimately, what I envisioned is some step wizard (something like this).

Dummy folder structure:
... snip ...
kindly give your feedback over this @lbrabec

Yes, something like is a direction I want to go. We should also consider redux toolkit for this change.

Ok, I am working on changing the folder structure a bit and will let you know, once I have completed a part of the code splitting and using redux toolkit. After the review, we can proceed with our discussion.

Also, I would like to mention that parallelly I can work on adding the tooltip to the question mark icons, which are currently non-functional. I hope this is required for the UI improvement.

@lbrabec, Can I work on improving the UI of the wizard page up next?
The collapsible used here is rendering the component below all three entries.
I think it'll better to show the opened section just below each section.
Also to mention that the click to close doesn't work as of now.

@lbrabec, I guess we should make it work.

Also, I would like to mention that parallelly I can work on adding the tooltip to the question mark icons, which are currently non-functional. I hope this is required for the UI improvement.

Sure, the tooltips should work.

I think the content on the landing page are too closely packed together and will need some breathing room on all screen sizes. On larger screens, there is a lot space not being utilized and on smaller screens the difference between sections fizzles away. I would suggest resizing and realigning the different sections and placing emphasis on the development schedule being a headline of the page.

hello @divyanshisingh can i join you in improving the ui and user experience?
which of the functionalities have you already implemented on your end??
which one can i start working on?

hi @lbrabec @divyanshisingh @manishakanyal @lindah I have an idea lets have a meeting on a google hangout to break this page into smaller components then we can work on it fairly I live in the UK please provide me with time all you can so we can meet and discuss on design and break this down into the smaller components.

yea @alisina92 , this is a great idea.
I am in Cameroon and am open to when ever the meeting is to be held.
though I received an email saying the mentors have public holiday in their country, so they will only be available after the 5th of April

@queeniva I am sorry I forgot to tag you. No offence. I believe all of us can collaborate on this page there is a ticket for everyone on this issue. let see when all people are available.

none taking .
yea, that's for sure, we can collaborate and transform the page

@alisina92 this is a cool idea. But I suppose we would decide this by Tuesday as @queeniva said. I live in Nigeria so timing wouldn't be a problem for me. anytime is fine by me.

@lindah Yes that Why I need each people to give a date and time UK time, please

Hi, @lbrabec @divyanshisingh @manishakanyal @lindah @queeniva I hope you had a nice holiday. I am going to set up a meeting for tomorrow 8th of april 17:00 UTC 18:00 BST to discuss this ticket as a team you are welcome to join me in here:

https://meet.google.com/fyq-xmbq-unk?authuser=2

ok, great

Hi, sadly both @lbrabec and I have a conflict at that time, but that absolutely does not mean you should scratch the meeting! We are happy to see you are reaching out and calling for a group effort on what is, essentially, the core problem to solve during the internship.

As such, I just need to make it clear, that this ticket is not really about "making the technological changes" as it may seem from some of the comments about the project's structure or discussions related to various toolkits and components, but about actually making the User Experience (UX) better.

Instead of splitting the Wizard into bits that you'd be individually reimplementing (feel free to correct me if I understood the "break this page into smaller components then we can work on it fairly" wrong), you should instead focus on the actual UX. You, as a group, are virtually the precise target audience, so your opinions and ideas about the usability can have profound impact on the project. Try using the Wizard (if you don't have it set-up locally, this should be available: http://37.205.14.49:5555/wizard ), and then collectively gather and compose structured feedback.

Note for context: The current form is not a representation of the "visual" but of the "way to present the information". We have (sometimes seemingly very complicated) processes, that the Wizard should boil down, and present in a digestible fashion to the "uninitiated", instead of scaring people away with the actual walls of texts that we have to describe such processes (to get a bit more in depth, read https://docs.google.com/document/d/11x_g-64d9pkAoXx2fvelG4Lktts2n4YNQqXhhISvufM/edit?usp=sharing ).

Having a reasonable context, and knowing the basis of the decisions is a cornerstone to any successful effort. You could, of course, be splitting the current code into small chunks, and rewriting them, and you could even be fairly successful in the end, but that would not really add much (if any) significant value to the project. The actual coding (WRT this particular Issue) is the proverbial cherry on top of the cake.

So I'd like to use your drive and enthusiasm in the most impactfull way possible - disregard the looks, and focus on the core of the Wizard - the information.
- Have you understood the different choices?
- Have you understood that the information is "layered/trickled down"?
- For each activity
- Is the "manual" making sense?
- Are there terms that you don't understand (even after reading the detailed manual) and you feel like that's preventing you from performing the activity?
- Do you feel the information is complete?
- Are you OK with text, or would you like to see some infographics?

You are in a great position to go through the these and collect structured feedback, and even try to come up with mock-ups/storyboards for what the "good version" could look like. This is the way to have the most impact here, not a "divide and conquer" approach.

As a final note, let me repost a comment I had in a different ticket - At the moment, we are at the stage of evaluating all the candidates, before we need to make the one pick. We are going to look at the code and communication provided in the assessment phase based on how each of you tackled the tickets - comparing solutions of the "same problem" by different people is an integral part of any decision-making process in the context of "hiring", and we find it especially important when looking at "intern" positions.

There can, of course, be "bonus points" if you make meaningful & reasonable PRs/comments outside of these, if you participate in reviews, or other activities outside of the "basic scope".

But at the same time, focusing on the easyfix tasks and delivering the best of your work is enough to get you fairly appraised even in the context of "more active" participants, because we are first and foremost judging on merit.

Hello, @alisina92 I would also like to join you guys in improving the UI. Can I join?

From having a look at the document above, the little discussion I had with @alisina92 and extra research I have done on my own, here are the following things that I feel will greatly improve the UI and the User Experience of the page:

1. The landing page should serve current members and new members as well, so it should provide a comprehensive view of what is happening on the different projects and teams. Eg. Recent test results on different teams. The use of infographics will needed but it will depend on the content being added.

2. The content of the Wizard needs to be worked on greatly. Following most of the links led to issues which addressed one or two things needed but wouldn't be considered a comprehensive introduction. Taking time to create documents that clearly address the issue of joining a team would be most beneficial. The wiki gives an overview and linking to it would be helpful but there's still more needed.

3. The layout of the content of the wizard needs to be improved to give it all a cohesive flow. The current segmentation according to estimated time of commitment makes sense but the sub categories of information can be better positioned to show hierarchy and make the content more intuitive.

4. Some components such as lazy loaders, error pages should be used to handle differences in network latency or other errors.

I could've made more suggestions but the information I had to work with was quite limited. @jskladan @lbrabec what do you think about this?

From having a look at the document above, the little discussion I had with @alisina92 and extra research I have done on my own, here are the following things that I feel will greatly improve the UI and the User Experience of the page:

1. The landing page should serve current members and new members as well, so it should provide a comprehensive view of what is happening on the different projects and teams. Eg. Recent test results on different teams. The use of infographics will needed but it will depend on the content being added.

2. The content of the Wizard needs to be worked on greatly. Following most of the links led to issues which addressed one or two things needed but wouldn't be considered a comprehensive introduction. Taking time to create documents that clearly address the issue of joining a team would be most beneficial. The wiki gives an overview and linking to it would be helpful but there's still more needed.

3. The layout of the content of the wizard needs to be improved to give it all a cohesive flow. The current segmentation according to estimated time of commitment makes sense but the sub categories of information can be better positioned to show hierarchy and make the content more intuitive.

4. Some components such as lazy loaders, error pages should be used to handle differences in network latency or other errors.

I could've made more suggestions but the information I had to work with was quite limited. @jskladan @lbrabec what do you think about this?

@lindah ,I would like to work on the wizard page.. I had also opened it as an issue #58 . So,I would like to work with you.