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

[Xiaodi Wu]

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

>
> On Oct 29, 2016, at 2:56 PM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
>
> 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.
>
>
> Because your arguments are assuming that the user can’t figure things out,
> when they totally can. It is an extremely common (almost subconscious)
> caricature of “The User”.  As a young designer, I was yelled at once by Don
> Norman for doing the same thing.  I was complaining about the design of a
> room key (The arrow on the key needed more salience to afford how to use
> it).  He replied, “Sure, it could be better. Things can always be better…
> but were you able to get into your room?”.  Yes, I had.  He then asked
> several other people nearby if they were able to get into their rooms.
> Everyone had.  “How many people in the entire hotel do you think were not
> able to get into their room because of this?  Tell me again why the hotel
> should spend thousands of dollars to reprint their keys to solve this thing
> which may be an annoyance, but hasn’t caused an actual problem?”.  He then
> told me that people were much more capable than I was imagining them to be,
> and that I should give them the credit they deserve because failing to do
> so is ultimately harmful not just to the user of my designs, but to the
> design profession in general.  It took me several years to really truly
> understand what he meant… but he was (as usual) right.
>

Perhaps he was right about your room key. But we're not designing room keys
here. (Also, have you *never* been annoyed by room keys and wondered to
yourself who the !@#$ designed that piece of crap? But I digress.)

Figure out how to use your room key and the task is done. You're in your
room. Figure out how to type and you're at step 0 of a long list of steps
towards writing anything remotely useful in Swift. Make every step slightly
annoying and you've got an infuriating language.


> I was being slightly hyperbolic, but you are arguing that figuring out how
> to use autocomplete (or even use the option key to type a symbol) is too
> difficult for beginners.
>

I'm not arguing that it's "too difficult" a challenge to surmount--I'm
arguing that if we stick to ASCII the challenge would not exist in the
first place, and that we should not challenge the user to any degree
whatsoever with regards to typing. There are other, more salient challenges
already.


> You have also argued that having both ‘formsUnion’ and the union symbol
> would be too much of a burden on someone learning the language.  You are
> assuming they will fail, no matter how well the UI is designed.  I am
> saying, there might be a brief moment where they are learning, but once
> they get it… they will get it… and they will be able to express themselves
> much more as a result.
>
> Also, I don’t think I have ever talked about requiring anyone to figure
> out the symbols.  Rather I have talked about building on-ramps to teach
> them to be able to use the symbols freely where they want to.
>

I understand. There's a mini-argument here that I didn't write out. It's
been said that Swift is an "opinionated" language, not a
to-each-their-own/design-by-committee kind of language. Thus, afaict, the
modus operandi is that what's decided to be the best way is adopted as the
*only* way.

Other than for compatibility reasons, perhaps, there are few if any aliases
in the standard library. If we decide that the less-than-or-equal-to symbol
is the best way to invoke that particular operation, then `<=` would be
deprecated and then in the next version removed. If that's too much to
stomach, then it's a hint that perhaps the less-than-or-equal-to symbol
isn't good enough to replace `<=`. I don't see room for an in-between
solution where the same function is named two or three ways.

> 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.
>
> Apologies, it was someone else who wrote me about vim.
>
>
> 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.
>
>
> I actually just finished teaching a Swift class for people who had never
> programmed before.  They had trouble with <= (“Why does the arrow mean less
> than or equal? Why can’t I use ≤?") and != (“But the ! has to do with
> optionals”… I think they thought it was unwrap and assign like *= is
> multiply and assign).  They were able to solve these issues, of course, as
> they are intelligent people… but let’s not pretend that ASCII is magically
> free of confusion.
>

If only you'd read as many documents as I have where the
less-than-or-equal-to sign is written by underlining <, you would see that
your proposed solution to these issues is not nearly as obvious as you make
it out to be. (I'm a biologist by training; the number of manuscripts in
that field where one sees it written as "*<*" [note to non-rich-text
readers: that's "<" with an underline] is very near 100%.)


> Having fewer available symbols means we are forced to chain the symbols we
> do have together in suboptimal ways (I believe there is talk of adding <=>
> to the standard library).
>
>
> 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?
>
>
> In Xcode, they could mouse over it and see the word “union”.  In the
> documentation, it could say “Union Operator. Adds the elements of the given
> set to the set.”  It could even have a hint on how to type it (e.g.
> '^union’), and that part could be auto-generated.
>

But if it needs to be documented as "union operator" and needs a tooltip to
say "union" and you need to type "^union", why wouldn't you just name it
"union" _as it already is_?

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.
>
>
> I do agree that easy things should be easy. I am saying we can make this
> easy if we want to.  Easy enough that it can be used in any Swift code,
> even the core libraries when appropriate.
>
> Again, if a symbol isn’t clear, we shouldn’t use it (and we can argue over
> what is clear or not in other threads). We should use whatever is clearest
> and most expressive. If that is ASCII, that is great, and if it is unicode,
> also great.
>

I'm arguing that any ASCII character is at baseline, simply by virtue of
having the increased recognition that ASCII characters do, clearer than any
non-ASCII character to a general audience. There would have to be a huge
win in expressiveness for any particular non-ASCII character to overcome
that handicap. And I'm arguing that the most plausible scenario in the
standard library where we might see a huge win--the union operator--does
not, for me, pass that bar.

Again, this has nothing to do with how you write your own third-party
libraries.

Why should we force ourselves to use something, which is by definition,
> less clear/expressive?
>

See above. I can't accept your premise that the clearest and most
expressive choice for any standard library API would be a non-ASCII symbol.

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.
>
>
> I am not saying that we should make things purposefully unintuitive.  But
> for expert systems, we want to optimize for efficiency of use, error
> recovery/prevention, and expression over walk-up-and-use.  Believe it or
> not, this is the mindset the original mac was designed with (people still
> find that easy to use), and it is the mindset we should be designing with
> here.
>
> As an aside, shutting down SHOULD require effort (Just as easy things
> should be easy… dangerous things should be a little bit difficult). You
> have to press and hold the mac power button for quite a while so that you
> don’t slip and hit it accidentally.  It could be made “easier”, but that
> would put people’s data at risk.  My understanding of why people ridicule
> Windows’ shutdown is that it was under the “start” menu.
>

That's a much earlier criticism of the Windows shut down menu options...


> 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.
>
>
> In the case of the menu item, it is used to teach an accelerator which
> saves time.  I am saying, we can use the same technique to teach symbols
> which are more concise, are more easily located in code, and are more
> representative.  If the symbol is less representative than the word in a
> particular case, then we should use the word.  We should use whatever is
> best.
>

Yes, and I'm saying, in the standard library, what's best isn't the symbol.


> Funny story: For new users (to a shortcut), especially those who are
> currently using the mouse, keyboard shortcuts actually take longer than
> using the menu, despite the fact that it FEELS much quicker to them. The
> brain basically stops making memories for a second during the context
> switch.  You can sit in coffee shops and watch it happen.  I always found
> it an amusing effect. (This changes with practice for common commands due
> to muscle memory)
>
>
> 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!
>
>
> Sure, but you are always going to have to teach someone who doesn’t have
> transferable experience (see above with students seeing <= as an arrow and
> being confused).  We find the mouse intuitive now, but the original Mac
> came with software which taught you how to use it (and they needed to).
> Should we have stayed with DOS, because people knew how to use the keyboard
> (and we don’t want to teach them a new thing)?
>
>
> 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.
>
>
> Well, image literals currently work exactly the same way I am saying
> unicode should.  I agree that they are very beginner-friendly and
> pedagogically useful.  Why do you think we can’t make symbols
> beginner-friendly and pedagogically useful?  Is having both image(named:)
> and image literals confusing to beginners?  No it is not.
>
> This is not to justify making an API change.  I am saying that we need to
> do whatever is clearest and most expressive.  We can argue over whether ≤
> or <= is clearer or more expressive (that is a separate issue), but I am
> shocked that so many are arguing that we should limit clarity to adhere to
> an ASCII only rule.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161029/f967ef3c/attachment.html>