Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1VhUYA-0004VG-I1 for bitcoin-development@lists.sourceforge.net; Sat, 16 Nov 2013 01:19:50 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of zikula.org designates 209.85.212.181 as permitted sender) client-ip=209.85.212.181; envelope-from=drak@zikula.org; helo=mail-wi0-f181.google.com; Received: from mail-wi0-f181.google.com ([209.85.212.181]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1VhUY8-0008RS-Hp for bitcoin-development@lists.sourceforge.net; Sat, 16 Nov 2013 01:19:50 +0000 Received: by mail-wi0-f181.google.com with SMTP id f4so1759473wiw.8 for ; Fri, 15 Nov 2013 17:19:42 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=EDOYkY6nKOsjEKTPnHQw5hyshz6m3Qn1oZUuDt0Sm6Q=; b=OnS2j44/8EXpXcHx+jZhP2++BBiCRrKJimILZCXJWqJw/syAzmGUjfMhR4Fnd2P7Ge PRFsE8wqaLlqD3SGcrY/C5cKI3gn6pa6wO+UBV+KhSbRAPm5F6VgoL0aAANuDJdLJPbN sHKpaSca7uP/+xuoQdfYwJWiPkPlLONuepPflNsqxNy3fj7C2YjtrBK9Z8pzI5RjViaR 9KxbGr+PSu1HupnJXCxHGqHbgmKc9ZRaLzylM9zj66Eq+zfJlKrC1gJvnqwIqP5Z7lzW 9IULrauoExPylXizIHfw5+wt0eHQNoFFpPh3GMbXoQOMWBAr9HrlcUycPXUbvpb/Epie y2ZQ== X-Gm-Message-State: ALoCoQndY6jzryGkqQjFcssjD6edan0bhM4oc6bD7bXmoqNkCQDd+x05yyRi3d/JHkTElwV9H0Pp X-Received: by 10.180.198.5 with SMTP id iy5mr9135849wic.45.1384564782281; Fri, 15 Nov 2013 17:19:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.93.105 with HTTP; Fri, 15 Nov 2013 17:19:22 -0800 (PST) In-Reply-To: <201311160110.42132.luke@dashjr.org> References: <201311142301.39550.luke@dashjr.org> <201311160110.42132.luke@dashjr.org> From: Drak Date: Sat, 16 Nov 2013 01:19:22 +0000 Message-ID: To: Luke-Jr Content-Type: multipart/alternative; boundary=047d7b624e2a045e0a04eb411ce3 X-Spam-Score: -0.5 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [URIs: dashjr.org] -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message X-Headers-End: 1VhUY8-0008RS-Hp Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] moving the default display to mbtc X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Nov 2013 01:19:50 -0000 --047d7b624e2a045e0a04eb411ce3 Content-Type: text/plain; charset=UTF-8 On 16 November 2013 01:10, Luke-Jr wrote: > On Saturday, November 16, 2013 12:41:56 AM Drak wrote: > > So "a payment clears after one confirmation, but you might want to wait > > until the payment has been confirmed n times". > > Then at least you are not using the same word for two different meanings > > and you're using stuff more familiar in popular lexicon. > > I dont think it's helpful for users if we use the word "blocks". > > "Confirmations" in a numeric context isn't correct, though. We're using to > it > because we've been using Bitcoin so long, but to the average person they > would > expect it to mean something more than it is. If not referring to blocks, > then > perhaps "witnessed N times"? If you are talking about user interface, I don't think you have to be technically correct. It must make sense to the user. A user cares about his balance, and did a payment "go through", and "did my payment arrive/clear". The UI is for their benefit. > > For years, people had a problem with "email address", instead using > "email > > number" but they got there eventually. Most people nowadays use "email > > address" > > So "payment address" or "bitcoin address" make better sense here when > > qualified as a " address" and not just an "address" > > > > You could also call it "payment id", but I dont think "invoice id" since > > no-one pays to an invoice id that's just a reference for a payment, not > the > > destination. > > > > People are very familiar with Paypal these days, and are familiar with > > "paypal address" or their "paypal id" so again I think valid contenders > are > > "bitcoin address" or "bitcoin id". > > I think you might be demonstrating my point with regard to user confusion > here. Bitcoin addresses are *not* like email addresses, paypal ids, etc. > Bitcoin addresses aren't the destination - they're point to a destination > (an > account in a wallet), but they also represent information such as who is > paying and what for - in other words, a specific invoice. Maybe, but again from the user's perspective they pay someone, and they receive money - just like you do with paypal using an email address. The technical bits in the middle dont matter to the user and trying to crap stuff in to be technically correct is just confusing to them. The UI needs to be about the user and fit with his experience of the world. Drak --047d7b624e2a045e0a04eb411ce3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On 1= 6 November 2013 01:10, Luke-Jr <luke@dashjr.org> wrote:
On Saturday, November 16, 2013 12:41:56 AM Drak wrote: > So "a payment clears after one confirmation, but you might want t= o wait
> until the payment has been confirmed n times".
> Then at least you are not using the same word for two different meanin= gs
> and you're using stuff more familiar in popular lexicon.
> I dont think it's helpful for users if we use the word "block= s".

"Confirmations" in a numeric context isn't correct, tho= ugh. We're using to it
because we've been using Bitcoin so long, but to the average person the= y would
expect it to mean something more than it is. If not referring to blocks, th= en
perhaps "witnessed N times"?

If y= ou are talking about user interface, I don't think you have to be techn= ically correct. It must make sense to the user.
A user cares abou= t his balance, and did a payment "go through", and "did my p= ayment arrive/clear".

The UI is for their benefit.
=C2=A0
> For years, people had a problem with =C2=A0"email address", = instead using "email
> number" but they got there eventually. Most people nowadays use &= quot;email
> address"
> So "payment address" or "bitcoin address" make bet= ter sense here when
> qualified as a "<foo> address" and not just an "a= ddress"
>
> You could also call it "payment id", but I dont think "= invoice id" since
> no-one pays to an invoice id that's just a reference for a payment= , not the
> destination.
>
> People are very familiar with Paypal these days, and are familiar with=
> "paypal address" or their "paypal id" so again I t= hink valid contenders are
> "bitcoin address" or "bitcoin id".

I think you might be demonstrating my point with regard to user confu= sion
here. Bitcoin addresses are *not* like email addresses, paypal ids, etc. Bitcoin addresses aren't the destination - they're point to a desti= nation (an
account in a wallet), but they also represent information such as who is paying and what for - in other words, a specific invoice.
=
Maybe, but again from the user's perspective they pay so= meone, and they receive money - just like you do with paypal using an email= address.
The technical bits in the middle dont matter to the user and trying to= crap stuff in to be technically correct is just confusing to them.

The UI needs to be about the user and fit with his experi= ence of the world.

Drak
--047d7b624e2a045e0a04eb411ce3--