[swift-evolution] [Meta] Let's talk TouchBar + Unicode
Sean Heber
sean at fifthace.com
Sat Oct 29 16:58:24 CDT 2016
Well said. For what it is worth, I agree entirely. Let's move programming forward a little!
l8r
Sean
Sent from my iPad
> On Oct 29, 2016, at 4:14 PM, Jonathan Hull via swift-evolution <swift-evolution at swift.org> 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.
>
> 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).
>
>
> 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.
>
> 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. 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?
>
> 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…
>
>
>
>
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161029/738c0057/attachment.html>
More information about the swift-evolution
mailing list