April 2011


In This Newsletter

AVAproject Fusion Series:
No. 2, The New and Improved Material List

What Makes a Network Application?

AVAproject Tip: Adding the "Finishing" Touches

Catalog Updates

 U.S. Price Books:

  • Air Louvers
  • Assa
  • Best
  • Bobrick
  • Curries
  • Falcon
  • Folger Adam
  • Ives
  • Monarch
  • Pioneer
  • Schlage
  • SOSS
  • Stanley
  • Stanley D.C.
  • Stanley E.D.
  • Von Duprin
  • Yale

 Canadian Price Books:

  • Assa
  • Corbin-Russwin
  • Daybar
  • Folger Adam
  • HES
  • McKinney
  • Sargent
  • Stanley

AVAproject Fusion Series: No. 2, The New and Improved Material List

This is the second of several articles in a special series introducing our newest product offering: AVAproject Fusion.

Fusion is about mastering your data. Information from AVAproject or virtually any other Windows-compatible data source can be brought together, manipulated, reported on and reformatted for use in other applications. See your data any way you can imagine it.

Last month, we focused on the process of bringing project files created in AVAproject into Fusion. Now we begin to explore why we're doing it. All the information entered in AVAproject culminates with the creation of the Priced Material Lists. For both Division-8 and Division-10, the net result is the same. The software creates a detailed listing of each and every component of the project. Even beyond this, the Material List identifies the way certain project affect others. For example, hardware items are not only listed themselves, but also the preparations required to accommodate them on the doors and frames.


AVAproject Fusion takes the familiar Material List to an entirely new level. In addition to the Material List on the Navigation Bar, is a brand new data table, the "Combined Information Pool".


At first glance this table may look identical to the Material List, but it is so much more! It is an enhanced Material List that links back directly

An Illustration of all Project Components Culminating into the Material list

The AVAproject Fusion Combined Information Pool

to all the data that was used to create it. As its name implies, this "Combined Information Pool" is exactly that – it is a fusion of all the Openings Schedules, Hardware Groups, Accessory & Misc. tables and other related data sources all available in a single, massive table of data.


"Right-clicking" on any column header will yield the standard "Insert Column" option, but with a huge added feature. In addition to the standard Material Columns, all the related data columns from the various source schedules are also offered.

Columns from All Source Schedules are Available in the Combined Information Pool

For all those users that have requested additional columns to be added to the AVAproject Material List, this is what you’ve been looking for - and so much more. Absolutely any column from the

Hardware Groups and Openings Schedules can be added to this new and improved Material List!


The advantages however, don’t stop with simply displaying this data.

These columns can also be used to group, sort and use in the creation of reports and tables within Fusion. In the next article, we’ll explore "Filters" and how they can be used to extract specific information from the projects.


Many of the concepts discussed in this article are expanded upon in the AVAware publication: "AVAproject Fusion: Theory of Operation". In it, data structures and the interaction between project components are illustrated in much greater detail. This comprehensive document is available in the Downloads section of the AVAware website.

What Makes a Network Application?

One of the most interesting aspects of running a support department is observing trends in customer inquiries and identifying common points of confusion.

By far the most common question where hear in both the sales and support departments is "Is this a 'network application'?" The question seems simple enough: "Yes" or "no"; "it is" or "it isn't". Simple, right? Not so much.

To a software developer, the term 'network application' or 'network capable' really means nothing at all. It's equivalent to asking if your new car is "road capable". There are so many different ways that a piece of software can be installed on a network and even more ways that its resources can be distributed on said network, that a "yes" or "no" answer to this question tells you absolutely nothing.

In most cases, when a sales person does answer you, they are either guessing at what you're referring to by your inquiry or more likely just giving you the answer they believe you want to hear. Quite honestly, virtually every piece of software is a 'network application' or 'network capable' to some degree – it just depends on how you look at it.

If we were to attempt to come to a meaningful answer to this age-old matter of network compatibility, we would be best to begin by looking at the various components of both the network and software in question.



The Network


While there are as many different networks configurations as there are stars in the sky, all of them can be broken down into three major groups:

Peer-to-Peer Networks: This type if network is most commonly found in homes or extremely small offices with only a few users. They consist of several computers, networked together, with no designated "server" or "main" computer. Based on security settings, each PC can optionally share its files and access files from all the others. There are also usually printers and an internet connection that is being shared by all the machines. What defines this type network however, is that no PC is more important than any other. Each PC is intended to be used by a person and there is no established central server on which the other PC is dependent. If any machine goes down, the others are unaffected.

Server-based Networks: This type of network is most common in commercial settings and is defined by one or more common "servers" that are accessed by some or all of the PCs connected to the network. Often the PCs within a server-based network also have peer-to-

peer functionality in that they can access each other's files, but the primary intent is to have shared resources stored on servers. This is essential to maintaining optimum performance. Unlike peer-to-peer file-sharing, servers dedicate 100% of their resources to "serving" files to the various users at top speed. The important thing to remember is, when the servers go down business comes to a screeching halt.

Thin-Client Networks: This is by far the least common and most radical configuration you're likely to find. In this environment, the only computers on the network are the servers themselves. They don't just serve files however – they also serve processor time. There are no PCs needed on the user's desktops, just "thin clients" (otherwise referred to as "appliances" or "dumb terminals" because they contain no software or operating system). All they can do is connect to the server and allow you to control software that is running on them. The servers "slice" up their processor resources and run the software application on behalf of each user. Although extremely simple to install and maintain, the drawbacks to this configuration are huge. Performance typically suffers because users are ultimately sharing a processor. In addition, those thin clients are completely useless when the server goes down.



The Software


Although this can vary between software packages, most can divide their resources into three major categories.

Software: The first major component is the software itself. This is usually located in the "Program Files" or similar folder and contains the program itself.

Static Data (i.e. Libraries): Often thought of as part of the software installation. It is the data component of the software program itself. This data is never changed by the users. It the case of architectural industry software this would include things such as location libraries and manufacturer catalogs.

Dynamic Data (i.e. User Files): The final component, the files that the users create. Their individual data files and the files that are shared amongst multiple people in the company all fall into the

general category of "dynamic data".



Where Does it all Live?


When installing software in a network environment, the big question is where to locate each of these three major groups of files. Any one or all of them can be located either on the server or on any of the individual PCs. As long as any one of them resides on any machine that is accessible by others on the network, you have yourself a 'network application'. Starting to see why this term is so ambiguous?

The next bit of news is really no more encouraging. There is simply no correct answer as to where these components should be situated. This is entirely a matter of opinion. For each choice, there are pros and cons. Every software developer will make decisions based on the way they configure their software based on their own priority structure. Trying to examine every conceivable combination and option is beyond the scope of this article – people have written entire books on the subject. But we will look at some of the basics. The first question is where to install the software application itself: on the server or on the individual desktops. Each one has its advantages, and it's up to the user to decide what is most important for them.

AVAware has followed the lead of application developers such as Microsoft and Adobe Systems. We install software and its static resources on the individual desktops and the user data (that is intended for sharing) on the file server. Every company has their own reason for what they do, these are some of the reasons for our choices:

Installing software on the server provides only one distinct advantage: ease of management. Software only needs to be installed and updated in one place. Generally speaking, I.T. people love this configuration because it makes their jobs a lot easier. But it does come at a significant price – many people, us included believe that this type of installation does not serve the best interests of the company as a whole.

Installing software and its resources on the users' local machines has a number of important benefits:

  1. Fault Tolerance. When software is installed on the server, every user is completely dependent on that machine functioning. If the server or any part of the network connecting the users to it goes down, everybody gets a holiday. In our opinion, the most important rule in a software installation is "Business is NEVER interrupted." When the software is installed on each machine, you could literally rip out the network cable from the back of it and business could go on. Users could still access the software and work locally. In cases of a network failure, data files could still be shared peer-to-peer or using thumb drives in a worst-case scenario.

  2. Flexible Updating. By installing software individually, users have the flexibility to install updates on their own schedule. New version of a program can be evaluated by select users before the entire company is committed to the change. This is particularly useful in vetting out new software as being useful and "bug free" before the entire company is switched over.

  3. Individual users have the option to work on different editions of price books as the need may arise. Someone working on older project may not want to update their price books if their projects are priced based on older editions.

  4. Distributed application installation allows for the use mobile devices such as laptops and remote PCs that need only connect to the network to update the user data files. A laptop computer is completely useless on an airplane if it's dependent on connecting to a file server to run its software.


At the end of day, the choice is up to the buyer. Those that offer server-based applications may have their own reasons for doing so, but the important thing to take way from this article is the fact that all "network applications" are not created alike. Many more questions need to be asked before you can arrive at a useful answer.

AVAproject Tip: Adding the "Finishing" Touches

The architectural hardware industry uses two distinctly different sets of standards to define hardware finishes: ANSI (American National Standards Institute) and BHMA (Builders Hardware Manufacturers Association). AVAproject supports both, but the same cannot be said for most hardware manufacturers. Most price books contain only one system, and that is the system that AVAware publishes in their electronic counterparts. When products are selected from the electronic catalogs, finishes are displayed in their appropriate column in the Hardware Groups. Based in the catalog, the product finish will be expressed in ANSI, BHMA or both.

When AVAproject generates a Hardware Schedule, all the finishes are aligned in a single column to the right of the hardware descriptions. (Per the DHI specified format)


AVAproject (in the Hardware Schedule dialog) offers many options with respect to how this information will be presented. For Canadian distributors, the "US" prefix of the ANSI numbers can be replaced with a "C". Also, a "preferred" finish convention can be specified. Where the finishes are expressed in both systems, the user can select which one to choose for reporting purposes.


This is all well and good, except that many distributors prefer to have the entire schedule expressed in a single finish system. Normally this would mean manually selecting a finish cross-reference for those products that are not expressed in the preferred system in their respective catalogs. AVAproject offers something much easier.  The  software  will  automatically   convert  BHMA  numbers  into  their  ANSI

equivalent, thus allowing the Hardware Schedule to be presented with a single convention.


Automatic conversions from ANSI to BHMA are another matter. Unlike ANSI numbers, the BHMA codes define both the product's finish as well as the underlying base metal. This effectively means that each and every ANSI number has several possible BHMA equivalents. As such, it is impossible to make  that  conversion  without  making an assumption with respect to  what

that base metal is. Attempting to do so automatically would result in far too many incorrect (and misrepresented) products for such a feature to be possible.

We welcome any questions, comments or suggestions about any topic mentioned in this edition of AVAwire. Please visit our website for more information, or contact us directly at (416) 239-9099.