Archives ➤ Monthly ➤ September, 2011

Text Editors: A Rant

Posted in Kaishinlab

Back in the early 2000’s, I designed crappy websites using clunky tools from Macromedia and Adobe. As I switched to Mac in 2006, I had the chance to give Textmate a try and was thrilled with its chromeless interface and advanced syntax highlighting. I gradually moved away from WYSIWYG tools, and before too long, I was already enjoying every line of code I write in Textmate.

Now don’t get me wrong, I am a designer, not a programmer. While I do happen to tinker occasionally with PHP, Python or Ruby, most of the code I write is HTML markup or pre-processed CSS. This leads me to another point: interface is a deciding factor when choosing my tools of the trade.

Ignorance is bliss. –Thomas Gray

Textmate was my ideal GUI text editor, until I had a closer look at the competition, that is. I have become to realize that there has been little to no improvement made to Textmate in the recent years. No auto-save, dumb undo, no dropdown autocomplete, not even a fullscreen mode. Sure, some of these features can be enabled via bundles and hacks, but I have a preference for native, officially-supported solutions.

And thus began my hunt for an alternative.

At first, I tried Coda and Espresso for a reasonable amount of time. Unsurprisingly, I was quite impressed with their endeavor to make web design and development as seamless an experience as possible. Notwithstanding, their main selling point is also their biggest snag: they suck as standalone text editors, and come to think of it, they never pretended to be one.

Subsequently, I turned to Google for enlightenment. The first results hinted at BBedit, Vim and Emacs. Albeit being the darlings of many, Vim and Emacs are simply too keyboard-centric for a mouse-trained brain like mine, not to mention their daunting learning curve and ugly non-native interfaces.

Eventually, my next stop was the two-decades-old BBedit, which coincided with the release of a major Lion-compliant update. Recommended by many pundits, I was almost confident that BBedit would put an end to my quest. Alas, that didn’t happen as I was offended by the intrusive toolbar, the nebulous syntax highlighting and the poor support for popular CSS preprocessors.

Although I was initially reluctant to try less popular alternatives, I had little choice but to wade through an unhealthy number of Textmate–2-wannabes. Some are clearly coming out of the lot (Sublime Text), while many are too unstable for doing any serious work. What they all seem to have in common though is the lack of support and third party extensions.

End of the road? I am concurrently using Sublime Text 2, BBedit and Espresso 2. Am I satisfied with my current workflow? Hell no, and not even the recent Textmate 2 announcement was enough to placate my urgent craving for a decent text editor.

Icon Template

A nice update to Michael Flarup’s icon template. Comes as a PSD with live multi-size previews, export actions and an awesome set of default textures.

iOS

On Copywriting in Interface Design

Joshua Porter on the importance of copywriting in interface design:

There is nothing that makes or breaks a positive experience more than the simple set of words that you choose to communicate with. In a world in which we have to simplify as much as possible, nothing matters more than the small vocabulary you end up with in your final work.

Yet, there is no shortage of established applications that are still underestimating the power of words, under the illusion that pretty pixels and fluid animations are all that matter.

Neven Mrgan on The iOS Back Button

Long story short: don't label your iOS back button as Back. Provide some context by displaying the title of the previous view or an abbreviated version of it.

Thoughts on Scrollbars in Lion

Posted in Insights

Scrollbar in Lion

Is it only me or is everyone whining about the ‘peekaboo’ scrollbars in Lion?

Much like the skeuomorph controversy, there seems to be a sweeping consensus that the iOS-inspired appearance and behavior of scrollbars account for a significant usability handicap that should be addressed in one way or another. They argue that the main culprit is the loss of information stemming from the contextual disappearance of scrollbars.

In the lack of any theoretical or experimental evidence coming to their defense, these claims are speculative at best. Trying so religiously to solve a problem that doesn’t exist in the first place is a complete waste of time and talent.

Scrollbars are first and foremost controls; they receive user input and instruct the view to move content accordingly. They also happen to visually inform users about the position of the visible area and how much of the overall content it stands for. In his lengthy Lion review, Siracusa argues that Apple had to sacrifice the convenience of constantly displaying the foregoing visual cues for the sake of simplifying the interface and saving screen real estate.

Now let me ask you this, how many times do you find yourself gazing at the scrollbar when browsing a page or working on a word processor?

Apple made the right assumption that, unless we are scrolling, scrollbars are very likely to be outside our locus of attention (Raskin 2000). In fact, even when scrolling, the odds that we shift our locus of attention to scrollbars are very weak; our main concern is displaying hidden content, making it ipso facto our locus of attention. Using up screen real-estate to constantly display non-critical data is nothing short of a hindrance. Progressive disclosure anyone?

The ensuing disappearance of any visual cues hinting at the presence of more content below the fold is also a false alarm. Getting an instant feedback from the content view is just one gesture away, and the carefully crafted bounce animations make the interface even more responsive.

I would't argue that those who relied heavily on scrollbars in Snow Leopard would be disoriented at first, but that is little to pay for an improved experience on the long run.