OSArch Community

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

  1. T

    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.

  2. S

    @Coen

    I think the name BlenderBim is the best for the following reasons:

    • Contains the term BIM

    • recalls its origin from Blender

    • It is short

    • it's very simple to pronounce (or at least in Italian)

    • clearly illustrates what the program does (it's not a simple IFC import-export)

    • I think it's perfect! XD

    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:

    • The clear reference to the major feature of the program (the IFC components) is lost

    • It seems to me, from the image attached above, the list is still too chaotic for simple use.

    Since BlenderBim is still undergoing heavy evolution I think that such a change risks being premature.

    I ask if you could:

    • postpone the elimination\moving of the IFC prefix to a future version in which, in addition to separating the elements by categories (structures, MEP,...), it will be possible to include the IFC reference (Ex. MEP - IFC ELEMENT)

    • show the name without IFC-prefix only in the general list in order to allow quick identification and choice and then show the name with the ifc-prefix when selecting the object (I don't know if it's possible and/or if you create even more confusion).

    Sorry for the wall of text, next time I'll try to be more concise

  3. N

    @SimoneC said:

    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.

  4. G

    for that one weirdo whose usecase happens to be merely generating thousands of slightly different walls

    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 !

  5. L

    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.

  6. C

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

  7. D

    Wow, this got quite some response. Thank you all for your input.

    Thanks @Moult for all the work on the new Blender BIM workspace layout. I was using BlenderBim v0.0.230701 before, but now with a dedicated BIM workspace it all starts to make more sense.

    And thank for your insight in where you see BlenderBim in its current development stage. To be in the early stages of AEC software based in a common open standard reminds me a bit of Linux, where some Geeks hack something in existence to build an alternative. It ain’t pretty, but it is a start.

    Metaphorically speaking, I hope that someday there will be a "macOS" too, which has under the hood has a lot of common with "Linux", but focuses a lot more on the UX for not so technically versed users (while still maintaining the ability to do so if needed). Sorry "Windows", but in the scope of this simplified comparison, you would be Autodesk.

    What I can read from a lot of the comments is, that many of the current users of BlenderBim are somewhat technically comfortable to use the IFC schema directly. Or to learn the schema specifications and adapt to a technically challenging environment.

    I‘d guess about 20-25% of users in the AEC business are able and comfortable to do so. But most would rather choose a tool which gets the job done the fastest and is as close to their native domain language as possible, even if it locks you in. Or as an evil actor just convincingly pretends to be easy.

    So the future challenge IMV would be to allow for an easy workflow and UX, while maintaining IFC schema compliance. In the end the tool which allows for the most human native workflow will win (in terms of adoption). IMHO not humans should adapt their workflow to computers, but the other way around. Computers/Apps should be build to allow for an intuitive human workflow, while doing the stuff necessary to be technically correct behind the scenes automatically.

    *Sidenote:

    Somewhere above in this thread was a lightheartedly response of "if it ain't broke...".

    Just think about it and its implications. It would mean living of substance until stuff breaks. The opposite is called Maintenance with constant fixing and improvement so that stuff does NOT break in the first place. I‘d rather choose the later.*

  8. L

    Just to add on the 'IFC schema is a specialist/poweruser/expert common language'. It is true that the IFC schema is not easy if you look at the full schema. However I feel there is like a front & back-end to IFC if this comparison makes sense, some parts of the schema are visible like entities, materials, property(sets) whilst relations and geometry representations (brep etc..) are less or not visible (depending of what tool you use i'd say). BlenderBIM does a good job of showing what needs to be showed (a perfect tool to learn IFC) and hiding what needs to be hidden for non-power users. I feel like this front end is not hard to understand and non-technical people should be able to understand this part of the schema and speak this common language. The back end however i feel is not needed for end-users.

  9. D

    Interesting Tweet from BuildingSmartUK comparing IFC to HTML.

    https://twitter.com/buildingsmartuk/status/1681339546858930185

    True as an open common data format/scheme for interoperability. But for direct user interaction? Maybe not so much. Just think about the popularity of Markdown compared to pure HTML in content creation.

    Thought: Maybe in the long run with growing complexity and scope of IFC there will evolve a new meta format which simplifies creating building "content", which then ist converted by automatic scripts to semantically correct IFC.

  10. B

    It is similar in that HTML and IFC are usually an unstructured mess exported or generated from a database. The difference is that IFC can be that database.

  11. N

    Nice, the menu is faster to read without the IFC prefix, I guess we are programmed to skip through an alphabetical list by sighting the first letter

  12. M

    I've been giving this quite a lot of thought and here's my current proposal which hopefully should satisfy both points of view.

    1. The "IFC" prefix will be removed on panel names. For example if the panel header was named "IFC Aggregates" it shall now be named "Aggregates". This is to prevent every single panel being prefixed with "IFC" which is redundant and not necessary now that we have all IFC panels in one UI spot (or will be, as things continue to converge into the new tab system). However, I will not change the word "Aggregates" or other similar terms as it is a very specific jargon in IFC and I think that is important.

    2. For now, I will undo the change I made to convert terms like "IfcSpaceHeater" (such as in that dropdown above by @Nigel) into "Space Heater". This means that the UI will go back to referring to it explicitly as "IfcSpaceHeater". It is clear that there are two camps here, one camp in favour of more prominently showing the IfcJargon and another camp in favour of more prominently showing the Readable Jargon (and perhaps the IfcJargon delegated to tooltips, etc). The reason I propose to undo it is because I believe although both camps are important, we are from a technical perspective not ready at this time to support the "Readable Jargon". Rushing into it will lead into technical debt and having to redo things later on.

    Specifically, I believe right now effort should be focused on getting the big-picture UX correct first: the big reshuffling of panels and recategorisation. This I believe will have a bigger impact on usability given the effort spent. Only after this is it worthwhile to focus on the details like the exact words within panels.

    Only after this big-shuffling is done, then instead of focusing on "IfcFoo" vs "Foo", I propose to first focus on i18n. I do not want to jump into a solution where we start hardcoding text replacement functions like "IfcFoo" -> "Foo" without a i18n system in place. The i18n system would then support people who want "IfcFoo" versus language-specific terms or autogenerated simple English. In addition, a proper i18n system would be part of an onboarding process: i.e. the first time you install BBIM, it will know it is not yet configured and prompt you to set global add-on settings like your language (or even other things like orbit presets blah blah but that's another UX discussion altogether). This is similar to how when you first load Blender, it prompts for things like theme, shortcuts, etc. This is essentially the "create a config toggle" solution but the way it's presented would be a smoother experience than hiding it in the add-on settings.

    Thoughts?

  13. N

    @Moult I don't think anyone can contest your commonsense proposal, not me anyway

    I think seeing the new BIM workspace generated a lot of interest in UI/UX and that is a good response

  14. O

    Pardon for jumping into an ongoing discussion from both last online meetup and the further extension on the UI talk here.

    Is there a limitation towards using the right panel in the blender code? Would it be a technical challenge to have special made panel be in the upper center of the active working scene? When overlooking the UI talk, I can potentially see that the standard blender panel has a limitation towards how much info you can compress into the existing information panel. Icons is small and also some supportive text is the same. Would it therefore be possible to disengage from blender UI by having some of the info in it's own panel in a horizontal design? As for architects and engineers alike, I assume we use a big cad screen which allows us to have more info on display doe the active scene we work in.

  15. M

    @Ole_Marius_Svendsen nothing is stopping you from re-laying out your panels however you wish. This is merely the default. Have you got a screenshot of what type of horizontal layout you had in mind? I could then let you know whether it's achievable.

  16. O

    It's not within my knowledge if a specific UI is patent. Though as one example, revits UI is a bit more straight forward as an example.

    Is it both realistic, and doable to have a panel in the horizontal direction underneath blenders panel? I'm referring to nr 13-15.

  17. A

    We do have some horizontal panel in BIM Tool and in another tools UI but in Blender it's pretty limited. I'm not sure if it's even possible to have two rows of operators/properties there:

    If we need horizontal panel we can kind of fake it by adapting some other panel that allows using more complex UI (like Properties):

  18. C

    @Ole_Marius_Svendsen said:

    It's not within my knowledge if a specific UI is patent. Though as one example, revits UI is a bit more straight forward as an example.

    Is it both realistic, and doable to have a panel in the horizontal direction underneath blenders panel? I'm referring to nr 13-15.

    I would dislike to see a similar UI in Blender. Blender UI/UX is in my opinion far better. (I also come from Autocad/Revit). Have you tried to play with Blender for a while following some tutorials? Yes it is very different but Autodesk world neither universal neither in my opinion the best in term of UI/UX. In CAD world look at CATIA which is largely used and many other software (ArchiCAD, Vectorworks etc...).

  19. O

    My usage of Revit stretches as far back as 2013 as a credited course during my education. So, i would say i am novice in both Blender and Revit. As for how long i have been playing around, i would say now and then privat and a bit specific usage for my line of work. If CATIA has a better UI, then i am more than confident the on-going discussion on improvement on the overall graphical design choices are in good hand. The best as far i can tell is to shop around for what works in different softwares. The latest monthly meetup displayed good intentions into how and where different functionality should be placed.

    If you feel today's placement of information is well suited to where it is today. Im sure you could elaborate a bit on why not going to the extreme as my UI inquiry and Andrej's suggestion?

  20. N

    I remember similar conversations when software went from DOS to Windows :) or the old Mac versus windows (insert yawn here) debate. Or 'SketchUp doesn't have enough icons to be proper software'

    It is worth asking yourself 'is it better or different?' and 'am I experiencing familiarity bias or exercising objective thinking?'?

  21. M

    Have you checked out the BIM Tool? When it comes to actual editing, the workspace tools provide essentially a vertical "ribbon":

    That said, I think I know what you mean. If we look past the "which overall UI paradigm is preferred debate" what I think you actually mean is that new users are looking for "hey, wheres the big "Wall Tool" icon for me to click on to draw walls?" If I install new BIM software, I expect to see nice big shiny buttons to let me draw walls, doors, windows, furniture, ducts, pipes, columns, etc.

    In BBIM, you have to click a rather innocent looking unlabeled nondescript cube and hope the user was informed enough to load the demo library then find a small dropdown in the top left (since the big tool panel with the preview is hidden by default). This is 3 clicks with the demo library and 9 clicks without. For powerusers these 3 clicks accurately resemble the decoupling of geometry and semantic types. For new users these 3 clicks are a slap in the face from a developer who clearly doesn't know that I JUST NEED TO DRAW WALLS. In less crude terms, new users need maximum discoverability (logic behind the ribbon) ... so I totally see your point.

    Up until now the discussion has been around the properties panels. There hasn't been much discussion around the workspace authoring tools (which I think is what you're actually addressing).

    Here's a proposed solution that is fitting with the Blender UX: 1) big icons in the tool shelf (Blender icons are 16x16px). 2) This effectively acts as a preset to the BIM Tool. 3) Provide quick ways to create basic (i.e. default) wall / door / window instead of having them to click through the type manager. Here's what it looks like.

    You can of course change the scale yourself or even have two columns. But the usability point stands: now the Tool Shelf holds what you'd expect: A Wall Tool. This reduces the demo module clicks from 3 down to 1, and a fresh project from 9 clicks down to 2. Nice!

    This also allows us to have hotkeys to quickly switch to most common object types (walls, slabs, doors, windows...) or via shift-space hotkey so your mouse doesn't have to move far.

  22. B

    I'm really excited to see the 'Create Pipe' icon...

  23. O

    I think you summarized my intention rather well Moult. Regardless of final UI design, a welcoming and somewhat self-explained icons reduce a potential user anxiety learning a new software.

  24. B

    I really like the tools icons on the tool shelf! It would let my colleagues and students get started much faster. I think it would also be good to follow the blender pattern of when you do something it does it with the defaults and then lets you modify the last operation afterwards. https://docs.blender.org/manual/en/2.82/interface/undo_redo.html#ui-undo-redo-adjust-last-operation

    With the parametric nature of blenderbim this pattern can be applied not just to the last operation so why not not start with a simple default if changing the wall properties is a drop down away.

    Really excited about where all this is going!

  25. A

    That is a good example> @Moult said:

    This also allows us to have hotkeys to quickly switch to most common object types (walls, slabs, doors, windows...) or via shift-space hotkey so your mouse doesn't have to move far.

    This is a game changer @Moult

  1. Page 1
  2. 2

Login or Register to reply.