Just some examples of how having a polarization filter handy can improve your photos drastically! All of the following photos are straight out of the camera (no post processing except perhaps cropping).
Labels: creativity, filters, glare, photography, polarization, reflection, saturation
Check out the first line of the update message in the screen shot that I took on my iPod Touch below. The mistake between ‘O’ and ‘0’ is too apparent to not write about… not to mention typographically gross!
Someone’s finger must have slipped from the ‘O’ to the ‘0’ — bad form!
Labels: annoying, apple inc., design, irritations, nit pick, ui, user interface
You know, it’s a shame that iTunes now sucks.
A few years ago in the midst of the chaotic world of digital jukeboxes, iTunes emerged as a simple application to manage and play music — offering the basic features that one would need. Although it wasn’t groundbreaking in most regards, it did manage to stand out among the rest due to its extremely simple interface and integration with Mac OS X*.
These days, iTunes has become the fat and greedy roommate of the OS — every time it is called upon, I can hear the squeak of the plastic sticking to it’s back as it readjusts it’s fat ass on the vinyl couch. Its shear size and its toll on the processor has grown immensely and we can thank the superfluous features that are bundled with it: an integrated music store, Quicktime (oh my God... Quicktime for heaven’s sake!), a synchronization manager for your events/contacts/ringtones, etc.
I’m a programmer so I know that little glitches occur here and there. But a stable release of software, especially when developed by a professional corporation such as Apple shouldn’t have the problems I’ve noticed with iTunes.
20 seconds have elapsed and there is more than three minutes remaining. Why is the progress indicator at half?
Moving on… the application allows for adding media into its library by simply dragging and dropping files into the iTunes window. This feature is nice but unfortunately also very unreliable with large quantities of files. When I attempted to add many files by this method, I noticed that not all the songs I imported had made it. In fact, only about 80% of them were successfully copied. Yes, I can prove it:
A diff of the original and imported librarys’ contents. The gaps on the right show files that never made it into the new library.
Why does fundamental functionality not work? Could it be because the application is so big now that there are more avenues for errors to be produced? Maybe errors like these emerged because Apple decided to add features like mad men to an application that wasn’t theirs to begin with.
…
What?
I know, but Iit’s true. iTunes evolved from an application called SoundJam which was originally developed by 3 people at Casady & Greene. Apple purchased from the rights to this bit of software and after a quick face lift, released it as their own “iTunes.” John Gruber talks a bit about related issues on Daring Fireball and John Knack responds with some insight. And if you’d like to know more about the early days of music players on the Mac platform, there is a very informative story written by the guys at Panic.
…
Anyway, company acquisitions and inheriting code is normal these days, but I fear that iTunes never had the proper foundation for the features that it now supports. The amount of functionalities in iTunes can be deceiving since it has managed to maintain the same basic interface structure over the years — a commendable design achievement considering the growth of iTunes in the last few years. But integrating new functionality and features under the same simplistic interface more often than not calls for shortcuts that can become problematic.
For example, whenever the LCD-like display is used for anything but current track information, comprehension for the user becomes a problem. Applications mimic real-life objects in order achieve intuitive functionality, but when the expected functional behavior of an interface element is modified, confusion arises.
With the release of iTunes 9, other inconsistencies have shown up. Take the volume slider for example. The part to the left of the dial is now “filled in” like a progress bar. But the slider on the heads up display when watching videos remains like the previous version (which I personally prefer) which is just a simple dial on top of a slider bar.
And wait a minute… isn’t watching videos in a music player an oxymoron?
I think the only reason I’m still able to use iTunes is because I disable everything that I can in the preferences. This way, I’m able to make iTunes appear like the simple music player it used to be; like the simple music player it should be. Even so, it’s still disturbing to know that all those frivolous features that I hate are still tucked in underneath and weighing my application down.
I’ve disabled as many of the features I can in order to keep iTunes looking like a simple music player. But even with the features hidden, they are just itching to jump out at me because despite having disabled the iTunes Store, I see a “Contacting iTunes Store” message when I launch the application. How frustrating.
*Yes, soon after its initial release, iTunes did of course have the ability to synchronize music to a portable player, but this feature wasn’t new for jukeboxes. The problem (that iTunes “solved”) was that you couldn’t buy a portable music player from Company A and use a digital jukebox from Company B to efficiently synchronize your music. The best way to manage music on a device from Company A was to use Company A’s own proprietary jukebox software. It’s no different with Apple. iTunes synchronization only works with Apple’s line of portable MP3 players — uh, I think they’re called iPod — so the way that iTunes “solved” this problem was to gain dominance in the market so that everyone uses an iPod and iTunes anway.
If only there had been a way to quickly synchronize the contents of a music library from Company X with a portable music player from any other company. Hmmmmmm.
Labels: annoying, apple inc., design, development, engineering, irritations, itunes, software, ui, user interface
I unplugged my MacBook Pro the other day but the green light on the head of the cord indicating that my battery is charged remained lit:
Typically, hardware isn’t as susceptible to buggy behavior as much as software is... weird.
Labels: apple inc.
I went the longest time wanting to know how to report the bugs I write about to Apple. The only way I knew of how to do so was when an application crashed, or through the "Report a Bug to Apple..." option in Safari. But these methods are limited by application’s ability to invoke the service.
I came across an Apple Bug Reporter online utility that apparently gets the job done — or at least claims to do so. It’s unfortunate that you need an Apple Developer Connection (ADC) membership and the utility appears to be several years old (judging by the interface).
At least it’s something... if anyone on the other side is still checking.
Labels: annoying, apple inc., irritations
Apple’s TextEdit application has a massive design flaw that could potentially erase other files on your computer. Weird, right? Ironically, it’s TextEdit’s safeguard against loss of data that is the culprit of the defect. And the corruption of files isn’t a randomly occurring glitch either — it is caused by a shortcoming of the algorithm used in the Autosave feature.
When editing a document in TextEdit, a copy of your work is automatically saved every 30 seconds to the hard drive*. This behavior is common in software as it provides a convenient means to recover some of your work should the application unexpectedly quit or crash.
Unfortunately, the means by which TextEdit saves a copy of your work is awfully rudimentary. It simply writes your data to a regular file and gives it the same name as your TextEdit document but with “ (Autosaved)” appended as a suffix (without an extension). And since no verification is performed to see if a file with that particular name already exists, it will overwrite anything that gets in its way with no confirmation or warning!
To better illustrate this flaw, take the following scenario. Suppose, for whatever reason, that I have a file named Craziness (Autosaved) and I create a text document called Craziness.txt in the same directory. In the screenshot below Craziness (Autosaved) is an image file (with the extension removed in order to illustrate my point):
When I start editing my Craziness.txt file in TextEdit, the application autosaves my work (as it should), but since my image document has the same name as what TextEdit would call its autosaved file, my image file is overwritten:
When I’m done editing my Craziness.txt document, TextEdit removes the autosaved copy (as one would expect). However, now my original image file is gone with no real way to recover it (since it’s not moved to the Trash but actually overwritten):
Accounting for this file naming issue is so programmatically simple that it’s astounding the defect even exists. The simplest improvement would be to prefix the filename with a period (as in .Craziness (Autosaved)) in order to hide it from the Finder since the chances of having a naming conflict with a hidden file are greatly reduced.
But hiding the file from the user still allows for potential name collisions and as Mac OS X’s default text editor, TextEdit’s naming convention should be even more robust. To start, TextEdit could include either a timestamp or a sequence of random numbers to help make its autosaved filename unique. Most importantly, however, should be to verify if a file would be overwritten and if so, generate a different random number or append an incremental counter. Heck, even my Page Capture widget won’t overwrite files since it uses the same naming convention as Apple’s screencapturing application (File 1, File 2, File 3, etc.)
One might argue that the possibility of having a file end with “ (Autosaved)” and not have an extension is pretty slim. So what? My argument is that the possibility of an application deleting other files blindly is a completely unacceptable use case scenario, no matter how rarely it may occur. I think it is more reasonable to expect that a corporation as large as Apple Inc. would produce software that doesn’t delete unrelated files from my hard drive without my knowledge. Especially since OS X is — as Apple claims — the “most advanced operating system in the world.”
*30 seconds is the default. The time interval is configurable and the user is allowed to disable the Autosave feature entirely.
Labels: apple inc., development, intuitive, nit pick, security, software, ui, user interface
I’ve created a new widget that will generate a screenshot of an entire web page — no matter how long it scrolls! The Page Capture widget is the easiest and fastest way to generate these normally tedious screenshots. No longer will we have to puzzle together multiple screenshots manually!
Labels: apple inc., convenience, dashboard, development, page capture, widget