Perspective vs Vision development time

Following on from a recent thread on Perspective vs Vision costs…

As an Integrator, most have an estimate template. E.g. X tags per day, add Y% if using UDTs. Z time per template/screen.

Has anyone compared Vision to Perspective development time? Assume a similar feature set, just comparing would be served up in a Vision client and the other in a Workstation Kiosk/Browser.

I’m interested in what people have to say on this topic.

I will throw in my 2 cents.

I think it takes more time to develop in Perspective for two reasons:

  1. It is a newer product that has very different UI/UX tradeoffs so for us at least there is a learning curve to figure out the best way to translate from the Vision way to tackle UI/UX
  2. It uses a completely different technology which still falls short of being ready for the plant floor because perspective clients cannot interact with the machine files and the security model causes the login to interrupt the entire workflow.

Now how much more time? That is a very hard problem to answer because if you are designing screens for cell phones all the way to workstations then it could be significantly more because more than likely you will need to design multiple different views to accommodate the different screen sizes.

Also good luck designing full blown P&ID drawings without proper drawing tools within Perspective! Now I do realize a third party tool like InkScape can fill in that void, but it certainly makes it a more frustrating and drawn out development cycle especially when I consider that ANY change the customer may want will require the objects to be opened once again in the third party tool.

So my general timeframe multiplier is 1.5x to 2x the time depending on the complexity of the application.

1 Like

I agree with @brandon1

I mostly do perspective development these days (though I sometimes have to develop the same page in both Vision and Perspective) and I feel that Perspective development takes way more time.

I can easily drag some stuff on a screen in Vision and bind my data to a power table, mess around in configureCell some to get any cell coloration or anything going on and be done in little to no time.

With Perspective I have to be cognizant of how the screen will look on phones and on the desktop. Use data transforms just to do simple things like change the background color of a table cell.

Mess around with flex basis settings and CSS to get things to work the way I want them to.

I also think that with Perspective people are asking for * more * features than with our vision application, even though we display the same data in each (for the most part).

People will ask: “I want to filter like how ebay filtering works”, “I want to save my selections so whenever I load this page it will auto populate my dropdowns”

I’ll even have to go in and re-work screens time and time again to account for the lowest common denominator (really small iPhones)

I love working in Perspective, but hate how long it takes to do stuff.

3 Likes

Very true, stemming from people having the “feeling” that they are viewing a regular web page. This leads them to assume that it “can” work like other popular web pages. They don’t know/understand that we lack access to a lot of the mechanisms which make the things on the popular web pages possible.

With vision I would often tell people if they could think of it, it could probably be done. I can’t be so free with Perspective because (right now) people can think of a lot of things that just aren’t possible.

I think that overtime the gap in development time between the two technologies will narrow. Right now I think everyone is still trying to figure out the best ways to do things. I’m certain that someone like @nader.chinichian could build a perspective application much faster than I can. With vision, there are established best practices and a very available knowledge base for how to accomplish most any task. That is what comes with a mature product.

2 Likes

I don’t think this is a big hindrance tbh to creating p&id mimics, especially having the piping tools now. I would have always used SVGs developed in Inkscape to create my device symbols, and with a script to convert perspective SVGs back to standard svg XML, you don’t have to worry so much about not being able to locate your original SVGs.

2 Likes

This is pretty much what it boils down to. With Perspective I have to try and “re-invent the wheel” so to speak.

1 Like

I guess I’ll come at it from the background of a software engineer, and not a controls engineer and say that my group finds Perspective development significantly faster.

Primarily we focus on data heavy projects, not as many HMIs with detailed P&IDs and what-not. Perspective offers so many more comprehensive tools for transforming data that we end up being able to knock out Perspective content much faster than it takes us in Vision.

I think because Vision is more akin to more “legacy” HMI/SCADA tools, it is faster for those who are used to that space. However at this point I primarily aim to hire web developers and software engineers, and the familiarity with React/CSS and the web world makes it much faster to develop.

It really depends on you and your teams background, and what type of projects you work in.

In terms of building responsive taking longer, I would say that’s due to it being an added feature? If you were to built 3 screens in Vision (with the legacy mobile module) instead of 1 responsive screen in Perspective it would take much longer. If we are talking 1-1 in terms of building a non-responsive perspective screen to compete with a vision screen, I find it much faster to put it together in perspective. That being said, the longer you build responsive, the more natural it becomes. To the point that we often build screens responsively with little to no added cost, because it becomes natural to the engineers to design that way from the beginning. This ends up giving clients more “features”, without really adding significant development time.

5 Likes

I take your point but I do not want the development team at IA to think that not having built-in drawing tools is acceptable. I don’t need all the features of a third-party tool but at least let me draw primitive shapes. And if I bring in an outside SVG make it easy for me to manipulate it within Perspective. That’s all I’m asking for.

At first I was thing like you that drawing tools is very critical in SCADA HMI applications but after some heavy projects I find out even the vision drawing tools is nothing compared to Inkscape or illustrator. If you want to draw objects fast and organised them in easy way you need to use those tools. I can say for some applications it is impossible to draw and make dynamic object even in Vision or ther legacy HMI software.

Even in future if IA introduce drawing tools believe I will use Inkscape because of the comprehensive toolset.
What lack here in perspective compare to vision is selecting a part of SVG object doesn’t select the elements automatically for us like Vision.

In Vision if you know java you can almost manipulate any thing which is hard and same is true with CSS in perspective but CSS is really easy to understand and learn. So me perspective is much powerful to Vision even I came from legacy world. So if you’re engineer doesn’t know both JAVA and CSS I would choose perspective as he will spend less time to learn perspective.

If someone want to learn perspective he should forget about the old workflow and start to learn web concept which is fairly easily but people tend to lean toward what they used to do.

I say if you don’t considered responsive design and only target same result as Vision you need only 20% more time. Why 20%?
Because Perspective UI is much slower compared to Vision and there are still bugs which make designer unstable and cause you loss some time.
Of course passing time make those problems less and less as IA focus on perspective.

At the end, you always have to consider price. Unfortunately perspective price tag is too high compared to Vision which is deal breaker in some projects

8 Likes

This. This is the main thing I miss from Vision as well RE SVGs, being able to select SVG elements as individual components, however I don’t see this changing in Perspective tbh and it would probably increase resource requirements on the clients including in the designer which would then slow down your pages.

In terms of dev time, the biggest increase in labour is noticed when developing P&ID mimics in Perspective compared with Vision, with the main reason being that Perspective is slower/laggier than Vision. Although I do think it’s getting better in the latest releases. For forms though, Perspective is the clear winner and actually saves you time. Instead of having to worry about using arrow keys / alignment tools to position your labels and inputs, you can just use the power of flex containers to automatically position your components. Once you fully understand how these work, they make short work creating user entry forms. Adding new fields is super easy compared with Vision where you’d have to manually reshuffle everything.

I think the worst thing in Perspective in terms of creating P&ID mimics is grouping. In Vision, you select your components and either Group or Containerise them depending on what you want to achieve. In Perspective, you can’t multi-select components to group them, but more importantly, even if you could and/or grouped them manually into a coord container, it still sucks big time. When developing in coord containers, it’s almost impossible to dev when they’re in percent mode, so I set to fixed mode in dev and then forget to change it back to percent mode for display in the client. But when you have groups using embedded coord containers, this is a massive nightmare since really you want to change all coord containers to fixed mode, and then back to percent. I guess I could bind the prop…

One thing I also really miss in Perspective is the ability to revert a View to its “master” size in a coord container. This is a massive inconvenience. So much so that I’ve actually been meaning to write a script to do it for me, although running the script would be a pita and would be ugly :confused:

4 Likes

One thing I forget to mention the user mouse event like dragging is extremely slow compare to vision because all event script is handle by python and as browser can’t run python they are exe in server side, so you can create smooth dragging in perspective.

That’s why I wish they let us do code java script for perspective client side and have component to write and link html, js by it so the possibility to add anything you can imagine is unlimited. If you see and like an specific chart in internet you can easily import it in perspective by this. (Using SDK is headache)

We have same concept in node red by uibuilder.
https://www.google.com/url?sa=t&source=web&rct=j&url=https://flows.nodered.org/node/node-red-contrib-uibuilder&ved=2ahUKEwjqjp7E5Jr5AhU-X_EDHe2ZBcQQFnoECAsQAQ&usg=AOvVaw33NJcnDDXC9InPZzP1Rw2P

1 Like

You can use webDev if you want to build HTML and JavaScript and regular Client frameworks etc but then you have to take care of authentication/authorization communication with tags data base etc etc! Perspective does it for you it’s not just the UI components. You can’t get best of both the worlds in my opinion!

1 Like