Add Dislike Information Panel

[sy-b]

Comes after #533

This pr will be updated after the API change & then can be merged. Do not merge unless you want to ask users about their views suggestions.

Wouldn't work as expected

• This isn't fetching anything from the endpoint. The values are hard coded.
• Changes will be made after the inclusion of required API fields

Required API fields

• extensionUsersLikeCount
• extensionUsersDislikeCount
• extensionUsersVotes

partially fixes #114

---

Originally posted in issuecomment-1109344899

Pros & Cons of this panel

• Pros

  1. People had requested variety of things. (I can't even recall 80% of them.) Maybe this can act as a one size fits all approach.
  2. Will work on devices where you can't hover over the button. (It can't rn)

• Cons

  1. Bulky UI
  2. The current way of implementation isn't good for most of the use cases.

I am inclined to reimplement this the way SponsorBlock has if we extpand its purpose.

from: https://github.com/ajayyy/SponsorBlock/blob/0c216792cf1737e13e358411902f4b77dce1725e/src/content.ts#L2095-L2112

function sendRequestToCustomServer(type, fullAddress, callback) {
    const xmlhttp = new XMLHttpRequest();

    xmlhttp.open(type, fullAddress, true);

    if (callback != undefined) {
        xmlhttp.onreadystatechange = function () {
            callback(xmlhttp, false);
        };

        xmlhttp.onerror = function() {
            callback(xmlhttp, true);
        };
    }

    //submit this request
    xmlhttp.send();
}

Also refer: https://github.com/ajayyy/SponsorBlock/blob/0c216792cf1737e13e358411902f4b77dce1725e/src/content.ts#L1666-L1733

This way we can have the same pages shown in popup & panel. Also, having these pages in a separate folder will be better.

---

@Anarios Can you add these fields? Or are you planning to add another endpoint for extension user data?

[sy-b]

Note: Adding button inside YT Player -> idea from SponsorBlock

[sy-b]

Please suggest a better UI or make one if you can.

[cyrildtm]

Speaking of trust level, perhaps we can come up with an empirical model with some maths and programming. if some-- as many as possible-- video uploaders can share their studio data , we may examine the links between these variables: subscribers, views, likes dislikes, ratio. We assume the more extension users the more accurate, but by how much? This quantified concept can become trust level

[sy-b]

video uploaders can share their studio data

This starts the question of "secure sharing & verification of data".

we may examine the links between these variables: subscribers, views, likes dislikes, ratio

While writing #114, I was assuming that creators would upload the data on a regular basis and we'll use these variables

• last upload time & date (trust/accuracy level decreases with time)
• Data upload frequency
• Data Source & their percentage
  (Now mostly useless & very complicated to implement satisfactorily)
  Data sources to consider
  • YT API data before it was pulled down
  • Archived data by archiveteam.org
  • Creator (authorizing RYD to collect their YT data)
  • Extension user votes
• Extension users percentage for that video
• Video upload time (requires the variables you mentioned)
  Recently uploaded videos tend to change vote count rapidly. This depends on creator's audience size.

After the idea of TLS modification method

• Upload method (App using API Key / Creator Studio)
  This is also mostly useless as the trust/accuracy level for that time must be set to 100%. But it's a bit easier to implement as we'll just have to consider time and optionally Upload frequency & extension user percentage as these factors wouldn't have much impact.
  And if the creator's app is uploading it every 10 seconds (YT API allows10k units/day) then there is no need of calculating accuracy level. It can be set to 100%. I find this unrealistic as the server load might be extreme but 1 upload per 5 minutes seems fine. And if possible, this upload per 10 sec upload can be done for live streams.

---

This now seems unrealistic to me.

[cyrildtm]

If we come up with an empirical model, we can just use much fewer existing video sentiments to calibrate it, so no need to constantly upload latest counts for every video. Using a model solves the eternal problem of sharing vs security.

[Nightcaat]

Converting to draft as it is not ready yet.

I think the logo in the player could be a tad smaller to match everything else better

[sy-b]

Converting to draft as it is not ready yet.

👍

not ready yet.

Depends on @Anarios. I am waiting for the changes.

[xHeaveny]

I would use Socal Blade for this ngl

[sy-b]

👍

[MulverineX]

While this more complex UI is useful, a simplified version on hover of the Like/Dislike/Ratio area would be appreciated also, perhaps something like this:

(all dummy data, marked up in Figma)

[MulverineX]

In fact, perhaps instead of embedding that giant panel for detailed data, that can go in the extension popup?

[cyrildtm]

go in the extension popup

That would require message exchange, which is a bit complicated, but it's doable, if desired.
That said, I don't think I will want to spend more than a split second to look into the dislike data.

[sy-b]

Pros & Cons of this panel

• Pros

  1. People had requested variety of things. (I can't even recall 80% of them.) Maybe this can act as a one size fits all approach.
  2. Will work on devices where you can't hover over the button. (It can't rn)

• Cons

  1. Bulky UI
  2. The current way of implementation isn't good for most of the use cases.

I am inclined to reimplement this the way SponsorBlock has if we extpand its purpose.

from: https://github.com/ajayyy/SponsorBlock/blob/0c216792cf1737e13e358411902f4b77dce1725e/src/content.ts#L2095-L2112

function sendRequestToCustomServer(type, fullAddress, callback) {
    const xmlhttp = new XMLHttpRequest();

    xmlhttp.open(type, fullAddress, true);

    if (callback != undefined) {
        xmlhttp.onreadystatechange = function () {
            callback(xmlhttp, false);
        };

        xmlhttp.onerror = function() {
            callback(xmlhttp, true);
        };
    }

    //submit this request
    xmlhttp.send();
}

Also refer: https://github.com/ajayyy/SponsorBlock/blob/0c216792cf1737e13e358411902f4b77dce1725e/src/content.ts#L1666-L1733

This way we can have the same pages shown in popup & panel. Also, having these pages in a separate folder will be better.

[sy-b]

a simplified version on hover of the Like/Dislike/Ratio area would be appreciated

Yeah, but this is inaccessible to mobile users.

perhaps instead of embedding that giant panel for detailed data, that can go in the extension popup?

Judging by the amount of people asking "How to get to the extension setting menu for colors", I can very well say that many people can easily find chrome://extension/whatever-extension-id than a settings button in the extension popup.
I am still inclined to that idea (panel(s) in popup).

I don't think I will want to spend more than a split second to look into the dislike data.

I agree.

[MulverineX]

Yeah, but this is inaccessible to mobile users.

Is this really a use case we should consider? Vanced is by no means dead (the old version works, will work for at least a year, and a new project is almost off the ground) and most others use 3rd party apps that add functionality like RYD. YouTube Web Mobile is trash, and the exclusive use case for touchscreen desktop tablets/2-1's is tiny.

[cyrildtm]

YouTube Web Mobile is trash

So true! I can't even watch a video full screen. Not to mention potato touch control. I never use mobile web version, avoid like plague

the exclusive use case for touchscreen desktop tablets/2-1's

I have a 2-in-1, and I use full desktop version. Mobile UI is nonsense.

the amount of people asking "How to get to the extension setting menu for colors"

You see this is the problem with Chrome. Those smart people think they can educate the human species into knowing things inside the developer's brains. Truth is, no, people will get confused as always.

[sy-b]

Is this really a use case we should consider?

Initial contributors did consider supporting it & most of the extension features are supported on mobile.
But yeah, why people will use mobile UI. ¯\(ツ)/¯ .

^{(I used to use it)}

[MulverineX]

Maybe there's a way to detect long press?

[Sidchou]

would be great if hovering the bar can shows more info like
#564 (comment)
we just need number for user %