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?

Graph Visualization in Delphi

For a project at Oasis Digital, we need to show the end user a graphical representation of a graph (in the “graph theory” sense of the word). The application is written in Delphi, and in looking around I didn’t find any native Delphi components for doing that.

I did find GraphViz, and a COM Wrapper for it called WinGraphViz. Wiring the latter up to Delphi turned out to be quite easy. The minimal code to do it, for a demo app, is below. To make this compile you’ll need to import the type library for WinGraphviz.

procedure TExampleForm.DrawGraphForData(Data: string);
var
Dot: IDot;
Image: IBinaryImage;
ImageFileName: string;
begin
ImageFileName := 'c:image.gif';
Dot := CoDOT.Create;
Image := Dot.ToGIF(Data);
Image.Save(ImageFileName);
WebBrowser1.Navigate('file:///C:/image.gif');
end;

Production code would probably use a better way of getting the generated graph on to the screen. GraphViz support imagemaps, making it easy to make the notes clickable. It can draw various arrow types, node shapes, etc., and tries to lay out graphs in a readable way, without crossing lines, etc.

A trivial sample app looks like this:

Update: a correspondent pointed out that the graphic example above is a bit ugly, with non-anti-aliased lines and fonts. To resolve that, I turned to SVG; GraphViz can produce output in SVG format (among others), and the freely downloadable Adobe SVG Viewer can display them.

With slightly different code:

ImageFileName := 'c:image.svg';
Dot := CoDOT.Create;
Image := Dot.ToSVGZ(Data);
Image.Save(ImageFileName);
WebBrowser1.Navigate('file:///C:/image.svg');

We get an application with this appearance:

You can download the Delphi WinGraphViz Sample Application Source code.

Now Forming: St. Louis Delphi User Group

In addition to Java and other high-profile tools and languages discussed on the site, Oasis Digital makes good use of Borland Delphi for Windows client applications. I’m interesting in forming a St. Louis Delphi User Group. (For those
of you around the world, this means the St. Louis, MO, USA metropolitan area.)

The first step is to attempt to find some developers and firms using Delphi in St. Louis. I don’t know if there are 2 or 2000 Delphi developers in the area, partly because many firms that use Delphi are rather quiet about it.

To facilitate communications, I set up a Yahoo Group… please join it:
http://groups.yahoo.com/group/delphistl/

Test Intensive Development in Delphi

Slides from a Birds of a Feather session at BorCon 2001

At the 2002 Borland Conference, I presented a “Birds of a Feather” session on Test Intensive Development in Delphi. A couple of dozen people attended, in spite of the early morning time slot. Most of the attendees were new to test intensive development, though a few were experienced in it and shared useful tips.

My introductory talk and demo was adversely impacted by a technical problem with the projector and missing microphone; hopefully this slightly expanded set of slides will fill in the gaps that caused.

Download TID-Delphi-BOF-Borcon-2002.ppt

A Content Management System

I generally say that reinventing the wheel is not a good idea. Sometime’s it’s an educational experience, though!

KCMS is Kyle’s Content Management System – a working name for the content
management system which “powers” this web site. It is an early work in progress, “version 0.1”
system. I put it together last fall to facilitate updating this site more easily.
It is composed of two parts:

On the web server, a few kilobytes of PHP code extracts content from a database,
applies a template, add in other elements (such as the advertisements), and thus
renders the page.

Unlike many other CMSs, the admin / authoring application is a
Windows application – not a web application.
It is shown here.


First, a login screen. This is logging in to an Interbase server on my machine;
I edit everything here, then push it to the production machine when it’s ready.
Although currently only I am editing content, this system would support multiple
users easily.


I use Internet Explorer as an ActiveX control for the "home". In
a business app, I would display some meaningful data there – some kind of current
snapshot of the problem space. For example, the number of orders placed so far
to day, month-to-date sales, etc. For the CMS I could indicate things like how
many articles need to be uploaded to the server.


The find / list screen is not all that helpful yet – it only filters on two fields (title and
full text), and sorts on one field at a time.


This is the above screen, filtered to articles that mention Delphi in the title.


Here are the details for one article / piece of content. This screen again
uses embedded IE to display a preview of the content. It uses the same style
sheet as the real web site, so the fonts and spacing match.


Right now, the only editing control is straight, un-high-lighted HTML. The
"edit content in DW" button launches DreamWeaver to edit this item
there. I may also provide an ability to launch GVIM or another HTML-aware editor
for syntax highlighting later.

Were this a commercial app, I could get a syntax highlighting component for Delphi
and provide good HTML and passable WYSIWYG. For an internal-use system,
using DreamWeaver works quite well.


The client software can connect to both the local development database and
the production database, and copy all updated data to the production system
on the web site. An alternative solution would be to apply templates and
generate static HTML locally, then FTP it to a non-database-equipped web
host. That would be quite useful for people who don’t want to pay for and support
database-capable web hosting solution.

That’s where I am so far. It’s all quite alpha – certainly many hours of work
would be needed to polish it up. It’s good enough to start using for content
though, so that’s what I did.


Motivation and Observations

Why did I do this, instead of just using FrontPage or DreamWeaver?

  • It’s my mechanism, I can add hooks as needed.
  • The template is stored just once, and applied as needed. This is a nice
    parallel to desirable software engineering practices, since it lets me tell
    the computer about the page layout "once-and-only-once".
  • The content is stored without any template applied. DreamWeaver applied
    each template "statically", so what I updated a template it would
    update every single page on the web site.
  • I can apply more than one template to the same content (i.e., printer-friendly
    version of each page). Because of the above points, I was able to add the
    "printer friendly" feature in less than an hour, and it works on
    every page powered by the CMS.
  • I can query the data, and automatically show the most recent additions on
    the home page, list everything on the listing page, etc.

What about other Content Management Systems?

Frontier / Manila looks quite nice, but I host all of this on a Linux machine.

I looked at a number of "open source" content management systems,
and it seemed like the effort to customize them to do what I wanted could easily
exceed the effort of building this from scratch.

Background on the URLs Used

When looking at some existing CMS systems, one of the things that bothered
me was the URLs they used. For example, I saw that BroadVision uses URLs like
this:

http://www.broadvision.com/OneToOne/SessionMgr/services/services_svp.jsp
?BV_SessionID=NNNN1165913018.1004016458NNNN&BV_EngineID=cccca
dcdgllkkdfcefecefedghhdfjl.0&serviceType=SolutionValueProposition&
channelname=Solution+Value+Proposition&channelRuleset=Services+Channels
&program
Name=Solution+Value+Proposition+Overview&programRule
set=Solution+Value+Proposition+Programs

Fortunately, I cannot afford Broadvision 🙂 . I suppose all of those characters in the URL
cost a lot of money.

With some excellent feedback from the St. Louis Web Developers’ user group
and elsewhere, I ended up with URLs like this:

http://sitename.com/story-NNN-other-text-here.html

The NNN is a number, and the other-text-here is a very short summary of the
page topic / title. These URLs have several advantages:

  • The look "static", so there is no risk of a human or search engine
    confusing them with per-user content (like a shopping cart, etc.)
  • They are short, and can be emailed without wrapping to multiple lines.
  • The CMS can key off of just the NNN part, so as I change page titles, old
    bookmarks will still work.
  • The URLs feel "harmless" to the end user who sees them.
  • There is some indication of the page content in the URL, which is quite
    helpful is a URL somehow becomes separated from its descriptions. I think
    this is superior to the approach used in Frontier Manila or in Vignette, both
    of which only have an identified.
  • It’s trivial to map these URLs to the proper content generation script using
    Apache’s mod_rewrite.

Why PHP?

PHP is ideal for small, simple needs like this. Although I use Java heavily
for enterprise web application development, the effort to install
and support a Java solution would not be justified for this app at this time.
The server part of this software consists of 2-3 PHP files and nearly zero installation
effort. I’ve implemented and personally deployed a number of Java web applications,
and it would still take me a good while longer to get such a solution running
here.

Why a Windows application for the authoring / admin?

Most content management systems use a Web interface for the administration
/ authoring interface. I found that I can build a good interface much more quickly
as a Windows application than as a web application – so why bother? I don’t
have any need at all for widespread, zero-deployment access to the admin interface.
I do have a need to work on the content when not even connected to the Internet.
Therefore, a Windows app was a good solution for my problem.