Add differentiating badge icon for issues and PRs

[bipplane]

Summary:

Fixes #480

Type of change:

• ✨ New Feature/ Enhancement

Changes Made:

• Added distinctive 'I' and 'PR' badge-titles in the top-right corner of cards to distinguish between issues and PRs.
• Colour scheme follows the border colours of the individual card.
• Added margin to card title to prevent overlapping with badges.
• Added Hover tooltips to badges showing "Issue" or "Pull Request" for better User Experience.

Screenshots:

Homepage

Hover tooltips

Proposed Commit Message:

Add distinctive I/PR badge-titles to distinguish between
issues and PR

Added purple badges with dynamic colours matching border states:
- Circular 'I' badges for issues
- Rectangular 'PR' badges for pull requests
- Color-coded based on issue/PR status (open/closed/draft)
- Hover tooltips for better user experience

This allows users of WATcher to quickly identify types
and statuses of cards at a glance, without causing as much
chaos as compared to using background colours.

Checklist:

• I have tested my changes thoroughly.
• I have created tests for any new code files created in this PR or provided a link to a issue/PR that addresses this.
• I have added or modified code comments to improve code readability where necessary.
• I have updated the project's documentation as necessary.

[NorbertLoh]

Nits to fix. Perhaps we should see if @damithc is ok with the colour choice. Otherwise LGTM! 👍

[bipplane]

this could serve as a starting point for default colour.

in the future, maybe we could let users choose their own desired colour for both issues and prs.

[damithc]

Nits to fix. Perhaps we should see if @damithc is ok with the colour choice. Otherwise LGTM! 👍

I'm OK with the colour. One downside is that we use purple to indicate the merged status. But I can't think of a better choice either.
One alternative is to use light purple for merged PRs, light red for closed PRs, and light green for open PRs (and light grey for draft PRs?).
The differentiation between issues and PRs is that issues don't have a background colour while PRs do. But not sure if using multiple bg colors will make the UI look too chaotic 🤔

[bipplane]

I'm OK with the colour. One downside is that we use purple to indicate the merged status. But I can't think of a better choice either. One alternative is to use light purple for merged PRs, light red for closed PRs, and light green for open PRs (and light grey for draft PRs?). The differentiation between issues and PRs is that issues don't have a background colour while PRs do. But not sure if using multiple bg colors will make the UI look too chaotic 🤔

i agree that multiple bg colours would probably not work well. and from a user's perspective, questions like 'what does this colour mean' and 'why is it in this colour' may also be potentially brought up in the future.

changing the background colour was a pretty simple implementation in my opinion - if given more time, i can try to work something out and see if i'm able to have distinguishing features, without causing too much chaos in the current UI.

[bipplane]

hi all, I have addressed the feedback and pushed new commits, this time using a badge display to differentiate issues/PRs instead of background colours. do let me know your thoughts!

[NorbertLoh]

hi all, I have addressed the feedback and pushed new commits, this time using a badge display to differentiate issues/PRs instead of background colours. do let me know your thoughts!

This is a tough one. It does help in identify PR and issues especially when both are open.
Here is an example

Let's see if anyone else has any comments before we merge.

[damithc]

This is a tough one. It does help in identify PR and issues especially when both are open. Here is an example

Let's see if anyone else has any comments before we merge.

hmm... the icon on the other end already differentiates between issues and PRs, right?

The background colours was meant to give a visual cue at a different level e.g., it helps the user catch unbalanced issue-PR distribution immediately even if the user is not looking for it(e.g., someone doing a lot of PRs but without corresponding issues or vice versa -- normally, we expect one PR per issue).
So, I'm not keen on merging the current version.