Example of published Gliffy diagram

Clint has been working his butt off on Gliffy while I’ve been doing some consulting work to pay the bills. One of the nifty features in the new version of Gliffy is the publishing feature. Here is a sample (click to enlarge):

If I make a change to this flow chart using the Gliffy diagram editor, the change will instantly be reflected in this blog posting with no additional effort.

Gliffy Beta Begins

The Gliffy closed beta has begun. We’ll slowly add more user to the beta in the next several weeks/months. Browse on over to http://www.gliffy.com and you can see our new home on the web. In fact, as of today, we are no longer Silver Tie Software, but Gliffy, Inc. Our first application is a diagram editor. Imagine Visio deployed over the web, with instant collaboration features. Interested in joining the beta? Send an email to info@gliffy.com.

A lot of hard work from many people helped to make this happen. A short list:

  • Clint Dickson – Founder – Director of Engineering
  • Lyla Warren – Founder – Creative Director
  • Dana Yobst – Early involvement with Biz Dev and more
  • Andrew D. Toebben and Gundersen Dettmer – Legal
  • Henry Lyne – Helped us build out soon to be defunct http://www.silvertie.com
  • Jason Lee – Helped talk through technical and strategic issues
  • Dennis Yang – Provided us valuable insight early on
  • Jo Ann Promponsatorn – Accounting advice
  • Mom & Dad – I might need a loan from you soon!
  • …and everyone else who listened to me talk non-stop about what we’re doing, providing feedback, etc.

Standard Interoperability API

Sam at Writely kicks off a conversation about a common interoperability API between all these new applications popping up. We totally agree that such an API would make applications such as ours way more useful. Here are some examples of how such an API might be used:

With open API’s, you could certainly build custom integrations between all of these pieces. However, imagine if there was a a single standard API that everyone used for the general case, making integration a snap!

Here are some features I’d like to see in such an API:

  • Single sign on and Identity management, using an open standard
  • Ability to list and select resources from other services (Maybe using OPML)
  • Ability to easily import documents from one service, and embed them in another, even if the imported document is not publicly published to the world.
  • All the while keeping in mind that the user experience must be easy and seamless

This isn’t the only type of integration imagined by folks. For example, GoingOn is a manifestation of an idea Marc Cantor has often talked about: The Digital Lifestyle Aggregator.

Update: Sam has created a Writely doc to get the ball rolling on this. If you’re interested in collaborating on this, drop him a line.

Simple answers to concerns about Office for the Web

My former co-worker and friend, Dave, had some common concerns about moving to an Office on the Web. I thought I’d chime in with my thoughts:

> Maybe you don’t want your company/state secrets going across the internet and stored on someone else’s servers?

Some companies in this space are offering access to their applications over the secure https protocol as a premium service. For companies concerned about the security of document storage, the option to host the application behind your corporate firewall is available as well. We don’t offer either of these options yet, but they are certainly on our product roadmap.

> Maybe because hardcore data entry over a web application severely impacts productivity?

The promise of AJAX, OpenLaszlo, and associated technologies is that applications built with these tool will be comparable to their desktop counterparts. It will take a little time to get there, but in the mean time we’re betting we’ll be usable enough given the tremendous advantage web deployed applications offer.

> Maybe you dont’ want version changes of your tools happening on the vendor’s schedule, instead preferring to upgrade when YOU want to?

The advantage of web based applications is that you don’t have to upgrade, since the vendor will handle that for you. This is particularly advantageous for small companies that have limited or non existent IT staff. For large companies, it will reduce the complexity involved in rolling out upgrades to huge numbers of desktops. ( SocialText has some big name customers who get this) Customers who want more control will have the option to deploy the application server in their own environment, and make upgrades on a single server as they are ready.

> Maybe you want to be able to work when not connected to a network, or when network connectivity is unavailable?

The solution to this issue is an offline client. While a local install will be required to support an offline client, it is technically straight forward. But I have to say, with wireless hotspots just about everywhere, and wireless starting to be deployed on airlines, I think being offline will become less and less of an issue.

I think all of Dave’s comments are very valid, and it’s a good thing there are some excellent answers about his concerns. We think that our application will surprise folks when they see how similar it is to its desktop counterpart. And we’ll cost less money, offer superior collaboration, and be much easier to deploy.