For a decently long time I’ve been keeping track of newsfeed articles that catch me attention in the ‘Clippings’ folder of NetNewsWire. Since I’ve just finished with school and have a lot of free time, I’m going to go back and see why I saved those clippings originally, and write a little something about each one, in order to get my creative juices flowing and try and rock out a bit more with my writing. The things I mention about each article might be related to the content, or the website design of the article’s page, or it might not be relevant at all. Think of it as a free association.

I call this movement: 39 Clippings.

Clipping I: 50 Ways to Become a Better Designer

I’m sure I saved this because I was interested in becoming a better web designer. Makes sense, right? :-) In general I really like the site style and how even separate headings in a blog entry receive a full graphic treatment. This is a devotion I don’t have currently, but I’m sure those little things are definite touches to consider when spiffying up a blog. I almost think the article is too long. If it were broken up into five separate articles of ten items each, it would feel a lot more accessible.

While there are a few worthwhile gems in the article, a lot of the advice seems overtly cliché. I think a lot of the technical advice is definitely important: Save often! Use as many layers as you can in Photoshop! Keep all of your digital and vector assets! Back things up! If I had a dollar for every time I wished I had followed this advice, I wouldn’t have to worry about becoming a better designer.

In any event, I think this has been sitting in my clippings folder long enough.

Clipping II: Immutability in C# Part One: Different Kinds of Immutability

I saved this because I only had a vague idea of what immutability was in terms of C# programming, and being a novice C# programmer, wanted to learn more about the nuances of the language. This is the first article in a series of eleven (!) articles about immutability in C#, and going through all of them to understand this one concept might take more time than I actually have this break! If I manage to make it through all of these articles, I’ll write about it.

This clipping is being bookmarked toread in del.icio.us, and I’ll be back for it later.

Clipping III: ActiveRecord::Base.with_scope { :only => ‘in your model’ } - Rails 2.0 a feature a day #4

The title of this clipping annoys me. Bloggers need to stop using Ruby code in their post titles.

The with_scope method in Ruby allows certain constraints on ActiveRecord operations to apply to all actions taken with a particular model. This cleans up a lot of duplicate code, but in certain situations Rails developers might find it necessary to place a with_scope block in their controllers, which is bad design. The article I clipped announced that in Rails 2.0, with_scope was now protected in the ActiveRecord class, preventing this awkward usage completely.

The article was written in what I call Linux Documentation Form, meaning it assumed the readers were familiar with the topic material before breaking new ground. It did this by providing a link to another blog post on with_scope, which explained its use and bad design decisions made with it. I support this form of blogging wholeheartedly because it means less work all around — except for the readers :-)

Now that I understand this awesome construct, I can remove this clipping and bookmark it in case I need a refresher.

Clipping IV: Porticus GUI for MacPorts

Porticus! A GUI for MacPorts! The title of the post says it all. Awesome. I never got a chance to check this out, but apparently at one point I wanted to. I’ll give it a go and see if it does anything particularly awesome (what more do you need from MacPorts other than sudo port install?), and write about it.

It’s downloaded, so there goes the clipping.

Clipping V: Photoshop vintage effect

Photoshop tutorials seem to be divided up between the extremely good and the extremely bad. This one looked awesome on a first skim. As it stands I don’t own Photoshop, but with some disposable income coming my way this co-op, I’ll soon have a chance to try this tutorial out.

Bookmarked.

That’s all I can absorb for now. Stay tuned for part 2!

A user spends an hour working on a document.  Because he/she is stressed, or under duress, they don’t remember to save their document, and when closing Word, reach the familiar dialog box: Do you want to save the changes to Document1? Still harried, they accidentally click the ‘No’ button, and lose their document. Because the software can’t decipher the user’s intentions, they simply obey what they are told, and don’t save the document.How can we address this problem? And is it a problem? I imagine so - as much fun as it is to blame the user, telling them they should have saved their document at the beginning, or telling them to save religiously every 10 minutes or so, this problem can be approached from a few directions in the areas of interface design or software design.Note that this post is not to address autosaving documents that already exist, as most text editors, as well as Word, already have excellent functionality in this regard. On the HCI front, we have:

Tinted Aid

Imagine this one simple change - tint the colors of the buttons on the dialog box. Green for yes, red for no. This one thing might give a user pause enough to consider their option more slowly. After repeated use, the colors may help to guide the user’s cursor, to enforce the habit of saving.

Second Action Aid

This change adds another button to the dialog box - making it more complex, but not an impossible change. The new button is a lock icon that sits next to the No button, and controls the enabled/disabled state of the No button. In order to click No, the user must first click on the lock. Unfortunately, this has the potential to become the same problem that we are trying to fix - namely that users who get used to taking a certain action will think about it less in the future. An absentminded user could just as easily make a mistake by clicking two things without thinking as clicking one.

Some other changes that might help, but would increase the complexity of the software:

• Adding a Firefox-like race condition timer to the dialog box, of 3 seconds or so, that would not enable the ‘No’ button on the dialog box until the timer runs out.
• Attaching a specific gravity to each button on a dialog box depending on its function. The Yes button here may physically pull the cursor to it with a stronger amount of resistance compared to the No box. I imagine, however, that users do not want their computers telling them what to do to that degree.

In terms of non-HCI concepts, we have the backend. Word utilizes AutoRecover, which is useful for accidents—power loss or the like. However, if a user never saves a file and exits Word without saving, the chances are very low that they’ll be able to recover that document. So what are our options?

• Individual incremental version control for all saved and unsaved documents. Every 10 minutes or so—or if a minute goes by without a keystroke—a commit is made to version control with that document’s changes. If the file is not named, it is provided with an identifying filename - such as its time of creation and the name of the user and computer.

That’s the only thing I can think of at the moment. Of course this sort of idea comes with enormous privacy concerns, and even if we explained to the users exactly what was going on, they may still be used to being able to open a document, write a nasty letter to their bosses, then close it without saving, thinking their secret is safe :-) The other disadvantage of this approach is that is users become accustomed to that kind of behavior in one program, they might be very surprised to find that other programs do not have the same functionality, and end up losing data over that misunderstanding.

I would be remiss if I didn’t mention how Linux users have been dealing with this problem for ages. In Emacs, a buffer is named before it is ever edited, since the command to open a file can also open files that don’t exist yet. It’s at that point that Emacs begins saving backups of that buffer. In vim, quitting and quitting without saving are two different commands: q and q!, respectively; or qa and qa! for exiting all documents. Since it would be extremely difficult to make the mistake of typing an exclamation point—at least in terms of a typo—the only issue here is that of muscle memory, and I imagine most programmers do not usually type the latter enough for it to become ingrained to that point.