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 > <[email protected]> wrote: > > >> On Oct 29, 2016, at 8:11 AM, Xiaodi Wu <[email protected]> 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 > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
