As someone who focuses a great deal on user experience, people are often surprised that I don’t use OS X as my primary desktop operating system. Most people tend to associate the extra effort Apple put into the design of OS X with a better user experience, but graphic design and user experience are not synonymous. The truth is, I find that all desktop OSes are rather lacking, and believe the primary reason people think OS X is so good is because Windows is so bad (and Linux is scary).
I use Linux as my default desktop operating system. I use Windows for specific tasks like writing my books, recording video tutorials, and running certain programs such as Adobe Premiere. I use OS X at my current job for Android development (at my previous two jobs I used Linux, but I also used OS X at the two before that). Each operating system has good aspects and bad aspects.
For instance, browse to a directory in Windows and open a new window. The new window is set to the current directory, which makes it easy to open windows to folders that are deep in the hierarchy but close to each other. In OS X the new window will go to “All My Files” and Linux will go to the user directory; both make it much harder to work with deep hierarchies (and they both have different workarounds for this problem).
I thought it would be useful to highlight a recent experience I had in OS X. The task was simple: I needed to save an XML file from the web, move the file to a specific folder, and make a minor change to the content of the file.
##The Experience## I started by saving the XML file to my home directory.
I opened Finder, but it went to “All My Files” instead of my home folder. There was no obvious way to get to my home folder. I enabled “Show Path Bar” but it didn’t show any path because it isn’t a real folder. I went to an arbitrary folder (Desktop) to make the path bar useful. Since there’s no apparent up navigation, I clicked on my home folder in the Path Bar. That didn’t do anything. I double-clicked; that worked, but it didn’t even have a touch/click state.
Finally at what should have been the starting point, I selected the file and pressed Command+X. Then I needed to navigate to a specific folder in ~/Library/ that I needed to put the file in. The Library folder did not show in Finder, but I was reasonably sure it already existed. I opened view preferences to allow it to show the Library folder. Then, I navigated into the specific folder I needed to put this file in and pressed Command+V… but that didn’t paste it. I opened a second Finder window and it was back at the “All My Files” location. I again navigated to Desktop, so that I could see the path bar, and then navigated to the Users folder and dragged my own home folder into the Favorites section so that I can actually get to my home folder easily.
I tried to press Command+X and Command+V again (in case any of the previous operations had caused Finder to forget that I was trying to cut and paste the file). It didn’t work. I dragged the file between the two windows instead.
I opened up the file because I needed to change one line, but it opened in MS Word. I closed Word and right-clicked on the file, picked “Open With,” and picked “Other…” I selected TextEdit and picked the option to always open with that program. It’s not a great program, nor is it ideal for XML, but it’s a much better choice than Word for the time being. I double-clicked the file and it opened in TextEdit. I changed the line I needed to change and closed the file.
I opened Android Studio, but it didn’t list the file in the dropdown. It should have automatically picked up that the XML file was there and listed it in the dropdown as an option. I tried closing and reopening Android Studio, but that didn’t help. I looked at Finder again and saw the file was now being considered Plain Text instead of XML even though it still had the same file name (XML files are actually just plain text and another file in the same folder was still listed as being XML, so this behavior was unclear). I assumed the OS reporting the file as the wrong type was the reason Android Studio wasn’t seeing it, so I explored the context menu and some other options, but there wasn’t an obvious way to tell the system that it was still an XML file. I tried changing some of the settings in TextEdit so that it would save as a UTF-8 file, etc., but there didn’t seem to be any way to tell it to not change the file “Kind” (which is presumably Apple-speak for file type).
A Google search later and the solution I found was that you need to open that application bundle’s Contents/Info.plist file and… What the hell??? No, I wasn’t going to do that. That was a little too close to jumping to a registry hack in Windows for what should be a relatively simple fix.
I decided to start fresh, so I clicked the file and pressed the delete key. It did nothing, so I pressed the other delete key (aka backspace), but it did nothing. I still don’t know why there are two keys with the same name that have different functions, but eventually I figured out that it’s Command + Delete (the backspace delete, not the normal delete) to delete the file.
I grabbed a copy of the original XML file again and double-clicked it. It opened in Word for some reason. Frustrated with the GUI at this point, I closed Word and opened a terminal. I used Vim to change the file and the command line to move it to the right place. It was still recognized as an XML file instead of magically changing to a Plain Text file. I reopen Android Studio and it still didn’t see the file. This finally made it click for me that the XML itself supplies a name, which is what Android Studio looks for. The file had a node that defined the name as something that already existed, but Android Studio didn’t throw any error and instead had just been ignoring the file. Once I reopened it in Vim and fixed the name, I was able to get Android Studio to see the file.
##Summary## If you’re not used to developing user experiences, your gut reaction is probably that I (the user) did multiple things wrong; however, if you focus on the user experience, you ask questions like, “What caused the user to do that?” For instance, what causes a user to try to cut and paste a file? This is a learned behavior that works in Windows and Linux. It also works throughout different apps in OS X, but it doesn’t work in this one specific case. It’s not clear why it doesn’t, so you then ask what indicators there are about this behavior working or not working. Unfortunately, there is only one single, subtle indicator. If you press Command+C, the Edit menu will briefly highlight; if you press Command+X, it doesn’t highlight. Unfortunately, the menu bar is not actually attached to the individual window in OS X, which means the Edit option was about two feet away from where I was looking on the rather large monitor. The fact that the file didn’t disappear or fade when cut didn’t trigger any user behavior because the feature is so strongly expected. Apparently, you can copy the file (Command+C) and then move the file with Option+Command+V. Why they would change the paste keyboard shortcut to replace the cut keyboard shortcut is unclear. Going to the Edit menu won’t even show that this is a feature unless you also hold down the Option key while the Edit menu is open.
Other issues have workarounds. For instance, you can press Command+Up to navigate up a directory in Finder, but there is no icon to easily do this with the mouse. Ultimately, a lot of really basic tasks are made harder without any obvious benefit. Once you spend the time it takes to get used to doing things this alternative way, you probably have a hard time understanding why someone would have any difficulty at all, but it’s important to ensure a user experience is good whether it’s for a beginner or a power user.