Polkadot JS Apps messaging & rebranding thoughts

This post is to share my thoughts around the “Polkadot JS Apps” naming and to promote discussion around how to position it (if even possible) in a way that is more coherent with the product and ecosystem expectations in terms of end-user applications.

My overarching thought here is that Polkadot JS Apps, being a primarily developer tool, should have this reflected in its naming. Right now the term “apps” gives the impression that it is catering for end users and that it should stand alongside apps like Moonbeam’s simple staking UI that any user can use, Acala’s apps app that although is not perfect, is positioned to be used by end users. Astar’s portal is geared towards end users with more of a focus on usability. Even Interlay, a basic and early stage dashboard, is geared towards end user usage.

Focusing on the Polkadot ecosystem of apps, JS Apps has a different use case to the staking dashboard, a different use case to Talisman’s dashboard, etc. If dashboards are a layer 1 product of the front end, Polkadot JS Apps would be a layer 0 product (if that analogy helps).

I personally like the name “Polkadot Console”, I think this suits the product very well and puts it in its own category as a developer tool. The Console naming clearly communicates that it is probably not positioned to be used by end users, and will clear up the misconceptions that the current JS Apps name currently ensues.

20 Likes

Second this. I think this should be the next step to stop promoting Polkadot JS as the default Polkadot wallet and start promoting more user-friendly ones like SubWallet, so that new users are not deterred from the ecosystem.

The W3F team made a great move in revamping the Wallet page in Polkadot wiki by prioritizing user-friendly wallets: Wallets · Polkadot Wiki

7 Likes

Yes polkadot js apps should be a developer console. Users should not use it.

Unfortunately we can’t just tell people to not use it at this stage without a proper replacement.

4 Likes

Directly telling users not to use it is something I would stay away from. I think the messaging of what it is and who should use it does indeed need to be revised to reflect its purpose better, so users can then make their own minds up on whether to use it.

1 Like

I think names matter more than we think, so that’s why I support this idea @ross :grinning:

1 Like

I’m 100% with you on this @ross. Naming it the Polkadot Developer console would likely help deter eager users from using it and thus diminish the risk of scaring people away from trying to use Polkadot.

I also expect such a change to help us carve a better narrative for onboarding new developers. These groups should have the expectation that the current apps UI is like lifting the bonnet of a relay or parachain engine and peering into it. Currently, it’s not clear what to expect as a new user of the apps UI, even as a developer.

2 Likes

I can agree and disagree with your opinion @ross .

Let me elaborate on this. I agree that PolkadotJS could be (and maybe should be) placed as a Developer console rather than a Multi-App, and it makes more sense for people that are more deep-dived into its functionality.
I disagree though as this is a very trustful by-the-community app. People know and trust that Apps will just work… no fear of bugs. I disagree that this can happen without providing alternative options for each sub-tool that exists (Accounts, Staking, Pools, Explorer, etc etc);

Thinking of the above lines, I believe that the best way to convince users, not to use PolkadotJS is to provide them with strong, stable alternatives for those sub-apps (e.g. what @ross and staking team, managed to do with Polkadot Staking Dashboard). Meaning, official tools with a better user interface, more common to the simple user, that will make one prefer it that the Apps.

1 Like

I agree @ross. I wouldn’t dissuade use of the App either. There will always be a spectrum of users that really only need orientation to the alternatives available. A features list of all the alternatives will help sort the user community to the best solution for their use case. It may quiet the chatter on recommendations that are so prevalent but user specific.

I’m a moderator on discord and matrix, and I have to chime in here that non-expert users very frequently complain that polkadot.js is too complex and confusing.

When guided to the third-party wallet solutions (even by giving them the link to the Treasury supported wallets page on the wiki), sometimes they balk, thinking those solutions are risky. It’s typical that users from other ecosystems, in particular, expect Polkadot to have one “official” wallet, and polkadot.js seems to fit that bill, so it’s widely believed that polkadot is not user-friendly or is uninterested in non-technical users for that reason.

Another issue is that polkadot.js extension and polkadot.js site have the same name, and users constantly confuse the two. This is quite challenging to deal with, and much time and energy is wasted with miscommunication until the confusion is identified and unraveled.

My go-to line is that polkadot.js is very powerful but was initially built as a dev tool rather than a wallet, so it may be a tough learning curve for a newcomer. I recommend the treasury-funded wallets page on the wiki. I mention that I myself use some of them (mainly Talisman and Nova) and that plenty of community members are equally happy with others (like Subwallet and Polkawallet), but that’s really not enough for some people, many of whom actually think wallets “hold” tokens and don’t understand that they can use multiple wallets to manage the same accounts and assets.

I would strongly favor some “official” comms encouraging users to try out the trusted third-party solutions and to think of polkadot.js as a powerful tool rather than a wallet. I also strongly urge the team to differentiate the polkadot.js extension from the polkadot.js site.

5 Likes

Why “3rd party”? Why not to create official easy tools so that the world can be onboarded in an easy manner?

That would be great too. I said third-party because convenient, user-friendly third-party wallets already exist and the vast majority of users should be taking advantage of them rather than getting lost and confused (and let’s be honest, frustrated and put off completely) by polkadot.js. And tbh the more I think about it, the more impractical it sounds to develop user-friendly wallets when the ecosystem already has several that are already developed, integrated, and used. Better to promote a working, existing solution than build a new one to do the same thing, imo.

1 Like

I made an attempt at suggesting this, but to no avail :frowning: Consider re-branding the `Apps` to `Console` · Issue #8971 · polkadot-js/apps · GitHub. Your show of :+1: in the issue might help change the maintainer’s opinion on things.

There are two different ideas:

  1. stop promoting polkadot.js Apps as a wallet, since mature wallets exist
  2. promote polkadot.js Apps to be the default dev console, like at “https://developer.polkadot.network

There is a third obvious idea I would like to suggest:
3. promote polkadot.js Apps to be the default APPSTORE at “https://apps.polkadot.network

There are many different ways you could do https://apps.polkadot.network using polkadot.js APPS as a starting point, but a default is:
(1) Add an “Apps” tab with a subitem “Appstore” [you could add many other “official” apps just like Apple and Google]
(2a) From “Appstore”, show Trending Apps, New Apps, … with “Install” or “Open”.
(2b) For every app, you should be able to see what previous users said about it. Anyone with an on-chain identity, a fellow, or lots of money might be trusted more
(3) When users click “Install”, they are shown what extrinsics the app is permissioned for, what else it does. Ideally, dapps could be held to this permissioning model technically in Polkadot 2.0, but otherwise the user base could complain about it in (2b)
(4) When a developer wants to submit their dapp, they go to https://console.polkadot.network stake some DOT on their submission and submit their app and poof, it is visible in “New Apps” – with an optional “review” process
There is approximately ZERO innovation in what I’m suggesting – 100% of us have done it in mobile already – I’m sure some old-time fellow can explain why the word “APPS” was in put in “polkadot.js APPS” but I’ll bet it was part of the plan to do an APPSTORE and this idea is a little more than pregnant and needs to be birthed.

After all, all the following platforms all have APPS and an APPSTORE:

  • Your phone has APPS and APPSTORE
  • Your computer has APPS in the dock and an APPSTORE
  • Your TV has APPS in the home screen
  • Many of the tools you use every day (Slack, Nagios, Salesforce) also have APPS and an APPSTORE

So, to make the Polkadot ecosystem user experience better, I believe there has to be:
(a) a place to see all the APPS you have INSTALLED – ie https://apps.polkadot.network
(b) an APPSTORE to find all the APPS you COULD use, including what everyone says about them (ratings+reviews) and even interact with the developer – ie
https://apps.polkadot.network
(c) a DEVELOPER APP to submit new apps and see the status and analytics of your apps (user installs, reviews/rating, revenue growth) – https://developer.polkadot.network

The way to get (a)-(c) is use polkadot.js APPS as a starting point to get the APPS/APPSTORE/DEVELOPER APP combination we need. You can throw it out and start over with a new code base, but I think its an excellent foundation to start with – its very well written React Typescript with a tremendous amount of love from jacogr and probably dozens of others over the years.

The high level bits for this idea are why to put the APPSTORE data on-chain (some people ask why, I ask why not … when there is an excess of “quality blockspace” these days), and then if on-chain then in common good parachain or not, how much of that suffocating Apple/Google type human review process has any place at all, and technically how extrinsic permissions are granted to enable users to trust more than the Polkadot and parachain “official” dapps.

At the very least, I think its crazy that polkadot.js APPS doesn’t even link to the parachain’s “official” dapps. Maybe its because the only non-opinionated ranking algorithm is the one which used used to order the parachains. You could start with that 1995 Yahoo style solution but really, since every parachain adds on their RPC endpoints, its really simple to start with this, and it doesn’t involve deciding any of these bits. It wouldn’t be very interesting but forcing the question of where the non-parachain dapps should go is an important can of worms to open. Avoiding this APPSTORE “What is the equivalent of PageRank” solution for APPS is also suffocating to the user base and the developers.

I am not advocating for a centralized website run by either Polkadot or a parachain team with the One Ranking To Rule them All. With user/developer app data stored on chain, if polkadot.js APPS can be built to be an APPSTORE for Polkadot at
https://apps.polkadot.network
every parachain/wallet/… team and indy dapp developer can build their own at
https://apps.acala.network
https://apps.moonbeam.network

using their own fork, emphasizing their own New Apps, Trending Apps, … etc. with their own ranking algorithm. Having seen everyone game the mobile/facebook/… app ecosystems, every developer will think about gaming these apps leaderboards within 17 mins of seeing it drive their app install volume. So the gaming of this has to be thought through a bit along with an actually decentralized review process that specifically somehow bricks dapps that lie and cheat people (I wish this of wallets as well). But my expectation as a user is that I would be able to see all my apps across the ecosystem in any of those places, and that none of the appstores are trying to censor anything unless there is an actual safety reason.

2 Likes

I’m pushing back on these notions, I would definitely not use JS Apps as a foundation for an app store, and I cannot see app rankings being a viable thing. I think stats like total accounts, market cap and general on-chain usage stats are better metrics. Polkadot is the app store.

Polkadot JS apps should be promoted as a developer console and nothing more. It will not evolve from what it is today into something different, this is very apparent.

JS Apps resembles nothing of an app store so this is immediately unviable in my eyes. The “apps” terminology stems from each page of the app having a separate package that are bundled in a monorepo. This terminology already is confusing to end users.

JS Apps also cannot act as a foundation to some sort of app catalogue. It would literally be replaced with a totally separate codebase.

I would suggest a brand new product more like Adobe’s creative cloud app, a catalogue of apps that link to their own executables or web counterparts. The process of adding apps should be open source or decentralised.

Many of the ideas mentioned here are centralised services. To reiterate my previous point, on-chain metrics are going to be the best data to measure apps.

2 Likes

Using “Substrate” instead of “Polkadot” might also be fair in this case.

7 Likes

More support for the Polkadot Developer Console rebranding in the comments of a recent tweet:

1 Like

There is way too much drama behind the JS-UI, in my opinion. The UI is not only for developers as it allows to full access functionalities such as proxy accounts, gov, crowdloans, wallet functionalities, bags-list, etc. that everyday users can grasp and find useful. It also gives notifications about metadata updates; you can switch RPC nodes or use light clients. It is an excellent tool, trusted by the community and supported by the Foundation. There is no promotion; we say we provide support because it is an official tool like the extension and the dashboard. The tweet by Leemo must be put into its context: the Polkadot Ambassadors Gathering in Barcelona, where ambassadors will be trained about the UI, the extension, and the dashboard.

Ambassadors are essential to the Polkadot movement as they represent the local source of truth and inspiration for the community and new joiners. As such, ambassadors must have strong technical knowledge about how the ecosystem and supported tools work to provide high-quality support and efficiently troubleshoot community issues. This, unfortunately, also includes the JS-UI.

I do agree with @ross that changing the name to Console is appropriate, and it will also help to be more clear in the documentation as right now Apps, UI, JS-UI, JS Apps are interchangeable and create confusion.

1 Like

Fully agreed. What would be the steps for the community to help push this along? Is it something controlled by Parity or something we could request to be changed?

I agree, but I’d argue that the training they receive should include training in why newcomers to the ecosystem should be directed to more user-friendly asset-management tools. It’s been said plenty, but it’s a very commonly-held belief outside of our little community that Polkadot is abstruse and forbidding to nontechnical users, and I’m 100% sure that the source of that belief is the fact that newcomers are first introduced to Polkadot.js, which is abstruse and forbidding to nontechnical users.

I started another one! Maybe it’ll help bring more eyes to it. Is this the natural way of trying to get it renamed?