Older blog entries for salmoni (starting at number 480)

I'm proud to announce that I'm an uncle again! Baby Dymond was born yesterday around 5.00am, and he and mother are both doing well!

In other news, I'm considering using the wiki concept to generate expert knowledge bases within specific domains. I'm curious as to whether the wiki concept will work if sufficient constraints are placed upon publishing.

Like all things, I guess that there is an optimal compromise between freedom and constraint that will produce the best documentation. There's a study in this: if anyone knows of any work done like this already, I'd be greatful to hear about it. NB - non-blind opinions by encyclopaedia editors won't suffice: I need opinions based on blind assessment by domain experts.

Not much happening lately in life because I've been busy researching at work and on Project Omega.

Omega's turning out very well indeed and should be useful for its intended purpose. Problem is that all this coding takes vast amounts of time so I hardly have a spare few minutes to post here ("phew! That's a relief", I hear you think).

Also got soaked today walking from home. The heavens opened and I didn't bring my brolly. Soaked at cold which is not nice. I would have preferred the weather to have been much colder and had snow. I would have been drier and probably warmer too (i.e., not chilled through being wet through).

Wikiversity

For all those working on the Wikiversity (mirwin?) I've come across a grant proposal offering money for work into reusable learning objects - which seems precisely what Wikiversity is about. Allows both proprietary and open regimes, and the cash is £30k-£100k.

Details on this link at EduSrv.

Deadline is 12th December - sorry about the short notice, but I've only just heard.

AlanHorkan - perhaps if overwrite mode is enabled, the cursor could change into a nice yellow pacman chomping its way through the oncoming letters? Only joking - animation might be too distracting, although a static one might give the idea without as much demanding visual attention.

Oh, and copyright issues...

apenwarr heh, I know what you mean about business-speak; although I thought that "challenges" were now "opportunities" (or, for the verbose, "opportunities for betterment / improvement").

They used to be setbacks, then minor setbacks, and then issues before being challenges. Let's start a meme. What will the next step be in business-speak (ie, "let's ride the memic wave of opportunity"!):

Problems will be "completion-adjustments". This will be dropped quickly because it doesn't communicate enough of the go-getting that ambitious business types need to believe are in their nature. "Adjustments" is beginning to sound of things like redundancies, but completion is a power word so that's good. However, "completion-adjustments" is hyphenated which is, by definition, clever, so it's not a dead loss.

So, following from the action aspect, perhaps instead: "solution duelling"; or resolute: "dilemma resolving"; or psychological: "stimulation response". Perhaps "denouement questing" might convey enough of the action-man without too much agressiveness? (and sound kind-of clever 'cause it uses rare words?)

Eventually we'll be up to "reality defiance". Maybe the irony will hit home then and we'll be able to understand them? ;^)

Aren't unit tests fun in Python? I've been stuck doing a bunch of them lately, and I quite like the way that no extraneous code is left in the working modules themselves. Basic stuff, but it's nice to present a finished application in a nice bundle with a separate bunch of unit tests to be examined by anyone.

The problem I have is making sure I don't put too many tests into a single testing module. Best to keep things nice and manageable.

I also need to go through my code with PyChecker and remove any unwanted variables that snuck in through the back door. That module is incredibly useful for testing and cleaning a Python application. I used it a lot for cleaning SalStat (when I worked on it).

SalStat has become a bit of an orphan lately. Downloads are okay and stable (~400-500/month) but nobody wants to contribute any code to it. I guess that's why the project died, even though a lot of people found it even more useful than the top commercial apps in the field. I even applied for a UI job at SPSS but received no answer whatsoever. That was surprising given that I've a) commercial experience in the field; b) lots of academic experience in the field (and qualifications); and c) had actually done the analysis already (though not implemented in SalStat, I had talked about it a few years ago).

I'm very sure that few other people had the same fitness as I had because the interfaces to stats packages are *&%!#@?£ awful (with one or two very minor exceptions) and show little evidence of good HCI work on them - at most, the usual "I've done my HCI-101 and that's all that anyone needs" input from the programmers - usually old ideas warmed over and badly implemented.

SourceForge is very slow tonight - I wonder if they're doing admin work behind the scenes, or is there a run on FireFox 1.5? I got it from a mirror - really good work folks and congrats to anyone involved.

Been having some thought about positioning of "context-dependent" menus (the ones that come up with a click of the right mouse button).

Constraint 1: they need to be visually close to the selection point to enable the user to infer that they are related (related to Gastalt theory: because it is close, users infer a relationship. Too far away, and it's context is inferred as belonging to something else);

Constraint 2: they should NOT overlay what the user is examining. Often, users need to look at what's underneath the menu.

These constraints are often exclusive. Doing one breaks the other - if the menu is close to "the action", it can easily block what has been selected. However, if it does not block the selection, it is too far away to be immediately (and obviously) related to the item.

How to get around this? The answer is actually quite simple. There needs to be some way to display the pop-up menu far away enough from the selection so as not to block it (and, ideally, not block other close items), and yet retain the visual connection with the selection. Here's where alpha blending can play a role: using something like a transparent connector (from furthest edge of selection to edge of menu for both edges in a plane) does not block the selection and displays to the user that the menu is related to that selection.

Theoretically, this means that the menu is shown retaining a visual connection to the selection, and yet does not require immediate visual proximity. It's not an ideal solution, but so much of HCI and usability requires compromise. It also breaks Fitts' law somewhat, but the time penalties incurred are minimal when compared to those incurred by loss of task.

Note: I am NOT talking about transparent menus: ever tried to read a text with another super-imposed? It's hard work and distracting and very bad usability and even worse if both need to be read.. Keep the two separate and yet connected, and there should be success.

Busy writing some statistical algorithms in Python. Most have been done before, but less so using linear algebra - curious as this saves lots of time.

I'm using these mostly for distribution on paper, first to show how powerful array processing can be, and second to try and establish some kind of repository of useful code. There might be a useful book in them somewhere, maybe something along the lines of "Numeric Recipes", but updated using a modern language which makes things enormously easier. I remember trying to do the same thing with Pascal and C *many* years (about 10?) ago and even further back in BASIC. Not much fun doing slow iterations through arrays or setting up fragile functions that broke every so often, but educational. However, as much as there are some things in my history that I like, this is one area where Python and a fast, modern computer really makes me smile.

Also wondering if there is room for a book on usability - a kind of practical guide for people who cannot afford to hire a "professional" out and wish to do the testing themselves. There's lots of information out there, but it's quite dispersed and of varying quality. I'll think about it. It might be useful for open source folks.

Curious thing. I find that when developing an application, 80% of the features I wanted are coded in 20% of the time. That should mean that the remaining 20% of features take 80%, so what's up?

Well, once an app is working reasonably well (though not perfectly), I lose interest. My real kick is out of getting the thing working from a few ideas. Once I have something remotely usable, I sit back, take it easy and pat myself on the back.

Bad idea. Consequence = little development = app remains languishing in orphan hell

The little things are also harder to find. And my feature set usually expands - not so much creep, but rather I find I do the awkward bits last and these invariably turn out to take more time than I anticipated.

The rule is therefore: when my app is nearly finished and complete, I will have to devote far more time and effort than I've already spent in getting it completed. Hah! Salmoni's law of development. Applies only to me AFAIK, but I'm sure someone's written about it already somewhere else.