An important usability problem has come up in this Boxer issue, and I’m belatedly considering how Boxer’s mouse handling should really work. My comment in the issue goes into more detail, but the short version is this:
To me, the best solution is to go back to what DOSBox does: ignore the mouse altogether until its locked. Clicking the mouse inside the DOS view would lock it and Cmdclick (or CmdL) would unlock it. The statusbar would tell you what how to lock and unlock the mouse, so there’d be no how-the-hell-do-I-get-my-mouse-back confusion.
What do you think? Are there other better solutions? Ways to reduce the friction of the proposed solution? Please share your thoughts, here or in the issue itself!
Whatever solution is chosen would become the default for new and existing users. The current behaviour is still appropriate and natural for many programs (such as adventure games and productivity apps) but it’s broken enough of the time that it shouldn’t be the default; I’m ambivalent about continuing to offer it as an option, since that would complicate support (two separate application behaviours instead of one) and doing so means adding interface clutter.
Having stabilized the code long enough to squeeze another build out, I’ve been trying my hand at making things for a bit instead of breaking things.
The last core feature yet to be reimplemented in Boxer 1.0 is game installation: AKA game importing, AKA making a new gamebox out of whatever you’ve got. I’d been flitting cautiously around this feature for a long time, like a thirsty yet apprehensive gazelle, while I figured out how to present it.
In Boxer 0.8x, installing a game was as uncomplicated as could be. You dragged the game onto the "Drop games here" icon, and Boxer worked out what to do with it from there:
If the game looked like it needed installing first (e.g. it came on a CD), then Boxer launched the most likely-looking installer program, and hoped that it would copy its own files into the new gamebox.
If the game looked like it was already installed and ready to go (e.g. like you downloaded it from somewhere) then Boxer converted the game files directly into a gamebox and handed it to you on a platter.
In a nutshell, was this: Boxer would decide entirely for itself what to do, and it would often get it wrong. It didn’t tell you what it was doing, or let you direct it otherwise, and when it screwed up you’d be left with a 300MB paperweight.
Simply, is a proper UI. The game installation process needs to tell you first how it thinks it should proceed, and let you adjust that decision based on what you know about the game. Ideally, offering you this control over the process should make the process seem less confusing and unreliable, not more so; and ideally, the default choice should still be right almost all of the time‚ so that you can trust Boxer to take care of things for you.
We start off with a dropzone, explaining what Boxer can eat. I’m of two minds about dropzones in UIs: they often make it harder to choose files than a simple Open panel, promising an awkward shuffle of Finder windows and swearing at one’s trackpad.
However, an Open panel always feels to me like directing a task, whereas dropping things onto a dropzone feels more like participating in a task, and I think that sense of involvement with the application is important.
In Boxer’s case, the game folder or volume is usually ready on the Desktop or close at hand in the Downloads folder, making drag-dropping fairly painless. And clicking directly on the dropzone will display a standard Open panel, for the cold of heart.
After dropping in the game folder to import, the dropzone slides to one side to become this import confirmation panel: showing you what’s getting imported, and where it will go.
The Change… button beneath the From icon displays an Open panel for choosing a different source folder. The Change… button beneath the To icon displays a Save panel for choosing the name and destination folder for the new gamebox. The destination folder defaults to your last saved location (usually DOS Games), and the initial name for the new gamebox is auto-generated from the source folder’s name.
In future, Boxer might automatically retrieve cover art for the game at this point; for now, you can at least drop your own cover art onto the nascent gamebox to replace the default gamebox icon.
Pushing the More Options button slides out these more specific import options: indicating just how Boxer thinks it should import the game, and letting you tweak its decision before proceeding.
The import panel remembers if you had toggled More Options, and keeps it open for you next time.
This is by no means the final interface, and it exists only in mockups at this stage. But I think it makes a good start on its goals: providing enough information and control over a tricky process, while retaining the simplicity that made this a killer feature in earlier Boxers.
What do you think? Post your insights, suggestions and criticisms in the comments!
Yes, after nearly 3 months, a new Boxer 1.0 alpha build is shaved and thrust blinking into the sunlight. This build comes with the following bullet points:
This is important, kids: a lot has changed under Boxer’s hood from my gonzo restructuring, and There Will Be Bugs. Furthermore, You Must Report Them otherwise They’ll Stay There Forever and Boxer Won’t Get Better and I Will Die a Sad and Broken Man.
There will likely be several more builds in quick succession as things are shaken down and all those bugs you keen entomologists report are squished. Either that, or I’ll tear the heart out of SDL’s input handling and the codebase will be busted for another 3 months. Oh, which will he choose!?
Keen observers will have noted a lack of visible progress on Boxer 1.0 over the past two months and may, perhaps, have lamented with wailing and beating of breast the dearth of new builds since January.
The principal reason for this delay was that I spent most of March on an impromptu and much-needed visit to my sheep-infested homeland and most of February frantically arranging said visit. As of Thursday, and after an unconscionable number of inflight movies, I am now back on terra firma and reacclimatising to dour Finland.
The other reason has been that in a fit of hubris I embarked on an ambitious rewrite of DOSBox’s old rendering pipeline: essentially replacing SDL’s renderer with my own, to give Boxer much tighter control over how DOSBox's video output gets to the screen. The benefits:
The drawback: by the time I’d finished tugging on that loose thread to my satisfaction, I had unravelled the entire sweater. Now I need to knit it all back again before anything works and I can release another build.
Understandably that’s a big job — among other things, mouse input is comprehensively, gloriously broken — so I’ve been entirely avoiding it by coding up paste-to-DOS-prompt and floppydisk detection instead. As soon as my USB floppy drive arrives, I can finally get some use out of my mint-condition Star Wars: TIE Fighter diskettes. Go team!
Design by 40watt.