Microsoft Office Tutorials and References
In Depth Information
Determining the Most Appropriate User Interface
Learning while you develop
Now a few words about reality: Excel is a moving target. Excel’s upgrade cycle is approximately
18 to 24 months, which means that you have fewer than two years to get up to speed with its
current innovations before you have even more innovations to contend with.
Excel 5, which introduced VBA, represented a major paradigm shift for Excel developers.
Thousands of people up until that point earned their living developing Excel applications (in
Excel 2, 3, and 4) that were largely based on the XLM macro language. Beginning with Excel 5,
dozens of new tools became available, and developers, for the most part, eagerly embraced
them.
When Excel 97 became available, developers faced yet another shift. This new version
introduced a new file format, the Visual Basic Editor (VBE), and UserForms as a replacement for
dialog sheets. Excel 2000, 2002, and 2003 introduced additional features, but these changes
weren’t as radical as those in previous upgrades.
Excel 2007 was perhaps the most significant upgrade ever. The key challenge is dealing with the
new Ribbon user interface. In the past, creating custom menus and toolbars was relatively easy,
and you could do it entirely using VBA. But modifying the Ribbon requires quite a bit of
additional work, and you’ll need to go beyond VBA to make it happen. In addition, the new file
formats will require some additional considerations. You may find it more efficient to create two
versions of your applications: one for Excel 2007 and 2010, and one for Excel 2003 and earlier
versions.
VBA isn’t difficult to learn, but it definitely takes time to become comfortable with it — and even
more time to master it. Consequently, it’s not uncommon to be in the process of learning VBA
while you’re developing applications with it. In fact, I think it’s impossible to learn VBA without
developing applications. If you’re like me, you’ll find it much easier to learn VBA if you have a
project that requires it. Learning VBA just for the sake of learning VBA usually doesn’t work.
One thing that I’ve learned from experience is to avoid letting the end user completely guide
your approach to a problem. For example, suppose that you meet with a manager who tells you
that the department needs an application to write text files that will be imported into another
application. Don’t confuse the user’s need with the solution. The user’s real need is to share data.
Using an intermediate text file to do it is just one possible solution to the need. There may be
better ways to approach the problem. In other words, don’t let the users define their problem by
stating it in terms of a solution approach. Determining the best approach is your job.
Determining the Most Appropriate User Interface
When you develop spreadsheets that others will use, you need to pay special attention to the
user interface. By user interface, I mean the method by which the user interacts with the
application and executes your VBA macros.
 
Search JabSto ::




Custom Search