The apps you create, whether for mobile or desktop, generate huge amounts of data, both from user input and information collected passively. If your app can make use of this data in way that creates value for the end user, your app will be more "sticky" -- a key differentiator in a highly competitive market. Many app developers are now providing such features as standard in their tools. But should independent software vendors (ISVs), systems integrators (SIs) or companies building internal apps build them in-house, or should they buy them? This post is the first in a series that explores how to get more value out of the data your apps create, whether to buy or build, and the most important factors to weigh if you choose to buy.

SaaS models have changed the industry 

The proliferation of software-as-a-service (SaaS) subscription-based business models has changed what people expect from ISVs and SIs. Cloud computing has revolutionized how people pay for software and has altered the relationship they have with vendors.  

 Today, users tend to pay a subscription on a regular basis and receive constant support and updates, resulting in consequences for development houses: 

• Retention is the measure by which success is defined: The industry’s standard of success is measured by churn rate — the number of users who cancel their subscriptions or simply stop using an app. 
• Customer satisfaction is more important than ever: Most ISVs and SIs embed analytics as a way of adding value and increasing customer satisfaction. They rarely charge a premium for these additional features and need their deployment to be as economical as possible.  
• There is constant pressure to improve and differentiate the app to reduce churn: In an age of free trials where users often “try before they buy,” the apps that succeed will be those that are “stickier” — the ones that give users more value the more they use the app. 

 At the same time, these apps are also creating data, which presents a major opportunity for growth that’s waiting to be realized.  

The data opportunity 

Individual apps collect large quantities of unstructured data on the back end. Every time a user interacts with your app, this information can be stored. But to be useful, this data needs to be converted from meaningless numbers to something users can understand. Embedded analytics tools can convert this information into visualizations that appear in the user interface.  

 The proliferation of generated data from apps and the need to continually add app value have caused app providers to explore embedded data visualizations as a means to retain customers, reduce churn, and differentiate.  

Embedded Data Visualizations as a Solution 

What are embedded data visualizations? 

Embedded data visualizations make complex information comprehensible by presenting it visually. They collect the data that users generate via an embedded analytics processor, and then make it accessible in the form of maps, pie charts, picture, and graphs. And because they’re built into the application itself, embedded visualizations make it easier for the user to view data and gain insights real-time and in context, removing the need to navigate away from the app. 

Customer benefits of embedded analytics: Embedding analytics provides end users with insights. Users expect their apps to help them work smarter and make better decisions. When the app offers this additional valuable content, it becomes “stickier,” a useful part of their everyday life or work.  

• In the B2B market: A task management app shows the end user how they spend their time at the office. By providing embedded visualizations, this kind of app offers insights into how they could use their time better. For instance, a simple chart can tell them that they are spending over a third of their time in unproductive meetings.  
• In the consumer market: A consumer fitness app that tells someone how many calories they’ve burned today compared with yesterday is much more motivating. The more data is collected about the user, the more “sticky” the app becomes. Users become less likely to switch to another app because your app contains information collected over time that’s useful for them to see – such as their long-term progress toward a fitness target. 
• Inside your own business applications: An integrated dashboard that pulls in data from your ERP and CRM systems gives users the information they need to make decisions quickly, without having to click through disparate applications.  

Developer benefits of embedded analytics 

Today’s app developers are competing in a crowded market. With all this availability, end users have little patience for apps that fail to bring them any particular value. If an app provides only short-term worth, users are likely to uninstall it fast; this is as true in the enterprise app space as it is in the consumer market.  

Users are keen for apps that continue to provide them with real, lasting value. Increasing numbers of developers are turning to embedded data visualizations as a means of providing this kind of value, differentiating their app and reducing churn. 

Now that you have a clearer idea of what embedded analytics can do for you, the next question is: Buy or build? The next post in this series breaks down the pros and cons of both. For a full decision tree on building vs. buying embedded analytics, go here. And if you're ready, drive insights and better business decisions by adding powerful analytics to your next app with ReportPlus Embedded. 

I hosted a webinar on Advanced Angular Component Concepts for India region on the 19th of January. This webinar covers:

1. Content Projection
2. ViewChild and ViewChildren
3. ContentChild and ContentChildren
4. Dynamic Component Creation

For your benefit, we went ahead and wrote articles on the topics covered in the webinar.  You can read them in the blogs linked above.

You can watch a recording of the webinar below:

https://youtu.be/IZeZiUDDwkk

And there you have it! If you like this post, please like it and share it. In addition, if you haven’t checked out Infragistics Ignite UI for Angular, be sure to do so! They’ve got 30+ material based Angular components to help you code speedy web apps faster.

NOTE: This webinar occurs on February 27th at 11 AM JST (GMT +9), for members of our APAC-region audience. Please find local time below:
3:00 PM (NZDT) GMT+12:00 (Auckland)
1:00 PM (AEDT) GMT+10:00 (Sydney)
11:00 AM GMT+9:00 (Seoul, Tokyo)
10:00 AM GMT+8:00 (Beijing, Hong Kong, Kuala Lumpur, Manila, Singapore, Taipei)
9:00 AM GMT+7:00 (Bangkok, Hanoi, Jakarta)

I am hosting a webinar to introduce XAML technology for Windows Forms developers!

Webinar Agenda:

Have you tried utilizing XAML or WPF for your desktop applications? Have you ever thought of the benefits these UI controls could have for your app development?

I will present the benefits of using XAML (WPF) in your LOB apps and why it’s important for developers to learn them. I will also showcase Infragistics’ WPF UI Controls and how to utilize them for maximized productivity.

In this webinar, you'll learn:

• An overview of XAML technology and platform as of January 2018
• The benefits of adopting XAML technology
• Offerings from Infragistics’ LOB WPF controls and tools
• Next steps moving forward

This webinar is best for:

• Windows Forms developers looking for the benefits on moving to XAML
• Developers looking to get started on programming in XAML
• Developers who would like to use Infragistics WPF UI controls
  

I have been working with a lot of Japanese companies who are trying to adopt XAML for 10 years. During the time I was getting questions similar to "Why should I move to WPF?".
In this Webinar, I would like to share mu opinion as well as suggest what steps to make you successful for your next XAML project.

Register Now!

From new levels of stability to an amazing ecosystem, we’re convinced that 2018 is a great time to be an Angular Developer. Our SVP of Developer Tools, Jason Beres recently had a chance to sit down with Stephen Fluin, Developer Advocate on the Angular team at Google.  This is the third of three parts of the conversation including the future of Native apps vs. PWAs, Server Side Rendering, and this post with Angular team’s advice for Enterprise Developers.

Jason Beres: You travel the world all year, you're on the road talking to customers at events like Angular Mix and Angular Connect.

When you're in front of your actual enterprise customers, and what do you tell them? What's your suggestion for them when they ask the tough questions like, "Oh, is this the right bet? Where's it going?"

Do you have any general thoughts for the developer audience at large to kind of give them peek at what you might say to a customer at a trade show?

Stephen Fluin: Some people may have heard me say this before, so I'll kind of start with what I said in the keynote at Angular Connect, where I actually do feel like at this point it's a great time to be an Angular developer.

We've achieved a level of stability and a level of innovation that we feel really, really confident, solves a lot of the people's problems and we'll help them build better experiences and better applications for their users.

Specifically, when it comes to our enterprise users, I often talk about five reasons why they choose Angular.

First, we talk about how Angular is opinionated. We make a lot of choices for you. Things like TypeScript. Things like HP client that try and help you build more maintainable, more scalable applications kind of automatically.

Second, we talk about being trustworthy. We have very clear semantics so you know exactly what's coming and releases. We're also committed to very smooth update process between versions. This is something we're spending a lot of time worrying about, all the way to the extent that for example within Google, where there's more than 300 applications or projects using Angular, every time we make a breaking change, we actually have to go update those 300 applications. So we have an intimate knowledge of when and how breaking changes affect the ecosystem and so we're highly incentivized to minimize those. But at the same time, we do want to keep innovating.

And it's this idea of trustworthiness I think is something that we wanted to start building when we shipped version 2.0.0 back in September of 2016 and over the past year or more, we've kind of proven that we're capable of doing that.

Third, we talk about Angular being scaled. We obviously design for solving kind of Google-scale problems. But that's not just in terms of number of users or number of developers. It's also in terms of a diversity of team roles. You see when we get large teams, you end up having a shared services org in the company or you end up seeing architects being distinct from developers being distinct from designers. And Angular is really designed with some of that thinking in mind, where you can have architects focusing on the module level. Where should we be lazy loading? How should we be building this platform? Developers more focused on the component level within a module. And then designers focused on the template.

And matches how people kind of want to build software.

So we've got opinionated, trustworthy, scaled.

Fourth, we talk about ecosystems. We have a fantastic ecosystem.

Just being at Angular Connect and hearing from people and talking to people, there are so many great companies that not only want to use Angular but want to give back to each other and work together

Beres: It's amazing the number of developers that are so engaged in the community - in the open source community. It's very impressive.

Fluin: Yes. Absolutely. I think our community's just fantastic in terms of the way that they exemplify a lot of our values in terms of respect and being welcoming.

We explicitly we ask our community not to go and criticize other people because there’s a little bit too much fighting and we can all work together and we can all learn from each other.

When one of us wins in an open collaborative matter, we all win. That's definitely a huge part of how we think about things.

The last one that we talk about is Angular as being familiar. Whether you're coming from AngularJS where we have a lot of the same philosophies, declarative templates, dependency injection services layer, even the components now existing in your JS. Or if you're coming from a Java world or a .NET world, and you're very used to this application mentality but you're maybe new to the web, Angular ends up being a very familiar entry point to delivering the kind of experiences that customers expect in 2017, 2018 and beyond.

Beres: So, as the Angular lead for all of the ecosystem and community out there, what would success in five years look like for you. When we're sitting here and toasting champagne and eating strawberries, you're like, "We made it." What does reaching that point look like for you?

Fluin: I would go back to three of the Angular core values that we talk about. Applications that you just love to use, developers love to build, and a community where everyone feels welcome.

I think if we can hold true to that and five years from now we're still taking advantage of the modern web, and releasing smooth updates and maintaining the level of innovation that developers kind of want.

There's this magic feeling when we can just flip a switch and they have a PWA for the first time. If we can keep that level of magic and stability at the same time, which is very challenging, I will feel fantastic about how we've kind of progressed.

Beres: Well, thank you so much, Stephen. We should go back and watch some of the awesome sessions from Angular Mix and Angular Connect. Thank you so much for the time!

###

We’d like to thank Stephen Fluin again for his time in this interview, and invite you to check out more of what he has to say over at the Angular Blog. To learn more about Infragistics’ support for Angular, check out our Ignite UI for Angular page and ICYMI- here are part one of the conversation, and part two of the chat.

For app development houses whose tools collect data that could be useful for the end user to make decisions with, there is little excuse not to use embedded analytics and visualizations. However, is it better to build the data analytics machine yourself or buy a bolt-on solution from a third party?   

Why should you build?  

• Small, fast projects: Creating analytics features in-house can be the best option when working on smaller projects with limited sets of requirements — especially if the development team in question has a relevant skill set and previous experience of developing embedded analytics and data visualizations. 
• Total control: One of the most convincing arguments for building is that it lets product managers remain fully in control over every aspect of their application: not just its functionality but the look and feel as well. By keeping all aspects of development in-house, product teams can control branding, user experience, and functionality. The loss of this control is one of the main disadvantages of buying.  
• Limitations of support services: Although most providers offer support services, these are not normally included in the price of the package, and are instead an add-on. However, in the majority of cases, such support services are in fact effectively a requirement to ensure the visualization is tailored to the use case and look and feel of the app. 
• Cost predictability: Standard price entry points for embedded analytics start at anywhere from $30K to $75K per year. However, behind the upfront pricing structure, there are often multiple levels of service, as well as limits on usage and number of applications the embedded analytics can be used in. This can make pricing far less predictable.  

 Why should you buy?  

• Focus on core product: The main disadvantage of the “build” approach is that developers have to switch their focus away from working on the core product to create complex embedded analytics features. Buying saves time and money overtraining a development team that may lack previous embedded analytics experience and eliminates the need for training where internal resources are simply not available. 
• High cost to build: There is a significant cost associated with building embedded analytics, which on average takes seven months to complete. The estimated average cost is as much as $350k (based on average U.S. salaries). 
  • This includes: 
    • 4 software developers for 7 months
    • 1 QA professional for 7 months 
    • 2 UX/UI designers for 6 months 
    • 1 data scientist for 1 month 
• In-house support: Anything built in-house will have to be supported in-house. With the buy option, support will be provided by the third party, via the cloud, and ISVs will not have to allocate resources to fixing issues if and when they occur. As much as 90%1 of the cost of software during its lifetime is tied to keeping it up and running. Maintenance costs can be significant. 
• Faster time to market: With average build-it-yourself times taking seven months or more, many product teams decide to buy a bolt-on analytics solution due to the need to release a product as quickly as possible. In a fiercely competitive SaaS market, and with CEOs demanding quick turnaround, buying a pre-built, off-the-shelf solution drastically improves time to market. 

That is why we are offering ReportPlus Embedded, as a means to help your customers easily visualize their data generated within your app. We’ve also gathered resources to help you make the right decisions for your app, your customers, and your business. 

• Still can't decide if you should you build or should you buy? We’ve created an infographic with a decision tree to help you make up your mind.
• And to make it easier for you to get started, we’ve put together a predictable pricing and all-inclusive product & service engagement.

Drive insights and better business decisions by adding powerful analytics to your next app with ReportPlus Embedded. 

NuGet is one of the most popular tools for sharing code. In the following article, we will explain some specifics when using the Ignite UI for JavaScript NuGet package to create an ASP.NET Core application.

Until version 2017.2 of Ignite UI for JavaScript, the NuGet package for ASP.NET Core MVC was distributed under the name “Infragistics.Web.MVC”. In version 2017.2 this package was renamed to “Infragistics.Web.AspNetCore” in order to differentiate it from the packages for MVC4 and MVC5, which are also called "Infragistics.Web.MVC".

Let us go through the steps that are required to add the package to your project and reference the Ignite UI for JavaScript scripts. This example will show you how to use the licensed packages from the Infragistics private packages source. If you do not have an Ignite UI for JavaScript license, you can follow the same steps but instead of https://packages.infragistics.com, you will use https://www.nuget.org as a package's source. This will install the trial versions of the packages.

First, we need to make sure that the Infragistics private NuGet package source is set up.  Open the “Options” dialog in Visual Studio and navigate to the “Package Sources” view of the “NuGet Package Manager” node. There, we should add a new source that points out to https://packages.infragistics.com/nuget/licensed.

After we have the Infragistics private NuGet feed set up, we can continue with creating the ASP.NET Core application. In our case, we are using Visual Studio 2017 and we are targeting .NET Framework 4.7.1.

In the next view, we stick to the defaults – we will create an ASP.NET Core 2.0 application.

After pressing “OK” our new project is created. Let us have a look at what is initially included in the “NuGet” dependency in our project. ASP.NET Core 2.x applications that target .NET Core (this is our app) only require a single NuGetPackage – “Microsoft.AspNetCore.All”. All the features of ASP.NET Core 2.x and Entity Framework are included in this package. Such a smaller application surface area help to improve the security and also improves performance.

After we install the Infragistics.Web.AspNetCore package – it will also be placed under the “NuGet” dependency. We select “Manage NuGet packages…” from the context menu and we see the NuGet Package Manager view is opened. We see that the manager is set up to use all the available package sources. In addition, we see an indicator that “Microsoft.AspNetCore.All” package is already installed.

At this point, you will be asked to provide the credentials for your Infragistics account. Those are required so that you would be able to download the licensed versions of the Infragistics packages. If you do not own a license key for Ignite UI for JavaScript 2017.2 – you will only be able to use the Trial version of the NuGet package that is available on nuget.org.

We need to change the package source to the Infragistics private feed to make sure that the Licensed version will be installed. Then, we search for the ASP.NET Core package. In this example, I demonstrate the difference between the packages in version 2017.1 and in 2017.2. I have licenses for both versions and after browsing for “Infragistics.Web”, I see both the packages. For this example, we will use the 2017.2 version which is the top package.

If you look at the dependencies for this package, you will find “IgniteUI” as a dependency. This means that installing this package will also install the Ignite UI for JavaScript script files. This is an important note as later we will see how to use those scripts in our application.

After the package is installed, we need to include the Ignite UI scripts that are installed by the package to our application. As our project uses PackageReferences, the static script files are not added to the project automatically. They are installed under “%UserProfile%\.nuget\packages” folder. So, you need to copy the files that are needed by your application and place it inside the “wwwroot” folder of the project. Inside your .cshtml pages, you need to reference those scripts from this folder.

As you can see on the following screenshot, I have added the combined .js files that I need under the “js” folder of my application and I have placed the Infragistics .css files that I want to use under the “css” folder.

After the script files are added, we can navigate to the .cshtml page that we want to add our Ignite UI for JavaScript control in. We need to import our namespace like this:

@using Infragistics.Web.Mvc 

Below we need to reference our Ignite UI scripts. In my example they would look like this:

<link href="~/css/themes/infragistics/infragistics.theme.css" rel="stylesheet" /><link href="~/css/structure/infragistics.css" rel="stylesheet" /><script src="~/js/infragistics.core.js"></script><script src="~/js/infragistics.lob.js"></script> 

Of course, do not forget to reference jQuery and jQuery UI before using the Ignite UI scripts. When this is done, you will be able to create the Ignite UI for JavaScript controls that you need in your scenario. In my example, I will create a numeric editor using the following line:

@(Html.Infragistics().NumericEditor().ID("newEditor").MaxValue(100).Render()) 

When I run my application, the numeric editor will be rendered.

In conclusion, we can say that using the Ignite UI for JavaScript NuGet packages is one of the fastest and easiest ways to boost your productivity when creating your next ASP.NET Core application. 

Introduction

Modern Web Application Developments introduces the complexity of dependencies for JavaScript libraries. You just want to use a JavaScript library, but the JavaScript library may be referencing/depending on other 5 libraries. Solving dependencies is time-consuming for new users and you may be giving up with using the library.

CLI (Command Line Interface) tool is very handy!

To solve this challenge, many CLI tools are available nowadays to reduce your groundwork. For Angular, Angular CLI is available and it creates a skeleton with referencing necessary dependencies. This allows you to get started with Angular development within 5 minutes.

Introducing Ignite UI CLI

Our Ignite UI provides two types of component sets for modern web app development. One is Ignite UI for JavaScript, HTML5/JavaScript based components which you can build very rich modern LOB applications for Desktop and Tablets. Another one is Ignite UI for Angular, Native Angular, Material based components which would be the best for creating LOB applications for mobile and tablets. Both require 3rd party libraries to use its powerful features like any other JavaScript frameworks or libraries and setting those necessary files is pain points when you just get started with our Ignite UI components or every time you want to start a new project.

This is the main reason for us to provide Ignite UI CLI. Ignite UI CLI is a Command Line Interface tool to scaffold for both Ignite UI for JavaScript and Ignite UI for Angular. In this entry, I am walking through from the beginning to create your first project with Ignite UI CLI.

Prerequisites

In order to use Ignite UI CLI, you need to install the followings to your environment.

• Node.js
• npm (bundled with Node.js)

Install

Open terminal or console and type following command to install Ignite UI CLI. You may need to run this as Administrator in some cases. 

npm install -g igniteui-cli

After completing the install, you can check the version with the following command.

ig -v

If Ignite UI CLI is installed, you will see this screen. I am using Ignite UI CLI 1.2.0-beta.1 for this entry.

Start Using Ignite UI CLI

If you type "ig -h", you will see available commands, but I recommend using our guide, which prompts you for options and you can select them by using cursor keys.

To start Ignite UI with the guide, simply type the following command.

ig

Define name of the project

When the guide starts, first you will enter a project name you will be working on.

Choose framework

Ignite UI CLI currently provides 3 options to choose for the framework you are going to use. Angular, jQuery, React. In this entry, I choose Angular.

Choose type of project

Here comes a confusing part. Now you have two options. One is Ignite UI for Angular, which is an obvious option when you are going to use Ignite UI for Angular for this project. Another one is Ignite UI Angular wrappers, which is an Angular Extension provided for Ignite UI for JavaScript. You can find more details about extensions and available packages in Ignite UI Package and Repo Name Changes. In this entry, I use Ignite UI for Angular.

Add components or views

After choosing the type of project, the structure of the project has been generated and now you can choose the component (a view with single control) or view (a view with multiple components generated from templates) repeatedly.

Add component

When you select to Add component, You will choose a group of components, then choose component to be placed. The latest Ignite UI CLI provides 3 groups, Layouts, Scheduling, Grids&Lists.

In this entry, I chose Grids&Lists group then, added a Grid. The name of added component is "myGrid". 

Add View

When you select add View, you can add a view provided by Infragistics. Views represent specific business scenarios and look like more completed. 

After adding a component and a view, you will see the output like below:

Build and Run!

When you choose complete, Build process gets kicked and after completion, you can open a browser to localhost's address specified in the terminal. Links on the side bar navigate you to pages generated by Ignite UI CLI.

How to run an existing project created by Ignite UI CLI?

If you receive or download a project, which was generated by Ignite UI CLI, you can run the project by using the following command in the project folder/directory.

ig start

Build starts automatically then project starts. If you want to add components or views, simply type "ig" in the project folder/directory.

Conclusion

Ignite UI CLI has been built to jump start using Ignite UI libraries. You can use this tool to learn how to use our libraries and also you can extend generated views to match your business needs.

If you would like to know more detail about Ignite UI CLI or would like to see the source code, you can visit our GitHub page.

Let's get started!

Embedded analytics are powerful for adding value and stickiness to your desktop and mobile apps, and buying analytics from a third-party vendor can be the most efficient way to take advantage of the data your apps generate.

Today there is a huge market of vendors offering application development tools and services, with many firms providing specialist analytics and visualization tools. Choosing the right vendor is extremely important. So, how should you choose between these providers?  

• Expertise --While we can assume any vendor pitching themselves as an embedded analytics provider will have good knowledge of this technology, it is worth digging deeper. Has the company received awards for its work? Are they well-established and respected in the community? Third-party review sites are helpful here.  
• Range of visualizations available -- Many vendors provide basic visualizations as part of their product listings (normally alongside many other generic offerings and widgets). However, in a market where your customers expect ever more powerful applications, you need to be able to update your apps with more powerful analytics. The specialism required to offer this sort of detailed insight will narrow down the field considerably.  
• Cost predictability -- How does the vendor’s pricing model stack up against your budget? Obviously, you shouldn’t really be paying any more than what it would cost you to simply build the visualization in-house, so an affordable vendor is essential. However, too often, overly complex pricing structures from vendors result in unpredictable costs, making ROI hard to judge.  
• Security and transparency -- How much do you trust the vendor? If you are collecting sensitive data about, say, your customers’ health, you want to be sure that the vendor isn’t also collecting that information covertly and selling it on the black market, for instance.  
• Customization -- How easy is it to customize the service? Is it easy for you to modify the look and feel of the analytics tool so it looks and feels like the rest of your app?  

Choosing the right partner will allow you to deploy embedded analytics fast, empowering your end users and making your app stickier. By including powerful embedded analytics and visualizations, you can differentiate your app, keeping users engaged and building long-term loyalty. 

This is the third post in a series about the value of including embedded analytics in your apps. Check out the first post to learn more about how embedded analytics can help you make use of the data your apps generate. Then read the second installment to find out more about how to decide whether to build in-house or buy from a vendor.

If you've followed Infragistics for the last few months, you know how excited we are about the potential for Angular. (And if not, you should check out our roadmap, our latest release, and our conversation between our SVP of Developer Tools, Jason Beres & Google Developer Advocate Stephen Fluin!)

This weekend, we are happy to be a part of the first Angular Conference in India, ng-India!  Here is what you need to know:

• Organized by one of the largest Delhi JavaScript meetup groups: geek97 - https://www.meetup.com/Geek97/
• 300 Angular Developers from all across India, representing  50+ different organizations have signed up to attend
  • Infragistics own Developer Evangelist Dhananjay Kumar is an organizer and will deliver two talks on Reactive Forms and Advanced Components
• They have planned 11 deep-dive talks on cutting-edge Angular topics
• One lucky winner will get a free license of Infragistics Ignite UI for Angular!

We're not the only ones who are excited, here are the words from just a couple other influencers who are also excited about this weekend's event:

https://youtu.be/hEq8nqMZlMY

https://youtu.be/UF8IydijDyY

Infragistics is happy to support the Angular and JavaScript Developer community ecosystem in India. If you're not able to make it to the event this week, watch this space for updates from Dhananjay's presentations, and the latest of what he learns from some quality time with the community!

Titanic & Monkey Business. Part 1 of Empathy Series.

Empathy is said to be a core tool in user experience. You might even refer to it as “Innovation’s pixie dust.” That makes it seem pretty important, and it is. Because it’s so important, we need to understand what empathy is and how it works. This will provide a context for, and enrichment of, our professional work.

What is empathy according to psychology?

“Trying to gain weight can often feel like an uphill battle.” — said Sympathy (and almost no one struggling with obesity).

“I know it’s not easy to lose weight because I have faced the same problems myself.” — said Empathy.

By definition, empathy is the ability to share someone else’s feelings or experiences by imagining what it would be like to be in that person’s situation.

Empathy is the what makes movies great and brings in huge box office grosses. If we take the audience’s point of view, it’s what makes so many people react the same way to a movie, like crying their eyes out watching Titanic.

Titanic-like movies trigger the emotional part of empathy, tapping into an emotion that we’ve felt before and allowing us to experience it again in the movie theater. But there is another part of empathy known as “cognitive empathy”. Cognitive empathy helps us understand why people act the way they do. It allows us see things from their perspective.

We can often see the results of empathy written in the facial expressions of others. But what is going on behind the scenes?

How is empathy manifested physiologically?

In the 90s, scientists conducting an experiment involving primates noticed an interesting phenomenon, later defined as a result of mirror neuron activity.

Quick description: Monkey is wired to a device. Scientists are observing the firing of certain neurons in its brain while the monkey grabs a banana. At lunchtime, a hungry scientist grabs a banana in sight of the monkey. The device shows that same neurons that fired when the monkey was reaching for the banana fire when the monkey observes the experimenter reaching for the banana.

 The neurophysiological evidence suggests that the monkey was provided with a vicarious experience — the very definition of empathy.

Not surprisingly, mirror neurons are also found in humans, in areas of the brain that account for spatial recognition, control of movement, language processing, touch, and pain processing.

While there is certainly more to the physiology of empathy, I am not a specialist in that area and won’t have much more to say about the gooey gray matter that links us with (at a minimum) the rest of the primate world. I do, however, have something to say about empathy and zombies ;-) but you’ll have to wait for my second blog about empathy for that!

Part 2 of Empathy Series: There is more to Observation than meets the eye

Part 3 of Empathy Series: Empathy in interviews

Synchronize it. Part 3 of Empathy Series.

What is it the underlying value of interviews as a research method?

*cough* Empathy *cough*

Neuroscientist Uri Hasson, Associate Professor of Psychology at Princeton University, studied this question and discovered an interesting result. He made fMRI observations of people’s brain activity while they were listening to a story. As soon as the story starts, the listeners’ brainwaves synchronize right until the end of it. That seems logical since they hear the same words.

Then he conducted a second experiment. Two groups of people told the same story. However, the story has a different beginning for each group.

Group 1: ”Wife has an affair.”

Group 2: “Husband is unjustifiably jealous.”

The story then continues exactly the same for both groups. Interestingly, listeners’ brain activity synchronized to the story within groups, but not between. Group 1 showed a different pattern than to Group 2. 

It turns out listening is not limited to a simple understanding of the words being transmitted. Rather, it is shaped by the ideas being communicated, in addition to the literal meaning of the words themselves.

To me, this counts as a good explanation of empathy at the biological level, and an important reminder of the value of direct user research methods, such as interviews and contextual inquiries. Moreover, UX researchers should also take Hasson’s work as a cautionary tale. If a single sentence is enough to fundamentally change the pattern of brain activation caused by a simple story, imagine how leading questions might affect the results of a poorly designed research study?

In other words — prepare carefully, sit quietly, cultivate meaningful dialog, listen, sync and make every word count.

More on Uri Hasson’s fascinating research on TED 

More about Empathy and User Research Methods from me!

Part 1 of Empathy Series: What and Why about Empathy

Part 2 of Empathy Series: There’s more to Observation than meets the eye

We have three pillars for Ignite UI for Angular:

• High performance UI
• Small JavaScript footprint
• Unmatched designer & developer productivity.

As we continue to evolve Ignite UI for Angular, those 3 pillars will be seen in everything we ship. Through continuous delivery in 2018 our focus is shipping new capabilities to our Angular data grids and Angular charts.

In the grid, we are currently working on row and column virtualization, master-detail views, inline editing, Microsoft Excel style filtering, row + column pinning, full column management like grouping, pinning, and multi-column headers, plus export to Microsoft Excel.

Charting will include the same real-time, high-volume data support for all the common business charts that we currently ship in our Ignite UI for JavaScript product, including complete financial charting capabilities.

As we continue to focus on helping design teams and developers deliver software faster with beautiful UX, we will ship high-productivity features like enhanced Ignite UI CLI features, integration with the Angular CLI, more Sketch UI kits and app templates for the designer-developer workflow, and visual configurators for charts and grids for any code editor, including Visual Studio Code.

Click here for directions on how to install Ignite UI for Angular, then sign up for a free 30-day trial that includes set-up along with enterprise-ready support. Call one of our five worldwide offices to set up a product demo. We’re excited to hear what you think.

Here at Infragistics, we take pride in our team of UX and UI development experts. Our Consulting Team has worked with customers across a wide variety of verticals and business challenges to design and build useful, usable, beautiful and maintainable software products. However, in addition to our consulting work, we also like to give back to the community.

Last year, our UX team worked with the Center for America, a non-profit organization that helps companies hire veterans. As part of a six-month effort to redesign and rebrand the Center for America website, the team from Infragistics improved the information architecture and usability, incorporated new functionality, and created a striking visual design language.

As a result, Center for America President Steve Nowlan said:

"I’m really delighted with the design. All of your conscientious and creative work is culminating in a website design that is going to be very well received and give our stakeholder group much better access to the resources we offer."

Can Infragistics help your non-profit?

In the past, we have helped charitable organizations update their systems, modernize their user interface, and more – all free of charge – and we’d like to help you next! If your charitable organization is ready for a transformation or your customer experience is due for an overhaul, we want to hear from you.

This offer is valid for organizations that help others and need help themselves with a website, software, or data visualization. If this sounds like you and you’d like to partner with us, drop us a line at services@infragistics.com by February 23, and a member of our Consulting Team will get back to you. Please include:

1. Name of organization
2. What community you serve
3. What you do for that community
4. What project do you have that you think we can help with?
5. Contact information

We look forward to working with you soon!

Angular pipes take data as input and transform it to your desired output. For example, using interpolation you are displaying name of the product. Now you want the product name always displayed in the uppercase. You can do this using Angular pipe uppercase.

import { Component, OnInit } from '@angular/core';
 
@Component({
    selector: 'app-root',
    template: `{{productName | uppercase}}`
})
export class AppComponent {
    productName = 'Cricket Bat';
}

In above component, productName will be displayed in uppercase. Therefore, pipe takes an input and transforms it into desired output as shown below:

Angular library provides us many built-in pipes like,

• UpperCasePipe
• LowerCasePipe
• CurrencyPipe
• PercentPipe
• DatePipe etc.

 Let us see how we could use the built-in currency pipe.

import { Component, OnInit } from '@angular/core';
 
@Component({
    selector: 'app-root',
    template: `{{productName | uppercase}} = {{productPrice | currency}}`
})
export class AppComponent {
    productName = 'Cricket Bat';
    productPrice = 990;
}

You can also pass parameters to a pipe using the colon. You can pass input to currency pipe as shown below:

import { Component, OnInit } from '@angular/core';
 
@Component({
    selector: 'app-root',
    template: `{{productName | uppercase}} = {{productPrice | currency:'CAD':'symbol-narrow':'4.2-2'}}`
})
export class AppComponent {
    productName = 'Cricket Bat';
    productPrice = 990;
}

Even though Angular provides many default pipes, there could be requirements when you create custom pipes. Creating a custom pipe is very as simple as creating a function.  Let us say that we want to create a pipe, which will capitalize first letter of each words in a string.

Consider below component,

import { Component, OnInit } from '@angular/core';
@Component({
    selector: 'app-root',
    template: `
  <ul *ngFor='let n of names'>
   <li>{{n.name}}</li>
  </ul>
  `
})
export class AppComponent {
 
    names = [];
    constructor() {
        this.names = this.getNames();
    }
    getNames() {
        return [
            { 'name': 'dhananjay Kumar' },
            { 'name': 'jason beres' },
            { 'name': 'adam jafe' }
        ];
    }
}

This component will print names as below:

Now we want to capitalize the first letter of each word in the name. To do that we need to write a custom pipe.  To create a pipe, you need to follow these steps:

1. Create a class
2. Implements PipeTransform in the class
3. Implement transform function

So, you can create a pipe to capitalize first character as shown in the listing below:

import { Pipe, PipeTransform } from '@angular/core';
 
@Pipe({ name: 'firstcharcateruppercase' })
export class FirstCharacterUpperCase implements PipeTransform {
    transform(value: string, args: string[]): any {
        if (!value) {
            return value;
        }
        return value.replace(/\w\S*/g, function (str) {
            return str.charAt(0).toUpperCase() + str.substr(1).toLowerCase();
        });
    }
}

As you see, custom pipes are nothing but a function which takes input parameters, and returns some value. You need to write all logic of the pipe inside transform method.

To use firstcharacteruppercase pipe, first you need to declare it in the module, as shown below:

import { FirstCharacterUpperCase } from './firstcharacteruppercase.pipe'
 
@NgModule({
    declarations: [
        AppComponent, FirstCharacterUpperCase
    ],
 

Next on the component, you can use it like below:

import { Component, OnInit } from '@angular/core';
@Component({
    selector: 'app-root',
    template: `
  <ul *ngFor='let n of names'>
   <li>{{n.name | firstcharcateruppercase}}</li>
  </ul>
  `
})
export class AppComponent {
 
    names = [];
    constructor() {
        this.names = this.getNames();
    }
    getNames() {
        return [
            { 'name': 'dhananjay Kumar' },
            { 'name': 'jason beres' },
            { 'name': 'adam jafe' }
        ];
    }
}

Now you will get in output the first character of each name in the uppercase.

To summarize:

1. Custom pipes are class, which is decorated with @Pipe
2. Name property of @Pipe decorator defines name of the pipe
3. Pipe class should implement PipeTransform interface

It should implement pipe business logic inside transform method.

There are two types of pipes

1. Stateless pipes
2. Stateful pipes

What we used and created above are stateless pipes. They are pure functions, which takes an input and returns transformed values.

Stateful pipes are complex to implement and they remember state of the data they transform. Usually they create an HTTP request, store the response, and display the output. Angular inbuilt async pipe is example of stateful pipe. In further posts, we will learn to create custom stateful pipes.

 Summary

In this post, we learned about pipes in Angular. Pipes transform an input data to desired output. Angular provides many built-in pipes; however, there could be requirements to write custom pipes. There are two types of pipes: stateless pipes and stateful pipes.

Like this post?

And there you have it! If you like this post, please share it. In addition, if you haven’t checked out Infragistics Ignite UI for Angular Components, be sure to do so! They’ve got 30+ material based Angular components to help you code speedy web apps faster.

We’re really excited about the growth of the modern web in 2018, and our SVP of Developer Tools, Jason Beres recently had a chance to sit down with Stephen Fluin, Developer Advocate on the Angular team at Google.  We have three parts of the conversation, this post on the future of Native apps vs. PWAs, one on Server Side Rendering, and a third with the Angular team’s advice for Enterprise Developers. 

Jason Beres: One of the things I'm really interested in, and I think our customers are as well, is progressive web apps. I want to get your opinion on where you see progressive web apps going. Do you have an opinion on Native versus progressive web apps?

Stephen Fluin: Sure. So where are progressive web apps going? I would say that they are going to continue to evolve and allow us to build better experiences with the web technologies that we know and have today.

So, if I think back three or four years ago, progressive web apps didn't exist. A lot of the API's that we rely on now for building engaging web applications didn't exist so you had to build a Native application. I was in consulting at the time and I met with companies over and over saying, "Build a native home bot. Build a native home bot." Have a team for Objective-C. Have a team for Java. This is the way you should go.

But the web has done a lot of catching up with the Native mobile experiences, so the situation has changed. First, we now have a bunch of the API's so I buy us things like progressive web apps and service worker. I can build an offline web experience using web technologies, but also from the perspective that all of the kind of intermediate layers that exist for translating between a web developer's Native JavaScript in HTML and these sorts of things, and interfacing with Native device capabilities, they've gotten better at that process as well.

It used to be that they were always two years behind in terms of catching up. They're still behind in terms of their ability to fill and provide all of these kinds of modern, new capabilities that come out with the Native platforms, but they're much better at it now. They have a process down, they have a system, they have teams of people working on these things. 

It's both evolving from the perspective of pure web, and the platform itself is getting richer. We have lots of new API's for payment request, for engaging with the camera and recording audio and video, things like that. But even if you do need the most advanced API's to take full advantage of these mobile platforms, you can do that with web technologies.

Beres: If you fast forward three to five years, how does an individual's behavior change where they would expect it from their progressive web app versus having to go to an app store? If they find a merchant's app, like you did the shoe store in your keynote or the retail merchant, and I can do a lot through their site, I don't need their app.

I don't need to go to the iOS app store and download something. How do you see the future?

Fluin: I definitely see a convergence in terms of the way that people find apps and the way that people find websites where there's kind of value to both.

So when I find things on the web it can be very transactional, right? I'm not making a commitment to the website I visit.

I can browse them, they don't necessarily have all my information, I'm not giving up anything about my device to work with them. That's a huge way that I think we see apps becoming more like Android's Instant apps. Now I can take advantage of Android app features right away, but at the same time, we see that things are going kind of the other way where I want to have a long-term relationship using these web technologies. So I see conversions.

There's also a huge amount of value to the app store and Google Play, whereby having a curated marketplace with standardized reviews, standardized kind of permission system, I trust those places in a way that I don't, there's not a network of trust that has been yet established for the web. We get that implicit network of trust from things like social media and from friend recommendations, from search in general.

But they're not as well developed. They're not as formal.

Beres: That's interesting. You're right on there.

So then how does the, does progressive web apps potentially play into the Android instant app concept? Is it similar, the same? Would you be able to take a progressive web app and make it an instant app and put it in a store?

Fluin: I'm not as familiar with this, but at Chrome Dev Summit recently, the Chrome team actually announced a set of new capabilities for building mobile applications where now you can more seamlessly handoff between the web layer and the native layer and really unify these two code bases. I think that's a really exciting technology as well.

Beres: The conversions will happen probably organically. Mostly to what you were saying in your consulting days, there's not, the budgets aren't there anymore in the enterprise or in the small business to have different teams working on different platforms that are unique, so you need technology that's going to help you get some bit of scale, economies of scale for the apps that you're building.

Fluin:  Sure. And there's always going to be use cases for, “I do need to build a native application for every platform I want to target,” right?

Including kind of more interesting ones like Assistance for example. I think that the web, in general, is getting better at all those things and so the kind of business opportunity cost of not having those is decreasing.

Beres: Yeah, the user experience of the progressive web apps I've seen is really, really good.

So when the argument around, well we want this type of UX so we're going to go native, that argument gets less and less critical now because with the web you can mimic that experience really well with the PWA.

Fluin: Absolutely. We've seen with the ride-hailing services, Uber and Lyft, you see this with Twitter. We're seeing tons of PWA's. There's a really cool URL that I point a lot of people to, which is Chrome://serviceworker-internals.

If you type that URL into your browser, what you get is an internal kind of Chrome debugging report that shows you every PWA that you've visited. A lot of people are kind of shocked at how many there are. Sites that they browse every day are starting to add more and more of these PWA features without the user ever needing to make a conscious decision to do that.

###

We’d like to thank Stephen Fluin for his time in this interview, and invite you to check out more of what he has to say over at the Angular Blog. To learn more about Infragistics’ support for Angular, check out our Ignite UI for Angular page, and watch this space for the rest of the conversation.

A few months ago, we showed you how easy it is to use Indigo Studio to test your prototypes with actual users, even if you can’t directly observe them.

We’ve made it even easier since then: now, in addition to tracking your users’ interactions with your prototypes, you can also record the users themselves via their webcam (with their opt-in permission, of course). Every facial expression, eye movement, and vocalization is synchronized to the interactions recorded in the prototype, so you can really dig into the user experience!

Check it out for yourself—we’ve created a sample usability study so you can see how it works.

When you run the study, you’ll be prompted to install a browser extension to support video recording. For full video replays, we require Google’s Chrome browser, but if you’re only interested in recording interactions with the prototype, any browser will do.

Pretty easy, isn’t it?

If you want to see what the replay looks like from the perspective of the study owner, here’s a look at a usability test I set up and then took myself.

https://youtu.be/8GM3sPiqFZs

Notice how every word I say (yes, I talk to myself) and eye movement tracks to the cursor on the screen. Also notice the red and blue dots on the timeline—they correspond to incorrect and correct interactions according to the flow I defined when I set up the study.

It’s really that easy.

You can also easily generate and review a report from each study--here's an example.

If you’re an Indigo Studio Professional or Indigo Studio Enterprise user, you already have everything you need to run unlimited usability studies with video replays at no extra cost.

Or, you can download Indigo Studio Essential for free and get 30 days of full access to all of Indigo Studio Professional’s advanced features, including remote usability studies.

To find out more and try for yourself, visit our "Usability Testing at Scale" page and learn how Indigo Studio can help you ensure your user experience delights your users long before the first line of code is written.

In this article, we will learn to create a component dynamically. You may need to load a component dynamically in various scenarios such as want to show a popup modal etc.

Let us assume that, we have a component as listed below, which we will load dynamically.

import { Component, Input } from '@angular/core';
 
@Component({
    selector: 'app-message',
    template: `<h2>{{message}}</h2>
`
})
export class MessageComponent {
    @Input() message: string;
}

To load MessageComponent dynamically you need a container. Let us say that we want to load MessageComponent inside AppComponent. We need a container element in the AppComponent.

Template of AppComponent is as below:

<div style="text-align:center">     <h1>         Welcome to {{ title }}!
     </h1>     <template #messagecontainer>     </template> </div>

As you see that, we have an entry point template or a container template in which we will load MessageComponent dynamically.

In the AppComponent, we need to import following:

1. ViewChild, ViewContainerRef, and ComponentFactoryResolver from @angular/core
2. ComponentRef and ComponentFactory from @angular/core
3. MessageComponent from message.component

After importing required things, AppComponnet will look like following listing:

import {
    Component,
    ViewChild,
    ViewContainerRef,
    ComponentFactoryResolver,
    ComponentRef,
    ComponentFactory
} from '@angular/core';
import { MessageComponent } from './message.component';
 
@Component({
    selector: 'app-root',
    templateUrl: './app.component.html'
})
export class AppComponent {
    title = 'app';
}

We can access template as the ViewChild inside the Component class. Template is a container in which, we want to load the component dynamically. Therefore, we have to access temple as ViewConatinerRef.

ViewContainerRef represents container where one or more view can be attached. This can contain two types of views.

1. Host Views
2. Embedded Views

 Host Views are created by instantiating a component using createComponent and Embedded Views are created by instantiating an Embedded Template using createEmbeddedView. We will use Host Views to dynamically load MessageComponent.

Let us create a variable called entry which will refer template element. In addition, we have injected ComponentFactoryResolver services to component class, which will be needed to dynamically load the component.

export class AppComponent {
    title = 'app';
    @ViewChild('messagecontainer', { read: ViewContainerRef }) entry: ViewContainerRef;
    constructor(private resolver: ComponentFactoryResolver) { }
}

Keep in mind that entry variable which is reference of template element has API to create components, destroy components etc.

Now to create component, let us create a function. Inside the function, we need to perform following tasks,

• Clear the container
• Create a factory for MessageComponent
• Create component using the factory
• Pass value for @Input properties using component reference instance method

Putting everything, together createComponent function will look like listing below:

createComponent(message) {
    this.entry.clear();
    const factory = this.resolver.resolveComponentFactory(MessageComponent);
    const componentRef = this.entry.createComponent(factory);
    componentRef.instance.message = message;
}

We can call createComponent function on click event of the button. Let us put two buttons in the template and call createComponent function on click of the buttons.

<div style="text-align:center">    <h1>        Welcome to {{ title }}!
    </h1>    <button (click)="createComponent('Welcome Foo ! ')">Welcome</button>    <button (click)="createComponent('Foo Again ?')">Not Welcome</button>    <br />    <template #messagecontainer>    </template></div>

In output, you can see that component is getting loaded dynamically on click of the button.

As you click on the buttons component will be reloaded with different message.  You can destroy a component using destroy method on the componentRef.

destroyComponent() {
    this.componentRef.destroy();
}

Either you can destroy dynamically loaded component by manually calling the function or put it inside ngOnDestroy() life cycle hook of the component, such that when host component is destroyed automatically dynamically loaded component will also destroy.

Putting everything together, AppComponent will look like listing below:

import {
    Component,
    ViewChild,
    ViewContainerRef,
    ComponentFactoryResolver,
    ComponentRef,
    ComponentFactory
} from '@angular/core';
import { MessageComponent } from './message.component';
 
@Component({
    selector: 'app-root',
    templateUrl: './app.component.html'
})
export class AppComponent {
    title = 'app';
    componentRef: any;
 
    @ViewChild('messagecontainer', { read: ViewContainerRef }) entry: ViewContainerRef;
    constructor(private resolver: ComponentFactoryResolver) { }
 
    createComponent(message) {
        this.entry.clear();
        const factory = this.resolver.resolveComponentFactory(MessageComponent);
        this.componentRef = this.entry.createComponent(factory);
        this.componentRef.instance.message = message;
    }
    destroyComponent() {
        this.componentRef.destroy();
    }
}

At this point on running application, you will get an error because we have not set the entryComponents in the AppModule. We can set that as shown in the listing below:

import { AppComponent } from './app.component';
import { MessageComponent } from './message.component';
 
@NgModule({
    declarations: [
        AppComponent, MessageComponent
    ],
    imports: [
        BrowserModule
    ],
    providers: [],
    bootstrap: [AppComponent],
    entryComponents: [MessageComponent]
})
export class AppModule { }

This is all you need to do to load a component dynamically in Angular.

Like this post?

And there you have it! If you like this post, please like it and share it. In addition, if you haven’t checked out Infragistics Ignite UI for Angular, be sure to do so! They’ve got 30+ material based Angular components to help you code speedy web apps faster.

In an age where users are looking for a high-value application with everything inside it, or one to rule them all, it is becoming increasingly important for developers to keep their users interested. This is even truer for corporate users, who are meant to stay within the available company-approved options. ReportPlus rises to the challenge, providing the ability to embed unlimited custom data visualizations into any application. Learn how to use the ReportPlus SDK to embed analytics, cut development time, and give customers or users the ability to access their data in real-time and in context. 

A quick introduction to the ReportPlus SDK 

The ReportPlus SDK allows users to embed ReportPlus dashboards (.rplus files) in their own applications, providing organizations with analytical tools and IT providers with a wide range of highly customizable embedded analytic tools and data visualizations. It is currently provided to users with the ReportPlus Desktop application installer. As of the 1.3 Desktop release, you can select the ReportPlus Embedded installation. 

Using the ReportPlus SDK to Embed your Dashboards 

You can find the complete, step-by-step, guide on how to embed ReportPlus dashboards in the ReportPlus Help Topics. In the steps below, you will see how to create your own WPF project and embed a ReportPlus dashboard in an easy set of steps.  

1. Create a new WPF Application Project

Note: Take into account that your Windows project needs to target .NET version 4.6 or higher because the ReportPlus.Sdk libraries are built against .NET 4.6. 

2. Add your ReportPlus.dll files and Install theReportPlusSDK for WPF Packages 

The easiest way to get all the required assemblies referenced by the project is to install the ReportPlus SDK NuGet package. 

Find the ReportPlus Desktop SDK for WPF package and install it in your newly created WPF application. This might take a while, but you can monitor the Visual Studio status bar as it will show which NuGet packages are being installed. 

If you cannot find the ReportPlus package, you can add it manually through the VS NuGet Package manager: 

At this point, you should be all set up in terms of assembly references. You will now begin to build your application and link ReportPlus to it. 

3. Bring the ReportPlusViewer Control in. 

This control is responsible for displaying and presenting the dashboards. In order to integrate it: 

a. In the MainWindow.xaml file, add a namespace using xmlns:rplus=“http://schemas.infragistics.co/reportplus/ReportPlusDesktop”. 

b. Add the ReportPlusViewer control into the empty generated Grid in the MainWindow.xaml using <rplus:ReportPlusViewer Dashboard="{Binding Dashboard}”/>.  

Right now, there is nothing around in the DataContext named “Dashboard”, but we will take a look at that soon. 

4. Build and Run your Project
   

Let’s now run your project. All it will show is just a blue labeled trial watermark that gets displayed at the bottom left corner. That is only if you have installed the trial version of the SDK.

5. Feed a Dashboard to your ReportPlusView control 

So far, so good. Now, when we have the ReportPlusViewer control ready and into the visual tree, it will make sense to feed a dashboard to it so it can really show its power.  

To do so, you will need a dashboard first. In order to get one: 

a. Launch the ReportPlus Desktop application and log in. If you need help creating an account or logging in, you can refer to this help topic. 

b. Open the Samples folder. 

c. Open the Email Efforts dashboard.  

d. Export your Dashboard. At the top right corner, you should see an “Export” button; select the “Export File” option. The application will ask you whether you want the local data source; make sure you do include it to make the dashboard fully usable. 

e. Create a folder on your desktop named “Dashboards” and save the Email Efforts rplus file dashboard there. 

6. Add a ViewModel to your Project 

You’re almost there! You have your view and your Email Efforts dashboard. You will need to add a ViewModel to your project, which will glue those two together. Add a MainViewModel.cs class file to your project and implement INotifyPropertyChanged in it as you see fit. 

After the ViewModel is done, it makes sense to add a Dashboard property which the view will already be looking for. Here is how the ViewModel should be looking like by now:

publicclassMainViewModel : INotifyPropertyChanged
{
        private Dashboard _dashboard;
        public Dashboard Dashboard
        {
                get { return _dashboard; }
                set
                {
                      If (_dashboard != value)
                      {
                              _dashboard = value;
                              RaisePropertyChanged("Dashboard");
                              }
                       }
        }
        protectedvoidRaisePropertyChanged(string propertyName)
        {
              if (PropertyChanged != null)
              {
                      PropertyChanged(this, new PropertyChangedEventArgs(propertyName));
              }
        }
        publicevent PropertyChangedEventHandler PropertyChanged;

7. Load the Dashboard

We have the view, the infrastructure and the dashboard ready. What’s left is to load the rplus file stream and then load the Dashboard out of it. Here’s how to get this done – add a LoadDashboard method to your ViewModel: 

privatevoidLoadDashboard()
    {
        var pathToTheDashboard = Path.Combine(Environment.GetFolderPath(Environment.SpecialFolder.Desktop), @"Dashboards\Email Efforts.rplus");
        var fileStream = System.IO.File.Open(pathToTheDashboard, System.IO.FileMode.Open, System.IO.FileAccess.Read, System.IO.FileShare.ReadWrite);
        Dashboard = Dashboard.Load(fileStream);
    }

Don’t hit F5 just yet…Make sure you load the dashboard  
If you try to load your dashboard at this point, you will only see the white screen and the watermark you had seen during step 4. At this point, it is crucial that you actually call the loading routine to get the dashboard loaded. You can do this by adding the simplest constructor to your ViewModel, which will allow you to cross the finish line.

publicMainViewModel() 
{ 
    LoadDashboard(); 
} 

And that’s it! 

That’s how easy it is to embed a dashboard into your WPF project. To view the working example, download the ReportPlus Desktop application (if you already have an Infragistics account, you can use this link instead) and enjoy the ReportPlus Embedded experience. 

To learn more about ReportPlus Embedded, also check out our past blogs here.