Open aott33 opened 4 months ago
This is the last version i have in my figma
Let's move the discussion from the slack thread here for now? Here my mockups from yesterday to discuss adding the option for color for modes, and the corresponding example colors:
Alternatively I also liked the idea of having configurable backgrounds behind the symbols as posted by @ArnaudDeClerck earlier:
I prefer the full background though because the goal would be increased visibility.
I'll post here since this is the highest priority issue mentioning Figma. I'm very new to Figma, what would be the best way to collaborate there?
Is there something that is free for collaborative open source projects?
First reddit hit on my google search looks pretty amazing: https://penpot.app/
I do notice that OpenBridge is using Figma. Is there a way to use it anyway as a team?
What does that mean '3 design files'?
I'll post here since this is the highest priority issue mentioning Figma. I'm very new to Figma, what would be the best way to collaborate there?
I do notice that OpenBridge is using Figma. Is there a way to use it anyway as a team?
Each file in figma has an owner and collaborators. Work as a team by having the owner invite or send link to collaborators.
What does that mean '3 design files'?
Figma is free to use with all the functions you need for this. The 'three design files' restriction means that you can only have three projects so if I'm on Starter and have one figma mockup each for Open Process Library, my website at russwaddell.com, and a storyboard for a video game about maintaining industrial robots, I will not be able to make a fourth file for a new project.
Draw.io (http://diagrams.net) is more minimal than Figma and the collaboration tools are clunkier. It is free and open with no restrictions on features, file count, etc. Collaboration is via google drive, dropbox, onedrive, gitlab, github
So everyone who is invited as a collaborator also has it count towards the '3 design files'? Or only the owner?
Good question. I have three files already and can't make a new one without signing up for a paid plan. If you send me a link to a file you own I'll test and see if I can open and/or edit it.
If you already have three files you can do the same test trying to open and edit this from my account: https://www.figma.com/board/Y06fYz9NPl8i1Stw6pAtlr/Happy-J%C5%8Db?t=SsH9j68zSStj0Dz9-1
Hi I have been implementing IAS components for OpenBridge. We would appreciate to get feedback on our components. Here is the valve component https://openbridge-storybook--pr189-demo-ais-esxofii4.web.app/?path=/docs/automation-button--docs
I like it. Interesting to see that the label is outside the alert box, while we have been trying to cram it in.
The biggest difference with how we do it is having it in a circle. We just put the valve on the pipe, no circle around it. A circle is often used for a pump though with a triangle inside showing the direction.
I like it a lot, aligns for the most part with what I had in mind with the badges and the alarm border.
I especially like the spinner for progress, makes so much sense. Never considered it or seen it on an HMI, but super intuitive because people know it from other applications.
I personally like that the valve icon visually shows if there's material flow or not, not only relying on color but also no need for open/closed text. The circle I don't mind either, first impression was "whaaat a valve in a circle" but why not really. It also helps with hiding the pipe behind the valve in closed state, and fits perfectly with my idea of having (optional) different backgrounds for certain modes or states.
The only thing I don't like is the dark fill color for closed/inactive but that's easily changed and should be a css variable anyway.
I have made a Figma page for the OpenBridge components. We can adjust the components to support your information needs. If you want us to adjust please add comments to this file. https://www.figma.com/design/eNCTx3BWgAmdYleDBUu1CE/Automation?node-id=1-12&t=0nmcQhBcNKEsyu5g-1
@kjetilnordby the first adjustment I would like to see for our use would be the closing of the internal part of the valve to look more like what @Flowject presented a few days ago. That's more typical visualization for our industry.
The second point is that we typically don't have visual circles. Much like what @ArnaudDeClerck presents above we typically create a logical bounding box around the instrument. This serves three purposes.
Thanks. We are considering making the circle optional in the design and include a "flat" button version. This is how we use boundind box in the system now. So the interaction states are visualized across the entire component.
Here is with alert state. Here the icon can be switched with the correct one. In general we prefer to use dark icon on color background since yellow don't have enough contrast towards background to adhere to WCAG regulation. In light mode. In dark mode it is fine.
ok thanks for the explanation. In general we don't use any color/shading inside the bounding box itself. We (and by we I really mean my personal experiences across a number of projects, not necessarily speaking for the entire group) typically will use a border color on the bounding box to indicate alarm/abnormal state and then also color/shading on the internals of the valve/pump itself, but never the field of the bounding box.
If you do a google search for "High Performance HMI" you will get a lot of good references. I think I will take a task today to compile some of what I think are the best. There was a really good book written many years ago on the topic. Interestingly enough most of the work came from research done on oil platforms where the ratio of devices to operators can be extremely high so it's critical that operators are able to locate abnormal situations very quickly.
The color is used only for interaction communication. Hower on mouse over and click indication. So it adds basic UI standards. it is fully possible to not use them in an application since they are only visible on interaction. One of the states are added to support keystroke interaction so you can tab between the components. Im not sure if anybody use that in these interfaces, but it is a standard for UI design so we added the function to the template. on ships we think key interaction might be better in turbulent waters.
Here you can see the gap in the closed and open valve together. It is added to make a farm change in addition to the color change with open and closed valves.
I compilation would be helpful. There is no problem for us providing icon libraries that adhere to the precedence here. There are some differences in regulation for maritime and what we we see in this forum that it is hard to align, (such as alert colors that don't follow the same scale) but in general we hope to create a system that work across as much as possible.
Her is an examlpe with handle.
ok I see the rationale behind how you are doing the shapes. And to be honest, it kinda makes sense but it's not what process is used to. Also with the colors I am assuming this would be a simple adjustment in some CSS. The only thing I am worse at than typescript is CSS so I'll leave all that to the professionals. 😊
yes. all the interaction states are just css changes. We have exposed the valves to quite a few automation engineers in the maritime domain, and so far non has actually complained. Im not sure they noticed the change. ;-) We look at it from a formal graphic design perspective where we always would like to reinforce a message through both color and shape. you can see the hower effect in this demo. These have the circle around the valves which we are considering removing. They make less sense after we expanded the click surface to the label area as well. https://openbridge-demo--pr189-demo-ais-c7zjyt0z.web.app/ias
I like the shape of the valve. It almost looks like two opposite triangles but it makes it clear when the valve is open or closed without only having to rely on the color. (which is the reason some people prefer to add a 'opened' or 'closed' text, further cluttering everything. Additionally it makes the library very recognizable. It will stand out, everybody will immediately see it's the OPL/OpenBridge library.
Another thing I lik is the spinner for opening or closing the valve. I don't know if you already do this but you could let it sping in different directions depending on opening or closing. (spinning clockwise is closing, just like you would intuitively close a tap) You can keep the spinner even without shoing the circle.
About the colors: keep in mind that we will not have white backgrounds: it will be lightgrey:
On the spinner for the valve the way I have always seen it is to flash the topworks on the valve when it is transitioning. Also the top works shows the SP and the body shows the PV. So if you see it flashing you know that it is transition to the SP indicated by the color of the topworks.
we have not though about the direction of the spinner. But that would indeed be a very nice visual que. I think it is likely to catch the direction quite fast.
Our components are made for grey background. we also support different grey tones on the palettes, however all the components will use light for active and dark for non active regardless in order to support isa 101
flashing is problematic in maritime since that is reserved for alerts. which make sense. So to align we would add some ease in and out curves on the animation.
I am going to attach an XML file here. It is an export from Wonderware System Platform styles. It's an XML that has all of the configurable properties for each named style. It could be a very good start to understand what are all the different CSS styles we would typically need and cross reference that with the styles you already have. I can't say I necessarily agree with all of their choices but it's a fast way to get a good process industry set of typicals. Will also work on grabbing images so you can quickly see for reference.
flashing is problematic in maritime since that is reserved for alerts. which make sense. So to align we would ass some ease in and out curves on the animation.
good point on the flashing. I do think people used the flashing in the days before HP (High Performance) HMI so I agree it doesn't quite align with best practices today.
While discussing colors: Honeywell has been advertising a while with dark mode now. I don't know if ISA-101 make any recommendations about that.
Here is the styles XML. Will upload pictures later today. Had to add TXT to get it to take.
While discussing colors: Honeywell has been advertising a while with dark mode now. I don't know if ISA-101 make any recommendations about that.
I do know that best practice in control room design is a dark control room without ambient lighting and only direct downward task lighting. But that's a whole other world and science behind all that.
As long as on is light and off is dark on the components, dark mode should be fine. That is already built into all our components, since it make sense to adjust the palette to ambient light conditions on the ship.
So imagine these graphics without the circle around the components and with handles.
One thing I will add is we will need to be able to represent the concept of a PEA. I don't know that there is a canonical symbol, but now that Process Automation is going more modular, we should be able to represent those.
PEA = Logical Unit? so a Reactor, a boiler, a distllation tower (which may or may not include your reboilers)?
Yeah exactly.
On Tue, May 28, 2024, 8:12 AM andy-gxpaasio @.***> wrote:
PEA = Logical Unit? so a Reactor, a boiler, a distllation tower (which may or may not include your reboilers)?
— Reply to this email directly, view it on GitHub https://github.com/Open-Mobile-Robotics/open-process-library/issues/3#issuecomment-2135321580, or unsubscribe https://github.com/notifications/unsubscribe-auth/AIYYER2RL5QTAT6GS5HM5ZDZESGF5AVCNFSM6AAAAABIG3PNNOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMZVGMZDCNJYGA . You are receiving this because you commented.Message ID: @.***>
What information do you want to show for a PEA? Typically these are custom drawn to represent a simplified version of the actual shape of the equipment.
Here is an updated sketch for the valve icon with handle in on and off status. (without badges and alert states) There this is adjusted slightly from our existing shapes and need more edits since the off state for 3 direction valve is not quite right.
This is an HMI from a pretty typical process systems. The shapes of the valves are directly from the vendor but they are very much aligned with industry standards. This is the screen from a skid machine my customer builds but since they advertise this unit with screenshots and videos of this screen I don't have any concerns about sharing with this group even though I don't technically own it.
Also included one with live equipment. Yes we are using green, it's a fight I lost a while back.
There are a lot more elements about the graphic I could comment on but for now we'll keep it to just the valve.
Thanks. It the S necessary on the valves? It seems like all the valves have it.
Thanks. It the S necessary on the valves? It seems like all the valves have it.
They are all solenoid valves. Not strictly necessary though. The square top kinda infers solenoid. If it was motorized it would be a circle of the same size. Also note the half circle on the analog valve in the top middle, PCV20.
Yes moving away from the green is difficult. Should be easy to configure it like this.
Ideally we should have the objects on an 'example' screen to have an idea how the overall look is.
Agreed on move away. On this platform it was just a matter of changing the style for Active. Say what you will about Wonderware but they did a great job with styles back a few release ago to support these concepts. For us I guess it's just updating a CSS.
Assuming this "example" screen would be a storybook? or is that just for components?
For the
I have a few questions related to the yellow numbers in the drawing. I hope you can help me out here. :-)
Also, Would it make sense to indicate active and non active pipes?
I'll let @andy-gxpaasio answer most of this.
But on your last question: indicate (color) active pipes: this is a question that often comes back from end users. I see on your examples that you have it in your design. We generally push back against the idea because:
I can imagine that maybe a standard skid would implement it, since they would feel the above mentioned problems less, and it would tick an extra box on the customer requirement.
Anway I don't think it should be part of the initial scope of the library.
Assuming this "example" screen would be a storybook? or is that just for components?
I'm imagining that we first would want to have one or more example screens for ourselves, to verify that the designed components look good on an actual process screen. Secondly for promotion once we're there.
- what is this and what does the circles in the circle mean?
- Is this a readout connected to the pipe and is the light grey square with a B a kind of badge?
- why are these light grey?
- it this showing where the pipe is from and the direction of flow?
- what is this and what does the bar in the bottom mean?
- is this a readout with trend? and what dies the yello square indicate? Is it an alert?
- why is there two bars? is it redundancy or is one set point and one actual?
Also, Would it make sense to indicate active and non active pipes?
And the big one. Highlighting pipes. We don't do this because on this system the math to determine when a section of pipe should or should not be highlighted as active gets insane really fast. At that point it is more likely than not you will misrepresent the state of a pipe and give the operator bad information. I take the philosophy that if I can't be certain I'd rather show nothing rather than something I'm 80% sure about. Another issue is that even if you have done the math, it adds a ton of complexity to have to create all the individual segments and animate each one. Also it comes down do opinion. You see the sections with the three things coming in on the bottom left. If the middle valve is open, should the horizontal line going to the pump be active all the way across? Technically yes because material will probably flow backwards a little bit into the deadleg. The questions like that tend to multiply quickly.
Ongoing process that started in the SASE Slack channel. Feel free to add details from the Slack Thread here.