I took a trip down to London’s Southbank on Sunday evening to see wow+flutter, a showcase of short, digitally-themed animations that are part of onedotzero, an annual festival and tour celebrating “adventures in moving image”. I’ve been several times before when it was based at the ICA (it’s now moved to the BFI National Film Theatre), and I always find it really inspiring. Normally, I can never remember the details of the films I’ve seen – it’s pretty intense; with over an hour of back-to-back shorts each lasting only 1-3 minutes – but this year they provided a list of the films details, so I can report on some of my highlights and provide links to some of the films.
The 7 signs your UI was created by a programmer
Do you suspect a programmer may have put together the terrible user interface on that “enterprise” software you’re forced to use every day? There are some give-away indicators. Look out for them in your software, hunt down the developer and force them to read a book about user interface design
1. Exclamation marks in dialog box messages
Look, it’s probably the 50th time I’ve seen this message today. The fact that this application “Cannot connect to database!” is no longer a surprise. You may have noticed that most professional software uses a neutral tone for its communication with the user. Try that. Also:
1a. Double negatives in confirmation dialogs
“Are you sure you don’t want to lose your changes?” Err… what? No. I mean YES. Oh sh*t. Any dialog that requires you to stop and try to parse the question in order to work out if you’re about to destroy several hours of work is not doing its job. It’s getting in the way of you doing your job. In fact, convoluted messages are such a serious issue that Microsoft even tried to help developers to help their users by introducing a whole new kind of dialog box in Vista: the question/task dialog. Good luck with that.
2. No tab ordering defined\mouse only navigation
Because no-one’s ever going to use the keyboard to navigate the zillion controls in your data entry app, are they? This one actually surprises me, because I’d have thought that developers would’ve needed to navigate quickly through the application while they’re writing it. Well, that doesn’t seem to be the case. Pretty much all commercial apps are good counter examples. I don’t mean to hold up Microsoft Office as a paragon of UI virtue, but they definitely do the “alternate way of navigating everything” thing well. Everything you need can be reached by both keyboard and mouse. Unplug your mouse and try that with your favourite piece of in-house software and see how you get on.
3. Group boxes around everything
This is a bit of a WinForms specific one. The clue is in the name: group boxes are for grouping logically related controls, not for providing a kewl recessed border around every single one of the controls in your dialog. Don’t kid yourself that this is doing anything other than using up some valuable screen real estate. (See if you can spot another pet peeve in the example dialog, too).
4. Icons created in the IDE
Look, Visual Studio’s a really good integrated development environment, but it ain’t no Photoshop. Don’t try and use it to create icons. And while you’re at it, please don’t make icons consisting solely of the name of your application (inevitably an acronym) in pixel font and primary colours. Oh, and don’t just steal various icons from another application, unless you’re going to steal the whole lot; one of the key visual aspects of a good UI is consistency. Mixing your hand-drawn 4-bit icons with the glorious 32-bit shiny ones you borrowed is going to be jarring. In fact, why not go the whole way and get someone who can actually draw to create your icons for you? After all, you wouldn’t have someone who wasn’t a programmer writing the code, would you…?
5. Data grids
Otherwise known as the “Excel is the pinnacle of user interface design” disease. Break the habit. Generally, the more types of controls that are embedded in your grid, the less likely that it’s the right kind of interface paradigm. Yeah, I’m looking at you, person embedding a calendar control, drop down box, graph, slider and checkbox in each row of a data grid. And whatever your 3rd-party grid provider of choice says, it’s not going to do screen redraw performance any good, either.
6. Not implemented message boxes
Ahh, the GUI equivalent of source code TODO comments. Of course, it’s an in-house software give-away; no commercial (desktop) software would be brazen enough to ship with bits of functionality dangling from the stumps of buttons and menu items. Would it? Feel free to provide counter-examples if you have them.
7. Excessive use of dialog boxes
Warning: dialog boxes are considered harmful (to usability). They’re the equivalent of restraining your user by force and preventing her from moving until she answers your question. That might be OK for matters of life or death (i.e. data loss), but not otherwise. Every time you find yourself about to add a new message box, stop, take a deep breath and consider whether it’s really necessary.
So, if you’re a victim or one, many, or all of these user interface faux pas, all I can say is: sorry. I’ve been responsible for doing at least one of these things myself over the years. Consider this post repentance for my user interface sins.
Posted in Excel, Rant, Software Development, Usability Tagged Excel, GUI, Usability, win32 42 Comments
Getting IUnknown from __ComObject
I’m working in an environment with a lot of mixed managed (F#) and unmanaged (C++ COM) code. One of the big problems with this is the mix of lifetime management techniques; .NET uses garbage collection while COM relies on reference counting. Furthermore .NET garbage collection is somewhat non-deterministic, which adds further complexity.
So quite often in our mixed code-base, we find that the .NET garbage collection process doesn’t kick in when we need it to. For instance, when we’ve allocated a lot of memory in the COM code that .NET isn’t aware of. Memory exhaustion has to get pretty bad for the GC to occur at any other time than during a .NET allocation, either the system-wide low-memory event has to be signalled or an OutOfMemoryException needs to be thrown. In both of these cases it’s probably too late to do anything about it.
In this case it’s extremely useful to be able to see what .NET objects are still alive, and what COM objects they’re hanging on to. Unfortunately this isn’t as easy as it might seem.
Read More
Missing content in long Wordpress posts
I’ve just spent several hours struggling with an annoying Wordpress problem: when I edited a post to make some additions, it suddenly stopped displaying any content. The title, header and footer were still visible, only the post body itself was missing.
After a bit of poking around, I came across this post. It points out the root cause of the problem is the PHP regular expression engine (PCRE) that Wordpress uses.
The easiest way to fix the problem is to ignore the advice in that post about modifying formatting.php, and instead make the fix to PHP.INI which is mentioned in the comments. I edited my copy to include the following line, which increases the backtracking limit from the default of 100000:
pcre.backtrack_limit = 1000000
After getting IIS to pick up the changes (iisreset) my missing content appeared again.
Finding the largest free block of address space
I’ve been seeing problems recently with fragmented virtual address space. During the lifetime of a process, bits and pieces of memory are allocated throughout the 2GB 32-bit address space to such an extent that large contiguous blocks of free space are no longer available. If anything subsequently requires a large block of memory (like, for instance, a somewhat out-of-date version of the GHC runtime), it will fail to get it.
It’s obvious looking at the output from VMmap or windbg’s !address command what the largest contiguous block is, e.g.
0:008> !address -summary .... Largest free region: Base 07300000 - Size 63ed0000 (1637184 KB)
But what if you need that number in order to make a decision at run-time? For instance, to decide whether your process is in a fit state to continue, or if it should instead commit hara-kiri. In that case, you need to access the information programmatically. That’s where the immensely useful VirtualQueryEx function comes in…
Read More
Posted in Software Development, WinDbg, Windows Tagged address space, c++, perfmon, private bytes, win32, WinDbg 2 Comments
Diagnosing out of memory errors with VMMap – Part 2
Diagnosing out of memory errors with VMMap
The other day a colleague pointed me to a new tool from Mark Russinovich et al (ex-SysInternals) that turns out to be very useful for diagnosing virtual memory/address space exhaustion issues. I thought I’d describe it here, and give some – hopefully useful – extra information on what it reports.
(I had problems with WordPress choking on this long post, so I’ve split it into 2 parts. This the first part, the second part is here).
Posted in Debugging, Software Development, WinDbg, Windows Tagged memory, private bytes, VMMap, win32, WinDbg 2 Comments
Ending the love affair with Excel
I heart spreadsheets
Unfortunately, given the ever-increasing focus on accountability and scalability in these domains, Excel is also an increasingly inappropriate platform for delivery of this sort of functionality. How can organisations ease the transition away from this environment to something more easily manageable, while retaining it’s positive benefits?
Visualising Black-Scholes option pricing using F# and WPF
The other day I was looking for an example of some code relevant to finance that I could use as a test for experimenting with Windows Presentation Foundation (WPF) and F#. I decided I could use a simple Black-Scholes option pricer combined with WPF to easily visualise how the option inputs affect the value and greeks. For example, given all the usual Black-Scholes assumptions, and a non-zero interest rate, you’d expect the value of an at-the-money call option to increase as time to expiry increases, whereas a put option would decrease in value.
Calculating option values using F#
The first thing you need is an approximation to the cumulative normal distribution. I used the Abromowitz and Stegun approximation, which should give us enough precision. It’s fairly concise to implement in F#:
let ncdf x = let b1 = 0.319381530 let b2 = -0.356563782 let b3 = 1.781477937 let b4 = -1.821255978 let b5 = 1.330274429 let p = 0.2316419 let c = 0.39894228 match x with | x when x >= 0.0 -> let t = 1.0 / (1.0 + p * x) (1.0 - c * Math.Exp( -x * x / 2.0)* t * (t*(t*(t*(t*b5+b4)+b3)+b2)+b1)) | _ -> let t = 1.0 / (1.0 - p * x) (c * Math.Exp( -x * x / 2.0)* t * (t*(t*(t*(t*b5+b4)+b3)+b2)+b1))
The CDF should be near 0 for low values, around 0.5 for zero, and near 1 for high values. Let’s check:
> [-5.0; 0.0; 5.0] |> List.map ncdf;; val it : float list = [2.871049992e-07; 0.500000001; 0.9999997129]
Looks good.
Now let’s put it to use by implementing the option pricing formula for call options:
let call strike spot (rate:float) (now:float) (expiry:float) (vol:float) = let exp = expiry-now let d1 = Math.Log(spot/strike) + ((rate+(vol*vol)/2.0)*exp)/(vol * Math.Sqrt(exp)) let d2 = d1 - (vol * (Math.Sqrt(exp))) (spot * ncdf d1) - (strike * Math.Pow(Math.E, -rate*exp)*(ncdf d2)), ncdf d1
Notice that the function returns a tuple of (value,delta). Give that the greeks are available analytically we may as well return them at the same time as the value.
We can poke this a bit to check that it’s doing the right thing. A call option that’s way in-the-money (i.e. spot > strike) near to expiry, has a lot of intrinsic value:
> call 10.0 100.0 0.0 0.0 0.1 0.5;; val it : float * float = (89.26911958, 0.9913821898)
An at-the-money call option should have a delta close to 0.5 at expiry:
> call 10.0 10.0 0.0 0.0 0.1 0.5;; val it : float * float = (0.6301280626, 0.5315064031)
All seems fine.
So lets see what we can do about visualising these relationships.
Using WPF with F#
You’d be forgiven for thinking that the XAML markup language is the only way to construct user interfaces in WPF. Indeed, if you want to avoid writing code it’s the way to go. But unfortunately it’s not possible to use F# as the code-behind XAML files, so you’re forced to use C#. And it’s also not as dynamic or immediate as it could be; involving the usual write, compile, run iteration. We can do better in F# using scripts and F# interactive (FSI).
The key is to construct the WPF object model imperatively, rather than declaratively with XAML. Yeah, I know this is normally the opposite of what you’d want to do.
For instance, here’s some code to create a Canvas. Note the use of a construction expression to both create the object and set some of it’s properties. This is just syntactic sugar which helps to make the object look slightly less mutable than it actually is:
let c = new Canvas(Name="Canvas", Width=250.0, Height=250.0) c.Background <- SolidColorBrush(Color.FromRgb(228uy,228uy,228uy))
We can use the WPF canvas panel to enable us to explicitly place points (or rather, Rectangles) on our plot, it uses absolute locations rather than the implied flow layout of the other containers (Grid, StackPanel etc). Putting this together, we can write a function which will take a parent Panel, and a list of (x,y) tuples and create a plot:
let plot (panel:Panel) (pts:(double * double) list) = let bgc = new Canvas(Name="Canvas", Width=300.0, Height=300.0) let c = new Canvas(Name="Canvas", Width=250.0, Height=250.0) c.SetValue(Canvas.LeftProperty, 25.0) c.SetValue(Canvas.TopProperty, 25.0) c.Background <- SolidColorBrush(Color.FromRgb(228uy,228uy,228uy)) let x,y = pts |> List.unzip let xmin,xmax = x |> List.min, x |> List.max let ymin,ymax = y |> List.min, y |> List.max let xscale = c.Width / (xmax-xmin) let yscale = c.Height / (ymax-ymin) pts |> List.map (fun pt -> let p = new Rectangle(Width=2.0,Height=2.0) p.Stroke <- new SolidColorBrush(Color.FromRgb(0uy,0uy,0uy)) p.SetValue( Canvas.LeftProperty, (fst pt - xmin) * xscale) p.SetValue( Canvas.TopProperty, c.Height - (snd pt - ymin) * yscale) p ) |> List.iter (fun rect -> ignore <| c.Children.Add rect) ignore <| bgc.Children.Add (fst (makeYScale ymin ymax)) ignore <| bgc.Children.Add (fst (makeXScale xmin xmax)) ignore <| bgc.Children.Add c ignore <| panel.Children.Add bgc ()
The function returns nothing (unit in F# parlance) and performs a side-effecting modify of the passed Panel. I’ve omitted the makeXScale and makeYScale functions, as they’re a bit gnarly, and don’t really serve to demonstrate anything in particular.
Now we need to create some data to plot. We can do this in many ways, but one thing I looked at was creating a set of call option values with varying time to expiry. I thought this could use a floating point sequence, but it generated a deprecation warning, so I decided to do it long hand instead. This function returns a list of (time,value) tuples, where time range from rfrom to rto in num steps and value is calculated using the passed function f.
let varyExpiry f num rfrom rto = List.init num (fun n -> let s = rfrom + ((float n/float num) * (rto-rfrom)) float s, fst <| f 10.0 10.0 0.05 0.0 s 0.5 )
We can pass the resulting list directly to our plot function, but first we need to create a window to display it in:
let w = new Window(Name="Plot",Width=500.0,Height=500.0) let wp = new WrapPanel() w.Content <- wp w.Visibility <- Visibility.Visible
Executing this code in FSI will display a blank window (probably behind your active window if you're within Visual Studio). Then we can add the plot to the graph:
plot wp (varyExpiry call 100 10.0 100.0)
Voila! Obviously the plot is very, very basic, but it's an interesting experiment, and it does makes it extremely easy to plot functions interactively in almost the same way as you can with applications like Excel and MatLab. Pretty powerful.
Call option values for varying expiries
Call and put option values for varying expiries
WinDbg !locks command broken
It seems that the extremely useful !locks command is broken in 6.11.1.40x, the current and previous release of WinDbg from the debugging tools for Windows.
You’ll get errors like:
0:007> !locks NTSDEXTS: Unable to resolve ntdll!RTL_CRITICAL_SECTION_DEBUG type NTSDEXTS: Please check your symbols
The suggested solution seems to be to roll-back to version 6.10.3.233, available from here, or you can just replace the version of ntsdexts.dll in the c:\program files\debugging tools for windows (x86)\winxp directory with the one from the earlier release.
Judging by the error message, I’m guessing that the new version may work if you happen to be using a debug (checked) build of the Windows kernel, but I don’t have one around to try it with.
