file_wrangler_2 UI Considerations

Spent the better part of last week (and will spend quite a bit of time this week) mocking up the UI for file_wrangler_2. The basic, driving concept behind the design decisions is in understanding how to break down renaming tasks into discrete, actionable units. While studying similar software (A Better Finder Rename, Renamer, etc.) I came to realize that my approach to the renaming process attacks the problem from the reverse angle.

Upon inspecting other file renamers, we can see that a group of folders/files is dropped into the application, then a series of tasks is performed on those folders/files. While this certainly gets the job done, it introduces a lot of repetition in the interfaces, and can make it difficult to understand how one task is affected by other tasks in a multi-step process. Does task C insert something before the 3rd occurrence of some text introduced in task B? Does task D then remove that insertion by mistake? The renaming steps in most programs are performed sequentially, but the process involved in each step may or may not be a relative change to the state of a file name. Some changes are global, some are relative, some are local, some are order-dependent, some are not, and so forth.

What I’ve been working on lately is understanding how to present a methodology that is as clear as possible about how a user-defined change will affect the file names. To do this means to flip over the interface conceptually and re-focus on why the user is using the program in the first place: to rename something. To rename something means she needs to build the blueprint for what the new name should look like. I wish to build a kind of “build-a-name” tool, rather than take that task-oriented approach. In other words, I want you to be able to tell file_wrangler_2, “Look, this is a template of how I want the naming to work. Do it like this.”

In my mock-ups I have created an interface concept that packs 80% of what A Better Finder Rename does into a window 2/3 the size of the Category/Action space on any given window of ABFR. No flipping between screens to get to the renaming actions, yet a definitively clear representation of what the user intends. This sounds like an incredibly dense interface, and it will be but only if the user desires it to be. This will be made clear in the coming weeks as I share a screenshot or two, but for now rest assured that the interface should allow for complex renaming tasks to be defined quickly and intuitively without overwhelming anyone with a hugely complex interface from the get-go.

I look forward to sharing more with you as I refine and finalize the designs.

P.S. – I am considering a name change for file_wrangler (née Filewrangler, née File Wrangler). Suggestions are welcome.

Review of “Core Animation for Mac OS X and the iPhone”

After finishing Aaron Hillegass’ Cocoa book during my “Cocoa Crunch” I hungered for some material that dug into specific frameworks more extensively. Notably, the Core Animation frameworks seemed to be essential knowledge these days for both iPhone development reasons and desktop OS X applications. When objects are manipulated by the user, she wants visual feedback about what will happen when the mouse-button is released, for example. Apple products always feature smooth transitions between states, the genie effect when minimizing a window on the desktop, the ripple effect when adding a new widget to Dashboard, the way menu items “make room” for a new object that will be dropped into a list, and so forth.

Of course, 3rd party developers have embraced these techniques over the past few years and the Macintosh shareware community has been able to raise the overall quality of the user experience as a result. The market now is more competitive from a “slick user experience” perspective than I ever recall seeing in the past. I knew I needed at least a little of this knowledge to provide a first class user experience for file_wrangler_2.

The Pragmatic Programmers website has a nicely designed online store for purchasing watermarked (with the purchaser’s name and time of purchase) downloading PDFs purporting to help one learn a variety of Macintosh technologies. Core Animation for Mac OS X and the iPhone by Bill Dudney is my first experience with one of their books, and I have to admit I feel let down.

Overall, I feel it covers the basic ground one would hope to see in such a book. It starts with a look at how Core Animation can be used at its most basic level, working on NSViews and gradually progresses into “full blown” Core Animation, using CALayer instead of NSView, then showing the different types of CALayer subclasses one can use.

We need an editor, stat! (Or to put it another way, what we need at this moment is a person who knows the skill of editing!)

My largest complaint with the book is that is needs editing, post-haste. Bill Dudney’s writing style is incredibly redundant, inefficient, somewhat poorly organized, and spins off into non-important issues. How many times were we “warned” about overusing animation effects in our applications? No offense to the author, but policing our use of Apple technologies is not his job. Is he so afraid he’s opening some Pandora’s Box upon the development world that somehow he will personally be held responsible when everyone’s interfaces start wiggling and jiggling for no reason? By page 39 of this 190 page book I had encountered such “warnings” enough times that I made a note to myself in the PDF margin, “Enough already!” Page 115, section 8.8, has a grievously redundant paragraph about the actionForKey: method.

Too hard for a beginner, too easy for a non-beginner

Dudney spends an inordinate amount of time explaining very basic concepts. Take the explanation of the Ease In / Ease Out curves, for example. Four pages of the book to show graphs that provide only a cursory amount of data and text descriptions that are redundant. If you tell me about “Ease In” and then tell me “Ease Out” has the opposite visual effect, I don’t ALSO need a full paragraph explaining what Ease Out looks like along with a bland graph. Why did the Ease In / Ease Out effects get so much explanation but other transitions did not? Contrast that with the OpenGL section and perhaps you can tell me who the intended audience of this book is?

In some ways he seems to target the beginner, yet I would argue that the book is not really for Cocoa beginners. He doesn’t explain code in anywhere near the level of detail the Hillegass book does, but he also writes as though he’s holding the developer’s hand a lot. He spares us from writing the code ourselves, as the book only contains a portion of the working code for any example (we really HAVE to download the pre-built examples to see what he’s talking about), but I’m not sure that is conducive to learning the frameworks very well. And that may be my biggest disappointment of the book. It seems too difficult for a beginner, as it assumes (rightly) an understanding of Objective-C, the Cocoa frameworks, AppKit, and so forth. Yet it also feels overly simplified for anyone with intermediate experience.

if (nil == [cocoa.accepted.formatting setFormat:dotVersus([self.format brackets])…

The examples in the book need a lot more polish and professionalism applied. The code is kind of haphazard and I found myself jumping up and down through a file to find a called method. When reading code this simple there tends to be a logical progression from method #1 to #2 to #3, yet the book’s code order does not reflect this logic. The code often contains unused ivars and methods. The code for rebuilding the Front Row menuing system has an ivar reference to a CIFilter for the bloom effect that isn’t used anywhere in the program. Yet I did see this filter being used in Apple’s sample code for building a similar menuing system, which strikes me as an odd coincidence.

The author also jumps around in his use (in my opinion, overuse) of dot notation and bracket notation, making the code kind of difficult to follow. @property and @synthesize make rare appearances and seems to only be injected when the author felt like it. No attempts at memory management seem to have been made. Odd use of syntax like “if (nil == someVariable)…” which is correct, but also reads kind of backwards to anything I’ve ever seen written by any other programmer ever. Basically, it just doesn’t feel like good Cocoa programming practices with any real forethought put into the examples. For that matter, the code in the Layer Scrolling and Geometry section doesn’t work right. Whether by Apple’s updates or not, the code has not been updated since June 2009 to provide a working solution to the problems there. I will post my own solution in the Codeshare later.

Oftentimes I would rewrite the code entirely, reorganizing and standardizing on one style, fixing the indents and removing the unusual end-of-line comments (tags for the publisher?). Suddenly the code’s intent was much clearer and easier to grok. I would have to recommend this course of action for anyone working through the book.

Suppressing the imagination

The examples themselves are kind of boring and seem slapped together. Take, for example, the Keyframe Movement example. A “heart” shape made of straight lines is placed awkwardly in the lower-left-ish corner of the window and a poorly lit graphic of a statue moves along the path. Some images float from right to left on the screen. The genie effect is half-heartedly implemented. Some drop shadows are applied to controls (although I did get a kick of of the pointillism effect on them). It did not exactly fire up my creativity, despite what he says on page 15, “Instead of trying to be your imagination, I attempt to spark your imagination. Often examples are contrived specifically to illustrate how something works or fits together rather than because they are a good fit for any particular application. I often choose the less-used effects or items to illustrate a point to try to spark your imagination…” (you may note the redundant use of the phrase “spark your imagination” in just this small excerpt). However, I can recall perhaps a single “less-used” effect in the entire book.

Should we feel “sparked” or “suppressed” when he claims, “We need to spend some time with this new framework building stuff that is gaudy and crazy to push the limits of what is possible.” then twenty pages later says, “Of course, we have to temper our imaginations by making sure that the animation is useful and not just eye candy.”

I can’t say I didn’t learn anything

I am impressed by Core Animation, but I can’t attribute that to this book. Yes, there were one or two examples that raised an eyebrow once or twice. Yes, I was surprised by how easy certain things can be animated. But that is really just a testament to Apple’s work on Core Animation, not because the author was particularly adept at making something complicated look easy. Basically he just made something that is already easy look easy, and I’m not entirely convinced that was worth the $22. I wanted to love this book, but I cannot recommend it over Apple’s free documentation and the plethora of free tutorials on the web.

How it can be fixed

  • edit the hell out of it
  • develop a few interesting projects that we develop over the course of a few chapters
  • pick a target audience and really cater to it
  • build on the teachings of Aaron’s book, adopting the code formatting and best-practices he teaches

Cocoa Crunch (Day 7)

Its the end of the crunch and I feel just a bit unsatisfied. I think, perhaps, I have finally outgrown Aaron’s book to some degree and its time to dig into specific technologies in a more substantial way. I have purchase three ebooks from The Pragmatic Programmer: Core Animation for Mac OS X, Interface Oriented Design, and The Art and Science of Javascript. I believe the next crunch should be for the Core Animation book before the iPhone courses as iPhone (and now iPad) development is slightly lower on my list of immediate needs. file_wrangler_2 must be the priority, and I believe Core Animation will assist me in delivering a proper “Apple polish” to that application. The skills are transferrable to the iPhone as well, so good leverage of skills. At 180 pages (versus the 250 or so of the Hillegass book) I believe it can be power-grokked (hey, I may have just invented a new word?) in about five days.

Also just started up a Java night course. VERY knowledgeable instructor at Berkeley Community College who says this class and its successor will prepare one for the Java Certified Programmer and Developer tests. Outstanding value at only cost $50/class, I think. We’ll be tackling all 1272 pages of Absolute Java over the semester using the NetBeans IDE and I will catalog my thoughts on Java vs. Objective-C as the course progresses. Regardless, it will be good to have a new tool in my toolbox, especially as relates to cross-platform development.

The final five chapters were really just four chapters (chapter 5 is a two-page “feel-good talk”), and really they were such glossy introductions to concepts that it is difficult to glean many useful data points from the knowledge. The NSTask issue I resolved the other day (and wrote about in Cocoa Crunch, Day 6) regarding how to get a chain of tasks to run. I used that knowledge in Chapter 34 and built my own app, “iGrep”, from scratch in under an hour. Select a folder, type in a phrase to grep, and get a nice list of matching results. It would have been just as well to do it in Cocoa using Search Kit and/or Spotlight, but it was good practice and really opened my eyes to wrapping terminal commands into pretty Cocoa shells.

The Garbage Collection chapter I read, did the examples, played with Instruments, and that was about it. I feel I need an entire book about Instruments to really get how to use it in a meaningful way. I don’t have any intention of worrying about the automatic garbage collector until the iPhone supports it; I don’t want to have two ways to working when one, carefully considered methodology works just as well.

The Core Animation chapter was enlightening in-so-much as a tech demo of what Core Animation can do, but I was left feeling a little mystified by how to implement it, when to make calls, what gets wrapped into which animation at what time, and so forth. Probably just need to do the exercise a second time, however I think a more detailed explanation of the whole animation process with the new Core Animation book will answer these questions for me just as well.

OpenGL is amazing and cool and awesome and a HUGE beast of a thing to learn. It is fun getting 3D onto the screen, manipulating it and playing with colors and lights. However it is also an absolutely dense topic with a vertical learning curve. I found these tutorials at NeHe that seem to be a great starting point for beginners to OpenGL. Perhaps for bones_2?

At any rate, pushing myself to get through the book in 7 days was a great feeling of accomplishment, but also reminded me of just how much there is yet to learn. I suppose the highest praise I can give Cocoa Programming for Mac OS X, 3rd Edition is just how eager it makes me to know more and to become an outstanding programmer with top-notch programming practices.

I’ll never be a John Carmack, but I really don’t need to be to deliver professional, polished, and useful software that genuinely helps people achieve more with less. That is my goal and my commitment to my past and future customers.

Cocoa Crunch (Day 6)

Chapters 26-30 of Cocoa Programming for Mac OS X, 3rd Edition revealed unto me three truths!

Signing Amazon requests is hard

Chapter 28 is pretty much defunct as Amazon now requires that all REST requests be signed with a secret, private ID. I thought, “Aha, a challenge!” and set to work building a protocol for NSURL that takes and NSURL and a private key and returns the signed NSURL for Amazon’s services. My word was that hard!

In fact, so hard I never could get it to work, mostly because I don’t have much experience with REST, base64 encoding, nor SHA256 HMACs. In fact, it may even be safe to say I had ZERO experience with those technologies, and it is difficult to build something you don’t understand. (ahem)

But, Amazon lays out a step-by-step on how to sign the URL and for the most part it was straightforward and seemed to work properly. However, when it came time to generate the HMAC and encode that in base 64, I quickly learned what a troublesome process that is. At least if we consider it from a “pure Cocoa” perspective.

After referring to various online forums and postings about the problem, a CCHmac (a non-Cocoa system call) seemed to finally work for me. Oddly enough, getting the base 64 version of the returned string was the troublesome, and yet unresolved, issue.

After much digging around, it seems that the very smart Marc Liyange was struggling with the same issue and wrote a nice Cocoa wrapper class for the whole shebang, leveraging Google code to get the job done. I was really hoping I could just use NSTask to make a command line call to something built into the OS. OpenSSL with “enc -base64″ flag, I’m looking at you…

Which leads me to…

A retrospectively obvious point about NSTask

I had chained up two NSTasks with an NSPipe to get the standard output from TaskA to flow into TaskB, the same as piping the two commands in terminal. But nothing would flow from TaskA to TaskB. Every example for NSTask I could find only showed a single task and retrieving the basic output stream from that. That was easy enough. Any samples that showed TWO tasks in a chain said something like, “Just make two NSTasks and pipe them together, or better yet do this completely other workaround.”

Today it finally hit me that after building an NSTask / NSPipe / NSFileHandle chain, then kicking off the first NSTask with [task launch], that that is not enough. I thought this would launch the whole kit-and-kaboodle, but each individual task must be launched individually. It just never occurred to me that every link of the task chain needed separate kickstarting.

Today’s work on chapter 34 led me to reattack this NSTask conundrum I had encountered the other day, and finally the light went off. I may have hope yet for getting my homegrown Amazon wrapper protocol wrapped up tomorrow, which would be a great ego boost to know I solved an issue that also stumped people I respect.

I still don’t get Core Data

Maybe it is because I rarely write applications that need something like Core Data? Chapter 30 has us building a more involved Core Data application, and the number of bindings is bewildering. Knowing whether to bind an object to the Model Object Context, the model’s Content, the model’s Content Set, the model’s Content Values, or the model’s Value is an utter mystery to me. What was most frustrating about this chapter is that I have no clearer understanding of why certain things are bound to other things and why we chose certain settings in Interface Builder. The chapter does a (frankly) poor job of illuminating Core Data.

To my mind, if Aaron Hillegass has trouble getting Core Date across to his readers, then that really means that Apple has made it difficult to get across to developers. I haven’t given up on Core Data by any stretch of the imagination, but I do feel a little bit that it will be a HUGE amount of study and understanding for very little payoff. I’d rather dig into Core Animation or Core Graphics (or OpenGL) if I’m going to invest so much time.