You are viewing a single comment's thread from:

RE: Feedback requested: One browser extension or two?

in Steem Dev26 days ago

and I assume @moecki has too

Yes, but I prefer Firefox for "daily" surfing. There are no "official" instructions for this, but it still works.

Now I wanted to install your new extension too. Chrome etc. don't complain at all, only Firefox is not working. The problem with the background service worker is known, but cannot be solved without changing the settings. I have therefore added the browser-action to manifest.json so that it runs on both browser types (Chrome also reports an error, but executes the extension anyway):

{
  "manifest_version": 3,
  "name": "Steem Follower Checker",
  "version": "20240518",
  "description": "Get total number of followers, median reputation, and follower network strength for a Steem account.",
  "permissions": [
    "activeTab"
  ],
  "action": {
    "default_popup": "popup.html",
    "default_icon": {
      "16": "icon16.png",
      "48": "icon48.png",
      "128": "icon128.png"
    }
  },
  "browser-action": {
    "default_popup": "popup.html",
    "default_icon": {
      "16": "icon16.png",
      "48": "icon48.png",
      "128": "icon128.png"
    }
  }
}

I wouldn't add this to the repo for now, as I don't know if you want to offer Firefox support at all. I think maybe we can think about that if you want it to go into the official store.

What I'm wondering though: why did you include the background service worker at all?

Feedback requested

I'm undecided about that. As a user, I would choose option 2, as I have to actively open the follower pop-up window by clicking on the icon anyway and the highlighting of the posts is intentional.
As a developer, I would of course choose option 4 to make it as personalised as possible... and then integrate the follower strength like this (or a little nicer):

grafik.png

Sort:  

What I'm wondering though: why did you include the background service worker at all?

'Cause ChatGPT said we'd need it later. I just took it out of my dev branches in both extensions, and it still seems to work fine. Will that fix Firefox, too? I'm fine with removing it until needed (if ever).

I don't know if you want to offer Firefox support at all

TBH, I didn't even think about it. I stopped using Firefox when Mozilla pressured Brendan Eich into resigning. But I have no trouble posting installation instructions and making simple changes if the same code works there. I just can't do any testing. If you want to give me installation steps for the readme file, I'll happily add them (or I could ask ChatGPT to write them, and you could verify..)

Another factor that occurred to me today is that the original browser extension was only written because we had no expectation of getting changes into condenser at the time. Now that @the-gorilla is making changes, the "right" place to visually notify the user of null beneficiaries and post promotion might be in condenser, itself, so I should probably get his plans on the topic before making any decisions. (hint, hint. 😉)

 25 days ago 

the "right" place to visually notify the user of null beneficiaries and post promotion might be in condenser, itself, so I should probably get his plans on the topic before making any decisions. (hint, hint. 😉)

Hint taken 🙂 I don't have anything concrete planned yet as I've not looked at the "post" data in the PostsIndex view properly but... the beneficiaries are displayed in the payout dropdown so it should be available to the page. I had considered an interface update similar to my alternative interface with one fire representing 25%, 2 representing 50%, etc. So non-intrusive. Now that I think about it, I could implement /promoted in a similar way to how I'm planning to approach "pinned" posts although I don't know if the /promoted posts are given any priority (like the pinned are) in the returned data so it probably won't be as easy as I hope. Unless another query's an option. Which it might be.

In summary:
@null beneficiaries - probably straightforward
promoted - possibly doable.

 25 days ago 

it should be available to the page.

Right. post["promoted"] contains the promoted costs and post["beneficiaries"] the data for beneficiaries.
These data are used for the drop-down menu, the payout items are collected here.

I therefore think that these visual notifs are straightforward to implement.

So non-intrusive

I would very much appreciate that.

it probably won't be as easy as I hope

I'm worried about that too. It is a separate request and is also treated as a separate location on the site. Adding it to another location is probably a bigger challenge.

 24 days ago 

I therefore think that these visual notifs are straightforward to implement.

I think so too although it would be nice to be able to move the "Promoted" higher up the screen... which I might be able to do with an additional API call. I'll have to have a think about that.

From the link you shared, I think that I can copy lines 470 to 481 and tweak it. In fact, I probably don't even need to copy it. The PostList.jsx file already loops through the posts in its renderSummary method so an additional post.get('beneficiaries'); check for null > 25%, along with an additional className on the summary.push will hopefully be all that's required. I can then target the new class in the CSS and add burning flames all around the element #burnitalldown. It might not get signed off but it'll be fun doing it 😆

 23 days ago 

with an additional API call.

That's a way.
But I just remembered what I saw in the logs inside the container:
The promoted posts are updated periodically. Perhaps they are already available in the store and you don't need to make an additional query. But I haven't checked it now.

Extract from the log:

Loading special posts
Loaded special posts: featured: 0, promoted: 0, notices: 0
Loading special posts
Loaded special posts: featured: 0, promoted: 0, notices: 0
Loading special posts
Loaded special posts: featured: 0, promoted: 0, notices: 0
Loading special posts
Loaded special posts: featured: 0, promoted: 0, notices: 0
Loading special posts
Loaded special posts: featured: 0, promoted: 0, notices: 0
Loading special posts
Loaded special posts: featured: 0, promoted: 0, notices: 0
Loading special posts
Loaded special posts: featured: 0, promoted: 0, notices: 0

ok, so I guess there's no harm even if we eventually have some overlap until we see how that evolves.

It seems like there's a general philosophy that I'll have to wrap my mind around: If the community agrees that something is useful/appropriate for all users and accessible, than it belongs in condenser. If it serves a niche purpose, is only relevant to curators, or is difficult to handle on the web site, then a browser extension makes sense.

How many people are you hiring to implement #Proposal-87 next year? 😉

 24 days ago 

How many people are you hiring to implement #Proposal-87 next year? 😉

Ha ha. I don't want Steemit's DAO to go the way of Hive's!

I fully expected to have finished what I need to do with proposal-86 although things are taking longer than I'd anticipated, presumably because I'm being more careful than I would be with my own site. I guess there's also an element of "where does this data come from", etc. Oh, and I hadn't intended to be doing so much JavaScript - my plan was for at least 90% of my work to be CSS whereas the opposite appears to be true. I'd like to think the output is coming together nicely though.

I've just been implementing some burning flames on the payout using purely CSS (not my code). Not quite hit the mark yet but quite an amusing distraction 😆

Coin Marketplace

STEEM 0.23
TRX 0.12
JST 0.029
BTC 66705.81
ETH 3626.46
USDT 1.00
SBD 2.93