Architectural domain language vs. IFC schema language in User facing UX/UI

D by doia on 13 Jul 2023, edited 23 Jul 2023 #

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?

M by Moult on 13 Jul 2023 #

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?

D by doia on 13 Jul 2023 #

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.

M by Moult on 13 Jul 2023 # +2 votes

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 :)

C by Coen on 13 Jul 2023 #

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

IFC is good and needed, but should stay on the computer side of things.

I kind of agree you don't need to know in detail like a defintion of an IfcExtrudedAreaSolid as an end user. For example

the extruded area solid (IfcExtrudedAreaSolid) is defined by sweeping a bounded planar surface. The direction of the extrusion is given by the ExtrudedDirection attribute and the length of the extrusion is given by the Depth attribute. If the planar area has inner boundaries, i.e. holes defined, then those holes shall be swept into holes of the solid.

But a good defintion of what a wall is, in this case is IfcWall is so critically important, not only to software but also humans.

The wall represents a vertical construction that bounds or subdivides spaces. Wall are usually vertical, or nearly vertical, planar elements, often designed to bear structural loads. A wall is however not required to be load bearing

D by doia on 13 Jul 2023 #

@Moult said:

I guess part of the reason is that most of the UI is actually generated and dynamic from the IFC schema.

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?

M by Moult on 13 Jul 2023, edited 13 Jul 2023 # +2 votes

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.

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:

Moving and renaming panels to remove the IFC prefix
IFC class assignment removes the IFC prefix and separates into words e.g. "IfcBuildingStorey" becomes "Building Storey"
CapsCase attributes get separated e.g. "ObjectType" becomes "Object Type"
IFC Type class is not necessary for IFC4. Just show the name?
Potentially merge spatial containment and aggregate panel as it is all part of "decomposition"?
Name cleanup e.g. "IFC Object Property Sets" becomes "Property Sets"

Note that some things have significance e.g. "PsetWallCommon" 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?

B by brunopostle on 13 Jul 2023 # +1 votes

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

T by theoryshaw on 13 Jul 2023 #

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?

B by brunopostle on 13 Jul 2023 # +1 votes

@theoryshaw said:

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

DE: Wand - Typ
EN: Wall Type
FR: Type de mur

B by bruno_perdigao on 13 Jul 2023 # +2 votes

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.

C by Cyril on 15 Jul 2023 # +4 votes

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.

M by Moult on 15 Jul 2023 # +5 votes

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?

N by Nigel on 15 Jul 2023 #

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

N by Nigel on 15 Jul 2023 #

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 :)

M by Moult on 15 Jul 2023 # +1 votes

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?

M by Massimo on 15 Jul 2023, edited 15 Jul 2023 # +6 votes

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 :-)

N by Nigel on 15 Jul 2023 #

@Moult said:

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'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

N by Nigel on 15 Jul 2023 #

@Massimo said:

I would stick to the schema

This is just my opinion btw :-)

if it ain't broke...

A by Arv on 15 Jul 2023 # +3 votes

@Massimo said:

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.

B by baswein on 15 Jul 2023 #

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)?

A by Ace on 15 Jul 2023 # +2 votes

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.

T by theoryshaw on 15 Jul 2023, edited 16 Jul 2023 # +9 votes

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. :)

https://twitter.com/theoryshaw/status/715909770239037440

C by Coen on 15 Jul 2023, edited 15 Jul 2023 # +1 votes

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

S by SimoneC on 15 Jul 2023 # +5 votes

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.