Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[UX] status bar information #137

Open
ixje opened this issue May 31, 2022 · 1 comment
Open

[UX] status bar information #137

ixje opened this issue May 31, 2022 · 1 comment

Comments

@ixje
Copy link

ixje commented May 31, 2022

There's quite a bit of confusion about what this status bar is supposed to tell us
image
I therefore want to open this issue to discuss what it is, isn't, should be, shouldn't be and strange behaviours I've observed.

Background

I first mentioned not understanding this status bar here #124 (comment) and then recently (2 months after the first post and having forgotten that I wrote about it) again here #129 (comment). I'm having a discussion with the user robliou in #124 and felt it was time to split it off in its own issue

What is its purpose?

Just from its visual presence I cannot understand what it is telling me, which from a UX perspective is a problem. Let's take this status as an example

Neo: Not connected

To figure out what connected in this case means and why I need to be connected I had to look at the source code. It turns out it says something about the "connection status" (more on this later) of the BlockchainMonitor class. This class, which if my scan is right, polls a chain on an interval for its block height and caches blocks that have transactions internally for quick access elsewhere in the code base. It obtains this information via RPC calls to the chain.

So "connection status" refers to the RPC connection of the BlockchainMonitor class? Yes and No. The status changes (or is supposed to, see the observations section below) depending on if the block count of the chain can be requested via RPC. RPC is not a long lasting connection, just short get/posts requests, which adds to the confusion of what "connected to" means in the screenshot above.

What I think it is; if the "system" can successfully monitor a chain.

Should it exist?

Why should I care if some internal process can cache information? I just want to know that it failed to obtain the latest information when I open a tab/window that actually uses the information this monitor tries to obtain/cache (e.g. the block explorer). Until that time I don't care.

I tend to think that this status bar shouldn't exist at all. If it is decided that it should exist, then please let's change what the text says to something like Chain monitor [Online]: monitoring <chain name>

Observations

Let's assume the status bar should exist

  • It does not show up at all for MainNet or TestNet yet is actively running in the background and functioning properly as we can see in the debug console on the left and by the blocks that have been fetched in the block explorer tab in the right window
    image

  • So it only starts to show if we start a local chain. If we do so and then kill the terminal (which stops the chain), then the status bar keeps saying "connected to".
    image
    I know the status is normally updated on an interval, but this one never updates (unless we start a new chain)

  • Which status to present? For example I can open a block explorer for multiple chains at the same time and they all update fine yet the status bar can show only one status. As far as I've observed there are no listeners that change this status bar to match with whatever tab is active

@ixje
Copy link
Author

ixje commented May 31, 2022

@devhawk would love to get your view on this

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant