From: Taylor Gerring <taylor.gerring@gmail•com>
To: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Fees UI warning
Date: Mon, 16 Dec 2013 11:55:11 -0600 [thread overview]
Message-ID: <75261AAF-989D-4A9A-A99A-160B13BC6B09@gmail.com> (raw)
In-Reply-To: <CA+s+GJB+qvYBhjzvut2WJCeVc35nmwwUwQM45w_6BYwbw2UawA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3602 bytes --]
Providing people with a great user experience is something that Hive Wallet is enthusiastic about, so this is stuff we’re thinking about constantly. For example, how do you alert the user to abnormal activity (i.e. sending “too much” on accident[1])? The removal of extraneous UI and functionality that can be automated is a priority, which is why we (to date) still don’t have a Preferences dialog. Smart defaults should be an important aspect of design decisions.
Thinking about stripping UI away as much as possible, consider what was done with dat.wallet[2]: no wallet file whatsoever and it doesn't even reveal the address except when explicitly necessary. For privacy’s sake, the intent should be to detect the use of an address and automatically rotate it away from the user. This minimal interaction results in maximum benefit.
Or take a look at the new Bitstamp app I’m writing for Hive[3]. How do you cram an entire trading API into a mobile-like window? Smart use of space and making intelligent event-driven decisions is often overlooked. In the linked screenshot, imagine the user actually clicks the deposit button. A “send bitcoins" dialog is pre-populated with the deposit address and the requested amount. Copying and pasting addresses is error-prone and not user-friendly in the least.
I would urge all software developers to think about UX when developing applications. What can be automated? What can we make a best guess about? In the case of fees, we will hopefully have more control over them in the coming months, but in the meantime, consider what your application tries to accomplish and how it can do that without getting in the way too much. Software should enable the user, not encumber them.
Lastly, I’ll leave everyone with an approach we’re considering once floating fees are feasible[4], something Mike Hearn asked about in a previous thread.
[1] https://github.com/hivewallet/hive-osx/issues/107
[2] https://github.com/darkwallet/dat.wallet
[3] https://github.com/tgerring/hiveapp-bitstamptrader
[4] https://github.com/hivewallet/hive-osx/issues/148
Taylor
On Dec 16, 2013, at 5:37 AM, Wladimir <laanwj@gmail•com> wrote:
> On Mon, Dec 16, 2013 at 11:46 AM, Jim <jim618@fastmail•co.uk> wrote:
> For the HD version of MultiBit we are removing the import
> of individual private keys entirely and only supporting HD
> addresses, primarily for safety reasons.
>
> I'd love to have the same in Bitcoin-Qt as well. Too many sob stories about people with outdated backups that lost part or all of their coins. These are much more common than fee messups.
>
> What we should really do is:
>
> - Use deterministic wallets. Making regular backups becomes optional (to retain label and transaction data and such) instead of mandatory.
>
> - Don't support importing private keys. Replace the importing of private keys by a "sweep" function.
>
> Wladimir
>
> ------------------------------------------------------------------------------
> Rapidly troubleshoot problems before they affect your business. Most IT
> organizations don't have a clear picture of how application performance
> affects their revenue. With AppDynamics, you get 100% visibility into your
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk_______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[-- Attachment #2: Type: text/html, Size: 4961 bytes --]
next prev parent reply other threads:[~2013-12-16 17:55 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-16 10:13 Drak
2013-12-16 10:46 ` Jim
2013-12-16 11:08 ` Drak
2013-12-16 11:31 ` Pieter Wuille
2013-12-16 18:26 ` Mike Hearn
2013-12-16 11:37 ` Wladimir
2013-12-16 17:55 ` Taylor Gerring [this message]
2013-12-16 18:45 ` Gregory Maxwell
2013-12-16 11:27 ` Wladimir
2013-12-16 18:28 ` Mike Hearn
2013-12-16 22:32 ` Andreas Schildbach
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=75261AAF-989D-4A9A-A99A-160B13BC6B09@gmail.com \
--to=taylor.gerring@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox