The Evernote corporation recently released version 5 for OS X. I believe the iOS apps were also recently updated. I haven’t considered using the application and it’s framework in a few years, but wanted to give it another look. I’ve got a lot of friends and coworkers who use it religiously.
The UI of version 5 is definitely improved. Overall, I’d say it looks more look a Mac app now and less of a cross platform half-breed. But after playing with it some more, I come away with the same conclusions I’ve had in the years past. Mainly, I don’t trust them with my data and getting my data out of the application is still more of a chore than it should be (a criteria I give top priority for any application these days).
Yojimbo may be less attractive in today’s data anywhere/everywhere mentality (sync is essential), but at least exporting is done right. Exporting a plain text note results in a plain text file. Same for an image. With Evernote, you still get a clunky XML based file that results in more work to get the key piece of info out. I’ll stick with other options.
I haven’t had a chance to give this a try yet, but the idea looks fantastic. Even more helpful if you’re using Sass. If you’re into Front End Development, give this a look. There’s a quote from Elliot Jay Stocks on the site that sums up the usefulness for me:
For early-stage local development, it’s making life so much easier!.
Also, read this post from Any Clarke for a real world example of how a pro puts the tool to use.
LaunchBar enthusiasts may already be aware of this, but I stumbled upon the ability to add reminders to Reminders (I now have visions of Austin Powers running through my head). It’s quite slick.
The key to remember is that the Reminders application from Apple uses lists. If you’ve never modified from the default, then your list is called Reminders, as shown in the image here. Simply type the name of your list into LaunchBar, then press enter to open the dialogue you see here. Add the description for your reminder, then a due date if desired. The due date comes after the right angle bracket (>), which can be created by pressing tab if you’re a lazy typer like me.
Little things like this were what drew me to using a Mac years ago, and they continue to delight me today.
I’ve played with Hazel in years past, but never looked at it too seriously. It’s definitely a powerful tool! But I found one aspect of the utility very unintuitive. For extra nerdy Mac nerds, this may be either underwhelming or very obvious.
I was looking for an a solution for a coworker yesterday, who had a fairly simple issue. She has her pictures folder filled with subfolders. These sub-folders have more sub-folders or images (Picasa puts the folders there). She simply wanted her Pictures folder to be filled with images, no folders. She was hoping for some kind of automated solution to move all the images into one location, minus all the subfolders.
My answer: Hazel should take care of that, no problem. And it did. But getting there was less intuitive than I expected.
The problem was this: no where could I find an explanation that when you choose to create rules for a given folder, you have to first specify that your rule(s) be applied to the contents of the folder. In my head, I had this assumption that this was implicit and did not need to be specified. I get it now — you may want to act on the folder itself, not its contents, so it has be explicitly set. But it took a good bit of testing (and a little guidance from Garrett St John) before I had the solution.
I looked through many a blog post, from authors such as David Sparks, Shawn Blanc and Ben Brooks, but never found any mention of this. Same for the Noodlesoft site (not the best source of documentation!). I realize this could simply because it’s obvious to most folks and I’m just a little dense.
But in the event that others have been tried out this tool and been confused, I thought I would share this tip. If you want to have rules that apply to the contents of a folder, you must add this rule at the top of your list of rules.
A few updates to my list of things to do on a new Mac:
I find a strange dichotomy with the direction of iOS, and correspondingly, with OS X. The push for focus, for embracing the constraints of iOS, where you can only work in one application at a time, has been a welcome change for me. Having this direction partially come over to OS X has also been positive (I say partially because full screen mode doesn’t stop me from swiping between spaces, but only slightly alters my perception of my work environment).
The contradiction comes with the Notification Center. It’s sole purpose is to distract, to disrupt the focus that the OS has given you. I find the difference between the two concepts striking.
It makes sense that this comes to me now, after having used Mountain Lion. One would think I would have seen the difference previously, on iOS. But on my phone, Notification Center makes a lot more sense. The device is a satellite, not my primary tool for work. And some of the notifications are instant messages or phone calls, which indeed often deserve the attention required to break my focus. My phone is often also a consumption device. So the opportunity to distract is at worst a very minor nuisance and at times, a necessity.
On my Macbook Air, the same is not true. Notifications have proven to be nothing but a nuisance. Anyone found a way to disable it completely? Let me know.
If there’s one thing the last two versions of OS X, Lion and Mountain Lion, have shown us, it’s that the iOS-ification of a desktop operating system comes with a few bumps along the road. Having worked on Mountain Lion for several weeks now, it’s clear that working with files is an area of confusion. Something that Apple has largely removed from the mobile computing experience is still somewhat awkward in the desktop arena.
I like Mountain Lion, I do. As I did Lion. Each had their issues at the time of launch, but overall, they both brought refinement to OS X. File management underwent a few changes in Lion, and again in Mountain Lion. One item that was removed in Lion, the option to make a new document from an existing one using the File > Save As command, was purportedly coming back in Mountain Lion. And the users rejoiced.
But the last week brought reports that Save As actually didn’t work as expected. In fact, it saved changes to both the original file, plus the new copy you created. That was a surprise — I hand’t noticed this is my own usage when I upgraded. This got me poking around, documenting a few things that I had noticed while working, but hadn’t investigated further (Half way through writing this post, I came across Matt Nueburg’s summary of this topic. He’s an expert, so go read his findings).
There are four aspects of Mountain Lion that made me pause:
It’s no surprise that iCloud has evolved on the desktop. In Lion, it started with the syncing of contacts, calendars and email accounts. With Mountain Lion, it made sense to move on to files. After all, it’s available in iOS, right? Apple’s focus on cloud computing means iCloud is the centre of your digital universe, and even though they started this path focused on media (photos, music, movies), hindsight shows us that Steve & co were focused on meeting all your needs from the beginning.
The opportunity for confusion here comes with the underlying concept. On iOS, there is no file system — not from the user’s perspective anyway. But with OS X, the file system is very much a key aspect of the user experience. At least, it has been up to now.
For more technical users, there may not be any issues at all. We understand the concepts and we can navigate the interface even when it’s unfamiliar. But what about the normals? I know my parents will experience some confusing moments, because I had a few myself. The first time I saved a Pages document to iCloud, I couldn’t find it when I wanted to work on it the second time. Why? Because my habit is to open the Finder or use LaunchBar to open a file, not the application itself. Since iCloud file storage is not treated like a folder in OS X, I couldn’t find it. Once I remembered I had saved it in iCloud, I opened the app, used the new file dialogue and got to work.
This is not necessarily a problem with Mountain Lion itself. It’s just that years of working with a file system have resulted in habitual usage. And this is not only true for me, but for my less technical parents. And so I predict some confusion as people adjust to the changes.
Another area of potential confusion is the new dialogue box introduced in Mountain Lion. It opens up when you launch an iCloud-integrated application like Pages or Numbers, giving you the option to open an existing file from either iCloud or the local file system.
In and of itself, this is not confusing if you know the file you’re looking for and where it’s located. But what about new files? There’s button on the bottom left titled New Document. Click this and a file opens. So far, so good. The confusion comes when you hit command+S to save for this first time. From there you’re giving another dialogue, but this time it’s not the iCloud-focused dialogue. Rather, it’s the more familiar Save dialogue box, which allows you to name the file and choose a location to save it.
And regardless of the location that was displayed with the previous dialogue box, the second one defaults to iCloud, but with an available drop down that allows you to choose another destination.
If you have decided to work completely with iCloud, this may not cause confusion for you. But if you prefer the local file system, having two dialogues that present different locations can be slightly jarring.
These new behaviours can be further confused when mixed it with varying applications. Many popular apps are not iCloud compatible. And so the behaviours displayed by an iCloud integrated application are not available with a non-iCloud app. A good example is Microsoft Word. When working with a Word document, typing Command+Shift+S brings up the old, familiar save dialogue, operating exactly as Save As did back in Snow Leopard.
This will be an issue for a less technically inclined user regularly using apps of each variety, switching back and forth between the two behaviours.
As mentioned above, Save As is back, but it’s a little different than it’s predecessor. For one, it isn’t visible in the File menu unless you hold down option. Secondly, as mentioned above, the original file will be altered when Save As is invoked in certain scenarios. Please note the distinction I make, which is different from the statement that got me looking into these behaviours in the first place.
The original statement was that the Save As option always modified the original document as well as the new version that is created with the Save As command. Funny thing was, I could not recreate the issue when I tried to. The reason why is because of my process — when I get to a point where I realize I need a new document, I tend to save manually, a habit created and enforced over years. Once I decide to create a new copy, I invoke Save As immediately. I do it before I add any additional changes, meaning that on the next Save of my new document, those changes are not included in the original version.
I can only assume that Apple’s developers had good intentions and this workflow seemed logical:
Blue = Original File, Orange = New File
The issue is that people expect the following workflow and anything else seems illogical:
It’s a small difference, and one dependant on a users workflow. Overall, I agree with the criticism; the behaviour is not intuitive and will only cause confusion.
One other aspect that can confuse the less savvy user is that the keyboard shortcut for Duplicate is CMD+Shift+S. That’s the same keyboard that used to trigger the Save As functionality in versions of OS X before Lion and I even fell for it. With my first few tests, habit kicked in and hit the familiar keyboard combination (familiar because I still use apps that use this combo for Save As). It took me a moment to realize the resulting animation and behaviour was from the Duplicate option, not Save As.
Speaking of animations, I find many included in Mountain Lion (and Lion) to be extraneous and unnecessary. But in the case of Duplicate, it makes sense. You hit that keyboard command and a new copy of the file pops out of the original. Even if the keyboard shortcut mnemonics don’t add up, the visual indicators do.
Overall, I like the changes in the past two iterations of OS X. I need to tweak my habits slightly, but the overall benefits of a full-blown iCloud integration have been fantastic for me. Notes & Reminders, Contacts & Calendar, and email are essential to this set up. But I have also been pleasantly surprised by the amount I’ve used the file storage aspect.
Despite the issues listed above, I feel the advantages outweigh the confusion. If you haven’t made the upgrade yet, go and get it.
“In Finder, when you delete an item the next item in the view is then selected. Previously in 10.7, when you deleted an item in any view, no other items would be selected. This is an amazingly nice touch if, like me, you often use Quick Look to peruse the files sitting in a folder, while hitting CMD+Delete to get rid of the ones you no longer want. Now you don’t have to find the spot you were in, you can just keep on going.”
Ben Brooks. Amen!
I threw together a little page of necessary items when I upgraded to a Macbook Air last month. This list is made up of a lot of random items that make working on a Mac more pleasurable for me. If you have some tips you’d like to suggest, please hit me up on twitter.
Here’s a handy utility for OS X that helps you use your current software more efficiently (or, as Mitt Romney might say, more bettr). When running, simply click and hold down the command key to see all the available keyboard shortcuts for the frontmost application.