Extended Holiday

September 3rd, 2010 by xtof

As each year, the summer period has been a very slow period for us. After two months we were ready to pick up our little projects again, but we first decided to do a little soul searching.

We’ve invested quiet some time in all this over the past 5 years, of which only the last two were really visible to the outside. We have now reached a point where we find ourselves pretty tired and no longer able to give the best of ourselves to these codebases. So we have decided to take this break to the next level and extend it to a point in the future where we are eager enough again to take them on and finish all the great ideas we have in store for them.

So, yet another abandoned open source project ? I personally don’t think so, I really believe that we will come to that point where we want to work on it again, probably throwing away a lot of the bloat that has crept into it and restructuring it to fit our by then probably renewed ideas.

Today we don’t have a lot of people that depend on our work, so we’re not really letting a lot of people down – if we do, give us a yell, because it simply means we don’t know you’re out there and your call to action might just be the reason we need to find our mojo again.

Until that time, everything will look a lot like the castle of Sleeping Beauty, everything remains exactly the way it is, until prince charming comes by and wakes us up with a gentle ….  ZZZzzz…

Posted in TheSoftwareFactory | No Comments »

Protecting ProtoJS

July 12th, 2010 by xtof

It’s holiday season, and we’re experiencing extreme summer weather these past few weeks here in Belgium. Today the rain is finally pouring down and everybody is enjoying some time inside the house. My wife is reading a book and our little sweetheart is running around playing with everything that crosses her path.

Over the past few weeks I’ve been working on the final piece of the ProtoJS puzzle and today I could finally…

$ git commit
commit eeec92e2257a554b050433c0d4133287011df361
Author: Christophe VG <xtof@pumpkin.local>
Date:   Fri Jul 9 18:52:25 2010 +0200
added ProtoJS.Test Unit testing framework
translated all regression testes to ProtoJS.Test
ProtoJS.Test contains everything we need to test ProtoJS: simple assertions, delayed assertions (to test asynchronous events) and support for simple unit-tests as well as testing one test with different sets of data at once.
The result is exactly what we wanted: from now on 170 lines of Javascript code are protecting all of our Javascript code:
So, why write a unit-testing framework, when there are already so many available? The same reason we started ProtoJS: we needed some extensions to the Javascript language to make our projects easier to work on and smaller. ProtoJS doesn’t try to fix browser issues or enable all sorts of dynamic HTML tricks. If you need those, you really should go for jQuery or some other browser-oriented Javascript framework. The same goes for ProtoJS.Test. It’s small, follows our ideas about development and is aimed at the console level only. So, no fancy colorful HTML-based dashboards around here, but you could create them easily if you wanted.
We will be using ProtoJS.Test to guard all of our Javascript projects from now on. Starting with ADL, but also Canvas2D and UmlCanvas real soon now. ProtoJS is included in each of them, and size therefore is still a major issue. Today ProtoJS is for the first time feature complete and we will be moving it to a 1.0 status in the near future. We are pleased to see that our size requirement has held up pretty nicely:
$ du -sh ProtoJS.*
20K ProtoJS.js
12K ProtoJS.min.js
 4K ProtoJS.min.js.gz

Posted in Javascript, ProtoJS, Testing | No Comments »

Big Brother

July 1st, 2010 by xtof

With only two hands and very little time to dedicate to an ever growing project, we most of the time are happy if we get things online. Following up on them is something we really try to do, but most of the time fail miserably.

One of the biggest mysteries surrounding Hosted UmlCanvas, is the fact that we get tons of account requests, but people seem to get stuck somewhere and don’t get to the point of submitting actual diagrams.

We know that a main reason for this is the current end-user experience. We’ve come a long way: initially one could use the Javascript API to draw shapes on Canvas2D or add elements to UmlCanvas. Next we introduced a DSL, ADL, to lower the bar, allowing to describe diagrams in a less technical way. One step further, we moved the ADL code out of the HTML body and into our Inspector, allowing bi-directional editing of diagrams.

For new users, hoping to quickly try out the tools, this still is not good enough, they really expect full visual editing capabilities … and they are right … and they soon will be able to do so.

But all that is not the real mystery. Hosted UmlCanvas and its online editor offer the possibility to create diagrams without logging on. If you create and commit a diagram this way, the diagram gets a random identifier and the diagram will only remain online for 24 hours. The ideal way to try things out. Only if you feel this is too limiting for your needs, you need to register for an account, allowing you to choose your own names and have diagrams online for much, much longer.

Now, what did we see ? Not one single user that requested an account, had created a diagram beforehand. This might explain that, once they got their account, they were confronted with an interface they didn’t like and just abandoned.

So the real mystery is: Why aren’t users first trying to create diagrams anonymously and why do they start of by requesting an account first ?

This question popped up in my head again a few days ago when yet another account request rolled in. This time, I wanted to know what happened.

Apache logs to the rescue!

Below is a cleaned up excerpt from our access logs, representing the sequential requests made by the IP address of the new user:

10:57:09 /Main_Page "http://www.google.co.uk/search?sourceid=chrome&ie=UTF-8&q=umlcanvas"
11:00:04 /About/Ways_to_Use "http://www.google.co.uk/search?hl=en&q=umlcanvas+extension+for+googlewave&aq=f&aqi=&aql=&oq=&gs_rfai="
12:16:58 /Download "http://umlcanvas.org/About/Ways_to_Use"
12:17:44 /Start "http://umlcanvas.org/Download"
12:18:51 /Tutorial:Your_First_Local_UmlCanvas "http://umlcanvas.org/Start"
12:19:58 /Tutorial:Your_First_Hosted_UmlCanvas "http://umlcanvas.org/Tutorial:Your_First_Local_UmlCanvas"
12:20:42 /Community/Create_an_Account "http://umlcanvas.org/Tutorial:Your_First_Hosted_UmlCanvas"
12:37:19 /Main_Page "-"
12:38:35 /Create "http://umlcanvas.org/Main_Page"
12:41:00 /Tutorial:Sharing_Your_First_UmlCanvas "http://hosted.umlcanvas.org/start/"

(Each line consists of a timestamp, the requested page and a referrer, separated by a space)

So what did we learn from this ?

First of all, Google is our friend. It seems the new user was looking for “umlcanvas” and Google showed him the way, right to our Main Page on umlcanvas.org. Too bad we can’t figure out where he found the term “umlcanvas” and why there wasn’t a link to us ;-)

Apparently he didn’t find what he was looking for and it seems our site navigation isn’t the best of its kind, because the second hit was again after a search on Google. This time for “umlcanvas extension for googlewave”. Aaah … it seems he was looking for our Google Wave implementation. Fair enough, UmlWave, our Google Wave implementation, isn’t quiet as prominently present on the Main Page as he would have hoped for. Still, it’s there ;-) Luckily Google showed him the way once more.

From this page, he pursued to the Download page. Which he probably found in the sitemap at the bottom. On the Download page we luckily put a link to the Getting Started page, which was really what he was looking for, because after that he consulted two tutorials: “Your First Local UmlCanvas” and “Your First Hosted UmlCanvas“.

Auwch … The second tutorial he found was in fact a stub for a tutorial I intended to write, but which never got written. Even worse, I did write what he was looking for, but he missed it by a click : Sharing Your First UmlCanvas.

Finding himself stuck on that stub page, he tried to find a way out and clicked the link labeled “Create an Account”, probably hoping to find a next step towards true happiness.

Create an Account consists of a single line, with a link pointing to … the sign up page on Hosted UmlCanvas. So, while we tried our best to create a good site, we in fact failed miserably and visitors did exactly what we asked them to do: Create an account.

While waiting for our manual approval process to do its magic, he continued and he went back to the Main Page. From there on he followed a link to a page called “Create”, which is labeled “Start” on the Main Page. Alright, he finally discovered the big Start button in the middle of the screen, now he’s on his way.

Auwch … Once again, we are to blame. This page also contained just a single sentence urging the user to create an account: “Login or request an account and start creating your models right now.”. And if that isn’t bad enough, the links on the page are also completely wrong.

If we quickly look at how people end up on the sign up page on Hosted UmlCanvas, we see that they indeed come in through all the locations where we urge them to create a account, in stead of trying it out first.

  51 "http://umlcanvas.org/Community/Create_an_Account"
   2 "http://umlcanvas.org/About/Collaboration"
   1 "http://umlcanvas.org/Tutorial:Sharing_Your_First_UmlCanvas"

Conclusion: we have great visitors and users. They actually do what we ask them to do, but which wasn’t what we intended.

Mystery solved … time to get our act together and clean up our site.

So while we’re going through log files, let’s quickly look into some other interesting bits … Where do our visitors come from ?

TOP 10 refers:
 199 "http://swik.net/JavaScript+UML"
  83 "http://webuml.org/Projects"
  79 "http://thesoftwarefactory.be/wiki/UmlCanvas"
  61 "http://swik.net/drawing+JavaScript"
  34 "http://themodelfactory.org/Main_Page"
  25 "http://www.linkedin.com/groupAnswers?viewQuestionAndAnswers=&discussionID=14394336&gid=1356&trk=EML_anet_qa_ttle-cnhOon0JumNFomgJt7dBpSBA"
  22 "http://swik.net/canvas+html5"
  21 "http://www.baidu.com/s?wd=QQ"
  21 "http://webuml.org/"

Taking only domains into account:

TOP 10 refering domains
 357 "http://swik.net
 229 "http://www.sparxsystems.com
 178 "http://www.google.com
 105 "http://webuml.org
  87 "http://thesoftwarefactory.be
  58 "http://www.linkedin.com
  42 "http://themodelfactory.org
  30 "http://www.google.be
  28 "http://www.google.co.uk
  25 "http://www.google.fr

And if we group all Google domains we see that they total up to 450.

Conclusions:

  • Google is our number 1 source of incoming links.
  • It seems we’ve been tagged a few times and people actually use these tagging sites to discover new things.
  • Beginning of this year, we started the webUML initiative. It seems that quiet some people are looking into this matter, end up on that site and find their way to our own implementation of the webUML ideas.

To end this very basic log analysis, let’s see what people are actually looking for when Google points them in our direction:

 161 uml canvas
  73 umlcanvas
  25 canvas uml
   9 uml diagram canvas
   8 javascript uml canvas
   8 html5 canvas uml
   7 html canvas uml
   5 javascript uml interactive diagram
   5 javascript uml diagram
   5 html5 uml diagram canvas

Let’s see that we can improve their experience and live up to the expectations.

Posted in Hosted UmlCanvas, UmlCanvas | No Comments »

What we make in Common

June 29th, 2010 by xtof

Some time ago, we briefly introduced our Common library. Today we add another chapter in this story, but this time we take it public from day one.

If you follow our releases you might have noticed that yesterday, we pushed two major/minor releases of ProtoJS and ADL into the public domain, bumping them into the 0.2 and 0.4 stages. Looking at the commit messages it shows why:

commit 737f5120ed52bc1578f85222f5f3d3ef03d35e87
Author: Christophe VG
Date:   Mon Jun 21 22:40:55 2010 +0200

    introduced common.make

Common.make extracts the common parts of our make-based build scripts and makes them available to all our (Javascript) projects. This way, we finally have a unified way of building and packaging our releases.

It wasn’t something we planned for, but bumped into while upgrading our build process from fetching everything from the web to keeping everything local in the repository, with a preference for git submodules. We started this effort because we were bitten one time too many by offline servers and releases of our dependencies causing havoc to our own projects. We really had to start to manage our dependencies. Making them part of the repository and upgrading them at our own pace was the logical solution.

But suddenly we saw many common parts pop-up and we decided to create Common.make, to hold all common dependencies. No big deal so far.

While cleaning up the Makefiles, we were confronted with the results of advancing knowledge. The first Makefiles we created and the last ones were drastically different, and upgrading them quickly became a real P.I.T.A. With 2 Makefiles done and at least 2 to go, I decided to also extract our common Makefile logic and put it in Common.make.

The results are pretty nice, if not only by the numbers:

$ wc -l */Makefile | sort -rn
     149 ADL/Makefile
      97 ProtoJS/Makefile
      44 ADL.with.common.make/Makefile
      28 ProtoJS.with.common.make/Makefile

Where initially, these two projects together had 246 LoM (Lines of Makefile), after introducing common.make this amount was reduced to a mere 72. And that even still includes about 15 lines of boilerplate code in each of them to make the end-user experience as smooth as possible:

APP         = ProtoJS
BUILD_STYLE = simple

SRCS=src/ProtoJS.js \
     src/Event.js \
     src/Mixin.js \
     src/Object.js \
     src/String.js \
     src/Number.js \
     src/Class.js \
     src/Array.js \
     src/Hash.js \
     src/Function.js \
     src/Ajax.js

#############################################################################
# boilerplate to kickstart common.make

have-common := $(wildcard lib/common.make/Makefile.inc)
ifeq ($(strip $(have-common)),)
all:
        @echo "*** one-time initialization of common.make"
        @git submodule -q init
        @git submodule -q update
        @$(MAKE) -s $@
endif

-include lib/common.make/Makefile.inc

Using Common.make, we now only have to configure what is really necessary: the name of the project and its sources. In case of ProtoJS, we also specify the optional build-style.

ADL is a little bigger, because it has to do some preprocessing to generate the actual sources using JSCC.

So if we gain about 174 lines, how big is Makefile.inc ?

$ wc -l Makefile.inc
     118 Makefile.inc

And this is only for ProtoJS and ADL … Canvas2D and UmlCanvas are of course up next.

Is it the next big thing ? Of course not, it’s just a refactoring of our own build scripts, doing things the way we like, hopefully making our software more dependable and uniform.

Having recently been confronted with the utter bloat and craziness of Maven’s pom files, I must say that it’s a relief to see that a proven technology can be a more valid answer these days than running after the latest technologies. But that’s another story that deserves a different time and place ;-)

Posted in ADL, Common, ProtoJS | No Comments »

The state we’re in

June 24th, 2010 by koen

At the moment, we’re preparing a major update of Hosted UmlCanvas. Redesigning the diagram submission process is one of the things we wanted to do. Currently two clients use the submission process: the Hosted UmlCanvas web site, and a web service, that is used by the Enterprise Architect plugin.

Our old submission code is almost 200 lines in length, mixing business logic and markup, without unit tests, resulting in a hard to maintain clutter. Not very nice, we know :-)

Time to fix it properly, so we created a state diagram  and a class diagram depicting the new design:

(Disclaimer: Yes, UmlCanvas has support for State Diagrams, BUT … it’s something we pushed to our public repositories in advance of the upcoming release. It’s almost impossible to create a diagram right now, and only a very limited subset of features is supported. If you really want to try it YMMV)

This diagram is an example of the state pattern. The submission web page talks to a DiagramSubmission and passes it information about changes to the user and/or diagram in the submission process. The DiagramSubmission delegates these requests to its state, which handles the requests and navigates to other states.
The DiagramSubmission is then used by the submission web page to feed a DiagramSubmissionReport, which will inform the user about the current submission.

Since the submission process is one of our major components, we do want it to be documented well. And what’s better for documentation than good unit tests? Decide for yourself:

  function testKnownUserSubmittingNewDiagram() {
    $submission = $this->createSubmissionForKnownUser( 'known user' );
    $data = $this->createValidDiagramDataForOwner( Session::getInstance()->getCurrentUser() );
    $submission->handleNewData( $data );
    $this->assertTrue( $submission->isInState( 'NewDiagramSubmission' ),
      'submission should be in state NewDiagramSubmission' );
    $submission->handleNewData( $data );
    DiagramService::getInstance()->expectOnce( 'save' );
    $submission->handleCommit();
    $this->assertTrue( $submission->isInState( 'SavedSubmission' ),
      'submission should be in state SavedSubmission' );
  }

You might notice we share Roy Osherove’s idea about preferring specific factory methods above large setup functions. It allows each test to share the same skeleton which really makes the tests more readable. We create specific factory methods to create diagram data (valid or invalid, as owner or as coauthor, …) and a submission (for an anonymous user or a known user, …). The createSubmission function also takes care of setting up mock objects that are relevant for the Submission class, but not for the test. The test function sets expectations only relevant to the test itself. We’d like to hear your comments about this.

Posted in Hosted UmlCanvas, Testing | No Comments »

Without words …

June 11th, 2010 by xtof

Posted in Canvas2D | No Comments »

Completeness of Vision

April 7th, 2010 by xtof

Was it really that obvious that we were holding something back when writing our previous blog post ? It seems that way. So let’s just bite the bullet and announce a project that completes our vision and corresponding offering: UmlSearch.

What is wrong with Google ? Absolutely nothing, but it’s still a generic search engine, trying to please everyone. The UML world is such a specific and sometimes strange world that we believe it deserves a special treatment.

UmlSearch will offer search results that are only related to UML and will present them using a lot of social pizzaz. We want every search of a UML related topic to result in useable information of high quality.

How we believe we can achieve this ? Patience! We have a lot of project currently under development and we want to release this when it’s ready, which might be still in a not so distant future. But if you have any thoughts on this matter, feel free to contact us.

Posted in TheSoftwareFactory, UmlSearch | No Comments »

The World According to UmlCanvas

March 25th, 2010 by xtof

UmlCanvas 0.4 is nearing its release and it marks yet another important release because support for class diagrams will be far more complete with the introduction of role names, cardinalities, etc. Also the introduction of UmlCanvas# and the Enterprise Architect plugin are exciting evolutions. Hosted UmlCanvas already contains al the resolved issues and new features, because we follow the principle of continuous integration and releases. Looking at the release page clearly shows what’s to be expected. But this release also marks another important milestone in our plan.

UmlCanvas and Hosted UmlCanvas are pretty nice tools, still in their infancy, but they clearly mark a new range of possibilities. UmlCanvas was the answer to our own need to be able to render UML diagrams on TheModelFactory and Hosted UmlCanvas came to live when I wanted to include the same diagram in multiple places while sharing the underlying definition. Both solve their respective problems, but are merely technological foundations.

Yes it is possible to go to Hosted UmlCanvas and create a diagram, send a Hosted UmlCanvas diagram link via email to a colleague, have him make changes to the diagram and send you a link to an updated copy. It works, but it’s not very user friendly. We know.

The same is true for the Inspector. It’s a great solution – and it will be even more when we add all the buttons and switches to create diagrams completely visually – but  when you want to create an extensive diagram or even manage a whole model, things get “a little” rough around the edges. It works, but it’s not very user friendly. We know.

We know this now, and we knew this a long time ago. One first has to walk before one can run. We had to create these technologies first before we could start building real applications on top of them.

Today we are proud to announce for the first time our complete vision and introduce you to the entire stack of technology and end-user applications and tools we will be rolling out over the coming months … “The World According to UmlCanvas”:

Some of the names in the diagram above will be familiar, others might come as a surprise. Let’s talk a look at them, starting at the top and moving along clockwise:

UmlCanvas is our Javascript library that turns any HTML5 canvas element into a UML editor and presentation tool. This is and will remain our most important and technological foundation. We are going to add more and more diagram types to it and make it a very versatile online UML-component.

UmlVault is the new name for Hosted UmlCanvas and will continue to store UmlCanvas based UML diagrams and enable sharing them in different web-enabled formats. It will focus on this and only this task. But more on that later.

The first new kid on the block is UmlPad. It will be an online, stand-alone, UML CASE tool, with UmlVault as a storage backend. It basically is the successor of uWe, our very old proof-of-concept UML Web Editor, but on a lot of steroids.

UmlPad will be a single page website, consisting of a custom editor implementation on top of the UmlCanvas Editor Framework. It will feature all that is needed to call it a true CASE tool and will include model level concepts. This way it aims to be a completely online CASE tool that you can use from everywhere you log on to the net.

UmlTalk solves the basic collaboration use case where we want to be able to discuss a UML diagram while both being able to make changes to it. UmlTalk is a UmlCanvas-enabled online discussion forum build on top op UmlVault. Think of it as Stackoverflow but for UML. It will also reuse UmlPad as a component to provide the users with a very user friendly online UML editor.

UmlWiki is a project that we already mentioned before. It will add UML and project methodology support to Mediawiki, making it the first integrated UML based documentation tool. We see UmlWiki as a solution to the Word Documents containing many our of date copy/paste UML diagrams offering a content and diagram editing solution in one. We’re going to develop UmlWiki very slowly, starting from TheModelFactory and give it a lot of time to mature. This is more than just plugging in UmlCanvas and will require also a lot of thinking about how analyses should be documented in an analyst friendly way.

Finally, UmlHub will be the central and all-in one collaborative platform for UML modelers, offering a unified interface on top of all UmlCanvas-based components. Log on to UmlHub and create great looking UML diagrams using UmlPad, store and share your diagrams on UmlVault, start a discussion using UmlTalk and write documents based on your diagrams using UmlWiki, but all from the same unified interface.

But it also wants to be highly collaborative and introduce a more social way of modeling: UmlHub will introduce communication between users, introduce concepts like user groups & projects and will allow you to reuse or share diagrams by or with other users in the hub, but also outside through the other sites.

With 4 new projects in the pipeline, you will understand that we’re hard at work to get the common parts firmly in place, to be able to deliver these babies as smoothly as possible. We’re happy that we’ve finally reached the point where we can cross the border between pure technology and applications, moving from the orange zone to the red zone.

Posted in UmlCanvas | No Comments »

What do we have in Common ?

March 24th, 2010 by xtof

Common is the name of the PHP library we use to render our websites and access the diagram and user data in our database. It’s called common, because it is shared among all of our sites. We try to keep the custom part of a website as small as possible so if we make a change it is reflected on all of our sites at the same time. We simply don’t have enough time, so we need to automate as much as possible and this way of trying to put everything in a common library enables us to create new sites in a consistent and fast paced way.

Currently common is used to render the UmlCanvas main site, where it extends our Mediawiki deployment, the entire Hosted UmlCanvas site is build on top of it, our testing site for UmlCanvas, the main TheSoftwareFactory site, … But also a site like the webUML site is build on the same foundations.

With UmlCanvas and its hosting service becoming more and more mature, we are moving beyond the pure technology barrier. Geared with these technological tools, we are starting to build applications on top of them. This will soon increase the number of sites we are going to have to manage, so our common library is becoming more and more important.

We therefore started an effort to clean up the common code base and lift it from the quick hack dungeons and turn it into a fully tested, documented and complete set of classes we can use to create and manage our sites.

We basically follow a proven pattern of : Object / Repository / Service:

Is it obvious we like DDD ? :-)

In our world we deal with: Diagrams, Users, Requests, Marks, … And all of them have a simple naked object form, as well as a Repository and Service interface. At first it may seem an implementation overhead, but in reality it is quiet the opposite. By clearly segregating the different duties, dependencies become much clearer and reuse is a lot higher. Implementing a new object with its repository and service almost boils down to a configuration of the properties.

Our projects are almost exclusively web-based. So we also have classes that represent Pages, PageComponents and Templates. We decided not to go with a “real” template engine like Smarty because currently our needs don’t really exceed the simple variable replacement. The fact that I put Pages and PageComponents in front of Templates also indicates that we’re currently focusing more on the functional view of our pages and their components, where we have classes that provide both the HTML generation (say client interface) and the processing of the returning information from that HTML (say server interface). Templates are only a very small part of that and a simple include 'TemplateName.php'; comes very close to the actual implementation. But, we did identify the Template class, which might allow us to implement it differently in the future, when our template needs exceed the current requirements.

Our goal is to have a fully tested and fully documented common library and we’re happy to say that we’re well on our way:

And because we’re almost done with this endeavor, we are about to start the implementation of Hosted UmlCanvas on top of it. It won’t be a simple line-by-line translation to the new API because we want to take advantage of the new possibilities of our common library. So we will be creating PageComponents and adding as much of them to the library. But we won’t be introducing new features. In fact, we won’t be introducing any new features to Hosted UmlCanvas anymore. We might even remove certain features currently available.

What no more new features? Removing features? Are we terminating Hosted UmlCanvas ? No, not at all. But we want to keep a clear focus and build small solutions that do one thing and do it well. In case of Hosted UmlCanvas this focus should be on storing and providing UmlCanvas based diagrams, making sure that your diagrams are available online. Hosted UmlCanvas therefore really is a technological component and any functionality surrounding it, should be separated from it in a functional component/application of itself. We should not fall into the “technology-as-an-application” trap.

So where is the functionality going ? That’s a different story. Check back tomorrow for a tour of  ”The World According to UmlCanvas.”

Posted in Hosted UmlCanvas, Testing | 2 Comments »

Warming up

March 23rd, 2010 by xtof

If you have been following our progress for the next release of UmlCanvas, you already know that it is about to be released. To get back in the mood of releasing and killing some time in between test runs, we are going to post a few more entries on this blog. Consider it an update long overdue or maybe a summary of what has been going on over the past few weeks. Today we focusing on …

Hosted UmlCanvas

Given the embryonal state of Hosted UmlCanvas, we never really cared a lot about usage statistics, visitors, … Releasing it back in October, was more of a way to force ourselves to get it online (release early) and keep improving it (release often). And it worked. Today, Hosted UmlCanvas has already a lot more features that make it a lot more fun to work with. Users with accounts are beginning to see more and more advantages over simply creating diagrams anonymously, and oh boy you should see what’s coming up next.

Currently we’re overhauling the back-end code of all of our sites (which is delaying the release of UmlCanvas 0.4 a bit). We have a lot of exiting stuff coming real soon now, and if we didn’t clean up our act now, we would regret it, not being able to roll out so many fun ideas at the pace that we come up with them. But that’s something we’ll discuss at a later time.

Today, for some reason, we took a look at the usage of Hosted UmlCanvas and plotted the number of served diagrams on a daily basis. We were really impressed with the results:

In little over 5 months, we’ve gone from zero to a daily average of around 100 diagram requests, and the trend line looks promising :-) For you number-freaks out there: the graph depicts a running daily average on a 7 day scope. With these relatively low numbers, day to day variations are pretty big and this way we flatten the graph a bit, showing more clearly what’s going on. So, given this graph you would say that we currently have peaks that almost reach 200 diagram requests, in absolute numbers we have seen days that hit as high as 500 diagrams. As always, you can proof anything with numbers and statistics.

Another fun fact is that enabling UmlCanvas to dynamically load diagrams using AJAX, proved a nice way to go. In the “early days” (pre-0.3) users could include diagrams from Hosted UmlCanvas by inserting a <SCRIPT> tag targeting Hosted UmlCanvas, which would load and run some dynamically generated Javascript to create the diagram. Today a user simply needs to include a <CANVAS> tag with and ID and a CLASS and UmlCanvas will automagically fetch the diagram data and render the diagram.

We currently support 3 different ways that users can retrieve diagram information: the old way with the script tag, in JSON format and as a Google Gadget, which allows you for example to plug any diagram into a wave. The numbers, again, speak for themselves:

With 84%, JSON is by far the most popular way to retrieve diagram information. The 10% of the script tag is diminishing by the day, but what really astonished us was the percentage of request for diagrams in gadget style: 6%. Given that this was merely a fun quick hack, it seems that people actually are using this feature.

Tomorrow, we take a look at what’s cooking under the hood of Hosted UmlCanvas and what the future has in store.

Posted in Hosted UmlCanvas, UmlCanvas | No Comments »

« Older Entries