Re: [Bitcoin-development] Fees UI warning

[Taylor Gerring <taylor.gerring@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 --]