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

[Jonathan Hull]

> 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 <mailto:jhull at gbis.com>> wrote:
> 
>> On Oct 29, 2016, at 8:11 AM, Xiaodi Wu <xiaodi.wu at gmail.com <mailto: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.

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.  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.


> 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.  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.


> 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.

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


> 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.

> 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.

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/89cc3eb1/attachment.html>