SVG vs. Canvas: Tastes Great, or Less Filling?

February 12th, 2006 by csimms

Now that there are two up-and-coming web graphics technologies (SVG and canvas), I thought I’d research them,
see what’s the difference between them, and see if they’re usable now.

Canvas Tag

The canvas tag got a lot of attention a while back when Apple announced they were adding it to their Safari browser,
and that they were using it to implement some of their Dashboard widgets.
What is it? Basically, the canvas tag is an “immediate mode” graphics technology — you start with an empty image jammed into your browser
page, and it’s your job to color all the pixels using javascript. It’s
going to be a “standard” by the WHATWG.

Below is a summary of current browser support for the canvas tag:

  • Firefox: 1.5 is first major Firefox release with it built-in
  • Safari: version 2 has it
  • Opera: 9 preview has it, will be in next major release
  • IE: of course it doesn’t support it. someone tried writing a small javascript emulator
    but that was just an experiment and not a real project

Here are some cool demos using the canvas tag:

SVG

SVG, or Scalable Vector Graphics, was made a standard by the W3C years ago (v1.0 in 2001 and v1.1 in 2003).
For a while it looked like just another W3C party where no one showed up.
What is it? It’s a “retained mode” graphics technology where you declare your graphical model as a tree of objects,
and the browser takes care of rendering it for you. Since the browser has your model, it can do lots of things for you like detect mouse clicks on objects and
rescale your picture to an arbitrary resolution.

Below is a summary of current browser support for SVG:

Here are some cool demos using SVG:

Conclusions

I took a graphics class in college a decade and a half ago, and the concepts remain exactly the same.
In general, SVG and canvas are complimentary, rather than competing, technologies. Anything you can do in one,
you can do in the other, but each one is optimized for certain situations.

Below, I put together a table summarizing the tradeoffs.

Feature SVG Canvas
Draw geometric shapes Easy: use SVG tags Easy: use API
Manipulate pictures Hard: Need to use poorly- or un-implemented image/feImage tags Easy: use API
Object Model Easy: You declare model, browser renders it. Model is part of DOM. Hard: No model. You can maintain your own Javascript model (fun!).
User interaction Easy: Event model is integrated Hard: None out of the box - you have to implement all event handling infrastructure, like tracking coordinates of objects in model.
Resizing Easy: that’s the S in Scalable Medium: You write the resizing code

You should know which technology to use based on your project and requirements.
If you’re just rendering some graphics, and you have no need for user interactivity, then the canvas tag is more appropriate.
If you want to have user interactivity, or if you have some other need for a model or user interaction, then SVG is more appropriate.

Ignoring the above trade-offs, if you want a technology that runs in all major browsers right now, then you have to go with SVG.
And that’s probably good, because my completely unscientific guess is that SVG is more appropriate for most (but not all!) applications.

Bottom line: SVG tastes great, but canvas is less filling.

P.S. Just for fun, I generated a GANTT chart using SVG and canvas to show how to write simple stuff
(if you have IE, don’t even try that link. :-) . I learned that for basic stuff, the APIs are quite similar. I also learned that
embedding SVG in HTML is a pain in the butt, which is why I put it in a separate page here.

Introduction to Geographically Distributed Development (GDD)

January 16th, 2006 by csimms

One niche that we’re targetting for our ProjectPipe product is
geographically distributed software development teams. Before the rise of the Internet (in the 1980’s and early 1990’s),
only the largest companies (i.e., Fortune 100) could afford to setup development in multiple geographic locations.
I think the original purpose was to have multiple teams working around the clock in different timezones
to increase the speed of development on projects. Products like
Rational’s ClearCase MultiSite
were used which supports multi-master replication — really cool technology, but you need a six figure budget
just for the initial setup, and at least one full-time admin for support and maintenance.

Nowadays, things have changed with the worldwide Internet leveling the cost of global communications.
Many products have been designed to work over the Internet, and they don’t crap out if your connection is slow.
For instance, you can use CVS and its descendant Subversion over a fast LAN or slow Internet connection.
As a counterpoint, ClearCase was designed to work
over LANs, and if you try to have its standard client talk to a server over the Internet on a VPN, you’ll see terrible performance and frequent
failures because ClearCase has very chatty client-server communcation — to be fair, they have a more recently introduced web-based client
which is missing some features but at least works over the Internet.

I could analyze all the tools you need to run geographically distributed development (GDD), but they all have the same need:
to be available anytime from anywhere in the world. Most client-server and even some web apps don’t fit this criteria.
IBM has a nice article about using IBM’s products
to do GDD
. But I’m not worried about IBM as a competitor. It’s true, they have googol (not google :-)
more software than we do, but their products are consultingware
– where it looks like shrink-wrap software, but really you need to hire experienced consultants to install and customize
it to do anything, let alone what you want.

What is Project Management?

January 6th, 2006 by csimms

While writing marketing literature, I was trying to figure out what ProjectPipe’s product category is. So far I’ve been
saying that we do “project management thru-the-web”. But it’s a little confusing to me because we integrate with
MS Project, which claims to be a “project management program”. If you have MS Project, why would you need us?
Both do project management. Is ProjectPipe just MS Project on the web?

The simple answer is no, we are not MS Project on the web. We are not interested in rendering
Gantt charts on the web. Some companies are doing that
– good luck to ‘em! (Though if SVG ever takes off then maybe I’d do it. :-)
ProjectPipe has a very different focus than MS Project — both products have mutually exclusive and complementary
features. ProjectPipe tries to cover all the major areas of project management defined
in PMBOK (Project Management Body of Knowledge).
However, MS Project just covers task and resource scheduling. Admittedly, that covers a lot of ground — budget
over time, resource levelling, etc. But it doesn’t cover: issue tracking, source control/asset management,
risk management, requirement tracking, etc.

It would be nice if there was another phrase besides “project management”, something like “project lifecycle management”
but I think we’re stuck with this ambiguous phrase.

Ian Landsman’s 4 Rules for the Practical Entrepreneur

December 30th, 2005 by csimms

Ian Landsman just wrote a great little piece outlining

4 criteria to evaluate a new product against

. I’ll take the bait and evaluate our new product in this context.

1. Fragmented Market

Pass - I’d say that the project management thru-the-web market is highly fragmented without one clear dominant vendor yet.
The desktop project management market is dominated by Microsoft, but we’re not competing with them
– rather, we complement them by integrating with them.

2. Business Before Consumer

Pass - we’re only targeting business. I can’t even imagine what a consumer-oriented multi-person project is.

3. Clear and Simple Revenue Model

Pass - we have a really simple table summarizing
our prices and product options.

4. Dog Food

Pass - we’ve been using our own stuff for a while now. And it really is great advice
– when we initially cut over to using our system, we found a bunch of bugs and missing features.

In summary, we pass all 4 rules!

Why Python?

December 22nd, 2005 by csimms

Here’s a question I get sometimes: why did we use Python? I had been programming in J2EE/Java for six years
before ProjectPipe. I had used most of the major technology areas in J2EE: ejb, servlet, jsp, jms, etc. I had
lead several successful projects that mostly used BEA’s WebLogic app server (for a while it was the best J2EE app server),
though I also used the JBoss/Tomcat combination as well (mostly during development because it was faster to reboot).

We’re not the only people who have left J2EE for hopefully greener pastures. Bruce Eckel just wrote
an article about people leaving Java for Ruby.
I left Java for Python. I left for two reasons: 1) my buddy Mike bugged me to look into Python and 2) once
I got over the white space/indentation Python issue, I found my productivity is higher. It’s difficult to compare
your productivity when using two different technologies, because once you solve a problem using one technology,
you’ve learned some things and it’s easier to solve the same problem in a different technology. Anyway, the only
concrete difference I can offer is that it used to take about a minute to boot up a J2EE app server, but I can boot up
my Python app server in 2 seconds. If you consider that during development you might reboot a hundred times in a day
(you usually don’t have to reboot in either technology if you just change a web page), then you can see that you might
lose 6000 sec (100 x 60 sec) or 100 minutes using J2EE vs. 200 sec (100 x 2 sec) using Python. Of course, when your
app server is rebooting you might look over code, but on the other hand it’s very distracting to wait an entire minute
before you can test changes you just made — you’re just as likely to keep surfing the web an extra ten minutes while
waiting for your app server to finish booting up. And since J2EE is so damn complicated, it’s tough to write unit tests
– I’ve done it occasionally in J2EE, but you usually have to either test outside of J2EE or go to the trouble of
setting up and using the Cactus testing framework. If you write
tests using Cactus, you’re still stuck with your app server boot time.

The Python community has a number of database and web frameworks available, but Mike and I chose
Twisted for our networking and Nevow
for our web framework. We rolled our own database support (written on top of Twisted). Mike was the
instigator to use Twisted — it took a while to convince stubborn me to use it, but after looking around, I grew
comfortable because the guys developing it are really smart, and their arguments on the simplicity and scalability
of their async approach sold me.

I would say that the only major thing I miss from Java is the boost in performance you get with Java’s excellent
JIT (Just In Time) compilers that come with the JVM. A while ago in an old weblog of mine,
I made some simple performance measurements
and found that Java with JIT is something like an order of magnitude faster than Python. Though I’m keeping my
eye out on the PyPy project which is working on JIT technologies
for Python (which is especially difficult because of the dynamic nature of the language).

Hello World

December 22nd, 2005 by csimms

One of my favorite SpongeBob episodes is Procrastination (sorry just a mediocre link),
where SpongeBob has writer’s block. He stays up all night putting off writing a short essay for Mrs. Puff, with the pressure building
the more he procrastinates, even going so far as to have Dali-esque nightmare of sleeping past his deadline.
(SPOILER: Yes he finishes his essay on time, but Mrs. Puff had cancelled the essay and didn’t tell SpongeBob.)
I’ll be honest and say I feel the same way trying to write my first blog entry. Taking the plunge anyway…

I promise you’ll get:

  1. Fresh content every working day from me or Mike.
  2. A little humor in all my posts.
  3. Something educational in all my posts.

Mike and I have developed a really easy to use hosted project management application.
We’re going to open it to the public real soon now — the private beta is just about over. We got some good feedback (thanks people!),
fixed a bunch of bugs and kept adding features.

Yes, the project management application space is crowded. However, crowded does not necessarily mean all niches have been filled.
You have the low end covered by such sites as Basecamp, which aim for short and small
projects such as web design. If you have a MS project plan with a thousand tasks, they’re not going to be helpful to you. And on the
high end, you have such “enterprise solutions” as Project.Net and eProject.
And when they say enterprise, they mean: no price quotes online (you have to negotiate, where the bigger the company the bigger the discount),
“on demand” means you wait for them to get back to you, and the feature set is described in hazy marketing literature.
But please understand, each company I just described has their own niche where their customers like how they operate.

Our product is a bit unique, we think that we have a good blend of the low-end friendliness and ease-of-use that people want, and the high-end
functionality that people need. We tried to design our application so that little or no training is needed to use it. We have two killer pieces
of functionality that I’ll explain more in a later post:

  1. Two way integration with MS Office (including MS Project).
  2. Easy-to-use traceability.

Usecase of Joining ProjectPipe - Jim Logs In

December 22nd, 2005 by csimms

Jim summizes the lousy in-house tool situation with his boss, and his boss agrees that it’s a shame.
When Jim asks if the company could pay for a hosted provider, his boss just
chuckles. Jim’s boss tells him that the project’s budget has already been set for the next three months, and
the time to get a purchase through accounting takes ages, but
if Jim personally pays for it that he could be reimbursed later from another budget area.
Having been burned in the past at other companies with unreimbursed expesnses, Jim sends a follow-up email to his boss
summarizing their conversation and cc’ing the business sponsor. The business sponsor sends Jim a private follow-up
email thanking him for taking initiative and saying he’s really looking forward to having a shared system so that
he and his direct reports can see how development is going.
Stated that way, it gives Jim the shivers, but he’s happy he got some brownie points.

So Jim ponies up for 1 month with ProjectPipe on his personal credit card.
He likes the fact that his user id is his email address - one less thing he has to remember.
He gets the login email in less than a minute, and immediately logs in.
The first thing he does is go to the team tab and invite his QA and developer guy. All he has to do is enter
their name, email address and role, and they’re automatically sent emails telling them how to login.

As soon as the team receives the invitation emails, they jump to work.
The developer imports the current cut of source code into the project’s Subversion repository, he wants
to play with it for a little while before moving the offshore guys to it.
Meanwhile, the QA guy imports the bugs from the most recent spreadsheet into the web app.
Since there are only a handful of bugs at the moment, he’ll just manually copy + paste them into the app,
but if there were a lot he could have used the small ProjectPipe client program to upload the data from
a spreadsheet (editor’s note: assuming Christian finishes that functionality).

While his team is busy adding data to their project, Jim installs the client program because he wants to upload
his MS Project plan into the web app. He probably would not have shared the project plan with the team
(he gets tired of developers nitpicking task timeline details), but since the business sponsor had talked
about it, he figures it’s better to be open and critized than quiet and fired later. Actually, Jim gets a little
happy (not too happy, he *is* a PM after all) thinking how he can CYA by saying that the entire project
plan and its status was always available to everyone on the team.

Jim reads up on how ProjectPipe integrates with MS Project, and is happy.
He wants to keep his .MPP file safe and local
and doesn’t want any program messing with it. He remembers the time when a BA took his 5,000 task project,
and ran Resource Leveling on it but didn’t tell Jim until he asked why the project had moved out several months
past deadline. Anyway, the ProjectPipe client is totally unobtrusive, after it asks for his email address,
password and project name, it just sits quietly in his taskbar. Its interface is through the web
(Jim wonders how they did that, but doesn’t much care that under the hood it’s using the XMPP/Jabber protocol,
as long as it works), so to import his project all
he does is go to the project tab in the website, click “Upload project to server”, select his file and click Upload.

To be continued…

Why ProjectPipe?

December 22nd, 2005 by csimms

Here’s a question I get sometimes: why would anyone pay for your product? If a project manager already has MS Project
and other software which is supported by their IT organization, why should they pay for anything else? And it’s true: if you’re
happy with the tools you have, then you don’t need us. But let me give one scenario where I think our product makes sense.

The project has been limping along for three months now, and the last PM (project manager) Larry
just quit because he got tired of suffering through long meetings with upper management trying to explain why the project was behind schedule.
It had started promising, like most projects do. Two weeks into the project, he and the BA (business analyst) had finished scoping out the project
and requested six developers for six months — they knew six good developers who were rolling off another project down the hall.
It wasn’t Larry’s fault that that their request was “modified” into six offshore developers.

Meet Jim, the new project manager. As a condition of taking the position, he got one developer and one QA guy working locally
to augment the offshore team and to provide him some local expertise on the project.
He also wanted to have an independent assessment on how the remote team was performing.

Jim’s first day on the job, he encounters his first stumbling block. The offshore team uses
MS SourceSafe for their source control system,
but their setup requires a VPN to access over the internet.
Jim’s developer needs to install the VPN software to compile the latest source
code, but Jim’s IT department refuses to let him install it because of cross-network security concerns.
One potential solution that Jim explored but rejected was installing the source code repository locally, and then having their offshore developers
use this repository remotely. But his IT department said it would take at least a month before they could provision
a new server, install it in their data center, install the software and get it running through their VPN.
Jim didn’t want to do what Larry had done, which was rely on the offshore team to periodically send him releases, because
Larry said that most of the time the releases didn’t initially work right. Whenever he would ask for a fix for a release, the offshore team
would always say that the release they had wasn’t worth fixing because it was terribly out of date,
and a new one was coming Real soon now.

Jim will try anything once (ask him why he doesn’t drink Tequila anymore), especially if he has no other options.
So he does a little research on the Internet to find
a hosted version control system. He finds that there are a large number out there, depending on what kind of repository
you want. Jim’s developer has been telling him that Subversion is an up-and-coming
version control system that is a replacement for good old CVS. And Jim’s developer
is begging him to switch from MS SourceSafe. The offshore team has worked with several version control systems in the past and doesn’t care.

Jim’s second day on the job, he encounters his second stumbling block.
On Jim’s first day, he had asked the QA guy how bugs are tracked on the project. Since the QA guy was new to the project,
he said he would get back to him. Today, the QA guy breaks the news that the team had been using a spreadsheet
which Larry and the offshore team had been emailing back and forth daily. That worked OK when there was no QA locally.
But now that development and testing would happen locally, they needed a shared issue tracking application.
The offshore team only has an internal issue tracking application which wasn’t designed to be shared over the internet.
So Jim goes to his IT department again, asking if they could setup an issue tracking system for him. They give him the same old
song-and-dance that it would take at least a month, but maybe even longer if they would have to buy and install a commercial
issue tracking system (there aren’t that many good free/open source issue tracking applications).

Jim goes back to his research on hosted Subversion providers. He finds that there are a handful at the moment, and that several also offer
Trac, a free issue tracker and project management tool. Trac looks
great for small projects, but Jim has been doing project management for years and doesn’t consider issue tracking to be project management.

Out of all the hosted Subversion providers, Jim only finds one that offers him
issue tracking and project management in a way that he’s used to. Stay tuned for what he does next…