Architectural domain language vs. IFC schema language in User facing UX/UI
Hey there,
What I noticed is that BlenderBim uses a lot IFC schema specific commands in its UI (almost exclusively). I have the feeling, while trying to effectively use/learn it, I first have to learn the IFC schema instead of concentrating on my specific domain knowledge.
E.g. instead of adding a wall and giving it a thickness of x with a fire rating of y, I have to add an IfcWall with selecting an IfcWallType, and specifying an IfcObjectMaterial with an appropriate IfcPropertySet which at that point I get completely confused and will mess it totally up.
For me, IFC is the language of the data structure / schema and thus primarily a computer related language. It is used to structure and describe the AEC domain to make it machine understandable. On the other side is my architectural domain language, which I use to communicate with colleagues and other stake holders on an actual construction project.
I know, as our working environments get more and more digitised and reliant on computers, it is necessary to become computer literate and at least gain some understanding on what is behind the 3D models we develop.
But IMHO AECO modelling software should use the domain language of the construction industry (architectural, structural, mechanical, engineering etc.) in its user facing GUI and translate this behind the scenes into a valid schema language and structure. Not force the user from the AEC domain to use a primarily computer related domain language.
So, I am interested in your opinions on how to deal with this gap. Is there a somewhat distant roadmap to maybe streamline the GUI of BlenderBim to make it more AEC domain like. Or do I have to life with it and learn the IFC schema?
How does an IFC schema language acts as an entry barrier for AEC domain people to use software?
Comments
I'd be curious to know exactly which parts of the IFC schema language doesn't click.
For example a "wall type" is a perfectly regular architectural jargon. Similarly a "fire rating property" is also pretty normal. Specifying the object's material is also ... pretty normal?
There are a few parts which IFC is a bit too specific like aggregates vs containment for everyday casual language, but is it really that often?
Ok, IFCWall and IFCWindow might be a bit too simple. But then why not name it directly Wall or Window? While other things like PSet_WallCommon don't even occur in the everyday language.
It's not about an unwillingness to learn the IFC schema, but why? Why not use the known domain language in the GUI directly? IFC is good and needed, but should stay on the computer side of things.
No hard feelings @Moult , but you basically live and sleep with the IFC definitions. Not so other users/architects, which just want to use OSS and open data formats for their work without learning a new language.
I guess part of the reason is that most of the UI is actually generated and dynamic from the IFC schema. Another is that we tend to have a lot of IFCs out there in the wild and it is actually really important to educate users on the quality of their IFCs, and "hiding" the exact IFC data will lead to a lot of misunderstandings. At least this is the case for large companies who already produce IFCs from proprietary software, and have lots of assumptions about what is and isn't in their IFC.
For example I get a huge amount of questions about generated quantities or locations by other viewers, or even Solibri which notoriously puts their own classification on top ... it's persuaded me that at least for now, being true to the IFC jargon is the right move.
That said, the UI has evolved over time to become "easier" despite the roots in IFC. I see this trend continuing, so hopefully the experience will improve :)
I believe that knowing the IFC language is key to succesfully collaborate on projects. And I don't think it's that hard to learn and everything is very well documented and available on BuildingSmart
I kind of agree you don't need to know in detail like a defintion of an
IfcExtrudedAreaSolidas an end user. For exampleBut a good defintion of what a wall is, in this case is IfcWall is so critically important, not only to software but also humans.
I see, this explains a lot. I had the impression that the GUI was deliberately created this way. I know BB is early alpha, so I hope it will evolve.
Regarding the education of the user I have a mixed view. Education is good, but right now it feels more like force feeding.
The GUI of any software should be as easy and intuitive as possible to the intended audience by default. It also should expose the underlying structure, but only if explicitly desired. Think of any Email program: you wouldn't expect the user to set the TCP header and what else correctly. You wouldn't even show these complex option to the user, the program would do this correctly on its own. If you have the option to edit everything, you also have the option to edit a lot of it incorrectly, if you don't know what you are doing. The bare minimum an email prog needs is address, topic and content. the rest is done by the software. But you have the option to view the raw source of an email if you desire to and analyse it.
So, one intend of this thread is to discuss and build opinions on how much or less IFC knowledge is necessary to do the job as an architect? And how much of it we can leave to the software developers? How to make the software as easy and intuitive for AEC whilst still generating correct IFC files?
Yes, except that this isn't typically how things are done in the free software world. In the proprietary software world, often the sales and marketing is done first, and so that end goal, workflow, or UX (and sometimes even the UI) is designed first. So we might start with "We want the user to click the Wall Tool, then click a start and end point and a wall will appear".
In free software, often we'll ship a functional version first just so that the technical geeks can have it "working on my machine". This often comes at the tradeoff of really ugly, unfriendly, or unintuitive interfaces. So creating a wall might only work with code, or work if you press 5 buttons in a particular order ... things which seem bizarre to most users but whoah super cool to developers who actually want to use code or for that one weirdo whose usecase happens to be merely generating thousands of slightly different walls. The "wall in 2 clicks" happens a bit further down the road.
There are pros and cons of both approaches. The free software approach often means that you'll get something working really quickly. Like, crazy quickly. Terrible, but quick :) It also means that if you do have a technical background, often free software is incredibly flexible. It's hard to describe just how much it is like night and day when comparing the flexibility of open source software compared to proprietary black boxes. That's because it's built first with the idea of building good under-the-hood tools, not a "point and click UX first". It also means that free software is often more "true to spec". When it comes to compliance, transparency, or trustworthiness, the free software approach excels.
As free software matures, often they will improve on the UX aspect, polish and intuitive UIs take a higher priority. But this takes time. I'd argue that the very first email clients were very technical and it took time for this to be hidden. We are breaking new ground as the world's first native IFC authoring platform, so it'll also take a bit of time to figure out "what's the right way to present this?"
tl;dr absolutely agree with you, just that I also believe the stage we are at is a necessary part of the evolution. I'd love for it to happen faster, but for that we need more contributors. Including posts like yours who take a more critical look at it. Even better if you could turn your ideas into a proposal / mockup. Good UX can be the difference between FOSS that stays small and FOSS that becomes accessible and grows.
Note that prefixing all panels with "IFC" was also necessary to distinguish between Blender data and IFC data. Now that we are creating our own tab system (have you checked the latest developer builds in the past few days?) perhaps we can rethink this.
Now for something constructive, can you submit a bug so that we can track this issue? Here are some ideas:
Note that some things have significance e.g. "Pset_WallCommon" is something I think you'd just have to learn. Anything with a Pset_ prefix is a ISO standardised property set and renaming it in any way will be harmful to users who have contractual requirements to use specifically named psets.
I'd love to hear other opinions too. Maybe they feel strongly the other way, that the IFC jargon should be exposed as much as possible?
Note that each IFC entity has a human readable version, eg. IfcWallType is also defined as Wall Type and there are German translations etc.. the GUI could use the blender i18n stuff to automatically show Wall Type when it would otherwise show IfcWallType
cool, i might know already, but where is this codified/documented?
At the top of each page in the spec there are some Natural Language Names, presumably these are already in the machine readable spec: IfcWallType
I generally agree with the idea of having less IFC jargons in the UI and a few tweaks (like removing the IFC prefix) are very important in the long run to make the software more appealing to new users. However, I still think that learning IFC will always be important at some point. Maybe not too technically, but I see IFC also as a way that we all "speak the same language" when collaborating. It gives us accountability for the information that we are creating. And, although the UI/UX should always be improved, I don't see a lot of proprietary software as necessarily being easy to use. AutoCAD, Revit and Archicad (the ones I used) are also full of their own jargons and technical stuff. Even Sketchup can demand high technical skills if you want to do a model that is closer to BIM.
In my opinion the human readable/domain language should be in front in the user spoken language but also the IFC term behind should always be visible. Using tooltips the same way you are able to see python function using python tooltip is in my opinion one of the goodway to go. Another very handy way I saw in a game is a shortcut to temporarily toggle all UI to «base language» but it might no be common or possible blender way.
OK, a few commits have gone in. The first is the removal of the "IFC Foo" prefix for panel headers. This I think we all agree is no longer necessary now that we have dedicated BIM tabs instead of the previous situation where things were mixed in with Blender panels.
The second is only a small example of what things would look like if dropdowns auto converted from "IfcWallType" to "Wall Type". No tooltips (yet?). What do you think? Yes? No?
Is it possible to add a Tab... so the user knows here lays 'all things IFC/BIM'
maybe Blender doesn't allow this?
It looks fine in the Ifc Class menu to not have 'Ifc' but in the scene properties menu I feel a bit uncertain if it's purely Blender or BlenderBIM
Also, is it possible to add a Hyperlink button somewhere in the BBIM menu to https://blenderbim.org/search-ifc-class.html as I need that so often :)
Blender doesn't allow us to add tabs, that's why we use the "scene" tab. Everything in the scene tab is now IFC unless you go into the dedicated Blender subsection of it. The BBIM menu has a built-in search, doesn't that make the website redundant?
I would stick to the schema as more as i can and so, for example, i would not remove the Ifc prefix.
I try to explain why: for the first time (i guess) we have a common schema where things are defined in a standard way and this schema is, of course, the IFC schema.
One of the things that i like about BBim is that we can easily create ifc things through BBim interface (and i think it is one of its main features). If we use our jargon, we create confusion about what are we trying to create. For example, i create a wall: is it an elemented wall? Is it a layered wall? Why not call it Wall or WALL?
So, for me, it's more simple to say: i create a IfcWall. What is an IfcWall? Let's take a look to the schema, somebody else has already defined what is it and it's a ISO standard so i use it.
Otherwise, it would be like to come back in the days when, using Autocad, a person named the wall layer Wall, another one WALL, another one walll, another one Wall-E (maybe a Pixar fan) and so on...
So i think that the best thing to do now is to focus on simplify the interface in order to make as simpler as possible to create ifc things.
Maybe, in the future, we can afford to dedicate time to create a better jargon but, for now, i think that it should be better to focus on more important things...
This is just my opinion btw :-)
I'll just re-program the brain to see BIM when I see the cone and sphere.
The search is a really nice addition but the website does give, albeit a techspeak, in-depth explanation that helps sometimes
if it ain't broke...
So, for me, it's more simple to say: i create a IfcWall. What is an IfcWall? Let's take a look to the schema, somebody else has already defined what is it and it's a ISO standard so i use it.
Totally agree with Massimo. And in the end, its not just any random wall, right? Its a particular data type called IfcWall, so why not just make it plain and visible and this makes it easy for users to check the schema and documentation too.
I find the Ifc prefix and caplital case makes things much harder to read and as I imagine introducing this to my collegues a turn off for them. What if IfcWall showed up on hover or was written as** Wall (IfcWall)**?
Maybe a checkbox /toggle to see if you want it to say "Wall Type" or "IfcWall Type" ?
I think people are always going to want to do the simpler thing, and searching alphabetically makes more sense without the Ifc prefix.
From a UI and UX perspective all the Ifc prefixes are just clutter, the simpler, the smaller, the better and easier it will be for the whole thing to be adopted, rather than saying hey you need to know everything is an IFC this and that from the get go.
I don't think it's that complicated to be honest but a toggle could help people get into it, removing the Ifc prefix would really simplify the UI.
I could be wrong, but I have a sense, if really distilled, the initial confusion with how to use BB is probably more because of a clunky UI, then it is the IFC jargon.
I guess I'm leaning on keeping the IFC prefix on things--as it provides a constant reminder that BB is couched in the IFC schema. I feel if you abstract away the underlying schema you lose the opportunity for users and developers to put pressure on BuildingSmart to improve things--as the initial reaction to a problem will be focused more on the program, when in realty it's the schema's shortcoming. _ (We all know there's a lot of examples like this)_ :)
In my opinion, FreeCAD and BB, have been a real important feedback loop for users/developers to realize that certain shortcomings in the program are not the fault of the program, but the schema and as such, are more empowered to provide their 2 cents back to BS. I think BS needs to hear this.
I also think too, having the UI obviously based on the schema, that it helps new incoming developers to quickly get up to speed, as it also helps inform future development-- acting as a roadmap essentially.
At the end of the day, IFC is basically a glorified classification system to help everyone speak the same language in the AEC--to help us collaborate better with one another. Like other classifications system (MasterFormat, Uniformat, etc.), it pays to learn it and use it, and not create our own mapping for it. If we do, we'll create another offshoot to the tower of babel.
...
I created the following as an April fool's joke once, but still think it would be awesome if by some miracle it came true. :)
Hello everyone,
Thanks for accepting me,
First of all thank you for what you are doing, I think BlenderBim is a beautiful software with huge potential.
I signed up because I think the removal of the IFC prefix is a strategic mistake.
I think the main and most valuable feature of BlenderBim is to be an IFC editor
This can also be seen from how entities are called.
A BlenderBim wall is not just a Wall!
It is a wall made with the ifc standard!
By showing this thing to people who don't know the program, they immediately understand the difference (or at least that's how it was for me).
I think hiding the IFC prefix hides BlenderBim's true potential and making it look like a simple 3D construction modeler (like one of many).
Thanks again for what you are doing. I think construction really needs a program like this.
I absolutely agree with @Massimo
To stir up the disccusion some more, why not rename BlenderBIM to the IFC add-on for Blender? I read somewhere the Blender does recommend using the name Blender in third party add-ons. This way you remove one problem and really explictily say what the add-on is about in the name
Both ways have their pros and cons. The IFC-prefix shows that the elements are part of the IFC namespace, not just random objects. However, it is tiring to read through all these words that start with IFC, e.g. when selecting an entity.
It would be great if there was a setting to swith between the two: for pros / devs to see the IFC Entities, and for users to se the locale name as suggested by @brunopostle and @Cyril. This would probably also speed up the translation in the IFC documentation that is not very complete atm.
@Coen
I think the name BlenderBim is the best for the following reasons:
From my limited experience, when people talk about BIM they think it is the 3D modeling program which allows them to export the IFC file (or even to Revit).
Obviously this belief is wrong.
But people have been taught to think this way by software houses.
Because, for example, when I had to update the calculation programs that I use, I bought the "BIM extension" of the software not the "IFC extension".
For this reason I think it is right to use the word BIM as a keyword in the program name and not replace it with IFC.
Because people (or at least me and those I know) google the term BIM first
Regarding the reference to the term Add-on
I think BlenderBim has all the potential to one day become much more than just a Blender add-on
As we have seen these days following the excellent work of Moult, BlenderBIm needs its own U.I. heavily customized compared to the standard Blender one.
I think that in a few years (or months) when we open BlenderBim we will be faced with a working environment much more similar to Revit, Allplan, Archicad,...
By calling it "IFC add-on for Blender" we would be debasing it.
Furthermore, there is already at least one example of this type: Z-Anatomy
About the IFC-prefix...
Couldn't the renaming be deferred to a later version of the program?
Removing the prefix increases readability dastrichically.
But:
Since BlenderBim is still undergoing heavy evolution I think that such a change risks being premature.
I ask if you could:
Sorry for the wall of text, next time I'll try to be more concise
No apology required in my opinion, any shortening may have lost your strong argument for a 'collective pause and think first' before making changes.
Concerning looking more like archicad or Revit, I just see those interfaces akin to factory farms of icons with hundreds of livestock pens of menus and on the counter to that is SketchUp with a simplicity that I think self-sabotages it's chances of being taken seriously as an end to end architecture app.
Somewhere between these extremes is a fertile ground for BlenderBIM's UX & UI.
I know it may not be fashionable in some circles but the excellent real world work of Ryan has highlighted the printed architectural drawing (albeit PDF typically) is alive and kicking. A well composed drawing sheet of crisp linework render with carefully considered lineweights, a judicial application of hatch and texture not to mention sufficiently dimensioned and curtly notated all laid out with an eye for viewers experience catches our attention and lays bare the experience and talent of it's creator more than any render. To this end my interest is in the UX & UI of the drawing/sheet creator, I haven't seen any great examples in the established CAD/BIM apps for inspiration but all have some elements to emulate or avoid I'm sure.
Haha I don't know what you mean.
I really like this discussion and the enormous UI changes that took place since a few days. The UX world and the technical world are really crashing against each other for the first time it seems. I'm eager to see what will come out of it !
I have to say i agree as for now with keeping the used terms as they are defined in IFC. I've just seen already too much confusion with people using BIMCollab & Solibri, where some attributes get aliases and in the and you don't know what attribute/propertyset etc.. you are dealing with. Furthermore, to take an example of a multi-lingual country as Belgium there is always confusion about every object because people communicatie in French/Dutch and local dialects. Pointing towards a common language like IFC can really help there. To end, I do think it will enhance IFC interest and knowledge, which again I think is key if we want the industry to evolve.
@lfcastel I agree that a common language is required and that's why I suggest to keep always IfcClass clearly visible somehow. Although ifc schema is a specialist/poweruser/expert common language. You have probably noticed how many technically qualified people have been struggling with all the bim jargon and how many people took advantage of that to provide bullshit services. Yes it should be made easy to learn the common language (ifc schema) but front door must be welcoming, it must talk our real life common language used in our building industry. I work everyday with a very qualified person which is freaked out by an English UI and I have been doing support for many people which struggle so much more. I am almost sure that people on this forum are polylingual specialist. Don't leave other people out.
Switzerland has 4 official languages. When you see professional associations/standards etc... , people of the second most talked language already feel left out by people of the most talked language. Most standards are not even translated in the third most talked language and I do not even mention the fourth one I don't know what it looks like.
Let the common language be just behind to leverage curiosity and let people find it out when they need it.
Otherwise I would vote to not support imperial units because come on what could be farther from a common language ?