A gentle walk yesterday evening brought us here (although we briefly overshot, engaged as we were deep in conversation and having forgotten to enable the proximity beeper on my GPSr).
Spent a little time hunting in a convincing-looking place that turned out to be wrong before the hint gave us a clue and – after the peeling back of some branches to be able to see the
thing that the hint referred to – sent us in the right direction. Lovely night for it, and we managed to get back to our accommodation in good time to avoid the start of the rain.
Our second holiday in Newport and a chance to hunt for a handful of the caches we’d missed last time around. A short walk by my partner fleeblewidget and I yesterday evening brought us to an easy find here on a road we’ve walked several times
before. TFTC.
His nuclear research helped a judge determine that former Russian spy Alexander Litvinenko had been assassinated – likely on Putin’s orders. Just months after the verdict, the
scientist himself was found stabbed to death with two knives. Police deemed it a suicide, but US intelligence officials suspect it was murder…
An easy find while taking my nephew out for a morning walk in his pushchair. Poor little fella fell asleep before we got to the GZ, though, knocked out perhaps by this morning’s early
heat! Nice and quiet this early on a Sunday: not a muggle in sight.
Me and mine are staying just down the road for a holiday – not part of last night’s noisy wedding party, though!
Something that jumped at me, recently, was a rendering dilemma that browsers have to encounter, and gracefully handle, on a day-by-day basis with little, to no, standardization.
Take the following page for example. You have 4 floated divs, each with a width of 25%, contained within a parent div of
width 50px. Here’s the question: How wide are each of the divs?
The problem lies in the fact that each div should be, approximately, 12.5px wide and since technology isn’t at a level where we can start rendering at the sub-pixel level we tend to
have to round off the number. The problem then becomes: Which way do you round the number? Up, down, or a mixture of the two? I think the results will surprise you, as they did me…
Some people think that usability is very costly and complex and that user tests should be reserved for the rare web design project with a huge budget and a lavish time schedule. Not
true. Elaborate usability tests are a waste of resources. The best results come from testing no more than 5 users and running as many small tests as you can afford.
In earlier research, Tom Landauer and I showed that the number of usability problems found in a usability test with n users is:
N (1-(1- L ) n )
where N is the total number of usability problems in the design and L is the proportion of usability problems discovered while testing a single user. The typical
value of L is 31%, averaged across a large number of projects we studied. Plotting the curve for L =31% gives the following result…
Software engineers go crazy for the most ridiculous things. We like to think that we’re hyper-rational, but when we have to choose a technology, we end up in a kind of
frenzy — bouncing from one person’s Hacker News comment to another’s blog post until, in a stupor, we float helplessly toward the brightest light and lay prone in front of it,
oblivious to what we were looking for in the first place.
This is not how rational people make decisions, but it is how software engineers decide to use MapReduce…
In the speech in which she committed to keep governing despite calls to stand down, the prime minister made reference to extending powers for the security services. Those powers –
which include regulation of the internet and forcing internet companies to let spies read everyone’s private communications – were a key part of the Conservative campaign, which failed to
score a majority in the House of Commons.
For the last few months, I’ve been GMing a GURPS campaign (that was originally a Warhammer Fantasy Roleplay 1st-edition campaign, in turn built upon a mixture of commercially published and homegrown
modules, including, in turn, an AD&D module…) for a few friends.
So far, it’s included such gems as a player-written poem in a fictional language, another player’s drawing of the most-cinematic action sequence they’ve experienced so far… and the opportunity, during a play session that
coincided with a player’s birthday, to explain the layout of a ruined tower by presenting them with a cake baked into the shape of the terrain.
“So we’re… here?” asked a player, jabbing with his finger at the cream-filled section of the tower at which he was standing.
But mostly I wanted to make this post so that I had a point of context in case I ever get around to open-sourcing some of the digital tools I’ve been developing to help streamline our
play sessions. For example, most of our battle maps and exploration are presented on a ‘board’ comprised of a flat screen monitor stripped of its stand and laid on its back, connected
via the web to a tool that allows me to show, hide, or adapt parts of it from my laptop or mobile phone. Player stats, health, and cash, as well as the date, time, position of the sun
as well as the phases of the moons are similarly tracked and are available via any player’s mobile phone at any time.
A rare instance of us using a paper-based battle map. Despite the fact that we play in-person, we’ve used digital tools to save table space!
These kinds of tools have been popular for ‘long-distance’/Internet roleplaying for years, but I think there’s a lot of potential in locally-linked, tabletop-enhancing
(rather than replacing) tools that deliver some of the same benefit to the (superior, in my opinion) experience of ‘proper’ face-to-face adventure gaming. Now, at least,
when I tell you for example about some software I wrote to help calculate the position of the sun in the sky of a fictional world, you’ll have a clue why I would do such a thing in the
first place.
