How do I master a Ignition Perspective?

Ignition
,
1

Hello guys,

I have used Ignition Vision for quite long and its totally fine about it. Currently I’ve some projects lined up which has heavy Perspective module in it.

I do have earned Ignition v8 Core Certification, however i want to learn perspective in deep like in vision. So is there any helpful stuff would you recommend?

For a start, I’ve downloaded demo application and learning from it so please suggest. Some stuff like how do we decide which container must be used here and like this.

2 Likes
2

I had to brute force my way through “mastering” perspective, and it still has many aspects that I am not sure I am handling perfectly correct. However here are a few tips I can provide for someone transitioning from Vision into Perspective for the first time.

1. The coordinate container is your enemy, and the flex container is your friend!
Everyone ALWAYS seems to latch onto coordinate containers because they feel really familiar compared to vision, however the further you get into your journey with Perspective you will realize this is not the best way to approach things. In the beginning nesting flex containers is almost always the way to go when trying to put together responsive pages. The more you build pages in this way, the more obvious it will become, and you will realize that your starter coordinate container pages were just not the right way to go.

2. Love the transform
Binding transforms in Perspective are one of the most valuable tools in your arsenal. Being able to query database data, then manipulate it before displaying it on the screen is very powerful. You will start to see how you can make applications extremely dynamic by utilizing transforms.

3. Always bind UP and not Down!
I always would find people binding components to properties of other components in ways that just fall apart in Perspective. In perspective when you change the structure of the page with new nested containers, you will break all of your bindings and be extremely unhappy. Utilize custom properties on your view in scenarios when you need two or more components to share a piece of data. That way when you bind the components to their parent properties, you will find that you can put them in any kind of containers you want without ever breaking your pages.

4. Leverage the knowledge on the Exchange
One of the most crucial steps when I was learning Perspective, was when the Exchange was released. It was the first time that I was able to “see how the pros at Inductive” did things. When I first used the Ad-Hoc Trends page by @mraybourn it taught me numbers 1-3 in this list! I had started to realize those on my own, but it confirmed my thoughts that I was headed in the right direction. I haven’t gone through everything on the exchange obviously, but look and find something useful to you. Then pick it apart and see how someone else did it.

5. Use the forums!
You are already halfway there on this one with this post! The most valuable place to find information on Perspective right now is right here in these forums. The module is still so new and different than Vision that even the documentation sometimes doesn’t have all of the information you might need. When you are not sure how to accomplish something, post it, and there are a handful of people here deep in Perspective that will be able to solve your question. If not @cmallonee seems to know everything about it… hahahaa

6. Realize that Perspective is nothing like Vision
This may sound obvious or not, but Perspective and Vision are so completely different from each other. They may both be parts of Ignition, but in terms of practices and procedures and just about everything they are different. Realize this, drop your Vision habits, and try to learn web based practices and you will be better off.

This may not have been exactly the answer you were looking for, as I don’t think there is any course to just jump in and master Perspective. I think that the classes provided by IA are probably good (I have never taken one), but I know that’s not always an option. The certification is really good for teaching you how to navigate the designer, but unfortunately being 7.9 and 8 core + gold certified I can tell you that it doesn’t always teach you best practice.

If you have any other questions let me know, I am always willing to try to share the experience that I have with Perspective to help others.

17 Likes
3

If you want really be a master in perspective you have to learn some basic web development and complete css3 course. This make every Things happened in perspective make sense and clear to you.
If I compare it to vision css3 is like the using Java code in python script in vision.

4 Likes
4

So many suggestions…

  • As @kgamble mentioned, do not default to using Coordinate containers. In my experience, the only time I thought to myself that the Coordinate container was the best option for a situation is when I need components to stack on top of one another. The Flex container does seem to be my most-used container, but I don’t do too much for mobile. I could absolutely see why the Column container and Breakpoint should be widely used when developing for user who might be using a mobile device.
  • read up on how inheritance works in Perspective. It’s incredibly useful to have pieces which are shared across projects in a parent project so that you don’t have to duplicate the logic or structure.
  • As @nader.chinichian mentioned, Perspective blurs the line between SCADA and Web Development. Due to this, you’ll want to have a solid understanding of how CSS works. This will help you understand not only how to customize project themes, but also how to get the fine-tuning everybody wants.
  • The Exchange is a great pace to find pieces of projects which someone has already done for you. Even if you don’t use a resource, downloading something just to see how it was done could open your eyes to new avenues.

Now for a direct answer:
How to choose a container
Coordinate: I only use Coordinate containers when I need items to overlap, or when I need everything within the view to maintain a certain aspect ratio (percent mode).
Flex: I highly recommend you become familiar with all of the setting the Flex container has available because the Flex container combined with components which have margin or padding applied allows for easily making Views which scale to most screen sizes gracefully.
Column: This is a useful container if you expect a variety of different sized devices to be using a View AND every component in the View is important. You can change the location of each component based off of a defined width, so what might look like a button row on a desktop can be turned into a button column on a mobile device.
Breakpoint: This container allows you to define how a View looks at two different sizes defined by the breakpoint. I find this useful when I have a View which might have lots of extra stuff which might not truly be important; when I design the “small” (mobile) View, I remove Tables, Images, Charts - anything that takes up a lot of space without being required.
Tab: I don’t use this container very often, but it’s a bit different than the other container types; if you know you need a tabbed layout, then you have to choose this container - you’l still get to pick how the inside of each tab flows by choosing one of the other types for each tab.

3 Likes
5

It's also incredibly disruptive to production if you are running multiple projects which are inherited from the same parent.Use wisely.

2 Likes
6

EDIT: I realized after posting that this thread was about Perspective while what I posted is focused on Vision. Some of these principals can be applied to Perspective as well.

Some ways to mitigate the disruption of project inheritance:

  1. Use notify mode rather than push for updates.
  2. Consider using a development server and then using EAM module to transfer the shared project(s) to production servers. This works quite smoothly when you design your projects to run on multiple servers and your development server has remote tag providers pointing to the production servers. It lets you test things fairly thoroughly before transferring to production servers.
  3. When you make changes to a shared resource that will break things, consider including backwards compatibility in your changes. As an example, when modifying templates to use a tagPath and internal indirect tag binding rather than binding a UDT parameter, you can change everything in the template to use tagPath and use scripting to copy UDT.Meta.TagPath to the new tagPath parameter if not tagPath. This doesn’t complete the upgrade, but allows transferring the project to the production server without breaking anything. Have it do the same thing when in designer and testing. Now when you open the pages using the template in designer and switch to test mode, all the template instances get the required parameter changes so you can remove the old UDT parameter from the shared project.
1 Like
7

This is the disruption. If you edit the parent it will notify EVERYTHING in the plant that is a child of the project regardless of if the child actually uses the component that was just updated. Requiring an update when the parent edit might not have any impact to the child project that was just notified.

There is balance of design when using project inheritance, to much reliance on the parent components and you might constantly be a nuisance if you have to constantly edit the parent. To little and you aren't taking advantage of the feature.

1 Like
8

Yes, these are presently more disruptive in Perspective than Vision (was thinking of Vision when I wrote that).

Good point on the balance. Maintaining a growing number of installations, I’ve been moving more and more resources to inheritance since upgrading to v8 to eliminate duplication of code and work keeping everything up-to-date. I’m using a separate development server and then pushing updates to production servers less frequently via EAM. Or using resource overrides in a child project to make the changes needed at one location now, and then copying that resource back to the inherited project once testing is complete so it’s available/updated at other locations (and removing the override on the local project).

1 Like
9

Thank you very much everyone for the tips and especially to the @kgamble & @cmallonee for posting in details.
Just FYI, I already have started learning CSS and reviewing Ignition Demo projects (also using same at my end). Thanks All!

Stay safe!

1 Like