The Desktop Strikes Back

Darth vs Obi Wan

I was surprised and delighted by Microsoft’s introduction of the Surface Pro 4 and and Surface Book. I have a feeling that Microsoft is doing something really interesting: Bringing back the general purpose personal computer. Wait, wait, I know what you are thinking! It’s all about the phones and pads and the Internet of things! I get it! I’m not some old guy pining for the days when PC were king and 640K RAM was a luxury. Well, actually, I am that old guy. But I have not personally coded a desktop app, native or web, since 2010. Everything thing I do for work or play is meant for mobile devices. I’m usually the guy in the conference room saying “We need to focus on Mobile!” and “kids today don’t even know what a desktop is.”

But Microsoft and some of the recent changes to Mac OS X in El Capitan are making me think there is some life yet left in the PC.

While Apple is targeting coffee shop-consumers by making MacBooks  lighter but less powerful or targeting highly specialized markets with high-resolution workstations, Microsoft has reminded me that there is a vast middle in this market. And that middle is still mostly using desktops that run Windows. There hasn’t been growth in the middle for a while but then again there hasn’t been much product to spur growth.

Every year I want to buy a new phone. I swear have every iPhone model in a drawer starting with number 3. But buying a new computer is something I do only when I absolutely must. There just isn’t any reason to upgrade a contemporary desktop or laptop. And looking at where Apple and Dell and other PC manufacturers were going it seemed to me that PC were just getting specialized. The middle ground was a nomad’s land of crappy plastic slow PC encircled by ultra-lights and gaming rigs.

A while back I bought a Surface Pro 3 with it’s pen, keyboard cover, and Windows OS. I found it… interesting. A had to pair it with an Apple Wireless Bluetooth Keyboard to get a decent typing experience. And Windows 10 is still a little rough. Ok, Windows 10 is a lot rough. And confusing. But it getting better.

I feel a great nostalgia for all things from the original Bill Gates/Steve Jobs era. I will probably end up acquiring a Surface Pro 4 or a Surface Book. I’m pretty sure either of those products will not displace my iMac 5K as my go-to general purpose computer for coding, blogging, podcast editing, and cartooning. (Everything else I do, I do on my iPhone.)

But heck, I want Microsoft to win here and bring the PC back to the forefront of the consumer electronics revolution. So here are five suggestions or tips for MS that would have me running to the Microsoft Store as if they were selling Tesla Model Xs at a deep discount!

Tip 1: Really rethink Windows and the UX of a desktop operating system.

I know MS got in trouble for removing the Start Menu. But seriously: There is no Start Menu in Mac OS X or iOS because for the most part the whole operating system is the Start Menu. Go back and look at the Xerox Star if you have to. Don’t try to mask complexity with a handful of easy-to-use screens hiding the real OS. When I worked at Apple we had a saying: “Every pixel counts.” It’s clear to me that on Windows some pixels count more than others.

Tip 2: Bring back desk accessories

I know that both Apple and Microsoft have failed at providing consumers with a library of little single-purpose applets that share the desktop with the bigger multipurpose applications. But, as guy who once wrote a mildly popular Yahoo Widget, there is real consumer value in DAs. I think the original Mac OS and PC DOS got it right: Apple’s Desk Accessories and Borland’s Sidekick provided little utility functions that were easy to access, simple to use, and fast to summon and hide. By contrast Apple’s Dashboard Widgets and Microsoft’s Desktop Gadgets were slow and clunky. These decedents of the desk accessory were too ambitious and missed the whole point. I want “info at my finger tips.”

Tip 3: Fix the menu bar or retire it

I was so excited when Mac OS X El Capitan enabled me to hide not only the taskbar but the menu bar as well. I hate the menu bar! It’s usually a dumping ground for every feature of an app randomly arranged. Long ago the menu bar had a formal structure. It was drilled into my head as a young software developer that menu titles were nouns and menu bar items were verbs. If I had a document menu then all the menu items were the operations that could be performed on documents. But right from the get-go both Apple and Microsoft ignored that simple and powerful idea. Almost all Windows and Mac apps have separate “File” and “Document” menus. I know that files are those objects that computer applications store data into but we tell consumers to call those things documents. Everyone is confused. And then there is the universal “Edit” menu which should be called the “Selection” menu. This might seem like small potatoes but I’ve learned trivial details are the stumbling blocks that kill product adoption.

Tip 4: Make the desktop a first class entity

Most flavors of Unix are doing the Desktop right and Apple and Microsoft are starting to get clued in. It should be very easy to set up and arrange windows on a desktop and have them stay that way for eternity. Like really forever and definitely between restarts and system updates. Adobe understands this and gives each of its apps a layout manager that allows artists to personalize and save their workspace. Context is everything. Humans are dumber in unfamiliar contexts and smarter in well known contexts. A desktop is really just a context of virtual objects. I think phones are easier to use, not because they are better designed than PCs, but because they naturally just have one context, one screen, at a time.

Tip 5: A list of five more tips

Bonus round!

  1. Don’t go too far trying to make the desktop UX the same as the mobile UX. They are two different use cases. Shortcut keys, content menus, and over lapping windows are great features and can’t really be replaced by gestures, hard presses, and split screens.
  2. Bring back BASIC or Hypercard or some kind of programming environment intelligent non-computer scientists can utilize to create real apps on their own. It’s not about workflow automation. Do not copy Apple’s lame Automator or evil AppleScript.
  3. Clean up your Windows Store. Be even more picky than Apple. Keep out the spam, copy cats, and useless garbage. But make sure users can continue to download and install non-certified apps. I know it’s risky but it’s also capitalism.
  4. Reactivate Windows third party developer base, not by enabling quick and dirty ports of websites into Windows apps but by continuing to empower and simplify and open Visual Studio. I went to one of the very first Windows developer events in Redmond in the early 90s. I got to shake Bill’s hand. I’m sure he doesn’t remember me but I really wanted to write Windows apps after that.
  5. Continue to revive and refine the general purpose personal computer that is great for everything and works for everybody. I don’t want or need a workstation. I do want to get a lot of work done. Instead of thinking like Apple, think like the Microsoft that re-packaged and made affordable the hoity toity graphical user interface in an open system for schools, small businesses, and nerdy kids.

Even if Microsoft succeeds with the Surface Pro 4 and Surface Book, the PC market will most likely continue to look to Cupertino and Redmond steal marketshare from each other. But unlike smart phones, pads, and household items with embedded microchips, PCs are programable–by users. And that is something worthy of a battle with the Empire.

The Secret to Swift is Enums

I’ve found the CS193P (Developing iOS 8 Apps with Swift) iTuneU class really helpful in wrapping my old Objective-C head around Apple’s new Swift programming language. Yes, I know we’re at iOS9 but the fundamentals of the class are still relevant and coaxing the code to compile in iOS 9/Swift 2.0 is a fun little last in and of itself.

The big revelation for me is how core Swift’s enums are to understanding and using the language properly. When Apple decided to improve it’s development environment it could have done so in a million different directions. Apple could have just patched up Objective-C. Apple could have moved over to Java or Scala or even JavaScript. (I was hoping for  JavaScript as Node.js and ECMAScript 6 have proved that JavaScript is an industrial strength language with a real future.)

So when I learned that Apple created a new language for iOS and Mac OS X (and now WatchOS and tvOS) application development I was intrigued and disappointed and hopeful all at the same time. Many parts of Swift seems easy and cool but some parts were down right intellectually challenging: Classes and Structs? Super fancy Enums? Optionals? Strings with out a simple function to get their length? What the heck is going on here?

Swift seemed promising. But it was also changing rapidly over the last year. I fooled around with it but when I hit optionals and weak references I realized the language was not going to sugarcoat the problems of null pointers and memory management–it was trying to make them more tractable.

Optionals were especially vexing. var amount: Double? was not a Double. It was a potential Double. Amount! had better be a Double or it would crash my program. If it was’t for Xcode’s automated static code analysis I never would have been able to put the ? and ! in the right places after the right variable names. And I didn’t like that feeling.

But then I found CS193P and Professor Paul Hergarty’s remarkable ability to explain things simply.

Enums in Swift are amazing little machines. They have little in common with C Enum other than you can use them to define collections of related constants. Enums are types with values that evaluate to themselves. But  you can associate a “raw value”, like a number or a string, or more a advanced value, like Tuples or Arrays or Dictionaries. And with advanced types come functions and closures.

Yikes. These are not your father’s Enums. As Professor Hergarty’s says, Swift Enums are types used for when you want to switch between values. And, point of fact, Swift Enums are defined like a Switch structure with case statements. Each of the cases, except with raw values, can be of different types.

And boom! That explains Optionals. When you have a value that could be nonexistent or of some type, an Optional is just an Enum that wraps up it safely so you can pass it around without crashing. ? and ! are just syntactic shortcuts for accessing the different states an Optional variable might be in. Imagining that Optionals are Enums gave me the handle my mind needed to process the whole concept.

In CS193P Professor Paul Hergarty uses an Enum to power his “Calculator Brain”. In any other programming language an Enum would be used to make the code more readable. But in Swift you can use an Enum as the glue to associate states with types with functions. I have a feeling that this Enum-driven mechanism is the cleanest way to write a Swift state machine. It’s still a little rough around the edges and verbose. But it’s a super reusable pattern good not only for the mathematical operations of a calculator but for managing the states of a web server, business application, or game.

You should watch all the videos in CS193P to get the full picture. But in the meantime I’ve created a simplified version of Professor Hergarty’s CalculatorBrain suitable for a Swift Playground (above). As you fool around with the code keep in mind the following points:

  • CalculatorBain is a class and when it’s instantiated it’s initializer creates a dictionary of operations that it knows about based on type. You can add more known operations by writing a little code in one place. In the sample code the operations for addition, subtraction, division, and multiplication are written very concisely using Swift’s shortcut syntax for closures with default parameter names. (This reminds me of the best features Perl.)
  • The custom type Op is an Enum that is self documenting and has values associated with either a Double (for operands) or a Dictionary (for operations indexed by name). So simple lookups via a case statement are all that is needed to process input and output a result.
  • The two Evaluate functions are recursive, calling each other until every operand or operation needed in the Ops stack is consumed. Evaluate basically does this:
    • Until the Ops stack is empty pull an item off the end of the stack.
    • If that item is an Operand return it and the remainder of the Ops stack.
    • If that item is an operation dig into the Ops stack until you can get two operands and then execute the function associated with the operation using the operands.
    • The return the result with the remaining Ops stack.
  • If I had to write this code without using recursion and without Swift’s muscular Enums, well, there would be a lot more code and it would be more “hard coded”.

The only improvement I can think of would be to declare the known operations as a literal Dictionary. But the Swift compiler isn’t ready for that and complains: “Expression was too complex to be solved in reasonable time”. I guess if Swift can’t do something swiftly it doesn’t want to do it at all!