Posts about: Stikis

Big update to stikis

Friday, January 4th, 2013

Today I made a quite big update to It’s been a long time since I’ve made any changes to the live site, so this one is well overdue.

New version of stikis uploaded


It’s pretty much a complete overhaul of the interface, but hopefully it’s not too confusing. Check the help pages if you have problems.

I’d love to hear your thoughts on the update, so leave a comment below or email me with your feedback.

Cursors are a hassle

Tuesday, March 17th, 2009
Cursors as displayed by different browsers

Cursors as displayed by different browsers

(I actually made this post and the update it talks about quite a while ago, but did not get around to publishing it until now).

Today a minor update to stikis so that mouse cursors are a bit more logical. I say a bit more logical, because, as you can see from the picture above, the way different browsers render the same cursors varies a lot. The strangest one to me is the different between how Firefox renders the ‘move’ cursor compared to IE and Safari. On Firefox, this is an open hand, actually identical to the ‘-moz-grab’ cursor, whereas on IE and Safari it is a left-right-up-down arrow. Another strange one is the ‘se-resize’ cursor, which Firefox and Safari both render as an arrow pointing down and to the right, but IE renders as a double-headed arrow. This actually looks quite similar to the way Firefox and Safari render the ‘nwse-resize’ cursor, but unfortunately IE doesn’t recognise this. Oh well.

There are actually lots of different cursor styles that you can apply with CSS. As usual, PPK has a good reference for support of cursor styles across different browsers. However, his table doesn’t show what these different cursors actually look like, even if they are supported. As the picture shows, there’s a lot of variation in this.

One tricky thing I encountered was that it’s not easy to take a screen-shot that includes the cursor. The solution I found was to use the osx ‘screencapture’ command line utility. The command I used was:

screencapture -m -C -T5 ie_2.png

(Command – Shift – 4) + Alt & Shift to constrain the selection. Space to take the whole window

Oh and also thanks to stikis user [Blake] for pointing out that the Chrome browser works with stikis (hmmm, perhaps that should be ‘stikis works with the Chrome browser’ – I don’t want to sound like the whole internet revolves around stikis :) ). I’ve tried it myself and everything does seem to work, but if you’re a Chrome user and you find a bug, please let me know.

Better Z-Index & Marquee Selection

Saturday, January 24th, 2009

I’ve just pushed an update to that allows marquee selection to work on Safari as well as making it more reliable on Firefox and Internet Explorer. The update also does a better job of keeping track of the front to back ordering of stikis, and fixes a number of small bugs. With this update, the site is almost fully working on Safari. The only big problem left to tackle is bold and italic formatting, which is currently broken.

As always, when addressing browser compatibility, I made some surprising discoveries about the ways that different browsers work. Here, for example are the keyCodes reported by Safari, Firefox, and Opera for the left and right apple keys.

Browser Left Apple Key Right Apple Key
Firefox 3 224 224
Safari 3 91 93
Opera 17 17

…why, why, why?

The indomitable ppk has a fairly good reference, but I’m not sure how much of his sanity he was willing to risk for a really thorough investigation. His tables don’t point out that Safari reports a different keyCode for the left and the right keys.

Show Rails TestResponse In Safari

Wednesday, January 7th, 2009


I use a test-driven development approach to developing my web-application, stikis. As I add new features to the site, I write tests to ensure that the new code does what I intend it to do and does not break existing code. This approach to development is very well supported by the rails framework, and test-driven development is a great way to work, but testing is still difficult. When tests fail, it can be hard to understand why. Sometimes your brain hurts.

Here’s a little thing I did to make one aspect of failing tests easier to understand.

Typically, if I can’t immediately determine the cause of the error from the output of the functional test, I will set a breakpoint in the test with the debugger command and then run the test again so I can interact with the code where the test is failing. It’s particularly useful in this situation to be able to look at the TestResponse (@response) object, which includes a ‘body’ property that holds the text of the response. Typically this is the html code that would be rendered by a browser.

Although it’s really great to be able to read the contents of the response body, I’ve often found myself wanting to be able to see the response as it would display in the browser, rather than having to read and interpret html, which is what you get on the command line. Compare the top and bottom parts of the picture above so see what I mean (admittedly, the top picture would look a lot nicer if I used puts to print it).

To address this, I added a method to the @response object that does the following:

  1. Converts the response body to base 64 using the Base64 module from the ruby standard library.
  2. Format a data: URI for it using the response header mime-type and charset.
  3. Open Safari with the data URI as the location using the ‘rb-appscript‘ gem.

Putting it all together

I first installed the rb-appscript gem…

$ sudo install gem rb-appscript

And then added the following code to my test_helper.rb file.

[sourcecode language="ruby"]
require 'appscript'

class ActionController::TestResponse

  def show_in_safari()
    type = self.headers['type']
    body = Base64.encode64(self.body)
    dataURI = "data:#{type};base64,#{body}"

    sa = Appscript::app("Safari")
    sa.document.end.make(:new => :document,
      :with_properties => {:URL => dataURI}


With the gem installed and the extra method included in the TestResponse object, you can type the following at a breakpoint to open the response body in Safari (assuming your breakpoint is set in the body of the test case itself).

(rdb:1) @response.show_in_safari


There are some limitations to this:

  • It’s Mac only and browser specific (but a similar approach would work for other platforms/browsers).
  • If Safari isn’t already running, it will open an extra window with your homepage.
  • It doesn’t give focus to the new browser window. You have to switch windows manually.
  • It’s fiddling around with the TestResponse class directly, which is probably poor form.
  • Linked resources such as images, javascripts and stylesheets won’t be included.
  • Relative links won’t work (but absolute ones should still be fine).

Welcome Firefox 3 (and Safari 3)

Sunday, June 22nd, 2008

Welcome Safari 3 and Firefox 3

Last week saw the release of Firefox 3 onto the web. So on ‘download day’, I joined the thronging millions to grab my very own copy. Now which site do you think I was first to visit with my prize? Stikis of course!

I excitedly typed in the address, logged in and arrived back at my last stikis page. Then… (cue sound-effect of nuclear reactors powering down)…nothing. Aargh, a compatibility bug in the script that hooks up the color patches. It meant that nothing on the page worked.

I know I should have downloaded the beta and tested it with stikis before the release date, but…well there was that pesky thesis to get out of the way :) and you’d expect Firefox 3 to work with stikis if Firefox 2 does…right? Wrong.

However, the bugs were fairly minor and yesterday I was able to make an update to the site that fixes them. An upshot of this was that Stikis now also plays nicely with Safari 3.

If either of these is your browser of choice, Welcome to Stikis!

Update to zooming

Sunday, June 8th, 2008

Today, I’d like to announce the first update to stikis since submitting my PhD thesis (woohoo!). That news probably deserves a blog-post of its own, so straight to the business at hand.

I have tweaked the zoom levels a little. Previously, pages would zoom to 8%, 16%, 32%, 64%, 100%, and 160%. There were a couple of problems with this.

  • There were more settings than needed. It only really needs three settings, one for focusing on a single stiki, one for arranging several stikis, and one for getting a big overview.
  • It felt slow to zoom out or in, because you needed to zoom through several presets.
  • Text was unreadable at 64% or less, so the majority of settings weren’t much use.
  • The numbers are a little difficult to remember (unless you’re into powers of two).

So the new zoom levels are (drum-roll please) 20%, 100%, and 200%. They don’t correspond directly to the old zoom scales because I moved the underlying zoom level up a bit. 100% is actually the same as 70% before.

That probably all sounds pretty confusing. Hopefully, most people won’t need to notice or worry about it.

OpenID plugin update mishap.

Thursday, February 14th, 2008

Yesterday my hosting company upgraded the software library that I use to allow OpenID logins to stikis. Unfortunately, this new version was not compatible with the version I have been using previously. This resulted in errors for users trying to log in using OpenID identities.

To fix the problem, I have ‘frozen’ the library I use to the last compatible version.

Apologies to any users who were affected by this.

My YSlow Shame

Wednesday, August 29th, 2007

There’s a little tool I read about recently called YSlow which analyzes the way your web-page loads and gives you a score along with simple tips for how to improve. It’s a plug-in for Firefox integrated with the fabulous Firebug extension.

I downloaded it tonight and ran it on Stikis. Stikis got an F. I feel a bit embarassed by that.

I guess the good news is that the tips listed are all pretty straight-forward to implement. I wonder how much of an impact they will have on the performance? To have a point of comparison, we can look at Firebug’s ‘Net’ report. It tells me that the version of Stikis I have running on my development machine takes about 2.5 seconds to load. I’ll report back as I implement the tips and we can see how much of a difference they make.

August 26th Update

Sunday, August 26th, 2007

Tonight I’ll push a couple of minor fixes to the current version of the site. I’ll kick the update off at 20:30 CEST and it shouldn’t take more than an hour.

Update: I’ve pushed the updates, but the web-server doesn’t seem to be doing too well. I’ll check back in the morning and if it’s still not working I’ll roll back to the previous version and try again next weekend.

Simple text formatting.

Editing buttons.

When you edit a stiki, you should now see buttons at the top of the edit pane to make text bold and italic. This works in Firefox, IE7 and IE6. However, unfortunately the tags that these browsers use to make the text bold or italic are different. This means that if you make something bold in Firefox, then open the same page in IE, you won’t be able to un-bold the text. I figure this is an acceptable deficiency for now, given the usefulness of the feature.

Remember z-index.

Order of stikis.

One of the most glaring omissions on the site has been that when you click on stikis, you can move them over the top of each other, but this doesn’t get saved. So sometimes when you reload a page, you might notice that a stiki which you had put in front jumps back behind. This is now fixed.

Improved IE6 compatibility.

In a previous post, I enthusiastically announced preliminary IE6 support, but this might have been a bit premature, since although you could move, resize, color and edit stikis, you couldn’t actually create new ones. I’ve fixed the problem that prevented this, so now you can create stikis too. I also fixed a bug where resized stikis wouldn’t be re-drawn properly.

ie6 opaque halo.

Unfortunately, the problem that prevented stikis from being created was in the code that sets up the halo for the new stiki. Since this doesn’t work in IE6, the halos of new stikis will be opaque until you refresh the page, as you can see in the screen-grab above.

Multiple selection.

marquee select

For a while now, a feature of stikis has been that you can hold down the CTL key, click and drag to draw a square for selecting multiple stikis. Unfortunately this didn’t work very well for Macintosh users, because clicking while pressing the CTL key gets interpreted as a right-click and displays a contextual menu. In a previous update, I changed it to use the ‘Apple’ key instead, but (you guessed it) this broke the windows version.

I’ve now fixed it so the following key combinations work:

Browser Marquee – select Click – select
Firefox (osx) Apple-key + click & drag Apple-key + click
Firefox (Win) CTL + click & drag CTL + click
IE7 / IE6 CTL + click & drag CTL + click

New job, new continent, new rails version.

Monday, May 21st, 2007

It’s been a busy few months for me. In January, I left Australia to come to Denmark to take up a job at the University of Southern Denmark. I’m living in a place called S√łnderborg in the south of Denmark, near the German border. It’s a remarkably beautiful area, with sea close by, a lovely forest, and fields of wheat. The job is exciting and stimulating and I get to work with wonderful colleagues.

At about the time that I left Australia, Rails 1.2.1 was released. While not quite as significant for me as moving to another continent, this new version of Rails did have some nice features. In particular, support for REST-style web services is built right in to the framework. Although this was great, nice and wonderful all at once, it also meant a lot of work for me, because I’d previously been using a plug-in to provide this support and that plug-in wasn’t really compatible with the new way of doing things. I ended up having to rewrite entire parts of the application in order to upgrade.

It took a long time, but this week, I finally was able to put my changes up and upgrade to the newest version of rails. My aim with this update was simply to replicate the code that was already there, so there weren’t many new features in it. However, there were a couple of small things that I think are worth mentioning.

  • Contextual help: When you click on the help link from any stikis page, you get taken to a help topic for that page. Also, in general the help pages are much more up to date than they were.
  • Marquee select for OSX: On a Macintosh, the CTL+click combination triggers a contextual menu in Firefox. Unfortunately, I was using this same combination to start a marquee select in stikis so things got pretty messed up. I added code to respond to the Apple key instead.

Next week:

From now on, I hope to keep much shorter development cycles. I plan to make an update at least once a week (see the ‘Iceberg model’ article from a couple of days ago). In fact, I’ve already been able to push another update which allows you to rename your pages. In the coming week, I plan to work on the Edit Pane and make it so you can add some simple formatting to stiki text. Being able to make text in stikis bold is one of the most requested features and I’ve been itching to get stuck into it for a long time, so it should be fun.

Update: I already got something working in Firefox. Shorter development cycles here we come!

Screen-grab of stiki showing bold and italic formatting.