JotBlog

Like many people, Team JotSpot waited in line this morning and saw “Star Wars III: The Revenge of the Sith” (see related post). I grew up with the Star Wars franchise and was excited / nervous about this final installment. As a former Hollywood agent, I know sequels can suck. Book of Shadows: Blair Witch 2, The Ring 2, Speed 2: Cruise Control, Beverly Hills Cop 3, Look Who’s Talking 3, Lion King 1 1/2, Son of the Mask…

The problem is motivation. When you make the original, you are making a motion picture. Films are creative labors of love that you hope make money. When you make a sequel, you are trying to make a profit. For a sequel to be greenlit, the studio believes they can generate a return on their investment by cashing in on the success of the original. It is not to answer all of the questions at the end of “Speed” or because audiences had been campaigning extensively for the back story to Jim Carrey’s character in “The Mask.”

The logic with sequels is that it is ok if you make a decent movie but it is not a requirement. Which is why very few sequels satisfy expectations: The Godfather Part 2, The Empire Strikes Back and Spiderman 2.

A key ingredient to sequel success is chemistry. Positive examples include Sean Connery as James Bond and Harrison Ford as Indiana Jones. Whereas Ice Cube as XXX and Jar Jar Binks both jump the shark. Said another way, if it ain’t broke don’t fix it.

Which is why JotSpot Hackathon Part Deux is sticking with our original formula and core values. Each of our engineers will crank on something:

• valuable to the company
• but not what they’re “supposed” to be working on
• can be taken from idea to working prototype in one day

Got an idea on what we should tackle? Feel free to cast your personal vote for features, bug fixes or projects. While there are no guarantees we would like to hear from you.

Details:

JotSpot Hackathon 2

Thurs. May 26

Air horn will sound at 9am and show & tell is scheduled for 8pm.

Thank you!

Team JotSpot

Like many people we geeked out and went to see Star Wars. Flickr photostream available here.

Yesterday was a relatively busy blogging day for JotSpot. In addition to Joe’s post about our inaugural hackathon, we started the JotSpot Developer Blog! The blog lives at http://developer.jot.com, and is actually a Jot app written by none other than our very own Reuben “Steel Trap” Antman.

One purpose of the Jot Dev blog is to create a place where internal Jot developers and guests can “tend fire” between hackathons. It’s sometimes frustrating to have access to new APIs and features weeks or even months before our customers. So we plan to share the latest pre-release JotSpot features and examples, both to inform but also to get early feedback. Another purpose of course is a place to riff on what interests us as individual developers. Yep, we’ve got opinions! But in the end, we hope that sharing our “inside” info and perspective helps folks succeed in developing apps, plugins, widgets, and themes with JotSpot.

BTW in addition to hosting the Jot Dev blog, developer.jot.com will soon host a new community site for developers only. More details on that later…

Can I get a shout out for the JotSpot inaugural hackathon!

Last Thursday, JotSpot had its first-ever hackathon (we were inspired by something similar done by the good folks at Atlassian). If I had advice for any company, it is that you should do this – and soon.

What the heck is a hackathon?

It’s a day-long event where our engineers each crank on something:

• valuable to the company
• but not what they’re “supposed” to be working on and
• that can be taken from idea to working prototype in one day

Why do a hackathon?

Because even startups get into a grind where engineers are working on longer term projects and creativity can feel stalled.

“But, Master Yoda, I am not afraid…”

We kicked off the event (with a mighty blast of the air-horn we bought at Fry’s Electronics) at 9:00am and we stopped at 8:00pm to do presentations. Jim (Customer Support) and I (CEO) were the food mules. Two dozen Kripy Kreme doughnuts, pizza and pez served as a brain-fuel.

Here’s our intrepid group of engineers poised at the hackathon starting line (with their individual rations of “Stax” – Pringles-imitation chips).

No one knew what anyone else was going to work on. Secrecy was the word of the day. Everyone hunkered down and cranked. There were only two pauses in the action – lunch and pez.

At 8:00pm, feeling like the SAT administrator, I yelled “pencils down!” and blew the airhorn. Pizza arrived and people wandered out of their cubes looking tired and slightly myopic from all the screen time.

Presentations began at 8:15 and it was amazing what this little team produced, in a frenzied, concentrated effort. When you give people the time to do the thing that always seems “just out of reach” people’s creativity cracks wide open.

So, without further delay, here’s what we built.

Real-time Editing

Abe “The Maine Brain” Fettig (you’ll find we all have stupid nicknames with obscure backstories), built a beautiful real-time multi-user editing environment. It allows multiple people to edit the same page at the same time and makes it possible for people to lock and edit at a paragraph level. The pictures don’t do it justice (so check out the flash movie below). It will be great for conferences and the like (instead of the IRC backchannel that often happens). Can’t wait for this to get out there!

Watch it in action: (click thumbnail)

---

Dev Buddy Plug-in

JotSpot has a new plug-in system (not yet released but coming soon!) that allows people to extend the interface and functionality of their JotSpot. Scott “The Eagle” McMullan, our head of developer relations, built the “Dev Buddy” plug in. It’s designed to make it easier for JotSpot developers to manage their products by adding another button to the interface that gives them instant access to XML source and the current “form” on the page. In addition, it adds a project area where they can place links to all the relevant project files.

Getting to the plug-in menu:

Selecting the dev buddy plug-in:

The results… Note the addition of the button to the chrome, the error reporting at the bottom of the screen and the section in the toolbar for project files:

---

Resizable Text Areas and Drag and Drop Tables

Alex “Waffle Donkey” Russell and Reuben “Steel Trap” Antman developed two very cool javascript widgets. The first was a cross-browser resizable text editor. For any of you out there who have big screens and who just wish you could grab a corner of a text edit area and resize it, you’ll like this. The second widget allowed you to reorganize JotSpot table rows with drag and drop in the browser. Tasty!

Before (small text area):

After resizing in browser:

Watch it in action: (click thumbnail)

---

Here are the drag and drop tables.

During the drag

Watch it in action: (click thumbnail)

---

The Wiki Browser

Michael “Vorlon” Nestler used the JotSpot APIs to feed link data into a Java applet which gives you a visual representation of your wiki. It’s a nice way to get a birds eye view of how any JotSpot account is put together. You definitely want to see the movie of this in action.



Watch it in action: (click thumbnail)

---

Triggers & Events, SVG, and Link Decoration

Graham “The Neuron” Spencer built a Triggers & Events system into JotSpot that allows developers to (what else), trigger events in the system based on the events on a page. So, for example, if in a JotSpot application (such as the trouble ticket application), you move the status of a ticket from open to closed, you can trigger a whole host of events, from the sending of alert emails to the modification of other, related, pages. It’s not released yet, but when it is, it will add a whole new capability to those who are building JotSpot applications.

Graham also added general SVG rendering to JotSpot. Any wiki page whose XML content is an SVG file will now get converted to PNG or JPEG and sent to the client as an image. You can refer to resources in the wiki (like other JPEGs) by using the same wiki: protocol that you use in other pages. Why is this cool? Because it lets you use server-side Javascript and XML inside the wiki to generate whatever images you want. For example, it’s just 3 lines of text in JotSpot to make a thumbnail from an image:

<svg width="4cm” height="4cm” version="1.1″ xmlns="http://www.w3.org/2000/svg” xmlns:xlink="http://www.w3.org/1999/xlink">
   <image x="0cm” y="0cm” width="4cm” height="4cm” xlink:href="wiki:${req/args/image}” />
</svg>

Of course you can use all of the SVG filter effects and drawing tools. A few more lines of code adds a nice rounded border to your thumbnail image:

You can also use it to do Link Decoration.

You’ll be able to install a server-side Javascript function that gets called for each link displayed on the page. There are all sorts of uses for this. For example, it’s a general way to handle the strikethrough effect you see in bug trackers – you can use a property of the page to apply an arbitrary CSS style, like this:

You can change the color of the link based on how recent the last revision was:

This last example combines the SVG rendering from above with link decoration to produce sparklines. There’s a server-side Javascript program (stored in the wiki as an ordinary page) that creates a graph of recent edits to a wiki page. The X-axis is how old the edit was, the height of the bar on the Y-axis is how many characters were changed, and it’s green or red depending on whether characters were added or deleted. Then a link decorator (again implemented in server-side Javascript as a regular wiki page) is used to prepend the sparkline in front of each wiki link:

Here’s a closeup of the sparkline image:

Conclusions

All that in one day.

So what did we learn? We learned that if you give creative people the time and the ability to focus, amazing things can happen. We also learned that a single day-long event is a great format for this. In fact, we thought it worked so well that we’re going to do it again. Next time (end of May) we want to extend the concept to involve members of the JotSpot community to play along in the “home game” version. If you’re interested, drop a line to Scott McMullan (scott at jot dot com).

Last, but not least, is my favorite line of the night. Reuben “Steel Trap” Antman, was so excited by all the new stuff that he blurted “Dude, I just want to crawl into my hole [his cube], grow a beard, and build shit!”.

I couldn’t have put it any better myself.

A side effect of working feverishly on your product in a heads-down manner is that you forget to step back now and then and show your users some of the cool things you’ve been working on.

That said, we’re making a concerted effort to talk more about the features that might interest you, and we’re starting with the Import Word Document feature implemented by JotSpot team member Michael Nestler.

Purpose:
Import a Microsoft Word document as an editable page in your JotSpot wiki.

What this means to you:
If you’re at all like me (I realize that’s a big IF), you get tired of both sending and receiving Word files as attachments in emails. Sometimes you send one to somebody to get their feedback (and vice versa). Sometimes it’s purely for informational purposes (e.g. take a look at these new stats, this new product spec, or what have you). In either case, we think it’s not very efficient to be emailing this document around and possibly dealing with the headache of reconciling the differences caused by people modifying their versions of the document and sending it back to you. Instead, wouldn’t it be nice if you could import the Word document into a central place, and invite co-workers to come and make changes to it or just have them contribute some comments?

Benefits:

• Stop receiving and sending potentially virus-ridden Word documents.
• Cut down on “versionitis” caused by multiple people changing their copies of the document, and then having to fold all their changes back into one “master” document.
• Once imported, all of the fundamental features of JotSpot can be applied to the page:  editing, adding comments, emailing it to others, attaching files, user groups and permissions for access control, and more.
• It will make all your problems go away. And it’ll end world hunger. Ok, this bullet point is a total lie. But the first three are absolutely true, and 3 out of 4 ain’t bad.

Here is the process, step by step, with screenshots.

First, find a Word document you want to import. Here’s mine:

In your JotSpot account, create a new page with little or no content in it, and save it. When you’re finished, this is the page that will contain the content of your Word document. I gave my page the very creative title of “MyPage", as you can see below.

Now that you’re on your new page, choose Import Word Document from your More Actions menu:

Next, you see a page asking you for the file you wish to import. Hit the Browse… button and locate the Word document on your hard drive. Once you’ve selected the Word document you want to use, simply hit the Import document button:

After the uploading/importing of the document is complete, you’ll be back on your original JotSpot page with the content of the Word document appearing right on the page:

Now here’s the fun part. Click the Edit button (make sure to choose “WYSIWYG” mode if you’re prompted, but your preference is probably already set to that if you’ve never changed it), and you are now editing what used to be your Word document right in your JotSpot page.

My own Word document happened to have a table in it, so now I can edit the table and change the values in the cells to my heart’s content, as you can see in the screenshot below.

Now that you’ve imported your Word document and basically turned it into a regular page in your JotSpot wiki, you can also add comments to the page just like you do with any other page:

Everthing except the comment in the screenshot below was purposely dimmed to draw your attention to the comment towards the bottom of it:

Important things to know, and caveats:

The Word document you are importing is first getting converted into HTML before it ends up as a JotSpot page. I’m telling you this for a couple of reasons:

1. Conversion from Microsoft Word format to HTML isn’t perfect. You will notice differences in layout/formatting after you import your Word document. Usually they are relatively minor differences, but if you have a particularly complex Word document your mileage may vary.
2. When you edit the page after you’ve imported your Word document, you are now using JotSpot’s WYSIWYG editor to edit the page in HTML format. The page is no longer in Word format, and the Microsoft Word application is no longer part of the picture.

Also, right now we have a bug where you can only import a Word document into a page that your user has created. If a user other than you created the page and you try to import a Word doc into it, you’ll get an error.

We’re interested to hear your experiences with this feature, so try it out and drop us a line.

About a month ago we were talking to Chris and Tim over at Rojo about their company web site. This was a couple of weeks before their recent public launch (congrats!), and they were interested in using JotSpot for www.rojonetworks.com. They were on a very tight schedule and had a bunch of requirements that related to running a public-facing company site. But they also wanted the power of easy updates a wiki provides. Did we have the right stuff and were we ready?

Hmmmm… thinking… Sure! we said. We had recently refined our CSS theming capabilities (e.g. see codebook.jot.com), had a fresh release online, and it seemed like a great fit. This may sound obvious to you, but running a company web site on a wiki seemed a bit novel and fresh to me. Here at Jot we live and breathe intranets, extranets, collaboration, and Wikipedia-style communities. But not so much good ol’ company web sites.

The result? Judge for yourself. We’re thrilled with what they came up with! And they’re really happy with it too. We appreciate their vote of confidence in selecting us on a tight deadline, particularly while we are still in beta. Their feedback has been extremely helpful, and we’re working on some direct enhancements. Everyone will be able to make this level of customization in the upcoming release.

We look forward to powering more good ol’ fashioned web sites – the power of the writable web won’t be boxed in!