[swift-evolution] [Meta] Let's talk TouchBar + Unicode

[Xiaodi Wu]

On Sat, Oct 29, 2016 at 4:14 PM, Jonathan Hull <jhull at gbis.com> wrote:

>
> On Oct 29, 2016, at 8:11 AM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
>
> However, *my* main point is that the Swift's standard library APIs (and
> the keywords and syntax at the core of the language) should use a character
> set that *requires no discovery whatsoever* for the vast majority of users.
> It is difficult enough to master a programming language, more difficult
> still to master one's first programming language (and--per the core
> team--Swift aims to be a great first programming language to learn); it is
> _bonkers_ to pile onto that the need to "discover" (however smoothly that
> goes) how to physically input the characters required to invoke some method.
>
>
> I am always amazed at this caricature of users as somehow simultaneously
> complete idiots (unable to figure out the option key) and experts in
> archaic computer architecture (…and they use vim).  It is extremely
> disrespectful to the actual user.  A good rule of thumb is to think of the
> user as extremely intelligent, but too busy and important to deal with your
> interface.
>

This is a completely unfair characterization of my argument. I'm not sure
how you conclude from the text that I've written above that I believe Swift
users to be "complete idiots." On the contrary, I am saying that the user
is indeed too busy with important matters to want to deal with figuring out
how to type some weird symbol they've never seen before.

And while I do find myself using vim sometimes, I hardly consider it a
paragon of discoverability, and I've never mentioned vim in any
conversation. Not sure why you're throwing that into the discussion here.


> From today’s Daring Fireball:
>
> Apple has always been very good at this — designing software and hardware
> where complexity is encapsulated rather than hidden. The genius of the
> original Mac wasn’t that it was suitable for dummies but that it was the
> first system that wasn’t confusing. Smart people flocked to the Mac.
>
>
>
> There is, by definition, always discovery.  I think what you are really
> arguing is that there is forward transfer from things like word processing,
> and there is… it is important.  But there are also still tradeoffs forced
> by your limitations that harm discovery in other ways (not to mention that
> I often use ≠ and ≤ in word processing).
>

Why does not having the less-than-or-equal-to sign "harm discovery"? FWIW,
it has been observed numerous times on this very list that operators are
_less_, not more, discoverable than other functions.

Let’s take, as an example, discovery of “formUnion”.  How will a user, who
> doesn’t know about this, discover it’s existence and how it works?
>
> • For the lucky people who already know about unions, but not swift’s
> crazy “formUnion”, they are in luck.  If they just start typing ‘uni…’,
> then ‘formUnion’ will show in the autocomplete.  Hmm… sounds like the exact
> method I was talking about with symbols.
>
> • Maybe they will command-click into the definition file, and then see
> formUnion definition there.  But couldn’t they also see the union symbol
> defined there?
>
> • Maybe they search for the documentation and find “formUnion” explained
> on the page. Again, the same is true of the operator.
>

OK, and if you've never seen that symbol before, just how do you say "∪"?
As in, literally, how would someone who just discovered such a hypothetical
operator in Swift's documentation for SetAlgebra turn to another programmer
and pronounce it? Here's the description in the documentation: "Adds the
elements of the given set to the set." Not very helpful for figuring that
out, is it?

There is the issue of how to learn from an already typed symbol how to type
> it, but I can think of several easy ways to do that in the UI (even
> something as simple as a tooltip). I trust the Xcode team to be able to
> come up with something appropriate and user test it as necessary.  (What
> about vim users?  I trust they can figure it out)
>
>
> We do need to be aware of and support beginning users, but optimizing
> Swift (or any expert system) for beginners just leads to a disempowering
> experience for everyone.
>

Disagree strongly. Easy things should be easy, even when they're part of
complex systems. Not everyone learning Swift has to grasp copy-on-write on
day 1, but no one should have to struggle with how to type something.

Just because a computer is a powerful device doesn't mean that we should
tolerate the power button being unintuitive. (See, for example, widespread
mockery of some versions of Windows because shutting down requires several
menu clicks.) Just because Swift is a powerful language does not mean that
we should give ourselves license to make the basic task of typing the
letters required to invoke a function any harder than is absolutely
necessary.

Instead, we need to optimize for the users they will become, and provide
> “on-ramps” for the beginners.  This is UX 101.  Alan Cooper is probably the
> one who talks about this problem most, but any well trained designer will
> tell you the same.
>
> You were characterizing having both ‘formUnion’ and the union symbol
> operator (or both <= and ≤) as a burden on the user’s feeble mind, but it
> isn’t.  It is an on-ramp.  It teaches them how to use the system!  Are
> people confused by having ‘Save’ in the menu bar and also ⌘S?  Or does the
> save menu command teach them how to use the keyboard to save time?
>

This argument is unpersuasive. The situation with "formUnion" is the
diametrical opposite of your example of the "Save" shortcut. There, the
more discoverable method (the menu) is slower than the less discoverable
one (the shortcut), so one points to the other. (Notably, on the Mac,
pressing the shortcut will also highlight the corresponding menu, so it
works both ways.) How is having the less-than-or-equal-to symbol "saving
time"? Is it really faster for you to type it out than to type "<="? That's
certainly not the case for me! Half the time I find myself responding to
you, I'm using the iPad, where I have not yet worked out how to type that
symbol at all. Hence, "less-than-or-equal-to" it is.

I'm glad you have some thoughts as to how to teach someone to do something
(typing the less-than-or-equal-to sign) that's more difficult than
something else (typing "<="). I totally agree that where something is
necessarily difficult, then we should be thinking to these methods of
teaching users. But you know what's better than a good way of teaching
something? Not having to teach it at all!

I should point out that all of your arguments also argue against things
> like color and image literals (which are features I absolutely love). I am
> really glad that those didn’t have to go through this process, because we
> never would have done it.  I guess that is what is worrying me…
>

Huh? How is this related in any way to color or image literals? Those are
extremely beginner-friendly and pedagogically useful facilities. Again, you
are misunderstanding my argument. Colors and images are often used in Swift
programming, and referring to them by a series of hexadecimal numbers or a
file path (respectively) is unintuitive. It is therefore useful to have a
beginner-friendly, WYSIWYG way of specifying a color or image. By contrast,
typing the less-than-or-equal-to symbol is not necessary in Swift. It is
totally backwards to design an elaborate way to make it easier to do so for
the purpose of justifying an API change that will make them necessary.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161029/77f67f38/attachment.html>