ASLO v4 usability/UX complaint/improvement

aperezbios commented 3 years ago

@srevinsaju, From my perspective, there is significant usability regression, when comparing the previous, legacy ASLO, to ASLO v4, because the current ASLO v4 landing page contains no useful information "above the fold", just a very large logo (which, frankly, I don't know the intent of, or understand what value it provides) and search bar. You must scroll in order to "browse" any activities. It seems that it would be worth re-visiting the landing page design to perhaps be more navigable and welcoming. Thoughts?

srevinsaju commented 3 years ago

Agreed, a visual template / layout (something like a figma design) might help to speed up the designing. I myself have no particular skills on designing, etc. I would like to hear about other's opinions too. Thanks for your suggesstion.

Shreyas-SAS commented 2 years ago

@srevinsaju I would like to work on this issue having used Figma for UI/UX design before but from the discussion above I cannot understand the requirement well. can you please explain me what exactly needs to be done.

srevinsaju commented 2 years ago

@Shreyas-SAS the issue seems to be that the current aslo-v4 design (v4.activities.sugarlabs.org) doesn't seem very user-friendly / efficient. So, we would probably like to redesign the UI following some good UX guideline, like resizing logo, moving some components to a different place, adjusting the size, etc

Shreyas-SAS commented 2 years ago

@srevinsaju @aperezbios I would like to break this issue into sub issues as this seems a very large change on the repository as a single issue. increase in issue number can give opportunity to others wanting to work on the issue which will be good for the community.

I have identified the following areas to be good for changes after reference to the present UI. i would like to hear youur thoughts and suggestions on it. More additions are welcomed.

I propose to make the following changes.

shifting logo inside navigation bar.
Linking logo to home page when clicked (bring it back to home page or else refresh on home page).
removal of home button in navigation bar since its just a repetition of the logo functionality.
moving search bar inside the navigation bar.
changing position of theme selector to the right side corner.
Addition of brief description to all activities.
Resizing cards to equal sizes.
Creating a hover effect on cards when mouse is moved on it.
Fixing flappy bird icon in dark theme. (changes to negative along with color inversion of black theme)

Suggested: MAJOR Change: (porting of activities from ALSO to ALSO v4, Activity count: ALSO: 1018, ALSO v4: 17)

Regrouping to fresh issues:

Changes 1-5: Rearranging navigation bar on ALSO v4
Changes 6-8: Re-Designing Cards in ALSO v4
Change 9: Fixing flappy bird icon in dark theme
Porting ALSO activities into ALSO v4 page

Shreyas-SAS commented 2 years ago

Also another addition to the UI would be adding preview images in the activity download pages just like the ones in the play store. it could give the user a better preview of what he is downloading and what to expect. only thing is that this will take a little more time.

quozl commented 2 years ago

Fixing the Flappy Bird icon should be an issue in the Flappy Bird repository.

Porting activities is a different issue, against each activity, not against aslo-v4. (i.e. there's no possible commit you can make on aslo-v4 to fix that, rather the commits would be in other repositories).

Same with adding brief description.

We have preview images in some activities in the screenshots directory.

On the page changes, I'd like to see them.

Also please understand the intended audience is elementary school children and their teachers. Design affordances should be chosen for the audience skill set.

Shreyas-SAS commented 2 years ago

@srevinsaju @aperezbios @quozl

Fixing the Flappy Bird icon should be an issue in the Flappy Bird repository.

actually the issue happens due to inversion of colors on the ALSO v4 home page, the flappy bird repository only provides 1 image as an icon but when theme is changed ALSO v4 webpage changes that image into a negative, to resolve this issue i believe that change in flappy bird repository will not be useful. the changes must be made in the dark theme folder on ALSO v4 repository only.

Porting activities is a different issue, against each activity, not against aslo-v4. (i.e. there's no possible commit you can make on aslo-v4 to fix that, rather the commits would be in other repositories).

Oh is it, I am sorry for that. we can keep that issue aside for now I believe.

Same with adding brief description.

Description is actually placed in the HTML file of the ALSO v4 repository statically and is actually not imported from activity repository dynamically as deduced from the inspect tab in google chrome developer tools. I believe that changes in the HTML file will only be required for change in visuals at the home page in ALSO v4.

We have preview images in some activities in the screenshots directory.

Oh is it, it will be great as the pain of taking screenshots in every game would be greatly reduced. just 1 thing bothers me regarding pre snaped screenshots, would they be up to date or missing major amendments in the Game visuals?

On the page changes, I'd like to see them.

Surely, I would love to work on them as soon as possible.

Also please understand the intended audience is elementary school children and their teachers. Design affordances should be chosen for the audience skill set.

surely, I would even have suggested changing the theme to a perfect children targeted theme with cartoons and visual effects but in past have been asked to restrict it to a bit formal and not too casual and child targeted when working on the SUGARIZER repositories so will try making is as approachable for kids following a formal UI theme.

quozl commented 2 years ago

Yes, some of the screenshots are old and need updating.

Shreyas-SAS commented 2 years ago

Yes, some of the screenshots are old and need updating.

oh, ok. then it will actually need us to click latest images rather than investing more time on checking whether or not the images are up to date. the same images can also be uploaded on the images repo so that they are made available for any other future contributions. For now I will keep this issue noted and will start working on the issues after my exams end.

For now I will be working on the changes 1-8 under 2 new issues addressing the same.

The other issues are free for anyone to contribute or I will start working on them in my summer vaccations alongside GSOC.

quozl commented 2 years ago

Thanks.

I've closed the issues as duplicates of this issue. I don't think more issues are needed, as the issue here https://github.com/sugarlabs/aslo-v4/issues/71 is well-defined. When you do any work to solve this issue, mention it in your pull request. A pull request that doesn't entirely solve an issue is fine, as long as some improvement is made.

There's no need to tell others you are working to fix an issue, as the chances of more than one person working on an issue in this repository is very small.

Overall, if you have time to work on anything, the more important problems are those you have already highlighted; the lack of activities available for download. We need people willing to do that essential work. That work is so obviously a need that we don't track it via issues.

Shreyas-SAS commented 2 years ago

I've closed the issues as duplicates of this issue. I don't think more issues are needed, as the issue here #71 is well-defined. When you do any work to solve this issue, mention it in your pull request. A pull request that doesn't entirely solve an issue is fine, as long as some improvement is made.

yeah, I am fine with it. but I would like to still place my commits in 2 different PRs. I actually would have loved if I were allowed to work with 2 different issues to track the work but its fine. I thank you for the time you invested to reply to me of your busy schedule.

quozl commented 2 years ago

Thanks, but it doesn't matter if an issue is solved by one or a hundred commits or pull requests, as long as there is forward progress. Two pull requests seems a very small number of pull requests for the amount of change required. If there's a chance the forward progress isn't obvious, then make sure the commit message explains it. See our guide to writing commit messages. I suggest your next step is to get started with the easy changes, and make pull requests for them. When working alone, you track the work yourself. Our respective schedules are not relevant. Use the time you have available.

Shreyas-SAS commented 2 years ago

just wanted to tell that I might not be able to fix the issue with my current skillset, the website has an extensive use of sass while I have a very low experience with it that can be said negligible. I tried to make changes to the file in plain CSS and tailwind CSS but failed, thought I could solve atleast some issues if not all but it seems it will be too early to make all commits.

I have noted down the issue in my diary and will work on the issue after I get a better exposure with sass. maybe in roughly 2 months.

@quozl @srevinsaju I am really sorry for the inconvinience and trouble caused to you.

Shreyas-SAS commented 2 years ago

I will try to contribute to some other issues in sugarlabs repository meanwhile

quozl commented 2 years ago

Interesting, thanks. You've reinforced my opinion that pull requests are the most critical and necessary first step for new contributors. :grin: When you look for things to do in other repositories, please assume that 99% of the opportunities are not listed as issues and never will be. You have to learn what the software is for, how it is used, what it does well, and what it doesn't do well.

Shreyas-SAS commented 2 years ago

Interesting, thanks. You've reinforced my opinion that pull requests are the most critical and necessary first step for new contributors. :grin: When you look for things to do in other repositories, please assume that 99% of the opportunities are not listed as issues and never will be. You have to learn what the software is for, how it is used, what it does well, and what it doesn't do well.

Didn't get it well, but i don't know why it feels like sir didn't want me to work on the issue. Well if that's the case still i am fine with it. You can always ask me not to work on the issue if our thoughts don't match. I wouldn't be angry or anything. 😂 One of the main things for working on an issue is not just contributing blindly but to understand what your organisation and mentors expect and want from you. If the frequency doesn't match, it might be an awkward situation for both.

Just that not being able to solve the issue does not mean that the 3.5 hours i invested in understanding the code base and trying to implement changes that didn't work out as expected were wasted. For the fix I had to surf through the entire repository and understand the code on what exactly is going on. In short it helped me understand ALSO v4 better. This will definitely help in other issues and the projects i target for GSOC. Maybe i will even be able to implement the same issue in near future. But since sir doesn't want me to work on it i will remove it from my diary of pending issues. Still i am thankful to you for not pointing it out at the start and letting me understand the repository so well.

Also to mention. I disagree with not creating an issue. If there were no simple issue in this repository that i felt i could implement, i wouldn't even have tried to contribute to ALSO v4 repository. Leave aside placing a PR. The term UI and UX design in the issue were complex for someone who just completed a sass tutorial but when i created the new issues i broke them into achievable parts. These could be attempted by other contributors who are just getting started and have a previous experience with SASS. This can bring in contribution to dormant repository in case anyone passes by, like i did. I wish you would consider my reasons for creating issues.

But I still feel that thinking that creating extra issue is just a waste of time and new contributors must learn the whole software without a goal (like solving an issue) and then find problems after which they solve it with a PR would be quite a lot to expect from a contributor. At least for me if the issue on UI/UX design were not there I would not have worked on this repository.

I am grateful to you and @srevinsaju sir for the time they invested on me even though i could not solve the issue presently.

quozl commented 2 years ago

I don't want you to misunderstand my intentions. I would like you to work on this issue. I'd like everyone to work on it, but that is wishful thinking. I'd like to work on it too, but I don't have the time right now, because I lack time, and there are more important things to work on first. I have been a mentor before, but I am not a mentor this year. Thanks for breaking your work into smaller parts, but that's something you can do without creating GitHub issues; e.g. by adding check items in a list to this issue, or to an empty pull request. GitHub has automatic progress determination for pull requests by counting the number of check items that have been checked.

Check items in Markdown look like this;

* [ ] step one,
* [ ] step two,

Shreyas-SAS commented 2 years ago

I don't want you to misunderstand my intentions. I would like you to work on this issue. I'd like everyone to work on it, but that is wishful thinking. I'd like to work on it too, but I don't have the time right now, because I lack time, and there are more important things to work on first. I have been a mentor before, but I am not a mentor this year.

Oh. I guess i took it the wrong way. I am sorry for the misunderstanding. Even i would love to work on this issue after i gain the required skills. But even if it was so it generally is a good practice in itself to clarify if ones frequency doesn't match. I fully respect that way as well.

Thanks for breaking your work into smaller parts, but that's something you can do without creating GitHub issues; e.g. by adding check items in a list to this issue, or to an empty pull request. GitHub has automatic progress determination for pull requests by counting the number of check items that have been checked.

Hmm. I completely agree. To think now i could have added checklist rather than create a new issue.

But regarding creation i would suggest that more number of issues will be preferable as most first time contributors will look for issues especially with good first issue tag. Also breaking this big issue down to pieces will be more attractive as it reduces the work burden on individual contributor. The task will look smaller. But yes addition of check marks will be equally welcoming.

At last i would like to apologize once again for the misunderstanding and say thank you for your quick response. I will contribute to this issue as soon as possible. You can count on me for this.

srevinsaju commented 2 years ago

A single issue with multiple checklist items as @quozl suggested helps to keep the idea/objective of the issue/change simple. This helps a completely new contributor to come up with a different approach, than that mentioned by Contributor A, for example. If multiple issues are created, it is very likely that the new contributor would follow the idea as specified by the issue title and description alone, and we would possibly miss an opportunity to accept the idea with the simplest / efficient implementation.

In the changes you have proposed in the previous comment, it would be best to see how it would look before we decide to invest time in changing them. That was one idea of the figma render, design layout, since its highly unlikely for us to agree on a design on the first try, but over repeated renders, reviews and comments, we might be able to come up with a simplified task list, but with a clearer goal on what we are trying to achieve, and how the UI should ideally look after the subtasks in an issue are completed.

quozl commented 2 years ago

I agree with @srevinsaju.

Developers do work on source code without the skills, and I suggest @Shreyas-SAS should go ahead and try that. I know I have no experience with Sass (syntactically awesome style sheets), but I know I can learn a new API or language in a few minutes rather than weeks, so I looked at the repository briefly just now.

Curiously, there is no use of Sass at all in this repository. I suspect @Shreyas-SAS has misidentified the dependencies or interpreted an early software service name as if it is a dependency. Following early review feedback the name "saas" was changed to "aslo-v4", but the change was not comprehensive.

(there is a class reference to sass-navbar, but it is a typo for saas-navbar).

As for good first issues, while they can be helpful if there are a lot of developers, they are a waste of time for repositories that have no developers. The time spent creating the issue is almost never rewarded, and in my experience it is always better to fix an issue than teach someone else how to fix it. The idea of good first issues does not scale here. I've no wish to deceive a new contributor by making it look way too easy to get involved, but I don't want to make it hard either. It is best to collaborate at the pull request level than in issues. Let's just fix stuff instead. :grin:

Shreyas-SAS commented 2 years ago

A single issue with multiple checklist items as @quozl suggested helps to keep the idea/objective of the issue/change simple. This helps a completely new contributor to come up with a different approach, than that mentioned by Contributor A, for example. If multiple issues are created, it is very likely that the new contributor would follow the idea as specified by the issue title and description alone, and we would possibly miss an opportunity to accept the idea with the simplest / efficient implementation.

In the changes you have proposed in the previous comment, it would be best to see how it would look before we decide to invest time in changing them. That was one idea of the figma render, design layout, since its highly unlikely for us to agree on a design on the first try, but over repeated renders, reviews and comments, we might be able to come up with a simplified task list, but with a clearer goal on what we are trying to achieve, and how the UI should ideally look after the subtasks in an issue are completed.

Hmm. I agree completely. The point sir raised here seems valid.

Shreyas-SAS commented 2 years ago

I agree with @srevinsaju.

Developers do work on source code without the skills, and I suggest @Shreyas-SAS should go ahead and try that. I know I have no experience with Sass (syntactically awesome style sheets), but I know I can learn a new API or language in a few minutes rather than weeks, so I looked at the repository briefly just now.

Yes i completely agree. Thus i stopped trying for now till i gain some experience with the required technologies.

Curiously, there is no use of Sass at all in this repository. I suspect @Shreyas-SAS has misidentified the dependencies or interpreted an early software service name as if it is a dependency. Following early review feedback the name "saas" was changed to "aslo-v4", but the change was not comprehensive.

(there is a class reference to sass-navbar, but it is a typo for saas-navbar).

I actually don't know either. But of what i know changing plain css was not working at all. So i assumed it must be due to sass as it was mentioned in many places.

As for good first issues, while they can be helpful if there are a lot of developers, they are a waste of time for repositories that have no developers. The time spent creating the issue is almost never rewarded, and in my experience it is always better to fix an issue than teach someone else how to fix it. The idea of good first issues does not scale here. I've no wish to deceive a new contributor by making it look way too easy to get involved, but I don't want to make it hard either. It is best to collaborate at the pull request level than in issues. Let's just fix stuff instead. :grin:

I actually don't know much about low traffic repositories and the point raised actually does suffice me. Even if we keep an issue open it will take long for someone to work on it. But yes it would attract more contributors if we follow that way but changing a dormant repo to an active repo will still be near impossible.

quozl commented 2 years ago

Well, now that we know Sass isn't involved, your changing the CSS and failing to see the change must have had some other cause. Dig deeper.