GUI: Who is the GUI being designed for and how do we better avoid bikeshedding?

michaelfolkson commented at 2:32 pm on November 6, 2019: contributor

This is a brainstorming issue on the GUI. If I am missing context of past discussions on this please direct me to links (That is certainly possible, there have been years of discussions I am not aware of). I am opening this because I value my time and other contributors’ time rather than because I am a regular user of the GUI (Disclaimer: I’m not but I have started reviewing some GUI related PRs and am interested in continuing to do so.)

I am not a trained UX/UI designer but there appears to be some basic design principles when it comes to designing the GUI and providing feedback on GUI PRs that are being ignored on this project. Ideally we’ll get some trained designers to start contributing to the project who can carry out basic feedback exercises to ensure GUI changes are informed and not subject to biases, bikeshedding etc

Who are we designing the GUI for? Long term Core contributors (highly technical) that use the GUI on a regular basis? I don’t know how many of these there are. Technically curious who use the GUI when they can’t work out how to do something from the command line? Complete Bitcoin beginners? All of these groups? If it is the latter then we should all be under no illusions that compromises are necessary which will mean it is impossible for the design to be optimal for an individual group.
Design preferences are subject to the “sample size of 1” trap where those reviewing GUI changes think they are providing feedback on behalf of a group that they don’t belong to. A highly technical user just does not know what is optimal for a beginner. The only way you see what is optimal for a beginner is putting alternative GUIs in the hands of a statistically significant group of beginners.

An example open PR that motivated this issue is #16966. This is not picking on any of the people involved in that PR. When the project was smaller with fewer contributors there was no alternative other than individuals discussing their personal preferences. But at some stage (and certainly if we want the GUI to be used by greater numbers of users) we need a more effective collective thought process on this.

I’ve reached out to some designers in the Bitcoin community and hopefully some of them will get involved in this discussion and/or review of future GUI PRs.

MarcoFalke added the label Brainstorming on Nov 6, 2019

MarcoFalke added the label GUI on Nov 6, 2019

laanwj commented at 2:42 pm on November 6, 2019: member

From my viewpoint, the GUI is intended for “power users” of bitcoin. It’s not specifically for developers (who tend to use bitcoin-cli in most cases anyhow), but also not for people just getting started. They might be better off installing one of the mobile wallets.

The most important design principle is “make it hard to make mistakes”. Bitcoin is very much like industrial GUIs, in that safety is a primary concern. Mistakes are generally irreversible, and costly. Which is why I tend to discourage the “cool gui” kind of designers. Making the GUI look cool or fashionable is not the point, and never was.

Trained designers that have worked on projects with a lot at stake, and understand human psychology in that context, would definitely be welcome. It does mean that some developer has to communicate with them. and implement their ideas, or it’s not going to work. I do not personally have time to do serious work on the GUI anymore.

michaelfolkson commented at 2:51 pm on November 6, 2019: contributor

Ok, thanks. That’s interesting. The second point I definitely understand. Who is a “power user” in this context? Semi-technical people who make a lot of daily Bitcoin transactions? They have the ability to use bitcoin-cli but using the GUI is somehow faster for them?

laanwj commented at 3:04 pm on November 6, 2019: member

Who is a “power user” in this context?

The kind of user that is motivated enough (either technically, or financially) to learn enough about bitcoin, and meet the hardware requirements, to run their own (pruned) node.

Semi-technical people who make a lot of daily Bitcoin transactions?

Or infrequent big transactions. The traffic doesn’t really matter. But they’re interested enough to run the software virtually 24/7.

They have the ability to use bitcoin-cli but using the GUI is somehow faster for them?

I think that’s a significant part, yes. They might be able to use bitcoin-cli or the console, but might also be scared of it (easy to make mistakes!), or use the GUI because it’s more convenient.

I think that’s a realistic aim. Maybe at some point in the future Bitcoin Core will be suitable for non-technical beginners, but it’s important to not focus on that at actual user’s expense. E.g. by removing features that people care about. GNOME comes to mind.

Also whatever the designer wants need to work in the context of Qt. The project is not going to switch to a web GUI like electron. A lot is possible with QML though.

MarcoFalke commented at 3:17 pm on November 6, 2019: member

I think a lot of users are drawn to the Bitcoin Core GUI because it is a full node and has a wallet built in (as well as the shell to interact with the RPC, which makes bitcoin-cli redundant). So if your requirement is to run a full node (even if it is just booted once a month to pay for a bill), the GUI is a candidate try out.

Given that parts of the GUI “wrap” the RPC interface, some tooltips and confirmation dialogs (which are needed to prevent costly mistakes as pointed out by @laanwj), as well as warnings or errors tend to be technical. Thus, the GUI is maybe less accessible to users than a mobile wallet.

However, the current situation should not prevent us from shipping a GUI that is just as easy to use as a mobile wallet. The long term plan to move the GUI to a separate repository makes it also possible to have multiple GUIs, each of which resonates with a different user base.

naftalimurgor commented at 3:30 pm on November 6, 2019: none

@MarcoFalke What’st the rough ETA for moving the GUI to a seperate repository. Sounds like a good plan. I find the bitcoin-cli a choice for programmers and tech guys

MarcoFalke commented at 3:33 pm on November 6, 2019: member

ETA is “when it is ready”. There is still a ton of work (review) ahead. Next step would be #16367

laanwj commented at 3:38 pm on November 6, 2019: member

Strictly it’s already possible to have multiple external GUIs, there have been wallet GUIs in the past based on RPC (a web-based one, a desktop one, and a ncurses one I can remember). Oh and don’t forget AbCore’s mini-GUI for android. But I think this is veering off-topic.

naftalimurgor commented at 3:58 pm on November 6, 2019: none

@Iaanwj That’s when we are talking A full node wallet. For spv wallets, its possible to have multiple external GUIs

laanwj commented at 4:05 pm on November 6, 2019: member

@Iaanwj That’s when we are talking A full node wallet. For spv wallets, its possible to have multiple external GUIs

No, I was not talking about SPV wallets but external RPC wallets for Bitcoin Core. SPV wallets access the network themselves and perform “simplified” verification (hence the SPV).

naftalimurgor commented at 4:10 pm on November 6, 2019: none

@Iaanwj That’s when we are talking A full node wallet. For spv wallets, its possible to have multiple external GUIs

No, I was not talking about SPV wallets but external RPC wallets for Bitcoin Core. SPV wallets access the network themselves and perform “simplified” verification (hence the SPV).

noted. Thanks for the clarification :+1:

luke-jr commented at 5:19 pm on November 8, 2019: member

IMO we shouldn’t intentionally exclude any target audience. It is especially important that it be usable by everyday end users, since Bitcoin’s security depends on a supermajority of the economy using their own full node.

Note that the GUI is needed for more than just the wallet… right now, it is the only realistic way for a normal end user to run their own node at all.

Rspigler commented at 11:36 pm on November 8, 2019: contributor

It is especially important that it be usable by everyday end users, since Bitcoin’s security depends on a supermajority of the economy using their own full node.

Absolutely agree. I guess the question is, should making the GUI usable for end users prevent security improvements for power users? IMO, I don’t believe so.

I think #16966 does both, by making the change off by default (https://github.com/bitcoin/bitcoin/pull/16944#issuecomment-534307676)

luke-jr commented at 11:44 pm on November 8, 2019: member

I guess the question is, should making the GUI usable for end users prevent security improvements for power users? IMO, I don’t believe so.

Of course not. We have expert options like coin control that don’t interfere with novice friendly usage.

jb55 commented at 0:36 am on November 9, 2019: member

I’ve started using bitcoin-core more recently thanks to HWI/fast importmulti/better hardware wallet support/psbts/ etc. I’ve been using rpc, but I’m thinking about switching to the GUI after #16944 lands since it’s much more user friendly and less error prone.

andronoob commented at 9:20 am on November 9, 2019: none

I once came across many users who stick to Bitcoin Core so tightly that they refuse to use any other wallet, just because they think that: “Bitcoin Core is ’the only true original official Bitcoin wallet’ among various wallets, therefore it’s the most secure & trusted wallet, which has no substitution undoubtedly”.😅

They had even developed an “one-time-disposable offline-signing usage (for true HODLers who seek extreme security)” of a fully-synced Bitcoin Core full node, which could be roughly described as follow:

Perform a fresh installation of Bitcoin Core on a computer which is ready for full disk wiping.
Launch Bitcoin Core, then wait for it to sync.
Unplug the ethernet cable. For laptops, the WiFi/BT module should also been dismantled.
Import the “precious” private key with importprivkey. Wait for the rescan to be done.
Compose & sign the transaction with the wallet GUI. The imported “precious private key” would obviously be reused by specifying “custom change address” (otherwise it would be just another tragedy like #11827). Then copy the raw transaction data.
Use QR code or USB thumb drive to carry out raw transaction data. Then the transaction could be broadcasted to the network.
Erase the hard drive completely.

ghost commented at 11:36 am on November 9, 2019: none

I am not a fan of fancy gui’s. Bitcoin is made by develooers for developers and end-users. A normal money wallet in my pocket begins with a open/close function and some compartments for coins and bills. Anything more for normal end-users could end up in analysis paralysis.

Full nodes are the corner stone of the bitcoin project but not every user can run a full node for various reasons. Maybe the bitcoin foundation should think about super nodes in the long run.

Op vr 8 nov. 2019 18:21 schreef Luke Dashjr notifications@github.com:

IMO we shouldn’t intentionally exclude any target audience. It is especially important that it be usable by everyday end users, since Bitcoin’s security depends on a supermajority of the economy using their own full node.

Note that the GUI is needed for more than just the wallet… right now, it is the only realistic way for a normal end user to run their own node at all.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/bitcoin/bitcoin/issues/17395?email_source=notifications&email_token=AFMHRUNIS6LT363EM7RTZDDQSWNY7A5CNFSM4JJVYGTKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEDSY4MQ#issuecomment-551915058, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFMHRUM7GHFQU4Q6LHPKJWTQSWNY7ANCNFSM4JJVYGTA .

Rspigler commented at 7:38 pm on November 9, 2019: contributor

We have expert options like coin control that don’t interfere with novice friendly usage

So I believe we are in agreement.

I once came across many users who stick to Bitcoin Core…just because they think that: “Bitcoin Core is…the most secure & trusted wallet”

Core is the most secure wallet. It is by far the most heavily reviewed. And while GUI code doesn’t have systemic risk like consensus code does, it still presents possible serious individual security risks to users.

Supernodes?? No such thing. Bitcoin Foundation? Dead (Good thing). And we are getting terribly off-topic.

andronoob commented at 4:03 am on November 10, 2019: none

Core is the most secure wallet. It is by far the most heavily reviewed.

However, I see (GUI of) Core still lacks some important features: mnemonic-based backup, offline signing, multisig…

There are reasons why weird things like Electrum Personal Server exist.

Electrum provides all the feature mentioned above. It also have straightforward and distinct management of various types of wallets - as for Core, the actual contents of wallet.dat could be a misterious mixture.

Though I’m very unfamiliar with contexts and history, but, I felt that a lot of things around SegWit is still unsettled, even if SW had been activated for quite a while, just like https://github.com/spesmilo/electrum/issues/3620#issuecomment-354735946

(Obviously off-topic, sorry) Should a pub/privkey handle all possible address (script) types? It seems that Core’s answer is “yes”, while Electrum’s answer is “no”. To me, it’s not simply some random trivial stuff, it’s a problem which had confused countless users.

jonasschnelli commented at 6:11 am on November 10, 2019: contributor

My personal view and projections on the GUI:

I think we should not give up the hope to make Bitcoin Core a wallet for non experienced users
Things like hybrid SPV mode (#9483), pruning and block-filter based p2p-fetch wallet rescans could make things way more attractive for novice users
On top, resource management could be done better. Use full, heavy CPU resources only if the user is AFK or if he/she intentionally allows Bitcoin Core to draw all resources. Otherwise the system may get really unusable for a few hours on a catch-up/sync. Sometimes the time to catch up a few days of blocks is irrelevant but the user prefers to have enough resources available to watch a movie or do some word processing, etc. Right now the default approach is sync as fast as possible. Which may be desirable for server based VPS, etc. But often not for home/personal desktop systems.
I agree with @laanwj that the GUI doesn’t need to be a super-modern HTML/CSS whatever. It needs to fulfil its job. Clear communication, simple to extend (Qt/cross platform), minimal resource needs (no HTML/CSS/JS).
However, there are many things that need more love. Among many ideas, a new wizard that helps people setting up the right configuration (pruning, blockfilters, maxscripthreads, etc.) in a way that is really simple to understand, would be one of the things that non experience users would appreciate.

If I would have some wishes open, one of them would be that the GUI works perfectly asynchronous over the RPC interface with a push channel like long-polling (#7949). I’m pretty convinced that this approach should work also for performance critical stuff. And not least, it would allow to use the GUI via a wireguard/VPN (run the GUI on a different machine) and the modularity would allow other GUIs / backends.

msafi commented at 11:19 pm on January 16, 2020: none

@jonasschnelli

If I would have some wishes open, one of them would be that the GUI works perfectly asynchronous over the RPC interface with a push channel like long-polling

I like this idea but as I’m sure you know the current GUI has access to information that RPC doesn’t provide. For example, the following information is not retrievable through RPC:

Initial boot-up messages that get reported through InitMessages
Header-first sync progress
The location of the data directory
The location of the blocks/ folder

When building Orange I worked around these limitations by retrieving some of this information from the log output. But that’s a hack that I would like to be able to fix.

The other thing that I found tricky to build by relying purely on RPC is the logic that sets the text for the progressBarLabel

We can probably fix these limitations by adding more data/commands to the RPC interface. What do you think about that?

michaelfolkson commented at 9:53 am on May 5, 2020: contributor

Some thoughts from @Sjors on Twitter (https://twitter.com/provoost/status/1257603593487687681?s=20):

Some changes are easy. Fixing an obvious bug, improving performance or adding a feature that’s tucked away in a menu.

Not loudly publishing a change can make it easier to get it done, but defeats the purpose of peer review, and can lead to followups that partly undo it.

Generally comments from regular contributors have more weight when they disagree with a change on non-technical grounds, so the total amount of “bikeshedding” isn’t the biggest issue. Some of the best technical reviewers strongly disagree on UX choices, that’s a bigger bottleneck

This problem is made worse by how hard it is to change anything in the code, partly because QT isn’t easy to work with, partly because the GUI codebase just isn’t very nice, with lots of quick hacks. So a simple change can be a lot of effort, with high risk of dying in review.

Which brings me back to my usual view on how to get out of this mess:

make GUI code so modular that people can work on independent implementations (that Core can cherry-pick from)
clean up GUI code so proposing a change is less expensive
stick to incremental UI changes

Knots is a clear example of this in progress. It has all sorts of UI improvements, which @luke-jr can make at his own disgression. But cherry-picked features from that project sometimes take forever to make it through review. Perhaps the above can make that easier.

MarcoFalke referenced this in commit c2bcb99c1d on Jun 18, 2020

sidhujag referenced this in commit e593102316 on Jul 7, 2020

Bosch-0 commented at 11:22 am on August 5, 2020: none

I summarized the above discussion as best as I can and made an issue over at the new GUI repo for those interested in continuing this. https://github.com/bitcoin-core/gui/issues/45

fanquake commented at 6:01 am on August 10, 2020: member

Any further discussion can be continued in https://github.com/bitcoin-core/gui/issues/45.

fanquake closed this on Aug 10, 2020

DrahtBot locked this on Feb 15, 2022

GUI: Who is the GUI being designed for and how do we better avoid bikeshedding? #17395