Slider Control for Touch-Screen Applications

An improved version of this post is cross-posted on the Oasis Digital blog.

At Oasis Digital we are working on an application that will run on a touch-screen computer, and which will be used to (among other things) control an audio amplification system. There are some design considerations for touch-screen applications which are rather stark once you use the touch-screen for a few minutes:

  • A finger is rather less precise than a mouse pointer – hitting small targets is hard
  • Drag/drop operations (or grab-adjust operations) sometimes don’t start quite where you aimed
  • Your finger blocks the point on the screen where you are pressing
  • The concept of keyboard “focus” is moot on applications with no keyboard

To accomodate the first two of these, I’ve built a prototype/example of a slider control to use for audio adjustment in such an application. It has these key features:

  1. It does not matter if you click on the “handle” or on the rest of the bar – because with touch screen you won’t be able to reliably do one vs. the other.
  2. The adjustment is not immediate; there is a limit of the speed of the adjustment to produce smoother audio control. The slider handle will move down very quickly, but will move up slowly. This avoids the possibility of an accidental touch pushing the audio amplification in to feedback.

The prototype/example looks like the screenshot here:

Touchscreen Slider

… but ignore the static image, it doesn’t tell the story. To see it in action, take a look at the screencast (currently in a WMV file, easily viewable only on Windows) or download the example program and play with it. The source is also on github.

This example runs on Delphi 2007 (rather old… but I had it handy on the PC at hand), an enhanced version of it in us used in a production application for a touch-screen audio control system. My secondary goal was to use it as a target to create an AJAX control with the same behavior. Anyone want to write that?

.NET Traction at Microsoft?

According to this article from Richard Grimes, it appears that .NET has not gained as much traction inside Microsoft as anticipated:
http://www.grimes.demon.co.uk/dotnet/vistaAndDotnet.htm

“My conclusion is that Microsoft has lost its confidence in .NET. They implement very little of their own code using .NET. The framework is provided as part of the operating system, but this is so that code written by third party developers can run on Vista without the large download of the framework. Supplying the .NET runtime for third party developers in this way is similar to Microsoft supplying msvbvm60.dll as part of XP.”

I think his conclusion is a bit overreaching, but this isn’t a big deal to me either way, and I’m neither a raving Microsoft fan nor a rabid Microsoft detractor.

However, this is good news in at least one important way:

To the extent Windows itself is not built on .NET, that in a sense leaves more room for other, non-.NET runtime environments to flourish as first class citizens, leaving more room for Java (we ship a commercial Java application, so that’s good…) and also for other currently and upcoming dynamic language runtime environments.

Bar Camp, Code Camp

I met some of the Bar Camp guys:

http://barcamp.org/

at ETech last week:

http://conferences.oreillynet.com/etech/

and mentioned Code Camp to them:

http://blogs.msdn.com/trobbins/archive/2004/12/12/280181.aspx

These two non-conferences seem to have a lot in common, though one is vaguely MS-centric (it was briefly known as MSDN Code Camp) with the other isn’t. Brian Button is putting together a Code Camp here in St. Louis soon, it will be interesting to see how it works out.

http://www.agileprogrammer.com/oneagilecoder/archive/2006/01/22/11023.aspx

SQL Server Log Shipping Fragility

In a customer production system, we use MS SQL Server 2000 “log shipping” extensively to offload reporting DB load to secondary servers… a common use of the technology. This generally works very well, most of the time.
We’ve noticed, though, that it can be somewhat fragile, in that it is easy to inadventantly run a SQL operation (such as a large index update, schema change, etc.) that results in many, many pages shipped, and hence in large log backup files, and large “standby” files – all of which are processed surprisingly slowly by SQL Server. The result of this (the fragility) is that the log ship destination servers can then take many, many hours to return to an operatonal state.
It turns out that one cause of this is that log backup (and hence log shipping) apparently happens at the “page” level: if one bit on a page changes, all 8K of the page is shipped.

A second cause is that if a log backup happens during the middle of a large operation, it will ship the partially complete operation; the destination servers will then generate huge “standby” files (we’ve seen them over a gigabyte) in the restore process.
One path forward is to to move up to SQL Server 2005, which has numerous log shipping improvements. Imagine my dismay to find this today:

http://sqljunkies.com/WebLog/acalvett/archive/2006/03/12/18993.aspx

in which Andrew Calvett found that the log ship monitoring functionality is much worse in SQL Server 2005 than in SQL Server 2000.

As usual there is likely a third party tool to make this better. But since log shipping is such a powerful and flexible tool for scaling up SQL Server based applications, it is disappointing to see the monitoring get worse rather than better. Perhaps in SQL Server “2010”…

Sea change in Web vs. Desktop Development

In the late 1990s, I rushed in to web-app development with a million other developers, following the demand. At the time I accepted that it took more work to get a web app working than a desktop app, using the tools of the era.

But looking at Ruby / Rails and TurboGears:

http://www.turbogears.org/preview/docs/tutorials/eajaxtg/paper.html

It strikes me that it is now *less work and less code* to get the functionality shown here working in a web app w/AJAX, than it would be to get it working in a rich client with Swing or in a multi-tier application in Delphi. The idea above that desktop client apps are less work than web apps, is no longer true. We are now paying a penalty when we choose to create non-web-apps.

Switched to WordPress

After a few years of using a barely-maintained homegrown CMS / weblog engine, I’ve switched to WordPress 2.0. Through a few hours of tedious migration work, most of the old content has been preserved. Moreover, a set of Apache directives like this:

RedirectMatch story-275- http://kylecordes.com/2005/09/09/direct-swing/
RedirectMatch printable-275- http://kylecordes.com/2005/09/09/direct-swing/

makes all (or very nearly all) of the old URLs still work.