Surround Your World

One of the things I do is look at competitive products. I do this both to understand their strengths and weaknesses as well as our own. Looking at someone else’s solution to a similar problem can often give you a fresh perspective.

As I looked at several of these, a few trends showed up. The first is that security in other products seems to be left as an exercise for the customer. I’ve talked about that before. Another area where other products take a very different approach is around triggers and alerts. This is another part of an application that either isn’t shown in a demo, or if shown the trigger is already installed and working. The user sees that emails are being generated or actions are being triggered with an aside of “all this and more can be yours with just a little script writing.”

Now, I like script writing as much as the next person (well, assuming it’s not Perl). But I mostly enjoy it when I’m doing it for my own use. When I need it to work for all those crazy other users, then it starts getting less fun. People have this tendency to enter bad data. Or not think exactly as I do. And as much as I try and get them to follow my every command, they refuse. Perhaps when my application for the evil league of evil comes through I’ll have more success. Until then, if other people depend on my scripts then I need to put in thorough error checking. And progress messages. Bummer.

Surround has taken a different approach. We let you write scripts or applications if that’s what you want or need to do. And sometimes you do. But we try to carry as much of the load as we can.

First, we let you specify as much of the criteria for your trigger as possible. That way we won’t even call you if it doesn’t make sense. And you can skip writing code that checks, for example, the user, or group, or file name pattern, or branch.

Second, we let you specify exactly what action (e.g. checkin, add, promote) and when (before or after the event) the trigger runs.

Finally, for some of the most common actions you don’t even have to write a script. That includes generating an email, changing the file state, or preventing the action entirely along with a message letting the user know why.

In a future posting I’ll be listing some of the features I like in other products. And maybe some ideas of how we might incorporate them into Surround.

If there is a feature or approach in another product, whether it’s a competitor to Surround or not, let us know. I’m not afraid to steal borrow learn from others. Now back to that plan for re-educating users to all think alike.

As a Macintosh user it’s easy to feel left out by cross platform application vendors. Microsoft is too easy a target (though I can’t miss the chance to say I use Entourage every day and it never ceases to make me angry), so I’ll pick on someone my own size. Seapine. Although we have a fully native (that means not Java, you cheaters. You know who you are) client and servers on Linux, Solaris, Mac and Windows we don’t always make them, well, native enough. Make all the command keys match common conventions on that platform. Take advantage of platform specific technology, or the latest UI craze.

Now, it’s easier on Linux and Solaris since the only GUI standard is to have one. Everything after that is gravy. And as a long time Windows user and developer I can say that not even Microsoft can always agree on how to do things. But Mac users often have a different expectation. Hitting command W always closes a window. Always. That isn’t to say that all Mac programs religiously follow UI guidelines, and Apple is often offender number 1, but I think that in general things are more uniform and conventions are more commonly adhered to.

So what about Surround? Did I mention we have a fully native client? Although we’re pretty good in a number of areas, we can do better. Some of our command keys don’t map to the generally agreed to convention. We don’t always follow the latest user interface guidelines (for example, there are a number of places we should be using sheets rather than dialogs on the Mac). I’d probably give us a grade of B minus, but I’m looking to make that an A as soon as possible.

That’s were you come in. Since I bounce around between platforms, I sometimes miss places where we aren’t native enough. If something in Surround seems less than Windows/Mac/Linux/Solaris native, drop us a comment either here or at the feature request forum. Since we go through all the effort to create native clients (and servers) on all those platforms, there’s no reason they shouldn’t go completely native.