Wednesday, 23 February 2011

New Forum

You might be being directed to the new JGraph forum at, as if you weren't bored enough already of us changing things about this week. The forum is a implementation, with lots more white space, we like white space. The basic idea is this: it replaces the old forum, the bug tracker and the feature request web site with a single voting style forum. Why? Because the voting system applies to all three systems and people tended not to use the bug tracker or feature requester.

The new forum makes voted up questions and answers more relevant to searches, providing a better result than a dumb keyword search. The feature requests uses a voting system, so that idea ports easily. And bugs can be voted for,  indicating the importance of getting them fixed.

And how do we separate out only bugs if we're looking for existing problems? Tags. Everything is tagged, by product, "JGraphX", "mxGraph". By nature, "bug", "feature". Even by platform, "Windows","IE". This gives us an organic organization of information all in one place, a self organizing knowledge base, if you will.

In additional, OSQA supports using external logins to register with the site, nobody wants yet another login and password on yet another system. This forum let's the community say who is useful and who is noise, voting applies karma to users and you can quickly see whether is user is respected in the community as a general indication of the quality of their answers.

The current feature requests and bugs will be imported to the new forum manually. Unfortunately, getting the context right from the old phpBB forum is a lot harder and it won't it possible to import from there. However, the old forum will be left intact in read-only mode for reference.

Any questions, just post them on the forum.

Thursday, 10 February 2011

Cloud storage security

I read this article and was happy to see someone agreeing with me on the issue of cloud storage. The idea of having to trust the same number of companies as web applications that you use is silly. If you trust just one cloud storage provider, then yes, web application using that instead of their own storage means you just have to learn to trust one company. One thing to remember in that case is that you might well transmit your sensitive data to the application provider first before they pass it onto the storage provider. That somewhat defeats the point and is something our Google Docs storage implementation on is currently guilty of.

But then, someone who works with me said "who the hell stores sensitive information" on the cloud. Well, we do in Google Docs and you probably want to assume information is sensitive, rather than deal with each document on a case by case basis. Cloud storage providers need to provide JavaScript library implementation of the their storage APIs so the client goes directly to the store for loads and saves. Oh, and if you're listening storage providers, how about a JS user interface implementation so we don't have to do it? .

So now whether or not the application provider is secure doesn't matter? Well, not quite, since very few applications don't go back to the server at all (let's face it, virtually none). We have to go back for image export and pdf export on, of course to create these the server has to see the current data, you have to trust us once more (your mother would approve of Gaudenz, me, no chance). Our solution is going to be to create the images and pdfs on the client, using custom code. It's not quite as hard as it sounds, and removes the issue of the back-end server needing to implement any custom rendering that the JavaScript client receives. Then we'll completely client-side, with the load/save going straight to cloud storage provider, everyone is happy.

Then we add real-time diagram sharing to Oh. Now we need hanging requests on a server for everyone listening to a shared diagram, so they can receive updates. Even if the changes transmitted are just deltas, the original diagram can't go straight from storage to sharing users because they are not the account holder, so the web application servers are handling the data again.

And so on, you get the idea.

Can you be expected to trust the data handling of every web application provider, no. Is it easy develop client-side functionality that avoid the server ever seeing the data, even if it's not persisted there, no. The solution is virtualization and/or private clouds, private clouds really being a super-set of the former. Eucalyptus seem to be leading the way enabling you to create your own hardware resources safe behind your firewall and run Amazon machine images and VMWare images on the collective hardware resource. Will this become the norm? Hard to say, but it's catching on in the bigger IT departments. It does present web application providers with a new headache though, to control their server hidden behind a firewall, possibly unable to communicate with it. Let's not forget this has been the norm for long time with license keys and so on of desktop server installs, the control providers have in cloud solutions in spoiling them somewhat. This setup makes the users life easier and easier, but web application providers clearly prefer the current public way of doing things and you'll most probably find them fighting to argue the case that they are secure so they remain in control of the hardware.

Tuesday, 11 January 2011

Diagramly, how we think web apps should be

I'm going to stay from the usual high level technical discussions in this post towards usability of web applications. We launched a very basic version of last week that provides a fairly simple diagramming tool. I say simple, although I forget the mxGraph component does expose a large number of styling options and it possible to draw 70-80% of diagrams using the tool.

But the key point with is the fact that 99.5% of it is on the client. The only things we can't do currently are save/load locally, and create images and pdfs. And we're working on images and pdfs, HTML 5 will also give us local save of sorts. So the key thing here is the built-in scalability of the solution. You might remember people talking about doing it this way 5 years ago, but so few solutions actually do. Removing the need to recover heavy server costs removes the freemium model temptation.

The other thing, in terms of as a web application, is to make it look like an application. The two things web apps so often do that makes the usability painful and start-up time awful. 1) Login or registration and 2) Putting a web site around the app. I don't believe these work, plain and simple. We are going to offer the option of a Google login to store the diagrams in docs, but other than that, the idea is to provide local save/load. And we're not going to ask to login to the Google account until the points it's needed (i.e. a persistence request from the user to Google Docs).

Same for putting a web site around the app, you are simply increasing the time before the app is usable. There are constant discussions comparing web apps to desktop apps, but people seem to have forgotten start-up time. Don't click on the button to try it now. Don't register in 30 seconds to enable saving. Go to the domain, use it immediately.

Aside from all web users hate of registration, I believe people don't like other people storing their stuff. I know this goes against SaaS principles that you're supposed to offload everything remotely, but I honestly don't think this applies to data. I'm happy to put it in my Google Docs account, but I don't like the idea that service provider assume I want them to keep my data just because I use their service. Apart from being more user friendly, this decision removes any database from the architecture, we store nothing. So each server instance has no dependence on other instances or on any database or database cluster, near-linear performance still.

The last issue is the freemium model. I don't like it and I don't think it's a serious business model to target end users for small sums to add a few features to a tool. It probably creates some pocket money, but I doubt somewhat that it scales to a viable business point in the vast majority of cases. It isn't worth the annoyance it causes users being constantly reminded what they get extra for x Dollars/Euro/Pounds/Francs per month. The tools need to advertise some other revenue stream indirectly, don't do it stand alone.

These are the reasons I think is actually more interesting to users than the fairly large number of Flash based diagramming sites that are mostly freemium/registration based. All we need now is you to tell us how to improve it so millions of users will flock to it to test my scaling claim.

Wednesday, 3 November 2010

OS X and Java Support

Apple have announced that Java will be deprecated on the next major OS X release, I think we can safely read that as basically broken. Will they give out their JVM source code for the community to continue with? Of course they won't. The reason they don't want Java applications on the Mac is they perceive the average Java application as having a poor/inconsistent UI compared to the Cocoa/Quartz standard. Java applications are also slower and more memory intensive than native applications. The community JVM will only be of worse quality than the Apple offering (unless some companies with heavy Mac/Java application investment step in). Java zealots can argue the difference can be reduced to a reasonably small amount, but the simple fact is that the average developer isn't skilled enough/lacks the time to achieve this. In essence, yes, I agree with Apple. Why should they have to maintain a technology that dilutes their  application quality, when overall quality in one of their unique selling points.

Are we going to rush off and create an objective C library component with exactly the same API as JGraphX so you can quickly recreate your application in Objective C? No. For one, we're not going to panic every time a company changes its mind and there's quite a lot that going on at the moment. We share Microsoft's view that HTML 5 canvas is going to be the lowest common denominator as a graphical platform and intend to build enough custom functionality on top of it, that for a hardware accelerated canvas you feel you could be working on a native application.

Is that not helpful to the Java developers (and only 3 people follow this blog to date, and I believe they are all Java developers)? Not really, we're continuing to support Java fully. We provide a very widely supported platform in the JavaScript mxGraph client. It's not free, like the Java client is, but the application written using JGraphX is only free if your time is worth nothing. The Java platform will remain a good way to prototype for the JavaScript client, having the same API. For academic and FOSS projects, we will be looking at some way to allow mxGraph to be freely used (free as in beer).

Ultimately, we feel that diagramming should be thin client with the server sitting virtualized in a cloud, be that public or private. I know these buzz words have been around for many years and never quite materialized, but it will arrive, one day.

Mobile Device Support, Native or HTML 5 Canvas?

All the rage now currently is support for mobile device, phones and tablets specifically. Is it the next big thing that we should all develop for? Do you need your workflow editor to work on a 4 inch touchscreen? I doubt it. Sure there are plenty of applications that make sense on smartphones, interactive diagramming most likely isn't one of them. Viewing diagrams, panning through them, maybe selecting cells, possibly. But this is possible using an image map and the processing on the server side.

Tablets are another matter. 7-10 inch screens make interaction possible, in fact, the whole process of diagram creation should be fundamentally different. But you'll see what I mean by that in the touchscreen examples we'll be releasing next year.

The question we're hearing a lot at the moment is are we going to support mobile platforms natively (iOS, Andriod, Symbian, Blackberry OS and Windows Mobile), or are we going to aim at getting mxGraph running on HTML 5 canvas and just have one implementation?

The second option would seem to be the obvious one, however, browsers implement things very differently. What looks like one JavaScript implementation in mxGraph is actually a heavyweight effort to smooth over the differences between browser under the hood of the mxGraph API. HTML 5 canvas is no different in this regard, the implementations vary wildly and the functionality available in HTML 5 canvas is really quite limited, especially when it comes to font rendering. 

On the iPad, for example, there isn't really any concept of a view port, from our initial investigations. This means having the graph extend beyond the visible region isn't possible with our current canvas prototype, and that will be some considerable effort to implement.

Ultimately, the question is do we focus on one thing that we consider to be our core work, or spread our bets amongst all the possible platforms? Our commercial strategy has always been to focus, even if the technology has started as being very niche. Why support the Java visualization client in addition? Because we always have and it serves as a very useful prototyping platform for us. Will Flash make it to production, no.

Production-wise the focus is do one thing and do it well. Doing one thing is the easy bit, just be too lazy to do a second...

Friday, 27 August 2010

Page Breaks/Layout in Diagramming Applications

Is it just me that hates them? Every time I run up the Java Swing version of GraphEditor the first thing I do is remove the page layout. What's the point of restricting the amount of available space the moment you start an application, is the idea to make sure the printed version comes out correctly? If so, with laptops and tablets now commonplace in meetings (printing from an iPad would be nice Apple), I suspect printing is in decline. Corporate environmental policies tend to see to that, as well. The other thing is, isn't the computer supposed to deal with details like this for us? How about diagramming application default to maximum screen size by default and intelligently sort out printing for us (by which I mean avoid vertices and text being split between pages and zooming as appropriate)?

Friday, 20 August 2010

PNG embedded diagrams

In the previous post I mentioned embedding the XML of mxGraph models into PNG. The PNG specification includes a zTXt element, which enables very large sections of compressed text to be placed in the PNG encoding. mxGraph and onwards contain functionality to embed the model XML in created PNGs and to decode PNGs created in this way, using the Java code base. The GraphEditor example of the Java Swing client now saves in this PNG+XML format (.png suffix) by default to demonstrate the idea. We felt this is a somewhat more intuitive way of storing and transferring diagrams than text XML, since suddenly every user has the tools to look at the diagram, without the need for mxGraph. It provides a simple means for the server side to display diagram thumbnails without having to process the diagram and removes the necessity to synchronise XML formats and their associated images.

You can still stick with text XML if you prefer, but we'll sulk if everyone doesn't use this shiny new feature. This does bring up the issue of whether the JavaScript display looks the same as the generated server diagram. By default, they are identical, but customisation of the JavaScript can cause duplication of implementation on the server technology to get image generation to look the same. The majority of cases where this occurs happen because of new shapes being added to the JavaScript client programmatically. Which is another important reason for adding the stencils mentioned in the last post.

We are going to add an additional option to add the text without compression, not everyone will want their servers unzipping every time a diagram is opened and it provides a mechanism to view and extract the XML using a text editor, if required. Given the text is likely to form the minority of the file size, we're inclined to make this the default save format.

If you have other cases where there is code duplication necessary (other than I/O), we'd be interested to hear.