One of the primary advantages of Apple's approach to widget engine implementation was that their engine (Dashboard) was based on HTML, CSS, and Javascript, which appeals to a wider spectrum of web developers out there.
Widgets - the idea itself - is nothing new. They were thought up long ago as mini applications with very specific purposes. For example, one such widget might deal with displaying a typical six-day weather forecast. Dashboard's offerings included widgets such as Weather, Stocks, Clock, and Calculator.
A couple years later, when the iPhone debuted, there was apparently news that these same aforementioned widgets' iPhone app counterparts were originally written in a manner similar to the HTML/CSS/Javascript-based Dashboard widgets, but that within the six months between announcement and release, they were redone natively in Objective-C for performance.
But Javascript performance has improved remarkably in the few years since then, with the improvements in Javascript engines from Safari to Chrome to Firefox, and while Apple's stance on native webapps was put aside for the timebeing with the release of the SDK, the webapp idea still lives on in various online and offline forms in Palm webOS apps, Chrome OS apps, and even iPhone MobileSafari's webapps. And it will be interesting to see how further performance improvements increase the viability of the webapp, and by extension, expand development opportunities to a massive number of eager web developers out there.
Backspace back-deletes text when form fields in the page are in focus, but goes back a page otherwise. These fields frequently come in and out of focus, which just increases the likelihood of the mishap of losing unsaved form data that much more. (Not every browser remembers unsaved form data when returning forward one page.)
Did someone think it was a good idea to use "backspace" because it reminded them of "back"? Backspace/delete keys suggest something destructive - it doesn't just move the cursor in a text context, but removes characters along its way too. Navigating back one page is not a destructive act. It's navigation, much like moving a cursor with the left arrow key.
All we have now are website-implemented safeguards - your auto-drafts, or perhaps JS detection of the "back" key to prompt the user when forms are on the page. But these aren't solutions because you can't depend on every site to be designed well to begin with.
There has to be a better way.
Programs like Winamp, Windows Media Player, and RealPlayer provided the features necessary to organize libraries heavily on metadata, but they generally didn't create much of an abstraction layer between the file system and the music library. Your audio files were linked, and its tags read, but the files were otherwise left alone where they were.
So on Windows, you might get:
C:\Documents and Settings\Gordon\My Documents\My Music\iTunes Library\Eagle Eye Cherry\Desireless\01 - Save Tonight.mp3
People either hated it or loved it.
This was managed music.
When the Windows port of iTunes came out in 2003, I began using it in parallel with Winamp, my incumbent music player of choice at the time. It was light, simple, and unmanaged. I had also stripped my entire library of all ID2/ID3 tags over the years, so it wasn't optimized for iTunes.
I was a hater of managed music.
I wanted to organize these files myself. I had my own folder structure and naming conventions. Yet over time, I grew to like iTunes managing my music for me. With every new file, I could drag it into the library, and it would take care of the rest (making a copy, renaming the file based on the metadata, and creating appropriate folders). Then I could delete that original copy or what ever I wanted.
The thing was that, as much fun as it may be to have full control and say over how to manage your own music, it just wasn't scalable to me past a thousand songs, much less several thousand. If the computer is so much better at automation than a human, I figured we should be offloading this tedious work to these machines.
Like iTunes, iPhoto by default created copies of any photo you dragged into the application, but also like iTunes, you had the option of disabling copying to the photo library.
With the latter, iPhoto would simply link to wherever that file sat, and wouldn't make a renamed copy. With the former, it would place a copy in a bundle "iPhoto Library" in the user Pictures directory, like this:
/Users/gordon/Pictures/iPhoto Library/Originals/2007/October 22, 2007/IMG_0001.jpg
This is nearly identical to iTunes behavior, with the one distinction that iTunes still involves folders that can be navigated through via UI the traditional way, instead of bundles that require "Show Package Contents" or a terminal.
/Users/gordon/Music/iTunes/iTunes Music/Coldplay/Viva La Vida - Prospekt's March Edition/1-07 Viva La Vida.mp3
Picasa, on the other hand, offers iPhoto's link-to-file option as the only offering, but differs beyond that for monitoring those watched locations for changes to the files (renamed, deleted, etc.).
As a Picasa user, I haven't embraced iPhoto in the same way that I had with iTunes. I tried to determine why that might be, considering that I have a much more overwhelming number of photos than audio files to manage. It could be that the metadata in music files played a much bigger role in determining how to organize them. Many of us were already manually organizing by artist or album, perfect for metadata. Sorting and filtering by genre, beats per minute, length, and other attributes were perks, but the point was that a lot of us were already manually managing the same way auto-managing worked.
Whereas with photos, my guess would be that there is more fragmentation in the way these files are organized from person to person. Some might group by events (Graduation 2003, Italy 2002, Birthday 2008). Some might group by year, or month, or months nested within years. Or some might group by year, with the photos within each grouped by events. Some might not group at all.
iPhoto does allow you to create smart playlists a la iTunes based on criteria, so that you can do anything from creating playlist/labels filtering out all photos taken with a specific type of camera, or more usual things like grouping by year.
But these are folders. These are like, again, smart playlists in iTunes or IMAP labels in Gmail. And this may not work for everyone.
Ultimately though, I would venture to conclude that perhaps not as many people see a need for managed photo libraries, as useful as it is, because photos are much more visual by nature, and can be spotted in a grid of thumbnails. In time, with the ongoing release of new tools like facial recognition and geotagging maps, perhaps managed photo libraries will be compelling enough for more of us to alter our ways.
There is a lot to focus on, so I will keep this one about file renaming.
This was a problem for a couple reasons. If you didn't know what a file extension was, you would likely accidentally rename a file extension. If you did, it was an extra three or four keyboard strokes for each file to place the cursor to the end of the actual file name. It doesn't sound like much, but you pride yourself on using keyboard shortcuts for the purpose of being fast.
Mom and Dad skiing.jpg
Fortunately, some years back, I noticed on Debian and Mac OS X that triggering a file rename highlights the file name only, with the option to move the cursor to the right into the file extension area.
Mom and Dad skiing.jpg
It was a huge improvement, but considering that most of the world was on Windows, it was important that this make it over to the Windows side.
What are the implications in this difference in behavior? Let's compare this to the way you would normally rename a file with the file extension hidden.
Before:Without file extensions, the keys are F2, arrow-right, and then delete or append right away, in the case of Windows. So if we apply this with the incorrect behavior of placing the cursor right of the dot, we get this.
Before:Screenshots after the break (note the text cursor placement):
DOWN ARROW ↓: Mom and Dad skiing|
UP ARROW ↑: |Mom and Dad skiing
Mom and Dad ski|ing.jpg
Otherwise, not much interesting is going on in the built-in UI file navigators.
Posts
All Comments
