Stikis

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!

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.

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.

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.
Here are screen-shots of the reports:

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.

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.

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.

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.

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.

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:

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!

I’ll be pushing an update within the next hour (before 20:00 GMT) that will allow you to rename stiki pages. The update is quite small, so I don’t anticipate any down-time. I’ll post an update once the update is live.

Update: the update went off without a hitch and is now live. If you go to your list of pages, stikis.com/pages, you should see a link labelled ‘rename’ to the right of each page. Clicking this link will take you to a form where you can type a new title for the page.

More information is available from the following help topics:

• Pages/index
• Pages/edit

When I think of stikis, I think of little squares that you can move around and type into and being able to zoom around the page. Writing the code to do these things was lot of work, but I’m beginning to appreciate that it’s only a small proportion of the total amount of work required to keep a site like this running. There are lots of other less glamorous things, such as writing help pages, making sure software is kept up to date, deleting spam comments from the wiki, responding to emails, and writing blog posts. In this way, stikis is sort of like an iceberg. There’s the small visible part out the top and the big hidden part beneath.

Models of the software development process often focus on the steps involved and how they relate to one another in a sequence. For example, the famous waterfall model represents software design as happening in stages from requirements gathering, to specification, to implementation, testing, integration and maintenance. Another well known model, the spiral model, while more sophisticated (giving more attention to iterative aspects of software development) is still constructed around the idea of stages and progression.

Models like this are especially useful as resources for project management and planning because they highlight dependencies between stages thereby allowing project managers to assign and coordinate organisational responsibilities. However, in a single developer project - like stikis - these organisational aspects are less important. What instead becomes difficult is maintaining a balance between all the different tasks that are required. This is especially so in a web-application context, where development, testing, maintenance and support are running alongside an already deployed application. In this case, I think it might be more useful to think of software development as being like an iceberg, rather than a waterfall or spiral.

The thing about icebergs is that they need to maintain a balance between the small visible part and the larger hidden part. If they don’t then the iceberg’s going to tip over (and the penguins won’t be happy). This is where thinking about your development work as an iceberg gets useful. The fun parts above the water are always calling for your attention, but if you spend all your time working there, you’ll eventually end up with help pages that are out of date, tests that don’t test the right things and spam-filled forums.

I’m not sure of the exact numbers, but if we assume that 86% of the average iceberg is beneath the water and 14% above - then that means for every hour you spend working on new features, you need to spend 6 working on the other stuff. Conveniently for the single developer, this means that you can plan your week of spare-time-development something like:

• mon: interaction design
• tue: write tests (software design)
• wed: develop
• thu: documentation
• fri: blog
• sat: deploy
• sun: server maintenance & review usage

…or some other order - provided enough time is spent on each of the activities. (Support emails should be answered as soon as possible.)

Does this seem sane?

I’ll be taking the site off-line later tonight to push an update. Hopefully the maintenance won’t take longer than half an hour.

Update: I’ve completed the maintenance and the site is back up. It took a lot longer than I anticipated - three hours instead of half an hour. Apologies for any inconvenience. I’ll write about the update some more later this week.

Phew, that was good to write as a headline. Actually, IE6 support turned out to be much simpler than I anticipated. It mostly hinged on two things - my use of fixed positioning, and png graphics. Thankfully there are fairly simple fixes for these obstacles that allowed me to get IE6 working with stikis from just a couple of hours work.

For fixed positioning, I used conditional comments to insert a IE6 stylesheet and used absolute positioning instead (along with html, body {height: 100%} ). For png graphics, I used a combination of substituting gifs where I could (all the icons) and using some javascript to fix the shadows of the stikis.

There still seem to be some glitches - for instance, when resizing stikis, there’s a noticable lag as the contents have their size updated to match. Also, the expander buttons don’t seem to work properly.
However, as the headline says - IE6 support is *preliminary*. This means that it should work, but please, please tell me if it doesn’t.

Cheers, Jared.