Skip to main content

Software That Feels Wrong

By
Original 1984 Macintosh desktop
Original 1984 Macintosh desktop (Photo credit: Wikipedia)
You look at the screen. You wonder what is wrong. The program or app does what it should do, but for some reason you don't like to use the software.

Something feels wrong with the application. 

I have been trying WriterDuet (https://writerduet.com) and for the longest time I couldn't pin down why I didn't like the application compared to Final Draft or Screenwriter. Technically, the program does what it should and has some excellent collaboration features. But I don't enjoy using it. 

I used to love Screenwriter (http://www.screenplay.com) and eagerly await version 6.5 for the Macintosh. Version 6.x has felt like a partial port (it is) to OS X and macOS for some time. I know the problem is that the "widgets" used for the user interface are not Apple's widgets for the current operating systems. It's slightly annoying, but I still like Screenwriter. In my ideal world, 6.5 is so great that I go back to Screenwriter as my primary screenwriting tool. 

What I — and other users — dislike about Screenwriter are some subtle UI issues. Overall, they are too minor to make anyone stop using the program. You notice, you dream of some polishing of the UI, but it doesn't distract you.

Final Draft (https://www.finaldraft.com) is streamlined beauty. It's how an application on macOS should look. I like the colorful, large icons. I wish Apple would return to icons that aren't monochrome and difficult to read. FD 10's interface helps me writer because I can see, quickly, what is or is not activated. 

This is WriterDuet's toolbar:


I can't read it. I've experimented with the colors and tried to get a combination that's better than this blue-gray scheme. But the scheme resets on me. And the icons, even with text, are hard to see and read on my large monitor. They don't scale up or adjust to the high DPI of my screen. 

This is a bad user experience. 

Compare the bland toolbar to Final Draft 10:

And here are all the icons available in FD:



Hands down, the colorful, uniquely shaped icons win. Steve Jobs once argued the shapes and the colors of icons should both be distinctive. I never understood why Apple gave up that great UI philosophy. 

This is the current TextEdit toolbar:


Come on, developers. Let's bring back some unique colors and shapes to the icons. At least I can locate the standard "left / center / right" and "bold / italic / underline" icons in TextEdit. That's not easy to do in WriterDuet. 

The great irony is that I learned word processing and text editing back when there were no icons at all. You memorized keyboard commands and combinations of keystrokes to do any basic task. And I still like WordPerfect and miss it. I use vim and emacs without any problem. Yet, I want my writing tool for screenwriting to look nice. 

Something about the overall interface in WriterDuet doesn't work well for me. I'll eventually memorize keystrokes and not care so much, but when you are new to a program the menus and toolbars are essential. 

Surely I can't be the only person who finds some applications simply "feel" strange to use. 

Related articles

Labels:

Comments

Post a Comment

Popular posts from this blog

MarsEdit and Blogging

By
MarsEdit (Photo credit: Wikipedia ) Mailing posts to blogs, a practice I adopted in 2005, allows a blogger like me to store copies of draft posts within email. If Blogger , WordPress, or the blogging platform of the moment crashes or for some other reason eats my posts, at least I have the original drafts of most entries. I find having such a nicely organized archive convenient — much easier than remembering to archive posts from Blogger or WordPress to my computer. With this post, I am testing MarsEdit from Red Sweater Software based on recent reviews, including an overview on 9to5Mac . Composing posts an email offers a fast way to prepare draft blogs, but the email does not always work well if you want to include basic formatting, images, and links to online resources. Submitting to Blogger via Apple Mail often produced complex HTML with unnecessary font and paragraph formatting styles. Problems with rich text led me to convert blog entries to plaintext in Apple Mail
2 comments
Read more

Learning to Program

By
Late last night I installed the update to Apple's OS X programming tool suite, Xcode 4. This summer, in my "free" time I intend to work my way through my old copy of Teach Yourself C and the several Objective-C books I own. While I do play with various languages and tools, from AppleScript to PHP, I've never managed to master Objective-C — which is something I want to do. As I've written several times, knowing simple coding techniques is a practical skill and one that helps learn problem solving strategies. Even my use of AppleScript and Visual Basic for Applications (VBA) on a regular basis helps remind me to tackle problems in distinct steps, with clear objectives from step to step. There are many free programming tools that students should be encouraged to try. On OS X, the first two tools I suggest to non-technical students are Automator and AppleScript. These tools allow you to automate tasks on OS X, similar to the batch files of DOS or the macros of Wor
2 comments
Read more

Learning to Code: Comments Count

By
I like comments in computer programming source code. I've never been the programmer to claim, "My code doesn't need comments." Maybe it is because I've always worked on so many projects that I need comments  to remind me what I was thinking when I entered the source code into the text editor. Most programmers end up in a similar situation. They look at a function and wonder, "Why did I do it this way?" Tangent : I also like comments in my "human" writing projects. One of the sad consequences of moving to digital media is that we might lose all the little marginalia authors and editors leave on manuscript drafts. That thought, the desire to preserve my notes, is worthy of its own blog post — so watch for a post on writing software and notes. Here are my rules for comments: Source code files should begin with identifying comments and an update log. Functions, subroutines, and blocks of code should have at least one descriptive comment.
3 comments
Read more