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.

If you have an OpenID, it’s the most convenient way to access stikis. This is the first of three articles about my experiences of providing openid logins on stikis. In this post, I’ll try to explain what OpenID is in simple terms (and highlight the new affiliate signup feature on the stikis login and signup pages). I won’t be going into too much technical depth, but hopefully, if you’re not familiar with OpenID yet you’ll have a better idea of what it is by the end of the article (for another great introduction to OpenID, see this screencast by Simon Willison).

In the next post, I plan to discuss some of the early usability lessons I’ve learnt for providing OpenID logins, and highlight of the salient issues you might want to consider when providing OpenID on your own site. In the final part, I’ll show how I test the parts of stikis that use OpenID using the ruby mocha gem.

OpenID is a better way to prove who you are.

If you don’t have an OpenID, you’re probably wondering what I’m talking about. One way I could describe it is as a new way to log in to websites. The most common way of allowing logins to a website now is to ask people to enter a username and password to prove who they are. There are lots of problems with this. It means you have to remember lots of passwords, you have to trust every site you log into to keep your password secure and you have to update your personal information in lots of places if it changes.

What if, instead of needing a separate username and password for each website you visited, you could just tell the website to go and check an address that you own to verify that you are who you say you are? That’s how OpenID works. Here’s a really simple cartoon that shows the process of an OpenID login.

The key part of this process is that there is a place on the web that you can point to which will be able to verify you are who you say you are (Fred’s ‘friend’ in the cartoon above). In fact, OpenIDs look just like regular web addresses. For example, here’s one of mine…

http://jared.donovan.myopenid.com

If you click on it, you’ll be taken to a webpage that looks like this…

Getting an OpenID

This brings us to the next question - how do you get hold of an OpenID address that you can own and that can verify you? There are a couple of different options

• Set up your own OpenID server on a website that you control. There are several free OpenID libraries you can use to help you with this. Stikis uses ruby-openid, written by Brian Ellin.
• Get an OpenID account from any of several free services that are available. In the example above, you can see that I’ve got an account with MyOpenID.com, some others are pip.verisignlabs.com and GetOpenID.com, there are many others to choose from too.
• Add a link to a web-page that you own that will delegate the openid authentication process to another server. This is much simpler than it sounds, it’s actually sort of a combination of the first two options.
• Finally, you may find that you already have an OpenID without even knowing it. If you’ve got a LiveJournal account, your OpenID will be fred.livejournal.com (substituting your own login for ‘fred’).

Another way you can get an OpenID is through the affiliate sign up link that’s provided on the stikis welcome, login and signup pages. Beneath the openid login form, there’s a grey box that looks like this…

If you follow the ‘click here’ link you’ll be taken off to a MyOpenID signup page which is customised for stikis users. Once you’ve finished the MyOpenID signup process, you’ll be sent back to stikis and logged in automatically. It’s painless.

This magic is all courtesy of the MyOpenID affiliate programme. If you’re running a site and you’d like to make it easy the people who visit your site to get an OpenID, I’d suggest giving it a try. It’s really easy to set up, and the staff at MyOpenID are really great to work with…but I’ll talk more about that in the next post.

The changes to the way zooming works that I wrote about in my last post are now integrated into the live site, so please give zooming a try and let me know what you think.

Also included in this update:

• Now you’re taken back to the last page you were working on, rather than the list of pages.
• A bugfix for IE where in the list of pages, the list was not showing up. D’oh! This should be fixed now.

Also, stikis user dantaeus left a comment on the previous post asking if I have plans for an api for the service. The answer is yes, and to start the ball rolling, I’ve created a discussion page on the stikis help wiki as well as a mailing list. If you’re interested in coding against an api for stikis I’d love to hear your thoughts on what would be useful.

Stikis user benmcg has written a thoughtful post in the stikis forum (the forum requires a separate login at this stage) suggesting a better way for the zooming to work in stikis. In the post, he points out that because the page is centered on the spot where you zoomed, you can’t leave your mouse still and keep zooming in on the same point. The following diagram shows what happens

You can see here how if the user leaves their mouse in the same position, each time they scroll, the original spot they scrolled over gets moved further away. Benmcg points to the way scroll-zooming works in computer aided design (CAD) software for a better alternative. In the software that benmcg uses, the screen isn’t centered on the position where the user zoomed. The drawing is just zoomed around that spot. Again, a diagram helps to illustrate.

Benmcg also sent a ’screencast’ (3Mb) of him zooming around in his CAD program, this also gives a fairly good idea of how it works.

After reading benmcg’s post and watching the movie he sent, I thought he had a valid point and that zooming in stikis would be better if it worked in the way that he described. So far, I’ve only made a first-cut at it but already the difference is striking. Now that I go back to the existing stikis interface, I feel like it’s pushing me around and telling me where to look.

I’ve checked back with how web-based mapping software (my point of reference for ui conventions) handles zooming and found that Google Maps works in the way that benmcg describes, while Yahoo Maps and Microsoft Live maps just zoom from the center of the screen without panning the map.

So why didn’t I do it like this in the first place? One reason, was it’s simpler to program if the zoom origin remains at the center of the screen, so to zoom in on a particular spot I chose to move the spot to the origin. I also thought (or told myself) that centering on the position that the user scrolled would be bringing their point of attention into the center and that this would be a good thing. I guess sometimes you can’t know how something should work until someone steps up and tells you how to change it.

Because I’ve only made a first-cut at these changes, they aren’t ready for the live site yet. I hope to have the changes tested and ready to deploy some time later in the week and I’ll post an article here when they’re up. In the mean-time, if there’s something about the interface that’s pushing you around, please let me know.

Up, Down, In, Out

A related point, (I’m not sure if benmcg metions this in his forum post) is that the conventions for whether scrolling up should zoom in or out vary from program to program. In stikis, I’ve followed the convention of web-based mapping sofware (which seems like the most related kind of application). But as you can see from the table below, there’s a lot of variation in how different programs interpret this.

To me, the most puzzling of these variations is between how browsers use Ctl+scroll-up to decrease the font-size and web-based mapping software uses it to zoom in. If web-based mapping software achieves zooming by dimensioning in ems (that’s how sitikis does it), then you’d think that falling in behind the existing browser usage would make sense. In an ems dimensioned application, increasing font-size and zooming in are the same thing.

If you know of other software that allows for scroll zooming, please use the comments to let me know what mapping it uses.

Stikis is built using the ruby-on-rails framework. The thing I love about this framework is when you think - “hmm, I wonder how you do that…I’ll give this a go” and it just works. Of course it doesn’t always happen like this - here’s an example for posterity.

I was writing a test that depended on the created_at and updated_at attributes of a record. In my fixture I wrote something like:

first:

id: 1

created_at: <%= 10.minutes.ago %>

updated_at: <%= 5.minutes.ago %>

When I ran the tests they failed and it seemed like the reason was that the created_at and updated_at fields were nil. I searched the interweb and found that the problem was I needed to do a bit more work to format the times for the database. Like so:

first:

id: 1

created_at: <%= 10.minutes.ago.to_s :db %>

updated_at: <%= 5.minutes.ago.to_s :db %>

The tests still don’t pass - but now it’s because of bugs in my code rather than my fixtures. A much better place to start from :).

While I was I writing this post, the list of people that are signed up to stikis has gone from being mostly people I know, to mostly people I don’t know. That’s kind of a weird feeling. It’s mainly thanks to myopenid.com, who listed stikis on their directory last week.

Getting people coming to the site from the wild meant that the old sign in page (three bare forms with no explanatory text) was totally inadequate. So after months of embarassment every time I log in to stikis.com, I’ve finally gotten to the task of creating a proper landing page for the site. As usual, the landing page is just a step in the right direction rather than a fait accompli. But I think it has some nice features all the same. Here’s a screenshot.

The main gimmick of the landing page is that it’s got some stikis at the top that describe what the site is. You can click on these, move them, and resize them. Below them, I’ve rearranged the login and sign-up forms into a two-column layout.

It’s obviously a risk putting all that javascript up-front on the landing page. It increases the load time and there’s the risk that an error will render the page unusable. However, if it works, I think it’s a very effective way of communicating not just the features of the site, but also something of the quality of the interaction (and whether it will work on their browser).

There’s also something about playing with those little blurbs that helps cut through the cheesiness of them. If I were to read “Space for your ideas” on a website I’d think “gimme a break” but when you start playing around with them hopefully you can kind of see what that cheesy marketing speak is trying to say.

Another change which is fairly minor is the addition of a footer with the following request; “Please tell me how to make stikis better.” I’m really hoping I’ll get some feedback from users as a result of this and I think it’s important to let people see who I am and understand that the site is a one-person project.

Quite a big update to the user interface yesterday, which changes the way the interface works a bit. There are four new features:

Zoom

You could zoom the page in the previous version of the site, but only using the buttons at the top of the page, (below).

Those buttons are still there, but now you can also zoom using the scrollwheel of your mouse. It’s similar to the way zooming is done in map sites (eg. Google maps) so hopefully at least some users will be familiar with it. The way it works is when your mouse is over the page, you scroll up or down and the page zooms in and out on that spot. A target will appear to show where you are zooming to. The image below shows the target on a page that is in the process of zooming.

I’ve also added some constraints on how far you can zoom. Previously, you could just keep zooming further and further out or in, which was kind of pointess and lead to people not knowing where they were any more. Now you can zoom out to 8% and in to 160%, as the following two images show.

Hijacking the scrollwheel is not something I’d do lightly. However, I feel there are valid reasons for doing so in this case. First, there’s an established use of this in map software which some users will be familiar with. Second, the previous method of zooming by clicking buttons was tedious and didn’t give you controll over where you zoomed in on. Third, the traditional use of a scrollwheel in a webpage is to scroll down the lines of a vertical document. In this case, the document stretches in both vertical and horizontal dimensions, and moving horizontally required the user to use the scrollbar, or use the scroll-pan (is that what it’s called?) function. Neither of these were very satisfying.

There are still some improvements I’d like to make to the scroll-zooming. A big one is letting you zoom more by scrolling more. At the moment you have to scroll, then zoom a bit, then scroll again, then zoom some more. It frustrating to zoom more than two steps.

Pan

Okay, so I hijacked the scrollwheel. Even though there were some good reasons for that, I needed to give people another way to move around the page. The solution I’ve added in this release is to allow panning by clicking and dragging on the background of the page. Like the scroll-zoom feature, this is in common use on map sites and it’s also well established in graphics programs (such as photoshop) and the Adobe reader software.

After poking around a bit, I found that the CSS3 proposal includes cursors ‘grab’ and ‘grabbing’ (below) which are a nice fit with the established use. The idea is that you use the ‘grab’ cursor to indicate that something can be moved, and then the ‘grabbing’ cursor to indicate that the user ‘has a hold’ of it and can move it around.

Fortunately, Firefox (one of my target browsers) supports these cursors through the -moz-grab and -moz-grabbing declarations. Unfortunately, IE7 (my other target browser) does not. Fortunately, it’s possible to specify a custom image to use at the cursor using the following markup.

#target {cursor: url(/path/to/grab.cur), default;}
#target:active {cursor: url(/path/to/grabbing.cur), default;}

When the target element is active, the cursor should be changed from ‘grab’ to ‘grabbing’. This works for me on Firefox, but I couldn’t get it to work in IE7, so in that browser, the user only ever sees the grab cursor.

Another point to mention with this is that the files need to be in *.cur format. From what I can gather, this is similar to the *.ico format which is used for icons. I used a freeware program to turn the example gifs on the Mozilla website into the cur format.

Select

It’s been possible to select multiple stikis for a while now by holding down the control key and clicking on them. This worked fine if you only needed to select two or three stikis, but it was very tedious for large numbers of stikis. For a long time, I’ve had plans to implement a select box function, similar to what’s used in graphics programs.

The usage is fairly straight-forward, you hold down the control key and click and drag with the mouse to draw a select box. Any stikis that overlap with the box will be added to the selection.

Chuck

With the ‘chuck’ function you can select a stiki (or stikis) press Control+Shift and an arrow key and the stiki will be swooshed off to the edge of the page in the direction you specified.

This function grew out of my experience of using the stikis as reminders of things I need to do. I found it convenient to move the stiki off the side of the page once I had completed the task, but it was a pain to have to zoom out and move it to the edge using the mouse. I just wanted a quick way to ‘chuck’ it. And so another keyboard shortcut was born.

Summing up

My aim with stikis is to have an experience where you can move around and zoom in and out without feeling like it’s a chore. If you want to get an overview, you should be able to skip right out and see the big picture. If you want to narrow in on a single thought that should be easy too. The interface still isn’t at the level I want it to be, but I think these additions are a step in the right direction. If you’ve used the previous version, I’d love to hear your reactions to the changes. If you’re a new user, let me know what you think.

I’ve installed a forum to serve as a discussion area for the project. The URL is:
forum.stikis.com

The forum runs on phpBB. I’ve not had much experience using this forum software, I just chose it because it’s available as a one-click install on my ISP.
In the end, it’d be nice to be able to use stikis.com itself for this kind of thing. But until I’ve implemented multiuser pages it’s not possible. Besides, for something like a forum: where users might be going to find help about how to use the system, it’s probably not a good idea to force them to use the system itself.

I’ll look at updating the look of the forum (along with the help wiki, and this blog) to give a more consistent presentation.