[tahoe-dev] barriers to using tahoe

Jody Harris imhavoc at gmail.com
Sat Feb 6 08:53:06 PST 2010


On Fri, Feb 5, 2010 at 11:05 PM, Chris Palmer <chris at noncombatant.org>wrote:

> Jody Harris writes:
>
> >   - "Those who understand what Tahoe is" (understanders),
> >   - And "Those who don't care" (users).
>
> I reject this dichotomy for practical reasons.
>
> http://en.wikipedia.org/wiki/The_Mythical_Man-Month#Conceptual_Integrity
>
> I suspect that bugs, unusability, insecurity, and unreliability go down as
> the gaps between the abstractions of UI, architecture, and implementation
> narrow. This usually results in the reduction of many (but not all) kinds
> of
> complexity up and down the abstraction stack.
>
> I also reject the dichotomy for ideological raisins. I refuse to accept
> that
> "users" are "stupid".
>
> http://www.amazon.com/Inmates-Are-Running-Asylum/dp/0672316498
>

I reject your rejection on grounds of good design practice.

Not "stupid." Invalid. Expression "does not care" does not equate to
"stupid."

Tools can be used on different levels.

Analogy: Linux command line.

It's there on every system, but the average user has no reason to ever see
it.

It's not that the average user is stupid or incapable. It's just that they
are not going to invest the time to learn and master it. If they decide to,
it's readily available to them -- there are no artificial barriers.

Analogy: web browser: view page source.

Analogy: computers
  Users don't have to understand how they work to make good use of them.

Analogy: Macintosh computers


Not every functionality needs to be exposed through every interface. Most
users are content that a task is completed per their expectations. Any
further information essentially "breaks" the system for them. Too much
information leads to mental buffer overflows.

Thoughts?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://allmydata.org/pipermail/tahoe-dev/attachments/20100206/028d0228/attachment.htm 


More information about the tahoe-dev mailing list