From: Stefan Thomas <moon@justmoon•de>
To: bitcoin-development@lists•sourceforge.net
Subject: Re: [Bitcoin-development] Random order for clients page
Date: Tue, 10 Jul 2012 04:36:39 +0200 [thread overview]
Message-ID: <4FFB9537.8040909@justmoon.de> (raw)
In-Reply-To: <CANEZrP3Y3nvRwiPw66bDhp01JnE-zVurw5MnxPzR-bi5H8h4Aw@mail.gmail.com>
> I think by "users" you mean, geeks who understand wiki syntax.
The point is to expand the circle of contributors. I'm pretty sure there
are more people who can edit a wiki than people who know HTML and how to
create a git pull request. :)
> Inability to agree on columns isn't why the page looks like that.
My apologies, I vaguely remembered Luke's original proposal and that it
got rejected, but you're correct, the reason wasn't a debate on the
columns but that people didn't like the feature matrix at all.
I didn't really mean to argue on the details of what the page should
look like, but just to briefly respond to Mike's point:
> It looks like that because feature matrices aren't especially helpful
> for newbies to make a decision, especially when the "features" in
> question were often things like how they handled the block chain or
> which protocol standards they support, ie, things only of interest to
> developers.
A well-designed feature matrix can quite useful and user-friendly.
http://www.apple.com/ipod/compare-ipod-models/
Prose is better to get a sense of the philosophy and basic idea of a
client. If it was between having only a feature matrix or only prose,
I'd probably go for the prose as well.
What a feature matrix is good at though is it allows you to very quickly
find the specific feature or general criteria you're looking for without
reading through all of the text. So it might be a useful addition maybe
not on Bitcoin.org, but certainly on the wiki.
On 7/10/2012 12:37 AM, Mike Hearn wrote:
>> I strongly agree, but this is *why* I suggested moving it to the wiki. I
>> recently had to choose an XMPP client and I looked on xmpp.org - after a
>> frustrating experience with their listing [1]
> Probably because their listing is even more useless than any of the
> proposals that were presented here. Thank goodness it didn't end up
> like that. Their table doesn't even attempt to list features or
> differentiating aspects of each client.
>
> I think the XMPP guys have pretty much given up on directly marketing
> the system to end users.
>
>> - more up-to-date (anyone can update them)
> Fortunately reasonable clients don't appear/disappear/change that often.
>
>> - more in touch with users:
> I think by "users" you mean, geeks who understand wiki syntax. Because
> that's what it'll end up trending towards. I don't believe a wiki
> would reflect the needs of your average person. It's still better to
> have these arguments here and try to find a user-focussed consensus
> than hope one will converge from a wiki.
>
>> If you want to see "the result of
>> internal politics", the current client page is a good example. We
>> couldn't agree on the columns for a feature matrix, so now we just have
>> walls of text.
> Inability to agree on columns isn't why the page looks like that. I
> know because I'm the one who argued for the current design.
>
> It looks like that because feature matrices aren't especially helpful
> for newbies to make a decision, especially when the "features" in
> question were often things like how they handled the block chain or
> which protocol standards they support, ie, things only of interest to
> developers.
>
> It's much easier to communicate the differences to people with a short
> piece of text, and maybe if there is no obvious way to explain why
> you'd want to use a given client, that's a good sign it's not worth
> listing there. Otherwise you end up like xmpp.org.
>
>> Some of the options that are de-facto the most popular
>> with users like BlockChain.info or just using your MtGox account are not
>> mentioned at all.
> It's true that bitcoin.org needs to be conservative. That said, I'd
> like there to be sections for them too, actually. I agree that risk
> isn't purely about how it's implemented and that whilst we might like
> to push particular ideologies around protocols or code licensing, that
> isn't especially relevant to end users who have different priorities.
> Track record counts for a lot as well.
>
next prev parent reply other threads:[~2012-07-10 2:36 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-09 15:54 Amir Taaki
2012-07-09 16:04 ` Gregory Maxwell
2012-07-09 16:09 ` Amir Taaki
2012-07-09 16:39 ` Stefan Thomas
2012-07-09 16:55 ` Harald Schilly
2012-07-09 17:21 ` Luke-Jr
2012-07-09 17:46 ` Gregory Maxwell
2012-07-09 18:03 ` Alan Reiner
2012-07-09 18:29 ` thomasV1
2012-07-09 18:18 ` Amir Taaki
2012-07-09 18:30 ` Mike Hearn
2012-07-09 22:26 ` Stefan Thomas
2012-07-09 22:37 ` Mike Hearn
2012-07-10 2:36 ` Stefan Thomas [this message]
2012-07-10 2:44 ` Alan Reiner
2012-07-10 3:05 ` Gregory Maxwell
2012-07-10 7:12 ` Wladimir
2012-07-10 9:11 ` Stefan Thomas
2012-07-13 15:20 ` Daniel F
2012-07-09 23:07 ` [Bitcoin-development] Wiki client list (was: Random order for clients page) Luke-Jr
2012-07-09 18:48 ` [Bitcoin-development] Random order for clients page Gregory Maxwell
2012-07-09 20:44 ` Jeff Garzik
2012-07-09 17:33 ` Nils Schneider
2012-07-09 18:24 ` Amir Taaki
2012-07-09 18:54 Jim
2012-07-09 18:57 ` Gregory Maxwell
2012-07-09 19:14 ` Alan Reiner
2012-07-09 20:13 ` Gary Rowe
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=4FFB9537.8040909@justmoon.de \
--to=moon@justmoon$(echo .)de \
--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