6/30/09
Of Bookmarks and Safari
I do have one major gripe with Safari, however, and that regards its infernal bookmark management system. Instead of having one central repository for bookmarks that is easily accessible from the bookmarks menu, it divides them into three distinct groups: "Bookmarks Bar", "Bookmarks Menu", and simply "Bookmarks." So, if you want to see a bookmark in the bookmarks menu, it must be moved out of one group and into the other—it can't exist in both. The same rule applies to the bookmarks bar. Instead of functioning like a dock for your favorite links, it requires that a bookmark be moved to its group before it appears there.
This would be like an application disappearing from the Applications folder whenever you moved it to the dock, and appearing in a folder titled "dock items." This may seem like a minor gripe, but it makes bookmark management seem like a chore.
In a future release, I hope Apple does away with these three groups. Any bookmark in any group would automatically appear in the bookmarks menu, and any bookmark or group that was dragged to the bookmarks bar would remain in its original location. These changes would make Safari an even more enjoyable browsing experience than it already is.
4/8/09
The Potential of Apple TV
The Apple TV seems like the forgotten child of the Apple community. Steve Jobs has called it a hobby, and most people who know what it is would rather use a mac mini instead.
Personally, I think it's a great product with a lot of potential, especially after its latest update. However, if the Apple TV is to fulfill this potential, it should be opened to developers. This doesn't mean turning it into a full-fledged computer for your TV but rather allowing plugins to be made that provide access to a wider variety of content sources. All those web-based video streaming sites that compel people to hook a mac mini up to their tv and control it through some hideously convoluted system would be able to provide a much more user-friendly interface for viewing their content from the couch.
I'd also like to see a greater consistency between the Front Row and Apple TV interfaces. In fact it would probably work best to just merge them into one app. The Apple TV runs OS X after all.
4/1/09
Safari 4 Beta Hates Xcode
Just when I decide to get back into coding, I have to revert to using gcc on the command line since Xcode won't work on a machine that has the Safari 4 Beta installed. Sorting through any substantial amount of errors on the terminal is a nightmare. Also, without the templates that Xcode provides I have to remember tedious tasks such as setting up an autorelease pool. If only I had access to the latest version of Xcode. That would fix everything.
As an aside, I think that the Safari 4 Beta is pretty cool. The new tab-in-titlebar metaphor makes a lot of sense even though it ends up breaking down somewhat during actual use.
1/31/09
Keybr.com
We just started keyboarding class in school yesterday. We're using a hideous Windows app on a beige Dell, and the keyboard doesn't sit well with me. Even though many people detest Apple's trend of using chiclet keys in all their keyboards, I find the new keyboards much easier to type on. They just seem much more spacious and spread out.
However, this is not the first time I've practiced typing. Up until this summer I was not very good at typing, and I knew I'd need to get better if I was going to take up programming. Thankfully I stumbled upon keybr.com. It's a free, flash-based web app that is delightfully simple. You can create a free account which allows you to track your average and maximum typing speed over time. It can generate random text for you to type out, you can supply it with custom text, or it can even use text from a newsfeed you specify. Also, the virtual onscreen keyboard shows which keys you need practice on by hi-lighting missed keys with a red/pink hue that darkens as you repeatedly miss them.
By the end of the summer, I actually had useful typing skills. If your typing needs brushing up, this is a great tool to try out, and I highly recommend it.
1/29/09
Long Live Xcode the Fourth
One of the coolest things Apple's dev tools is their cost... nothing! If it weren't for that little fact, I might not have decided to take up cocoa or any other kind of programming at all.
The latest version of the dev tools, the one that came with Leopard and the first one I used, is pretty nice. Interface builder, Instruments, and Dashcode have a decidedly delicious feel to them, and Apple's touch is very evident throughout.
Unfortunately, I don't get the same vibe from the star of the show, Xcode. Its interface feels clunky, spread out across too many windows, and generally outdated. Admittedly, version 3.1 remedies some of this by using textured buttons in the toolbar and nicely revamping the project creation ui, but I can't download it since I am to young to acquire even a free ADC membership.
That's why I can't wait till Snow Leopard hits the shelves and, hopefully, a deliciously awesome Xcode 4 along with it.
1/23/09
Death to Folders and Filenames!!!
As the title of this post suggests, I have a beef with the way file systems have forced us to manage our files since the dawn of personal computing. I would much rather have my computer manage my files for me than have to waste my mental faculties managing files manually. Obviously folders have their place but a file system built primarily around tags and metadata would be a dream. A file can have as many tags as it wants but you get only one folder per file, and that can be very limiting.
Regarding metadata, especially on the mac, I would like better options for developers. As of now I have not seen a straightforward way to examine and, in some cases, alter the metadata of a file in Cocoa. Furthermore, although developers can develop plugins to make their file's metadata available to the file system, they have little control over how that data is presented to the user in the "get info" panel. Additionally, it would be very useful to be able to tack on extra metadata to a file and to have that metadata remain intact even when the file is transferred to other platforms or opened in another application.
Also, something needs to be done about the pain that is file names. It's one thing to figure out a naming scheme and stick to it when you're talking about a school report, but it's quite another thing to figure out meaningful names for a batch of images and also keep their names from conflicting. After all, a file preview often conveys much more than "IMG_0023" ever does. In my "dream" file system, files would be automatically given names by the file system unless they already had meaningful or user-given names. These names would be hidden from the user by default, and they would be automatically changed to prevent conflicts. If user-defined names conflicted, the file system could maintain its own unique names internally but still present the user-defined names to the user.
Of course, for a system that doesn't rely on folders, it needs to have robust searching and metadata based organizational capabilities. Obviously, on a mac, smart folders would become way more important, and the Finder's design would need to change to accommodate a much larger number of them. However, unlike the current system, where a search is often cluttered with files a user rarely cares about, files could be marked as resources by both applications and the os and would be excluded from most searches.
A file system like this would largely do away with a frustratingly archaic system that requires too much effort on the part of the user just to keep their data organized. After all, with computers this powerful, they should be doing the work for us.
Update: In retrospect, it has become quite clear to me that Apple's solution to this problem is the iPhone os. An app-centric design largely bypasses the filesystem and its difficulties. However, this design does cause data to be "trapped" inside applications. If Apple can implement a really sweet solution for sharing data among applications, we will finally be able to relegate the filesystem to the domain of geeks and programmers.
11/19/08
The Trouble with Plugins
One of the things that excites me most about developing apps is the enormous potential of plugins to extend an application. Xcode and NSBundle make it quite easy to implement too.
Unfortunately, loading external code can be quite risky, and, from what I've seen, there appears to be no built-in solution to help with this. Sure, you could be very careful about what objects you give the plugin access to, and it can't send your objects a method you don't publicly declare in the framework or header files that you make publicly available. However, there are plenty of classes in the Apple frameworks that any object, externally loaded or not, can get a shared instance of. Once it has one of these singleton instances, malicious code could possibly gain access to your data model and controllers through the accessors methods for the object's delegate. Even if it never gained access to your custom objects, it could still wreak havoc with an instance of, say, NSApplication or NSWorkspace. In addition, poorly designed, non-malicious plugins have freedom to do undesirable things like loading new windows and views without the host application's consent.
This is something I'd love to see Apple do something about. They could introduce a class called something like NSRuntime perhaps. This class could let objects ask for a notification to be posted whenever an externally loaded object sends a particular message or calls the method of a specified object. Additionally, the loaded objects could be forced to only communicate with a specified list of objects and or classes.
Of course, there are other solutions like letting other developers only create plugins with a special application (something in the vein of the iSync Plug-in Maker app) or by using a scripting language. However, I'd love to see Apple produce an elegant, cocoa solution to this (or maybe even a language feature of objective-c 3.0).
