You’ve already used an Electron application; you just might not have known it. Electron applications provide the basis for some of the apps you use daily—Microsoft Teams, Slack, and Visual Studio Code.

Electron is a modern, open-source framework for building desktop applications. Since it runs on the Node.js runtime, Electron makes it possible to harness JavaScript—typically a web technology—for the development of desktop applications. That’s a powerful way to take our expertise in web technology and apply it to desktop development.

Let’s talk about why DMC loves building with Electron!

Why DMC develops with Electron

Electron is cross-platform. Have a use case that calls for compatibility with Windows, macOS, and Linux? Your Electron application will run on all three, so you need just one code base. You’ll benefit from a smaller, tighter engineering team focused on a single application for minimized time to market and maximized market reach across multiple platforms. A singular code base means that bug fixes, updates, and new features need only be implemented once.

Built on the Node.js runtime. Equally as important is the runtime itself. Electron runs on Node.js, a JavaScript runtime environment, taking advantage of JavaScript’s position as the world’s eminent web technology. Not only does this align with DMC’s sweeping base of expertise in developing JavaScript-based applications, but it also means that you’ll be able to involve your developers in the technical process during an application’s development and support, including post-handoff of the application. That common technical understanding means all parties are speaking the same language and are geared up for success for the lifetime of the application.

Prototyping and proof-of-concepting. An often-understated utility of Electron development is its handiness for prototyping. Since Electron applications can be spun up quickly — and because you’ll have access to the vast community of established libraries and frameworks built for JavaScript — an Electron application is ideally suited to building out a viable proof of concept perfect for getting projects off to a promising start.

Trying out new ideas with Electron Fiddle. Sometimes, all you need is a playground to test out that idea that’s been bouncing around in your head. Electron Fiddle is Electron’s take on JSFiddle. It’s a lightweight desktop studio for quickly running a simple Electron project. Maybe you want to experiment with a new feature for your application. Or maybe you want to download someone else’s demo and click around on your own. Fiddle allows you to run an Electron application without the overhead of initializing a completely new project. I love this capability and use it both for exploring new features and testing out small tweaks to colleagues’ code. You can read up on Electron Fiddle here.

Packaging and Distributing with Electron Forge. Electron Forge is the all-in-one tool for initiating, configuring, pipelining, and distributing an Electron application. At the start of your project, you’ll use the Electron Forge CLI to spin up a template application. Later, when it’s time to distribute, Electron Forge facilitates three core steps in the distribution sequence:

1. The packaging of the application to a bundled executable
2. The making of the bundled executable into a distributable (such as a .zip or an .exe)
3. The publishing of the distributable so that your application is available for users to download

Users love it

Developing for the web means recognizing the dominant design for the everyday user’s experience. Developers and non-developers alike have come to expect a certain standard: a modern browser serving webpages on a modern JavaScript framework—think React with Material UI or Angular with Angular UI. Why shouldn’t this expectation carry over to the desktop application experience? For consistency and seamlessness, it makes sense to craft desktop applications that look and feel like their web counterparts.

An Electron application fluently brings the desktop application must-haves—offline capabilities, local system access, process launching, hardware discovery—and merges them with the familiar user interface elements of the web.

When it comes to picking JavaScript frameworks and libraries, Electron lets you choose your own tools. You can keep things simple and lean on basic HTML and CSS. Or you can scaffold up a full-fledged React application via Next.js.

Case Study: A desktop application for high-throughput data analysis and visualization

The problem: Our client, a global aerospace and defense technology company, sought to modernize their in-house data analysis and visualization workflow. Their existing workflow relied on several de-coupled applications for processing and exhibiting their data, and there was no official means of warehousing the data. Their team needed a successor platform to provide stronger scalability and faster workflow throughput while still retaining the data reporting functionalities of the legacy system. In modernizing the legacy platform, they laid out a set of key requirements:

• The solution must provide for the storage of captured data.
• The solution must ingest large datasets and visualize them clearly, and it must do so performantly.
  • Presentation of data must support advanced visualization controls such as time-shifting, zooming, and time-trending.
  • Plotting must be capable of processing up to 1 million data points.
• The solution must support the validation of data.
• The solution’s data processing must be offline-capable. If data is available locally, no network connection shall be required for the core functionality of the application.

The solution: DMC identified a path forward to replace the legacy workflow platform with a single cohesive solution. The bedrock of the solution is a data analysis desktop application built on Electron. Here’s why we landed on Electron for building out this application:

• Electron gives our development team access to a range of powerful JavaScript packages for plotting, UI, and navigation. These are the packages that supply the familiar, expected experience of the web, and Electron brings them to the desktop environment.
• Electron’s access to the native OS empowers us to launch a local Python service upon Electron startup. This allows us to easily take advantage of Python’s proven libraries for data crunching, validation, and report generation.

To round out the solution, we then spun up cloud-based data storage hosted on Amazon’s S3 service. As a whole, DMC delivered an application to meet the client’s need for a comprehensive data intelligence and reporting platform.

The post Electrifying Desktop Application Development with Electron appeared first on DMC, Inc..

Prerequisites

• Visual Studio Code installed on your machine
• Node.js version 20.17.0 installed on your machine (other versions of Node will likely work as well)
• General understanding of navigation in Visual Studio Code IDE

Steps

1. Open Visual Studio Code and create an empty folder “LocalizationExampleJS”:
   
   
    
2. Add the file “LocalizationExample.js” at the top level of your new folder:
   
   
    
3. Add a new subfolder "Resources" with empty files “en-US.json”, “es-MX.json”, and “fr-FR.json”:
   
   
   
   
4. Add the following code to each JSON translation file. It’s important for the text keys in all 3 files to be identical – in this case, the sample text we are using has the key “HelloWorld”.

en-US.json

<code>
{
  "HelloWorld": "Hello World!"
}
es-MX.json
{
  "HelloWorld": "¡Hola Mundo!"
}
fr-FR.json
{
  "HelloWorld": "Bonjour le monde!"
}
</code>

<code>
{
  "HelloWorld": "Hello World!"
}
es-MX.json
{
  "HelloWorld": "¡Hola Mundo!"
}
fr-FR.json
{
  "HelloWorld": "Bonjour le monde!"
}
</code>

5. Add the following code to “LocalizationExample.js”. This will enable you to supply a command line argument containing your desired locale string during testing. (Note that in an actual web frontend solution, the frontend code would need to access the current user’s culture from the server, NOT via command line argument.)

<code>
const args = process.argv.slice(2);
const currentCulture = args[0];
console.log("Your supplied culture is: " + currentCulture);
</code>

<code>
const args = process.argv.slice(2);
const currentCulture = args[0];
console.log("Your supplied culture is: " + currentCulture);
</code>

6. Below the code to extract current culture from command line arguments, add the following code to access the “HelloWorld” string for the supplied culture. If a culture is supplied that is not present in the application, then an error message will log accordingly, and the application will default to the “en-US” locale.

<code>
var pathToJson = "./Resources/" + args[0] + ".json";
try {
  const jsonObj = require(pathToJson);
  console.log(jsonObj.HelloWorld);
}
catch (err) {
  console.log("Culture \"" + currentCulture + "\" does not exist in this application - using default locale en-US.")
  pathToJson = "./Resources/en-US.json";
  const jsonObj = require(pathToJson);
  console.log(jsonObj.HelloWorld);
}
</code>

<code>
var pathToJson = "./Resources/" + args[0] + ".json";
try {
  const jsonObj = require(pathToJson);
  console.log(jsonObj.HelloWorld);
}
catch (err) {
  console.log("Culture \"" + currentCulture + "\" does not exist in this application - using default locale en-US.")
  pathToJson = "./Resources/en-US.json";
  const jsonObj = require(pathToJson);
  console.log(jsonObj.HelloWorld);
}
</code>

7. Your code is ready for testing! It should look something like this:

<code>
const args = process.argv.slice(2);
const currentCulture = args[0];
console.log("Your supplied culture is: " + currentCulture);

var pathToJson = "./Resources/" + args[0] + ".json";
try {
  const jsonObj = require(pathToJson);
  console.log(jsonObj.HelloWorld);
}
catch (err) {
  console.log("Culture \"" + currentCulture + "\" does not exist in this application - using default locale en-US.")
  pathToJson = "./Resources/en-US.json";
  const jsonObj = require(pathToJson);
  console.log(jsonObj.HelloWorld);
}
</code>

<code>
const args = process.argv.slice(2);
const currentCulture = args[0];
console.log("Your supplied culture is: " + currentCulture);

var pathToJson = "./Resources/" + args[0] + ".json";
try {
  const jsonObj = require(pathToJson);
  console.log(jsonObj.HelloWorld);
}
catch (err) {
  console.log("Culture \"" + currentCulture + "\" does not exist in this application - using default locale en-US.")
  pathToJson = "./Resources/en-US.json";
  const jsonObj = require(pathToJson);
  console.log(jsonObj.HelloWorld);
}
</code>

8. Open a terminal and test out the LocalizationExample solution using the command node .\LocalizationExample.js xx-XX, where “xx-XX” is a locale string representing the combination of a language and a region. Try out “es-MX”, “fr-FR”, “en-US”, and “pt-BR” (Brazilian Portuguese) as command line arguments.
   
   Note that the HelloWorld resource for the cultures “en-US”, “es-MX”, and “fr-FR” all appear translated as expected. However, the “pt-BR” locale yields the HelloWorld string in English, because this culture is not present in the collection of translations, and our code explicitly defaults to the “en-US” U.S. English locale in this case.

Localization Tips and Tricks

When it comes to localization, there is a lot more to consider than simply translating text and accessing it appropriately from code. Read on to learn some tips and tricks for elevating your localization solution!

Text Key Organization

Generally, DMC has found that it is beneficial to organize text keys into separate files based not only on language, but also based on what page of your application the text belongs on. For backend localization, this is likely best done by splitting text by controller. Here is an example of a backend localization file structure that includes two controllers, “Login.cs” and “Home.cs”, and two cultures, a default culture and “es-MX”:

• Resources folder
  • Login folder
    • Login.resx
    • Login.es-MX.resx
  • Home folder
    • Home.resx
    • Home.es-MX.resx

This separation organizes your translated text in a way that is easily modifiable for each individual page of your application.

In the event that identical text appears in multiple places in your application in English, it is still beneficial to duplicate that text key/value entry across pages, rather than maintaining a single key/value item. For example, if the word “Email” exists on both the “Login” and “Home” pages in the example above, this text key/value should exist in both the “Login” resource files and “Home” resource files. This enables you to update the text in one place without modifying the same text elsewhere, if desired. Also, translations of the same English word or phrase could be different across different languages, depending on the context of how the word or phrase is used – in this case, separate text/key values are necessary for translators to appropriately translate your application text.

Variables and Pluralization

Variables and pluralization can be quite tricky to handle in any localization solution. For a backend solution with .resx files, if you have a sentence to translate with a variable in the middle, you need to separate any given string key/value into separate parts that precede and follow the variable.

For example, say you want to include the phrase “Hello, {name} – welcome to my site!” The following key/value structure would need to be implemented in each .resx file to handle this phrase:

Additionally, numeric variables add an extra layer of complexity to a localization solution, because pluralization must be implemented for these. The way words are pluralized can actually differ significantly across languages. For example, Slavic languages (e.g. Russian, Czech) have a different style of pluralization for 5 or more of an item than they do for zero, one, or 2-4 items. So a solution that translates to Slavic languages must implement separate logic for pluralizing 5+ items than for other items. For example, the sentence “You have {number} items in your cart!” may have a key/value structure like this in English:

As you can see, this is a complex case to translate for – there are 8 total key/value pairs to accommodate just one sentence that integrates a numeric variable. To avoid the need for this, one solution is to reduce or eliminate the need for accommodating plurals – for example, you could rephrase “You have {number} items in your cart!” to instead become “Number of Items in Cart: {number}”. This would only require one key/value pair to be translated instead of eight.

Fallback Cultures

When a user’s specific locale does not have a translation present in your application, it can be beneficial to implement fallback cultures so this user is given a more suitable approximation of their desired language. For example, say a Spanish speaker lives in Spain and therefore has their browser locale set to “es-ES”. However, your application only has resources for Mexican Spanish “es-MX”. Ideally this person in Spain would see the application in Mexican Spanish rather than the application default of English, because Mexican Spanish more closely matches their desired language than English does.

Using .NET backend localization, fallback cultures can be implemented by simply renaming any files ending in “es-MX.resx” to instead end in “es.resx”. Per .NET’s culture fallback scenarios, upon receiving a request from the Spain Spanish user, .NET will still search for “es-ES” first. But upon not finding this specific culture, .NET will “fall back” to just the “es” portion of the locale string and will access the text as it exists in this new general Spanish file. Users using Mexican Spanish “es-MX” will see the same behavior.

Common Pitfalls

Localization can be complicated, and there are some common pitfalls you may encounter if you are implementing your own localization solution. Here are some examples:

• Logging / error messaging: if you are displaying raw exception messages to your users, then these are not able to be localized because they are generally hardcoded in English by the entities providing the error messages. In this case, your application should be updated to display custom error messages to your users instead of raw messages.
• Identifying EVERY source of user-facing text: There are many possible sources of text in your application that can go unnoticed, which can then become difficult to handle late in the localization process. Some examples are images, email templates, and messages from external libraries/packages/APIs. If you are doing frontend only localization, then it becomes necessary to make 100% certain that there is NO user facing text coming from the backend – if you discover late in the process that some user facing text comes from the server, then some “hacky” solutions may be necessary to preserve the frontend-only localization scheme.
• Not enforcing a single source of truth for text: If there is not a very solid system in place for establishing and updating the “source or truth” for translated text, then the localization process can quickly become messy. Things are always changing during development, and if there is not an established system to deliver text updates to translators and other stakeholders, then any one party can modify text without other stakeholders’ knowledge and introduce confusion. Enforce a single source of truth for text that all stakeholders can agree on. (Resource files are likely NOT the appropriate single source of truth, since non-developer stakeholders should also have control over text in the application.)

The post Basic JavaScript Localization Setup Using JSON with Visual Studio Code appeared first on DMC, Inc..

A simpler solution is to use Javascript & jQuery, and the following code outlines how to hide any field on your SharePoint form. If you are unfamiliar with Javascript, no problem! Just edit the fieldsToHide line with whatever fields you wish to hide. Separate fields using commas, and surround each field with quotations.

If you would like to understand how the code works in detail, read the following section. If not, skip to Adding the Code to Your SharePoint Site.

The Code

<script src="//code.jquery.com/jquery-latest.min.js"></script>
<script>
	function HideFields() {
		//Enter the fields you would like to hide here.
		fieldsToHide = ["Enter", "Field Names", "Here"];
	
		//Get all SharePoint fields
		var formFieldTitles = $(".ms-formtable td.ms-formlabel h3.ms-standardheader");

		//Iterate over each row in the form
		formFieldTitles.each(function () {
			//Get the text of the field title
			var textToMatch = $(this).text();
			//Get the table row associated with this title
			var currentRow = $(this).closest('tr');

			//Iterate over our list of fields we wish to hide
			for (var i = 0; i < fieldsToHide.length; i++){
				var field = fieldsToHide[i];
				//Match the SharePoint field name to our field name
				if (textToMatch.toLowerCase().replace("*", "").trim() === field.toLowerCase().replace("*", "").trim()){
					//Hide this field
					$(currentRow).hide();
				}
			}
		});
	}

	function AddToBodyOnLoad(){
		//Ensure that our function is called last by pushing it again
		_spBodyOnLoadFunctionNames.push("HideFields");
	}

	//Add our function to the array of onload functions
	_spBodyOnLoadFunctionNames.push("AddToBodyOnLoad");
</script>

<script src="//code.jquery.com/jquery-latest.min.js"></script>
<script>
	function HideFields() {
		//Enter the fields you would like to hide here.
		fieldsToHide = ["Enter", "Field Names", "Here"];
	
		//Get all SharePoint fields
		var formFieldTitles = $(".ms-formtable td.ms-formlabel h3.ms-standardheader");

		//Iterate over each row in the form
		formFieldTitles.each(function () {
			//Get the text of the field title
			var textToMatch = $(this).text();
			//Get the table row associated with this title
			var currentRow = $(this).closest('tr');

			//Iterate over our list of fields we wish to hide
			for (var i = 0; i < fieldsToHide.length; i++){
				var field = fieldsToHide[i];
				//Match the SharePoint field name to our field name
				if (textToMatch.toLowerCase().replace("*", "").trim() === field.toLowerCase().replace("*", "").trim()){
					//Hide this field
					$(currentRow).hide();
				}
			}
		});
	}

	function AddToBodyOnLoad(){
		//Ensure that our function is called last by pushing it again
		_spBodyOnLoadFunctionNames.push("HideFields");
	}

	//Add our function to the array of onload functions
	_spBodyOnLoadFunctionNames.push("AddToBodyOnLoad");
</script>

The first line imports the jQuery library, which makes it easier to select and hide elements on a page. To learn more about jQuery, visit their official website.

The first line in HideFields() defines which fields we are going to hide. This is the line that you should change to match the fields on your form, and add additional fields if desired.

The AddToBodyOnLoad() function forces our function to be loaded last on the page. This ensures that the fields have been created and are viewable in the DOM.

The HideFields() function iterates over each field on the form, then iterates over each field in our list of fields we want to hide. If there’s a match, the entire row is hidden from view. Unfortunately, we cannot remove this row from the DOM, since there will be unintended side-effects, and SharePoint will not be able to save the list item.

Adding the Code to Your SharePoint Site

SharePoint 2013 & Office 365

1. Navigate to your SharePoint list.
2. In your browser url, replace AllItems.aspx with the name of the form (default forms are NewForm.aspx, EditForm.aspx, and DispForm.aspx).
3. Click the Gear icon in the top right, then “Edit Page”.
4. Click “Add a Web Part”.
5. Under “Categories”, select “Media and Content”.
6. Under “Parts”, select “Script Editor”.
7. On the new Web part, click “Edit Snippet”.
8. Copy the code from above, and paste the contents into the dialog.
9. Edit the 5^th line with the fields you want to hide on this form.
10. Click “Insert”.
11. In the top left, click “Page”, then “Stop Editing”.
12. Your fields should now be hidden from view.

SharePoint 2010

1. Navigate to your SharePoint list.
2. In your browser URL, replace AllItems.aspx with the name of the form (default forms are NewForm.aspx, EditForm.aspx, and DispForm.aspx).
3. Click the “Site Actions” in the top left, then “Edit Page”.
4. Click “Add a Web Part”.
5. Under “Categories”, select “Media and Content”.
6. Under “Parts”, select “Content Editor”.
7. On the new Web part, click “Click here to add new content”.
8. In the “Editing Tools” ribbon section, click “Format Text”.
9. In the “Markup” section, click “HTML”, then click “Edit HTML Source”.
10. Copy the code from above, and paste the contents into the dialog.
11. Edit the 5^th line with the fields you want to hide on this form.
12. Click “OK”.
13. In the top left, click “Page”, then “Stop Editing”.
14. Your fields should now be hidden from view.

Learn more about DMC’s SharePoint services.

Contact us for SharePoint consulting.

The post How to Hide Fields on a SharePoint Form appeared first on DMC, Inc..