22 aug 2018-09 Setting the standard and the Return of the Tree
This post is also available in Swedish: Sätt en standard
For me perfection isn’t the idea of something that’s flawless, but something that is consistent in the way it’s doing things, how it works, what results it yields or even its limitations. A strive for perfection is in a way a strive for consistency, a cohesiveness or, if you will, a standard.
Is it better to have a flawless performance under optimal circumstances or a consistent performance under varied circumstances?
Is it more important that we do things a certain way or is it more important that the results are comparable and consistent?
How do you create the “perfect” tender?
If we allow ourselves the premise of perfect equalling consistent; How do you ensure that your cost estimation process results in a consistent format that can be reproduced and remains transferrable to other people in your organisation?
While developing Geometra we’ve aimed to keep true to the idea of a standardised way of doing things but at the same time making sure we open up for real creativity to come to life in how we solve challenges that arises during the cost estimation process. If you would indulge me I would like to dive into our ideas a little deeper. Heads up though, this next part might get a little theoretical.
With Geometra we want to provide you with the framework for creating your own standard result of your output. The level of the output is up to you to define; whether you want a super detailed, well described and thorough model or simply a brief overview of the project, Geometra provides a way to build that. Our framework is based on a couple of global assumptions about the process but leaves you free to create your own standard within them. The assumptions:
- Information needs to be structured in relevant scope and order – this can be achieved by utilising the Annotation Tree and creating folder structures for information sorting.
- Annotations need to be able to have properties, contain data and serve multiple purposes. By entering data in both the Annotation Properties and the Annotation Rows you can achieve additional levels of detail in your data and information.
- Working on projects must be a collaborative process, built so that information can be forwarded or transferred to other parties involved in the process. No part of the construction process is an isolated event without dependencies. Sharing project information internally in your organisation is easily achieved by using Geometra.
- It needs to remain easy! Easy to understand graphical user interface, easy to learn features and an easy way to contact support – these are all things we work hard on to make sure we keep in mind.
Translating the above into the real world
It’s all fine and dandy to talk about theory, but how to make use of this in the real world is quite a different beast all together. Luckily there’s a saying that comes in handy in times like this;
“- How do you eat and elephant?”
– One piece at a time.
We talked about estimation methods the other day and are very well aware that there are probably as many views as people on what this is, but we’d like to offer our view on A method of doing it. Feel free to use it as inspiration!
For the Annotation Tree we see a way to dividing and sorting the project based on which types of rooms or objects and which order they need to be worked on.
In our small example (on the left) we’ve got many different rooms divided up in folders tagged E01-E05 to mark work order. Each group have been named appropriately for their content. Offices, common areas, technical areas, misc. areas and interior walls.
Right here we can start to see part of the planning stage as we’ve already defined which order, what and where we have work that needs to be done.
Each Annotation, or object/room if you will, contains a set of base data. This data can be used to represent information like colour coding to help you visualise project layout, order, types or events.
Base data for Annotations, or as we refer to them in Geometra: Annotation Properties, are a couple of fields that give you a way to better define the global properties for that particular Annotation. These are:
Base data also includes square meters, lengths, volumes and wall surfaces of various parts of the Annotation. These can also be transformed from data to information by using them with the Annotation Rows that are available in Geometra.
Converting base data into information is done by giving the base data context, like saying the wall needs to be painted, or the floor needs to have oak wood parquet. By placing data into context, we generate information that lets people understand what we’re going to do, with what, how much and where we’re doing it. In Geometra we use the Annotation Rows as a way to facilitate the data -> information conversion that needs to happen.
Data != Information
I’ve talked a few times in this post about data being converted into information, but for some of you out there this might sound strange – isn’t data and information the same thing?
Well not really, I try to explain it like this:
- Data: Data is the presence of properties or values. Properties and values don’t mean anything by themselves until they’re put into context. For instance, you might have a wall that’s 15m2.
- Information: Information is data that has been put into relevant context for you to partake in. This is where we define our data into something that we can work with. The 15m2 wall that we have in our data set can now be transformed into e.g. 15m2 of wall that needs to be constructed and painted.
Here’s hoping that this post provides you some insight into how we think and develop around the idea of Geometra, the cost estimation process and collaboration. If you have any questions, please reach out to us – are we missing something, do you have a completely different view? Let us know!
// Fredrik, CTO & Founder
A couple of months ago we made a release which aimed to bring the functionality of the TreeTable model to web client of Geometra but sadly something didn’t work out as planned in the underlying technical structure of the release and we had to pull it back and go back to the drawing table to figure out what went wrong. I’m happy to let you all know that we believe we’ve solved the technical difficulties and are bringing this feature back onto the live versions of Geometra again today!
The Annotation Tree is making its return along with some other features and bugfixes but the majority of this release is actually a technical update along with new versions of server ware and middle layer upgrades to get everything running again.
We’ve compiled a guide for the new Annotation Tree, which is live again over at: https://www.geometrasoftware.com/en/support/guide-annotation-tree/
This release contains upgrades and fixes as follows:
• Fixed a bug where the project name didn’t display properly in the delete project dialogue.
• Fixed a tooltip error where singular definition of text was displayed when multiselect was made.
• Removed download button when selecting folders, the download wasn’t meant to work anyway.
• Removed the open option when multiselecting files, we currently only support opening one file at a time.
• Fixed a bug when multiselecting was displaying incorrect filename.
• Fixed a bug where downloaded files would receive an extra file extension to the file name.
• Removed a misplaced label when the dialog for upload file was shown.
• Implemented the upgraded version of the Annotation Tree, se guide for more information.
• Shift select for interval selection
• Drag ‘n’ Drop support for folder sorting
• Expand/Collapse all folders in view
• Detailed search through all levels of folders
• Folder content labels
• Added progress bars to several steps when selecting Annotations to better show when the app was working on something.
• Ctrl + A now works to both Select all and Deselect all Annotations in a project.
• Rewrote select and edit layers for Estimate view to improve data flow in the application and speed up GUI actions.
• Optimized callbacks to the GUI to improve flow and speed of the GUI.
• Fixed a bug when hitting ESC during the placement of an Annotation wouldn’t correctly reset the annotation tool.
• Fixed a bug where incorrect label was shown on Display Values selection box.
• Fixed a bug causing the mouse cursor to display the wrong cursor graphic, should now be more consistent with applicable action.
• Fixed a bug where incorrect formulas for Annotation Rows would display very weird results, should now display a correct ‘Incorrect Formula’.
• Fixed a bug where scales could incorrectly be created multiple times on a single PDF page.
• Upgraded compression in socket layer to improve speed and reduce network load.
• Made improvement to batch management of data.
• Upgraded compression in socket layer to improve speed and reduce network load.
• Added better batch management on server when working with larger data sets.
• Added additional verification to a method for checking scale inserts and updates on PDF pages to prevent a bug.