Hi Bart,

My company develops ScreenSteps and I am the programmer who works on it. Thanks for taking the time to write a review. I would like to comment about and respond to a couple of points.

I will begin by saying that ScreenSteps is an application written for people who have to write a lot of tutorials/documenation and whose time is more important than their money. We have spent a lot of time creating a workflow that makes it fast to create documentation, publish documentation and keep that documentation up to date. ScreenSteps (as well as ScreenSteps Live) are built around our philosophy that each step of providing instruction to a customer should be easy. You can read more about that here if you are interested: http://www.bluemangolearning.com/screenstepslive/learn.html#plan_not_to_plan

Behavior on OS X

Some of your comments center around the look, feel and behavior of ScreenSteps on OS X. When someone chooses to use ScreenSteps they are choosing a cross-platform application. For our current customer base and the potential customers we are targeting a cross-platform application is very important.

But with a cross-platform application come certain tradeoffs. Do you write libraries (C/C++) that work on both platforms and then hook up the GUIs using native tools so that each platform gets the native experience? Do you use a cross-platform C++ framework like Qt? Or do you use an environment like RealBasic or Revolution which offer faster development cycles in most cases?

I am the only developer that works on ScreenSteps and the ability to iterate with a development environment is very important in the way we design applications internally. We often discuss workflow internally and with customers and then do small releases that make improvements. Maintaining a single code base is important for me in order to do this. We chose Revolution because it provides me with a single code base that I can quickly and easily test cross-platform. This allows us to iterate more frequently which we feel is a good thing.

Downside? No Cocoa. I can understand that this is frustrating for power users. I've been using OS X since 10.0.0 myself and consider myself a power user. But it is a concession we made in order to meet our larger goal of cross-platform support. I don't mention all of this as an excuse for why some things don't work as you intended but rather to provide some context.

So why do we pattern some of our look and feel after OS X applications? Like I said, I've been an OS X user since 10.0 and that is the look and feel I'm familiar with. I'm not a UI designer and we don't currently have one on staff so I pattern the UI off of what I know (not blindly however).

Inconsistent Context

The way we handle toolbars for text and images could definitely be improved though we won't be tackling that in the 2.x series. It is something we know we need to look at with fresh eyes for version 3 though.

We do not, however, have context-sensitive controls that appear in two places when you select an image. The only context-sensitive controls appear in the top toolbar. The three icons that appear to the left of a step image are always present if the step has an image. The icons allow you to replace the step image, copy the step image to the clipboard or save it to disk. They are not related to annotations while the top toolbar controls are.

Keystrokes

I'm not sure that cmd + i is a standard keyboard convention for opening an inspector on OS X. For one, cmd + i is used for italicizing text which makes it an inappropriate choice for opening an inspector palette in an application used for writing. If you launch OmniGraffle (version 5) or OmniOutliner (version 3) you will notice that cmd + shift + i is used. Pages using ctrl + shift + i.

Image Annotation

I don't think that it should come as a surprise that applications dedicated to image annotation and drawing should outperform ScreenSteps in this category. We have a lot of other features to worry about in addition to image annotation. I don't mean to say that we like to settle for second-rate behavior but there is only so much time in the day. I try to make improvements here and there when we release 2.x updates.

That being said I know that the modal selection behavior is a pain. Look for this to be addressed.

Primitive Text

ScreenSteps text behavior is quite primitive at this point. No argument there. We have our hands tied at the moment in respects to some things (such as lists) because the development environment we chose doesn't support them yet. We are actively looking to remedy that because as a customer you don't really care about the reason, you just want it to work. Especially when it is something as common place as bulleted lists.

One thing worth mentioning though in regards to fonts. ScreenSteps supports output to multiple formats from a single source - HTML, Word, PDF, Blogs, Wikis and ScreenSteps Live. HTML limits the fonts that you can display to the user in most cases. For this reason you don't really want to assign a font to text but rather a style. That style would be able to define different properties for different output. HTML would get a font family and PDF/Word would get any font you chose. Once we have support for styles you will have more options and have the ability to update that style across all of your documents.

That is about it. Again, thanks for taking the time to write a review.