Inside the CxAlloy Cloud

When we were building CxAlloy TQ we knew we wanted a flexible, powerful system for locations. We didn’t want to just have a list of rooms and a “Location” field on an issue. We wanted to be able to express the relationships between locations and to deeply integrate them with equipment, issues, checklists, and tests. This desire grew out of specific uses that we wanted make possible, including:

• Getting a list of all issues on a floor, including issues associated with equipment on that floor.
• Getting a list of all equipment in a building on a multi-building project.
• Making it natural to create locations like “Roof” and “Garden” that didn’t fit well into the Room Name/Room Number model.
• Creating checklists based on a location instead of equipment for room walkthroughs or similar applications.
• Allowing the creation of relationships between locations, but not require those relationships.
• Seeing easily the related room, floor, and building for equipment or items associated with that equipment.

In coming up with solutions that addressed these needs we were greatly aided by the work done for the COBie standard (you can read more about our integration with COBie here). In particular their concept of “spaces”, a broader concept than “rooms”, was a great insight.

Besides calling rooms “spaces”, the basics of locations work as you’d expect – buildings contain floors, which in turn contain spaces. Importantly, you don’t need a building or a floor to add spaces. By allowing you to add spaces first and then connect them to floors later (or not at all), we make the software faster and more flexible. When you are adding equipment and realize you need to add a new space, it’s much nicer to be able to add the space right then without having to worry about what floor and building it’s in, especially since you may not have created the building or floor in CxAlloy TQ yet.

Earlier incarnations of CxAlloy TQ had both an “Equipment” and “Location” field for issues. As we put together the current version we realized that having both fields is redundant. If the equipment has a location and the issue is connected to the equipment, shouldn’t we know the location?  CxAlloy TQ is much smarter now – for example, let’s say you create an issue for AHU-1 which is in Room 101. When you create an issue for AHU-1, you don’t need to add “Room 101” to the issue because it’s implied by the connection to AHU-1. And not only that, we know it’s on the first floor in the main building!

Of course, these connections aren’t that useful unless you can use them to organize your issues. We knew that and carried this concept into our filters and sorts. For example, if you filter your issue list to the first floor, you’ll see issues connected to equipment on the first floor right along with issues connected to spaces on the first floor and issues connected to the floor itself. You can sort by location as well. And, like with all of our filters and sorts, you can generate a professional PDF of the filtered and sorted set.

Finally, you want to be able to see these relationships as you work with issues, equipment, and other items. We do this by having a list of related location information showing you that not only, for example, is an issue connected to AHU-1, but it is also in Room 101 on the first floor of the main building.

I’ve been focusing primarily on issues and equipment, but CxAlloy TQ lets you take locations even farther by integrating with Checklists and Tests. All of the same functionality that I’ve outlined for issues is available for Checklists and Tests. This really opens up their potential uses.

The flexibility and power that locations in CxAlloy TQ affords – while still being easy to use – is really quite remarkable. I hope I’ve been able to show you a little of the benefits that CxAlloy TQ and its location model can bring to your projects.

Tablet devices, particularly the iPad, have been described as “terrible computers with pretty decent graphics processors”. The hardware capability of your iPad is far less than what you’d find on the computer on which you are likely reading this post. That created a challenge when it came time to design CxAlloy TQ for tablet devices. The iPad seems pretty quick – icons slide around the screen as smoothly as you can swipe them. Even using CxAlloy TQ from Safari on iPad seems to operate similarly to using it from a desktop browser. So, it may seem like designing a tablet-oriented interface for the software would just be a matter of creating bigger, touch-friendly buttons, right? Not exactly.

Offline Changes Everything

With the CxAlloy TQ mobile web app we wanted to do more than provide a touch-friendly interface for the software. After all, the desktop software is already fully functional on an iPad. The primary purpose of CxAlloy TQ would be to work offline. This one feature, offline access, completely changed how the mobile app would function compared with the desktop version. It would be a challenge, but we knew we could tackle it. And we knew we had to – the benefits of being able to work in the field without an internet connection were just too great to ignore.

One of the biggest challenges was performance. So-called “native” apps – those you’d download from the App Store or Google Play Store – interact more directly with the hardware[footnote 1], while the web technologies upon which CxAlloy TQ is built operate at a higher level. Using web technology gives us more flexibility to fix bugs quickly and roll out new features as soon as they’re ready, but require us to more carefully optimize our code to ensure the app is fast and responsive.

You may think it can’t be that difficult since you probably visit lots of regular web sites on your iPad and they don’t have any performance problems. Perhaps you’ve even used CxAlloy TQ – the desktop version –  from your iPad and found that it is pretty zippy. This is because of another advantage that traditional web apps have – servers. Most of the heavy lifting of searching through records and building pages is done by dedicated servers that were built to do just that. So, every time you visit a page in CxAlloy TQ, most of the work to create the interface in front of you was done by the servers and shipped down to your browser. But in order for the CxAlloy TQ web app to work offline, it can’t depend on the availability of the server to do the heavy lifting. It’s on its own to process data and build the interface. It has to do this with the iPad’s relatively meager resources.

Zombies, Workers, and Hardware Acceleration

So how do we manage to create a fast and responsive web app? Well, there are a few tips and tricks we can use to spread the work around and manage the device’s memory effectively.

For example, when the software syncs its data up to the server, it does it using a background process called a “web worker” which means that the main processor can spend its time making sure the interface is snappy while the background is busy chugging away sending records to and from the server.

Another trick is to utilize 3D technology to draw the interface in the mobile web app. This may seem odd seeing as how there aren’t any 3D graphics in the software, but by offloading certain interface elements to the tablet’s 3D hardware (which is surprisingly powerful), we can free up the main processor for data crunching while still keeping things sliding around smoothly on screen. Offloading something onto a dedicated piece of hardware is called “acceleration” and it’s a good name; graphics that are hardware accelerated are much, much faster than those controlled by the software itself.

Another challenge with offline web apps are zombies. Zombies are bits of code that seem to go away but actually hang around eating up memory (or “brains”, if you like) which slows things down.  They also sometimes will pop back up, causing errors when you least expect it. Like most zombies, they are difficult to track down and dispose of and will generally ruin your day. On desktop web apps, zombies are cleared out every time you navigate to a new page, but since the page never really refreshes in an offline app, we have to be vigilant in order to not cause zombies.

A Nip Here, A Tuck There

Hardware acceleration, background processing, and zombie-hunting coding practices are good overall habits for making sure things are running as smoothly as possible, but unfortunately, there is nothing we can do to speed up the iPad’s hardware. Some actions are just slower on an iPad. In those cases we can employ techniques to make the software feel faster.

Recently, we removed a 300ms delay on tapping elements such as buttons in the app. By default, an iPad will wait 300ms after you touch the screen before it counts it as “tapped”. It does this just to make sure you aren’t holding your finger down in order to “press” something. We don’t have anything in our interface that needs to be “pressed” so we included code that doesn’t wait for this 300ms before declaring something “tapped”. The result is an almost imperceptible change than makes everything “feel” much faster even if we only cut out 300ms from a tap.

Another recent change that helps to make the software feel faster is the addition of a loader on a record’s detail view. When you load up the checklist section, for example, it has to not only load up the list of checklists, but it has to load up the first checklist in the list (or the last one you viewed), as well as all of the checklist lines for that checklist, images that have been downloaded, and issues. It’s a lot for a humble iPad and it takes some time. By adding a large loading animation we communicate to the user that their request was received, providing a visual indicator for what is happening. We also added immediate color changes to list items when tapped to confirm to the user that the software has received the action and is working instead of the user waiting to see if the software really did register their tap. Uncertainty over what the software is doing leads to discomfort. And discomfort is a slow feeling. It may seem a little “smoke and mirrors”, but the end result is a mobile web app that feels responsive and quick even as it is processing large amounts of offline data.

– footnotes –

So-called “native” apps – those you’d download from the App Store or Google Play Store – are created using native technologies that are translated (or “compiled”) to the binary code that computers can understand before they are sent to users. Web technologies upon which CxAlloy TQ is built is “interpreted” code, which means that it is translated to machine-readable binary code every single time you use the app. Interpreted code is much more flexible than compiled code, allowing us to fix bugs and address problems more quickly and easily as well as give us the potential for a cross-platform app. But, since interpreted code is converted when it is run, it is slower than compiled code.

I’m pleased to announce the launch of Progress Reports as part of the latest release of CxAlloy Total Quality (TQ). This release also features revamped PDFs and a number of other improvements. I’d like to give you a quick tour of these features and share with you some of our thinking behind them.

The new Progress Reports section.

Progress Reports enable project managers to effectively communicate work done over a given time period. Project work happens in a lot of ways and in a lot of places – at planned site visits, in impromptu conference calls, at scheduled meetings, and via email, to name just a few. Some of this work is planned and structured, such as functional testing, while other work happens extemporaneously. Progress Reports allows for efficiently communicating both structured and unstructured work. For unstructured work, project managers can outline the work completed however they see fit as part of the “Actions and Activities” component of the report. CxAlloy TQ provides the common formatting tools necessary to write an effective summary of work, such as bold, italic, and underline text formatting and bulleted lists. Structured work over the selected time period (such as issues closed, checklists completed, and tests attempted) can be included automatically by simply selecting those options when printing the Progress Report PDF.

The Details section allows you to see what’s happened during the selected time period.

Common formatting tools are available.

Progress Reports can be found under the “Reports” tab in your project. By default only account administrators have access to Progress Reports. Account administrators can grant access to other CxAlloy TQ users on the project by updating their permissions.

This update also features expanded and improved PDFs. We updated our PDFs to better accommodate the needs of project managers and in response to customer feedback. One thing we heard was that it wasn’t sufficient to include the project logo on only the first page of a given report. Now each printed item (such as a checklist or test) has a full header, including the project name, number, and logo. We also added full title pages to more clearly communicate the contents of a given report. Finally, we made the issues PDF more compact. Now this frequently printed document will require less paper and be easier to manage in the field.

The project name, number, and logo now repeats for each item.

PDFs now feature a bold, clear title page.

Not only did we improve the PDFs, but we added a lot of new ones! You can now print a PDF for any asset: spaces, zones, floors, buildings, equipment, equipment types, and systems.

As usual you can see the full list of updates in this release by checking the release notes.

I hope you’ll use and benefit from these new features. If you have any questions or comments, get in touch! We love to hear from our customers.

Jacob Terry

CxAlloy Director of Product Development

It’s finally here. Version 4 of CxAlloy TQ is now live!

We’ve been working diligently on the latest version of our CxAlloy Total Quality software and have now released it publicly. This is an exciting day for us at CxAlloy! This new version combines all the great features and benefits of version 3 with a whole lot of new features. New technologies have allowed us to again raise the bar on what quality management is all about.

What’s the same? We’ve kept the transparency and simplicity. Those things will never change. But we’ve updated a lot of the features you’ve come to enjoy, based on your feedback. Here’s a taste of what’s changed:

Notifications. Some folks like to get notified of every single change in their project. Some don’t want any emails at all. We’ve listened and devised a strategy to accommodate all preferences. Now each account user has a personal profile section that allows customized notification options. These options include immediate email notifications about all changes in a project or summarized daily emails of activity. You can change the frequency, the project, and even specific items of interest.

Offline Compatibility. Our software works well on a tablet, but there are times when you don’t have good Internet connections. To mitigate this we developed a mobile application that enables you to continue working in the database when Internet is not available. Just download your project to your mobile device while you are connected to the Internet. The ability to continue entering and accessing data is seamless whether connected or not. And the best part is the synchronization happens automatically the next time you are connected to the Internet. No interruptions, it just happens.

Customizations. When we first began developing CxAlloy TQ we met with industry professionals and made some big decisions about data organization. We then incorporated those decisions into CxAlloy TQ. Some of those organizational elements included issue statuses, report names, and permission levels. Over the past year, we revisited these options and decided to allow organizations to customize CxAlloy TQ more to fit their own needs. We believe this will allow even more groups to start enjoying the benefits of our quality management platform. We still believe in providing this structure, which we call, “sensible defaults.” However, account holders now have the option to customize CxAlloy TQ to best fit their internal quality process.

Over the past year, we have been attempting to design and redesign our applications to meet the needs of all our clients. This has been an enormous challenge since our users come from varied backgrounds with some having little to no computer experience while others are pros. We also see a range of devices that are being used. New technologies are coming out at an increasing speed, and everyone wants their device to work instantly. With all these rapid changes, we’ve been consistently meeting to come up with ways to address these challenges.

I found an article recently that articulates the problem. Brad Frost points out in his article, we must work towards a web that is truly “Future-Friendly.” This means that we can’t get boxed in to a particular format and either ignore or react to whatever comes next. We need to prepare now for what’s coming next. This verbalizes exactly what we’ve been trying to do, but have lacked the words to describe it. We must get rid of the clutter, get rid of the distractions that people are now being bombarded with on a daily basis. When people visit our sites, they need to be presented with only the tools and features that they need, not some cute or fancy interface that puffs up the experience.

We also need to cater to our client’s devices. This doesn’t mean everything works in all places the same way. Instead we must evaluate the needs of the user in each situation and address those core challenges. Some of the other ideas out there include responsive web design, mobile first design, and getting away from viewing web pages as, well, pages. We’ll be discussing those later. Check back with us often, we look forward to hearing from you.