Clint pointed out this great post about using Gliffy Online combined with Google Docs as an agile way to use Gliffy’s Flow Chart tools for software documentation. Very slick.

Several of our beta users have been kind enough to write about us as well. Here are a few we’ve found:

- Michael Sica – “gliffy is pretty impressive.”
- Fred Cavazza (english translation) – translated quote: “…very impressive.”
- t. – “…I found it a useful, intuitive, and visually pleasing tool.”
- A Zulu In Silicon Valley - “This is really cool if you’re looking to share flwocharts, which is currently a huge pain of MS Visio.”
- Ben Atkin – “…I am pretty impressed by the program overall.”
- Billy BLOGirlardo – Making A Diagram In A Jiffy With Gliffy
- Francine Lévesque – “…I find the features are easy to navigate and use”
- Tom Smith’s: theOTHERblog – “I like it.”

Check out Technorati where you can see a whole bunch of blog postings from other folks too. If anyone can translate some of those blogs in Chinese we would love to know what they’re saying…. (The google language tools for Chinese doesn’t quite do it)

We are extremely grateful for all your feedback and support. Thank you!

We would love to see Gliffy on this list in the near future. Today we moved one step closer with the expansion of the closed beta for our web based diagramming tool. Included in our new release is a really nifty publishing feature that allows you to put images of your diagrams in your wiki or blog postings. Clint recently posted an example of a picture he drew & published using Gliffy. Expect to see many more examples here in the future. If you would like to be added as a beta user in the future, sign up on the Gliffy home page.

• You’re composing a blog entry, and want to incorporate a spreadsheet from NumSum to get a point across.
• You’re working on a business plan in gOffice and you want to plug in some photos of the founders directly from Flickr.
• When working on a document in Writely, and you want to refer to a project management schedule in Basecamp.

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.

> 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.