#484 Redesign the easyfix page
Opened 3 years ago by jflory7. Modified 2 years ago

= Summary =

The [https://fedoraproject.org/easyfix/ Easyfix page] in Fedora is helpful for pointing new contributors at things they can tackle, but it doesn't fit the modern theme for Fedora and could use a UI/UX rehaul.

= Analysis =

  • Deadline: No hard deadline - Fedora 26??
  • Developer: Yet to be determined (came up in APAC Design Team meeting)
  • Examples: Current site theme fits pre-getfedora theming days - having it match the rest of the Fedora Project theming would be helpful and unify our brand on this important page
  • Type of web project: Mockups??
  • New or existing?: Existing - https://fedoraproject.org/easyfix/
  • Source code: Unknown (CC'd robyduck from Fedora Websites who might be able to help here)

= Implementation =

  1. Review current site design, understand how the easyfix page uses the [https://fedoraproject.org/wiki/Easyfix wiki page] to generate data
  2. Create mockup / new theming for page to match the rest of Fedora's current theme / maybe update UI to be more user-friendly
  3. Begin working with Fedora Websites team on writing updating the code to follow the mockup
  4. Test in a staging instance
  5. Publish new changes, make page for visible within the project

robyduck,

Just wondering if you know where the sources for the easyfix website itself are located?

Yes, sure, here you go: https://github.com/fedora-infra/fedora-gather-easyfix

The easyfix page is just a bit of Html and CSS, the rest is a script, which gets the data from the wiki. If you need changes or help with that, pingou is the person to talk to.

This came up in triage today! Any updates?

@ryanlerch, is this one you wanted me to look at?

Hey this came up in triage today! @kathryng - you taking this one over? I will reassign to you!

Sure. I'm happy to look at this one. :) Apologies for missing the meeting, timezones and all...

still believe a good way is to merge asknot with it

and btw thats a double ticket see #465

@gnokii, the other ticket seems to cover this and other aspects of easyfix (badge comms etc), so both need to remain open I believe.

Here are some initial mockups - any feedback greatly appreciated. I have designed this so it is in line with fedora bootstrap.

1 - HOSTED PROJECTS
- expandable lists which are collapsed by default
- kept sidebar as it is best way to display all projects from outset - but also made expandable lists which are collapsed by default
- projects in sidebar are now grouped by the system they are hosted on
- issue status is now a colour coded label so they are easier to distinguish between
- icons and text added for type (task/defect) and icon added for component (which will say component on hover)
- search box added if functonality permits
- filter project issues by status (open, assigned, new - any others I don't know about?) and type (task, defect)
- sort list of projects by last updated or alphabetical (just an idea - feedback appreciated) - sort by #?

2 - HOSTED PROJECTS (dropdowns)
- Status filter dropdown
- Type filter dropdown
- List shows multiple issues for one project

3 - HOSTED PROJECTS (sort dropdown)
- Sort projects dropdown

4 - BUGZILLA
- sorted by project
- expandable lists which are collapsed by default
- contact information made consisted with 'Hosted Projects' tab
- search box added if functionality permits
- sort list of projects by last updated or alphabetical (just an idea - feedback appreciated) - sort by #?

@gnokii, the other ticket seems to cover this and other aspects of easyfix (badge comms etc), so both need to remain open I believe.

They are the same, I can remember that this topic came up on the FAD and the idea was to offer the easyfix also from side of the design team.

To be honest the easyfix are for starters so people new to the project, so the should be easy accessible for them not tons of collabsed lists no search boxes nothing. Simple after the person has found on out what he wants to do and he thinks he has the skills for hint him to the right easyfix task. That was the idea behind

Ok thanks for the clarification @gnokii.
I will remove the extra functionality added such as the search etc and will make those boxes expanded with no collapse functionality. The point of the expanding boxes was to reduce the amount of content on the screen when the user first arrives but it makes sense to display all the issues from the outset.

Hi @kathryng!

Thanks for the mockups! These look great! Some thoughts:

  • I love how you have the contact info for each project. Makes it really clear how to get help / mentorship. Have you considered adding an avatar for each contact too? It might make them more approachable?

  • I think the distinction between different project hosting sites / ticket platforms (pagure, bz, trac / fedora hosted, github, etc.) is probably less important to people looking for stuff to help with than things like the skill set required (design, python, ruby, html/css, etc.) I don't know that the skill metadata is available, but I don't know that it makes as much sense to potential contributors to break the tasks down based on the repo they're on.

  • I'm confused why some ticket systems get a tab (fedora hosted, bugzilla) and some are in the sidebar on the right? (pagure, github, trac (trac == fedorahosted)). What's your thinking there?

  • The tickets that are already assigned are probably the least interesting because nobody wants to work on a ticket someone else is working on. i'd consider filtering them to the very bottom or not even showing them at all. (or maybe have the tabs based on the state? open, new, assigned)

  • what's the distinction between open vs new?

  • is there any way we can get metadata about what kind of languages / skills are needed per ticket? i think github offers language stuff. can we talk to the devs of this app to see if they could do some heuristics to make an educated guess? If not, maybe have a direct link to the code repo as part of each item so people can assess for themselves the skills needed?

  • this is a good start to matching the fedora-bootstrap theme (Eg that this site, pagure.io uses.) I think the logo needs a pagure-style icon and treatment (font is montserrat), and i think the sidebar design is a little off from what pagure uses. Let me know if you need help with these sort of visual design tweaks and I can go into more detail.

Does this make sense?

hi @kathryng - this came up in triage. just wondering if you have any updates.

@duffy

Thank you for the feedback.

I love how you have the contact info for each project. Makes it really clear how to get help / mentorship. Have you considered adding an avatar for each contact too? It might make them more approachable?

Good idea, I will add avatars

I think the distinction between different project hosting sites / ticket platforms (pagure, bz, trac / fedora hosted, github, etc.) is probably less important to people looking for stuff to help with than things like the skill set required (design, python, ruby, html/css, etc.) I don't know that the skill metadata is available, but I don't know that it makes as much sense to potential contributors to break the tasks down based on the repo they're on.

Another good idea. I am not a user of Easyfix so I appreciate the feedback. Is a list of all the possible skill sets available? If not, I will add some defaults to my designs.

I'm confused why some ticket systems get a tab (fedora hosted, bugzilla) and some are in the sidebar on the right? (pagure, github, trac (trac == fedorahosted)). What's your thinking there?

I have been referring to the current site design and layout of Easyfix: https://fedoraproject.org/easyfix/ with the two tabs for bugs hosted on the server and from bugzilla. The sidebar lists all of the projects grouped by repo type (which I will change based on your previous feedback). My understanding of this task was to redesign the current EasyFix page (linked above) to be more inline with the Fedora theme used elsewhere.
Is there another better way I should be approaching this?

The tickets that are already assigned are probably the least interesting because nobody wants to work on a ticket someone else is working on. i'd consider filtering them to the very bottom or not even showing them at all. (or maybe have the tabs based on the state? open, new, assigned)

I shall do some filtering, and make sure they are not shown by default.

what's the distinction between open vs new?

I think new means open and recently added, while open means that it is not a recently added issue.

is there any way we can get metadata about what kind of languages / skills are needed per ticket? i think github offers language stuff. can we talk to the devs of this app to see if they could do some heuristics to make an educated guess? If not, maybe have a direct link to the code repo as part of each item so people can assess for themselves the skills needed?

I would be interested in this information also, who would I contact to find this sort of data?

this is a good start to matching the fedora-bootstrap theme (Eg that this site, pagure.io uses.) I think the logo needs a pagure-style icon and treatment (font is montserrat), and i think the sidebar design is a little off from what pagure uses. Let me know if you need help with these sort of visual design tweaks and I can go into more detail.

No worries, I can do this.

Does this make sense?

Yep :thumbsup:

@kathryng awesome :) some responses to your q's above here:

Skill sets

The only skillset metadata I'm aware of is, if the repo is github, github does break it down, eg:
https://github.com/fedora-infra

In the upper right you'll see a legend - blue is python, yellow javascript, orangey-red HTML, etc. and per project there's tags using that color scheme.

I'm pretty sure Bugzilla does not have this. Other issue tracker systems may. Whether or not we could make use of metadata currently out there I think would be up to the person implementing the new easyfix page. I think to know what to do here, will require some digging with a developer familiar with this sort of thing (maybe pingou?). Maybe a thread on the infrastructure list?
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org/

I did ask around on #fedora-devel and sloccount was mentioned as a potential useful tool - https://www.dwheeler.com/sloccount/

If we can't get that kind of metadata, I think the closest you could get to this in the design would be to categorize the issues by the project that owns the issues, and next to the project name have some manually-written description of the project that includes information on the technology used. (or maybe have manually-written tags on a project-level basis. hard to maintain tho :( )

Redesign approach

Well there's two ways you could approach this ticket. One would be to keep it a simple reskinning task, the other would to be a full redesign. I was under the assumption this was a redesign, in which case you can throw out any or all of the existing design if it's not working.

I think the right sidebar on the current site is cluttered and hard to read: i don't think, for example, we need the github org name before each project's listing. eg. instead of

cockpit-project/cockpit (github)
fedora-infra/datagrepper (github)
fedora-infra/datanommer (github)
fedora-infra/fas (github)
fedora-infra/fedmsg (github)
fedora-infra/fedora-packages (github)
fedora-infra/fedora-tagger (github)
fedora-infra/nuancier (github)

Should be

cockpit
datagrepper
datanommer
fas
fedmsg
fedora-packages
fedora-tagger
nuancier

And then i'd categorize from there, eg:

Fedora Infrastructure Backend
fedmsg
datagrepper
datanommer

Fedora Infrastructure Web Apps
nuancier
fedora-packages
fedora-tagger
fas

Fedora Software
cockpit

And to further iterate maybe some on-hover or otherwise non overpowering description of what each is since it's not so obvious from their names.

So it depends how you want to do this - if you want to do a full redesign and improve the UX or keep the UX as-is and just update the skin.

Thanks for that @duffy.

I will ask around on the list about metadata that can be used for the skill set categories.

I am approaching this as a redesign, improving elements of the current site where suitable. I will definitely do some reordering on the sidebar, which will be the best way to show what projects are available while not getting in the way of the side content. I think the LHS content and the sidebar to the right is the best approach for what we need as the sidebar is secondary and not used for main navigation. So as far as the redesign goes, I think the layout is alright - but there is room for improvement in how the issues are displayed.

I will look at removing the tabs so that bugzilla submissions are viewable with the fedora-hosted ones, and will include a filter to change which types of issues are displayed. Any thoughts on this or any other things I have mentioned?

I will get this done in the next fortnight, been busier than expected. I hope that is ok.
I try to make the design meetings when I can, in Brisbane, Australia so the meeting times can be a bit difficult for me.

Logo designs have been included alongside the mockups, I prefer #1 personally

easyfix-logo.png

I have made sure to use the pagure theme treatment for this design.
Removed the new label, as users will only care what is assigned and what isn't.
The projects should be listed from latest updated to oldest, with the option to view oldest to newest -
this allows users to jump straight to the oldest tickets that have not been resolved.

Assigned tickets are not shown by default, but can be turned on using the filter.
I realise that this needs to be a simple site, but I think that filters are necessary to allow users to sort through the issue list.
Alongside filters for issue type, status and source, labels have been included to indicate what group this project is a part of.

Mockup 1 - default

Mockup 2 - filter list shown

Hi @kathryng! I love the bandaid! I don't get the part though?

Thanks for the feedback.
@duffy , I'll remove the code icon. It does seem a bit excessive.

I like this :)
It will include all projects using the easyfix tag actually, right?

I think so. My understanding is that it would include all projects that have issues on the current easyfix website. I am not aware of how those issues are populated to that website.

This is done with this script: https://github.com/fedora-infra/fedora-gather-easyfix

My question was more related to the list of projects you have on the right, but you already answered my question. Thanks.

Any feedback on this design?

Hey @kathryng ! I think the design is pretty great, 1 concern is that right now labels overpower the actual ticket names, since they are so big and colorful. I think they can be smaller than issue names and come after them. What do you think?

I am also not clear on how double dropdowns work, can you please explain further? Thanks! =)

@kathryng I love this updated design. You've really done a great job here applying the feedback and I think it's much stronger for it. I agree with @mleonova the labels are a bit overpowering; i'd scale them down a bit. (maybe we can just use the same CSS pagure uses for them? and limit the color palette?)

@mleonova, @duffy: I shall make the label design smaller and shall limit the colour pallete. I will have a look at what pagure uses.

Also @mleonova , with the double dropdowns, as indicated in this image, it means that multiple options can be selected, and they appear inline in the dropdown selector. https://pagure.io/design/issue/raw/9a8f7162a554895c82109e5fbe238d10410b368944712ef77a8a23d4f6db6439-easyfix-v3-hovers.png

Updated designs (label variations using the same colours as pagure) - I also updated the dropdowns so that it is more obvious which labels are selected.

Mockup 1 - default
Mockup 2 - filter list and project list popover shown

Login to comment on this ticket.

Metadata