Bypassing the primary interface

January 27, 2009 at 8:12 pm (User Interface Design) (, , , , , )

At CES a couple of weeks ago, toymakers Mattel demonstrated a nearly-ready-for-production release of a toy which is operated simply by concentrating.

Telekenesis? Not exactly

This device claims to translate brain activity (measurable via EEG) into a command which controls a small fan…this fan blows a stream of air which lifts a light ball into the air. The ball can then be moved around a sort of obstacle course. All this movement is apparently triggered by how much the player is concentrating.

My first reaction was that it would probably be quite easy to fake this…just make the fan blow randomly and you’d probably achieve a sort of placebo effect, where people convinced themselves that it was their concentration which triggered the fan. I’d still love to get my hands on one to try it.

Straight to the core

A researcher (fellow) at MIT has developed a relatively inexpensive device which allows images to be projected directly onto a retina, thus allowing people who are blind as a result of afflictions such as hemorrhages to ‘see.’

The device can be connected to to devices such as cameras and computers. It is effectively a miniaturisation of a scanning laser opthalmoscope which has achieved massive savings in terms of cost of production and size due to the development in technologies such as LEDs, which have replaced the laser in the original device.

Our methods and channels of interaction are changing

For the last few decades the speed of communication has been increasing at a much accelerated rate compared to the decades of the early 20th century.

The telegraph instigated the move to binary storage and transmission of data, but the same input/output channels were utilised – fingers which previously wrote now tapped keys, eyes which read letters on paper now read letters on screens, ears which listened to sound still listen to sound, albeit transferred through a different medium such as VOIP, and vocal cords are still used to generate that sound.

There have been some recent evolutions, such as voice transcription systems, and text-to-voice transcoders, but nothing which truly stepped outside established channels.

Now we have (if it’s not a hoax) a system which can translate brain activity – thoughts in their base form – into action in the world around us. Yes, this current implementation is barely more than an on/off switch, but it opens up the realms of possibility. Suddenly, controlling devices by thinking doesn’t seem impossible.

Imagine the combination of an evolution of these two devices – a paraplegic could ‘think’ into a computer, which could then create an image of that text and project it onto the retina of a deaf & blind person. It is an extreme scenario, but think of the possibilities it represents in terms of data communication, and the boundaries which it crosses.

Permalink Leave a Comment

Quickbooks – disable close button on application window

January 22, 2009 at 8:10 pm (Software, User Interface Design) (, , , , )

Quickbooks, while it is a very nice integrated accounting package, has long had a major usability flaw – it is very easy to accidentally close Quickbooks.

When its internal windows – reports, registers etc – are maximised the button to close the internal window sits directly inside the Close button on the application window…much like in Excel:

ex

Closed the program by accident…again

Unfortunately it is very easy to click the main application Close button instead of the internal window one. The first time you do this the program asks you if you’re sure you want to exit. If you tick the “Do not ask me again” box when answering this question, there is no way to re-enable the dialog (re-installing isn’t an option due to the difficulty of getting licenses for older versions of Quickbooks from Intuit).

This is more of a problem on older versions of Windows where the application Close button was identical to the internal one, but even on XP and later we had a frequent issue with people in the office getting frustrated because they closed the application by accident. When you’re running on old hardware and you’ve got a company file open which has hundreds of thousands of transactions, generating reports can take upwards of 15 minutes. Losing all that because one has accidentally clicked the wrong button is frustrating.

Searching the various user forums found several people citing the same issue, but with no resolution. Digging through the XML in various settings files didn’t turn up the option either.

It appears that Intuit may be fixing this in Quickbooks 2009, but they still don’t explicitly say that you can re-enable the option.

Solved by a script

So I looked at a couple of different options, but the only one which I had the confidence to attempt was to disable the generic Windows application Close button. The only scripting language I have much experience of is AutoHotKey.

This script polls for the existence of Quickbooks application windows every 5 seconds, and if one exists, calls the appropriate dll and removes the Application Menu Close option and button from the window, if it hasn’t already been removed.

It has only been tested on Windows versions up to XP, and on Quickbooks versions up to 2006, but as long as the Quickbooks developers don’t decide to change the (bizarre) name of the Quickbooks app class – MauiFrame – it should continue to work for newer versions of the software.

Its not the most elegant solution, but it works, and the users in our office, particularly some of the less technologically inclined ones, were very grateful for it.

Get the .exe here (codeplex isn’t the most appropriate place to host it but I don’t have anywhere else just now) and place it in the Startup folder. The source code is here – open it in any text editor.

Permalink Leave a Comment

So…Windows Live Writer

December 19, 2008 at 12:19 am (Software, User Interface Design) (, , )

After getting over my hulk rage during the download process when Microsoft forced me to update Messenger at the same time, and having used it a few times, I’ve finally had the chance to think about Live Writer objectively in comparison to in-browser editing.

Interface

toolbar

Microsoft have kept things pretty simple – the user interface is uncluttered, and controls are mostly where you’d expect them in terms of formatting…its a bit like a dumbed-down version of Word.

The Tasks and post Properties panels are toggled with function keys, although screen real estate probably won’t be as important due to the limited dimensions of many blogs.

Editing can be done in Edit (Presentation/WYSIWYG) or Source format, so fine control over html elements is possible, and drafts can be saved locally or online.

Functionality

The Tasks panel is really the only place that Live Writer seems to me to have a big advantage over the web editor provided by mature blogging environments such as WordPress.

tasks

Inserting Images/Hyperlinks/Video takes one click to pull up the appropriate dialog…and having done so you get quite a deep level of control over the properties of that object (copy & paste doesn’t provide the same control over the object). Resizing an image is as easy as stretching the border or specifying an exact size in its properties.

If you frequently post non-text objects in your blogs then the speed advantages in performing all this work locally is quite significant, as well as being simpler in my opinion. When finished, Live Writer can be left to publish to the web in the background.

Categorisation/Tagging is all performed at the bottom of the screen, with intelligent lookup of previously used tags/categories, and even automatic creation of new ones if a searched-for term isn’t found:

autoadd

There is a growing selection of plugins available here.

Benefits compared to in-browser editing
  • Speed – doing all the formatting work locally gives considerable savings over online editing, especially for those of us with occasionally spotty internet connections
  • Ease of non-text object editing – as mentioned above, this functionality is well advanced on WordPress’ in-browser editor
  • Reliability – Ever press Publish in your browser and had a timeout/connection failure? Rarely an issue for those of us lucky enough to have broadband, but for people working off weak wireless/narrow pipes it’s still (very) occasionally an issue. Doing all your work locally means there’s nothing to lose.
Weak points compared to in-browser editing

All I can come up with is:

  • Limited Preview – while the layout is perfect in Preview, Live Writer doesn’t reflect my custom theme in Preview and shows it in the default theme…maybe this will update automatically in time? Edit: As per Brandon’s comment below, View -> Refresh theme does indeed update the theme, and after refreshing the Preview view actually shows the current front page of the blog, including all posts, and inserts the blog-in-progress at the top. Very impressive!
  • No support for audio objects – WordPress allows the insertion of audio objects (songs), which I’ve never done, but Live Writer doesn’t have this yet.
  • You can’t install Windows Live Writer on Linux – Need to fire up VMWare or one of its ilk…
Annoyances
  • Can’t customise the toolbar – granted, there’s not a lot to customise, but not being able to extract the font size control and save myself having to dig to it through the Font dialog is a mildly irritating – 1 whole click potentially saved :P – and there’s a bunch of unused space on the toolbar.
  • Non-unified toggle between Edit (presentation) and Source views – F11 to get to Edit (which is the default) view, Shift+F11 to get to Source. Eh? There shouldn’t be a Shift required, it should be straightforward toggle. Likewise F12 should toggle in and out of Preview.
  • Can’t customise panel layout – The tasks panel is on the right, which is probably natural in terms of mimicking real-world action placement for the majority of users, but what if I was left-handed? My control hand would be on the left, and I’d be used to reaching left.
  • Occasional lag – Oddly, I get a bit of lag from time to time when editing. Generally it seems to be when I select a few words of text, but I haven’t definitively nailed it down. Live Writer is still in Beta, so hopefully this will be exterminated by the time it comes out of Beta. Edit: This is using build 14.0.8050.1202 – the lag is rare but persistent.
Conclusion

This is an excellent piece of (free) software. I don’t like the forced upgrade in its distribution channel, but I can’t see myself using anything else to write my blogs any time soon.

Edit: Having just Published this post from Live Writer, two of my images lost their centered format. This didn’t happen previously in my previous post.

Permalink 2 Comments

Robocopy – bad GUI, brilliant functionality

December 17, 2008 at 7:39 pm (Software, User Interface Design) (, , , )

Further to my post yesterday talking about the absence of any regard for user-friendliness in the design of the User Interface for Robocopy, I want to expand on and emphasise the brilliance of function in the utility itself.

As a simple backup (mirroring) solution I don’t think that Robocopy could be beaten for minimal use of resources and speed.

Run it to copy a directory with the switches /S and /XO and you’ve got incremental copying of a directory and all its (populated) subdirectories.

I use it as a home (where some web programming work is done) solution in case of disk failure.

One simple script to copy the appropriate directory, scheduled to run every evening, and I’m backed up. No errors or asking me whether I really want to copy a particular file, just simple, no fuss execution.

Permalink Leave a Comment

Why bother? Robocopy’s “GUI”

December 16, 2008 at 9:24 pm (User Interface Design) (, , , )

Having gone through the pain of trying to use Windows’ built-in file/folder copy utility to copy a large amount of data, I played with a few different tools.

Of all these, Robocopy seemed to be among the most robust and configurable. Unsurprisingly, as its distributed as part of the Windows Server 2003 Resource Kit Tools package, it is targeted at command-line use, but an MS engineer called Derk Benisch kindly wrote a GUI for it for those of us to whom pointing and clicking comes more naturally.

Unfortunately, this is the result:

robogui 

While the GUI does provide a big advantage over the command line, namely that it supports and facilitates multithreading and it also allows you to save your scripts, I might as well have a printout of the help section beside me and use the command line.

By the time I actually remember what even the most commonly used (by me) switches do, I’ll be faster running it from the command line, and I’ll have learned the actual syntax properly.

Sure, there’s no extraneous information at all in this UI, but that doesn’t fecking help if I have to spend time firing up the Help file every time I want to vary my script!

Jakob Nielsen would have nightmares.

Permalink Leave a Comment