Getting Professional
This column appeared in the October 1998 edition of
EXE, and was just an opportunity to get a few general thoughts off my chest
If you’re familiar with using Windows then you can learn
the fundamentals of writing Visual Basic applications quite quickly by working
through the Programmers Guide, right? Well, yes I suppose. But this
doesn’t necessarily mean that you’d be doing anything that you’d
necessarily be proud of with another eighteen months of experience under your
belt. Writing a Visual Basic application is easy, but writing a good Visual
Basic application is another matter. In this months column I want to outline a
few thoughts about writing professional applications with Visual Basic. This is
a very difficult task to do in only two pages of magazine space so I’ll
state from the outset that I’m just scratching the surface, but
consequently the content will tend to come over as something of a potpourri of
thoughts and observations.
What the user sees
In my time I’ve seen some user interface designs that are
almost beyond belief, using a combination of wholly inappropriate controls and
hard coded colour schemes so psychedelic that they bring on an instant
migraine. In order to develop for Windows, you need to understand Windows from
a user perspective. Microsoft injects a lot of effort into building consistency
throughout their applications to help a user that is familiar with one
application get up to speed with another application in as little time as
possible. Unfortunately when some applications emerge from the development
department the consistency can virtually disappear and the poor users have a
steeper learning curve than would otherwise be necessary. Microsoft Press
publishes a book called The Windows Interface Guidelines for Software Design
(ISBN 1-55615-679-0) that is intended to be, and indeed is, a bible for anybody
writing a Windows application. It details how to lay out screens, what sort of
behaviour should be expected under different conditions, menu designs,
providing on-screen feedback, and so on. I’ve been programming for Windows
since 1990 and yet I still find that I refer to this book, say, a couple of
times a month to help me clarify the nuances of how a Window feature should
look or behave. Regardless of what language you program in, every Windows
developer should have access to this book.
One pet hate of mine (and this is purely
a personal view) is to see a top-level application form consist
of a grey form that only contains large grey buttons, and with
no shortcuts. If you really don’t feel that you can encapsulate
your application into a menu based environment, and I’ll
admit that it’s not always appropriate, then at least try
and turn it into an icon-based form loader. A comparable design
scenario would be if Microsoft had designed the Control Panel
to be a grey form with just grey buttons, as shown in Figure 1.
It just doesn’t look good, and yet I’ve seen lots of
developers adopt this approach.
Figure 1 - Not how Microsoft designs its forms
One important component that is often omitted from an in-house
product is an associated help file. Printed documentation does tend to get
produced more often, but it is often an afterthought. On a solo (i.e. one
developer) project the individual can probably write the help file at the same
time as the application code. If a project is of a size to warrant a team of
developers then that team should include a professional technical author who
can devote as much time as necessary to writing both online and printed
documentation. There is more to providing user assistance than a help file
though. ToolTips are incredibly easy to add to most standard controls now, and
they should leave the user in no doubt as to what a specific form component is
there for. This facility is augmented by the "WhatsThis?" feature
whereby a popup help window can be associated with a specific control if a
ToolTip explanation isn't going to be long enough. Furthermore, write short and
concise instructions on the form that outlines its basic purpose wherever
possible.
Error messages should be meaningful, straightforward, and
single-purpose. It’s unhelpful for a user to see a message like
"Validation failed" on a form with 10 input fields, and it’s
even worse to get an uncaptured ODBC driver error passed directly to a
MessageBox. Where appropriate the error message dialog should include a Help
button that links to the application help file. Furthermore, if a MessageBox is
to be displayed with an error message, think carefully about what sort of
severity to give the icon. I’ve noticed a tendency to use the Critical
icon for error messages of a "Telephone number is of the wrong
format" type severity. A Critical icon should mean something really bad
has happened, like the hard disk is full.
What the user doesn’t see
Still on the subject of errors, every sub, function, and event
should have some sort of error handler. The default behaviour in a Visual Basic
application is to report a run-time error in a MessageBox and then terminate.
There is no way that Microsoft Excel would survive in the marketplace if it
displayed a "Divide By Zero" dialog when this problem arose and then
unconditionally unload itself. Each piece of code should be designed so that
every error that could predictably occur (for example, the divide by zero error
again) is catered for in the error handler. Because not all errors can be
predicted, though, there should be a centralised error handler that will take
all other errors, display a polite message, and store the error details to some
form of storage.
Management Issues
MSDN is a great source of information, and will probably
answer two in every three queries that a Visual Basic (or Visual Studio)
developer will have. Additionally the Enterprise Edition ensures that you are
sent the service packs as they become available. If your company gets MSDN how
accessible is it? Are the developers informed when a new edition is available?
If a developer gets a REAL problem, what facilities have you provided for him
to make use of?
One way in which a development department can make life easier
for the general development community is to create a dedicated development
support function. The role of this team is to act as a central location to
which a developer can go for technical notes, whitepapers, installation disks,
and company standards. These would be the people who would be the named
individuals to make use of a Microsoft – or equivalent – technical
support contract. By acting as a single liaison point in such cases they are
then in a position to add the problem resolution, together with any additional
relevant information, to the local knowledge base.
It would also be the responsibility of a support person to
actively push information out to the developers, ideally through an Intranet. A
typical bulletin would include notification that a new service pack was
available, had been tested, and was available for download locally. This
function could also take a more proactive role in the development process by
developing and maintaining common code and standard form templates.
Microsoft Certified Solution Developer
As somebody who has taken and passed these exams I feel that I
am in a position where I can vouch for their value. Studying for them goes a
long way towards understanding the broader areas of the Windows platform, and
makes you aware of both the key areas of technology and of the less widely
known SDKs that Microsoft issue. Working through the original syllabus for the
core Windows Open System Architecture (WOSA) exams provided a good grounding in
all of the key Windows technologies at the time (mainly OLE and ODBC). To pass
these exams it was necessary to read and learn a lot of whitepapers and SDK
chapters, and it would be true to say that I gained a broader picture of the
Windows platform than I previously had. Then Microsoft announced the retirement
of the WOSA-based exams and introduced the syllabus for the Windows
Architecture exams, which additionally required a fairly comprehensive
knowledge of general Internet development issues, digital certificates,
replication, Unicode, shell extensions, and so on. Up to this point candidates
were examined on general core Windows technology issues and needed to also pass
two of several option exams which tested knowledge of specific products, for
example Visual Basic and SQL Server.
In June of this year Microsoft announced at the Fusion 98
conference that the Solution Developer certification was being revamped again
in order to bring the syllabus content in line with developing technologies and
future product releases. The most noticeable change is the structuring of the
core exams, in that there are now three core exams and one optional. However
the core exams have been split into two streams: one for Visual Basic 6
developers and one for Visual C++ 6, with an additional Visual J++ stream
apparently due to appear later on. These new exams are due to start appearing
around now, although the latest details can be found at on the Microsoft MCP
site at http://www.eu.microsoft.com/mcp. For existing MCSDs who passed with the
WOSA exams your certification will expire on March 1st 1999, while those with
the Windows Architecture exams have until July 1st 2000 to upgrade.
For the Visual Basic developer the new core exam titles look
like this:
-
Analysing requirements and defining solution architectures (common to all
streams)
-
Designing and implementing desktop applications with VB6
-
Designing and implementing distributed
applications with VB6
I firmly believe that an IT training manager looking to
upgrade the general level of technical knowledge amongst a Windows-oriented
development department should focus staff training towards this certification,
because it provides a clear and quantifiable goal for developers to aim at.
ActiveToolBars
As I mentioned in last months column the menu editor in Visual
Basic 6 remains unchanged from previous versions. This means that it is not
possible to produce the menus that incorporate associated bitmaps such as you
get in Microsoft Office 97 and, indeed, the Visual Studio suite. Microsoft are
apparently unwilling to classify the libraries that enhance menu items as
redistributable components, so for this reason there is no point in altering
the menu editor as it’s perfectly workable as it is.
Fortunately there are a small number of third party offerings
to rectify this. I obtained an evaluation copy of one such product that I had
heard good things about, namely ActiveToolBars by Sheridan Software Systems,
Inc., and found it to be a well designed tool. As with other Sheridan products
that I’ve had there is no printed documentation, but the online help is
excellent. The product basically offers the ability to create Office97 and IE4
style menus and toolbars. The menus support animation and different display
styles, while the multiple sliding toolbars are dockable/free-floating or fixed
as required. As with mainstream Microsoft products the toolbars can be
customised at runtime if you wish. The product comes with a reasonable stock of
the most common images and sounds, and there is an image editor to allow you to
create your own graphic resources.
To be honest I didn’t personally
find the product particularly intuitive when I first started to
use it, but the tutorial is very well designed and, now that I
can use it, the design makes sense. Once you’re proficient
in it’s use then you should find that it takes no longer
to assemble a toolbar than it would do if you were to use the
standard Visual Basic mechanism. One feature that I do like is
a small auto-coding facility that will generate an appropriate
Select Case statement onto the clipboard once a menu/toolbar has
been generated - a simple but timesaving feature. The product,
along with the rest of Sheridan’s software range, is available
from Contemporary Software at http://www.contemporary.co.uk
priced £115 plus VAT and delivery.
