Phone800.366.3472 SupportGet Support DocumentationDocumentation Resource CenterResource Center
search
close
Open Menu

Synergex Blog


Virtual Reality: How We Successfully Pulled Off Our First Remote Conference

By Liz Wilson and Heather Sula, Posted on July 27, 2021 at 11:20 am

Liz Wilson and Heather Sula

March 2020. We were three months away from the Synergy DevPartner Conference, an in-person learning event we hold for our customers every 18 months. Then the pandemic hit and upended everything. We had no idea that within a year, we’d have to completely reconceptualize and adapt our entire conference blueprint for a virtual audience while providing the same educational value and keeping the communal spirit of our in-person gatherings.

In the end, we were able to present 16 content-packed virtual sessions to a record number of attendees that, thanks to a boatload of planning and persistence, went off with barely a hitch. (You can watch most of the conference sessions here.)

Conference moderator Haley Hart and subject matter expert Marty Lewis lead a Q&A after a session.

Here’s how we did it.

Planning

Planning any large event is a significant logistical undertaking, requiring coordination and cooperation between multiple departments. The more you plan ahead, the less you have to panic at conference time. We won’t bore you with every detail of our particular planning process, but here are some foundational steps we took to make sure all our bases were covered.

What we did:

  • Held weekly conference check-ins. Communication is key for making sure nothing falls through the cracks.
  • Created standard branding. The conference had its own “look” that was used to design the website, PowerPoint templates, webinar rooms, session landing pages, etc., to ensure a cohesive aesthetic that distinguished it from our usual content.
  • Got organized. Whether it was shared spreadsheets, Kanban boards, etc., we made sure the key players had insight into the necessary tasks and timelines, so no one was in the dark.
  • Allowed time to work on “nice-to-haves” (informal networking sessions, giveaways, etc.) in addition to the necessary components of the conference. Sometimes it’s the little things that make an event special.

Additional Takeaway: Hold a pre-mortem. A pre-mortem is a thought experiment that encourages people to think about what could go wrong. A few members of the conference planning committee got together in April and did some brainstorming about specific issues that could arise during the conference. For example, we determined who would step in as moderator if either of our two main MCs called in sick. Or, if the Q&A portion of a session went on for longer than expected, we came up with a solution: unanswered questions would be collected and answered during the wrap-up session. Thankfully, no one wound up getting sick, but it was comforting to know we had a plan in case that did happen.

Execution

While planning is nine-tenths of the game, you still have to execute. The following are some things to keep in mind so everything goes smoothly when the time comes.

What we did:

  • Created a task force to handle registrant issues that communicated frequently. Because we had additional people on hand to field customer support, the organizers were free to focus on making the conference happen.
  • Kept an eye on statistics. We sent analytics to our sales team after every session so they could reach out to customers accordingly.

Additional Takeaway: Talking to a camera instead of an audience is…weird. Pre-recording most of the sessions was helpful for a handful of reasons: it allowed presenters to take a substantial breather between slides (grab a cup of coffee, get the demo ready without rushing), and we had the opportunity to add some creative flourishes in post-production. Still, most presenters found the camera to be a poor substitute for a live audience. In the future, we’ll consider inviting additional staff to recordings to act as a stand-in audience.

Session recording in our makeshift conference studio at Synergex HQ.

Flexibility

Ultimately, you have to be nimble, ready to adapt to changing circumstances, and take on any challenges that pop up. Luckily, you can prepare for flexibility too.

What we did:

  • Backups, backups, backups. For pre-recorded sessions, the main plan was to upload the files into the webinar platform and hit play. But we always had a backup plan in case something went wrong (private YouTube video versions of the sessions we could link to, etc.).

Additional Takeaway: You don’t need to use a one-size-fits-all formula for conference sessions. We had to work around several factors when recording the 16 sessions, including each presenter’s geographic location and level of comfort in a live vs. pre-recorded context. Rather than make everyone do everything the same way, we gave presenters flexibility in terms of how they wanted to structure and lead their sessions, and we wound up with a nice variety because of it.

We look forward to seeing you at the 2022 conference!

Check out the conference sessions and learn how to do the following:

  • Improve development productivity and practices through adopting more efficient development methodologies.
  • Enhance years of Synergy data and code with new technologies, enabling connectivity through RESTful web services and APIs.
  • Keep up to date with Synergy SSL and operating system security patches. (Security and disaster recovery are important for compliance!)
  • Use traditional Synergy in Visual Studio to gain a huge productivity boost, lower the barrier to continuous code integration, and improve processes and software quality.

Watch sessions here


Elevate Your Endpoints

By Liz Wilson, Posted on July 14, 2021 at 12:55 pm

Liz Wilson

If you’ve checked out our GitHub documentation, attended an office hours session, or watched a web services–related video on our YouTube channel, you may know that OData is a critical layer of the tech stack that makes up our open-source Harmony Core solution.1 There are several reasons for this: OData is standards-based, it supports query validation (so you can choose the data available to users in a given context), and the learning curve is minimal. Developers can look at a sample OData request and immediately get a sense of what is being asked for, and our implementation of OData emits JSON, a standards-based data format that other programming languages can parse with ease.  

OData is easy to work with, but it’s important to know how to make the most of Harmony Core’s API functionality, beyond just the basics. Here are some tips for maximizing the readability and performance of the APIs that you will be generating via Harmony Core’s OData services. 

Use Meaningful Names 

Harmony Core OData services rely partially on data structures and files from Repository. That said, where appropriate, it’s a good idea to have meaningful names for data structures, as these will be turned into URLs. For example, “CustomerNumber” would be better than “CSTNBR.” 

vs.

Don’t Skimp on Data 

It might seem odd to buck a “less is more” approach to exposing your data, but in the world of Harmony Core, the better setup will likely be one in which most of your data is initially made available to developers, and the specificity of who gets what is determined when these developers create URLs, like the one below, to extract the exact information they need:  

To do this, you can configure your Harmony Core environment to enable the entity collection endpoints feature. This will generate a new GET method in each of your controller classes that exposes their respective collections (e.g., all customers, all products, etc.). You can access the GET method through an HTTP GET request without parameters.  

Plan Ahead 

The more planning you do in terms of the data you’d like to query for, the more specific you can make your endpoints. The more specific the endpoint is, the faster your query will be, as asking for a smaller amount of data takes less time than requesting a large collection.  

If you have access to an entity’s primary key, you can adjust your environment configuration to enable single entity endpoints. This will allow you to whittle down your results with a URL that incorporates the item’s unique key, thereby reducing load time. To illustrate, our sample Harmony Core service provides testable queries for all customer data, as well as for a single customer.  

When I tracked how long it took to load each page, I noticed that the “all customers” collection took 114 milliseconds, while the single customer query took about half that time—52 milliseconds. 

vs.

If you’re able to map things out in advance and narrow your data needs further, you can specify an entity’s discrete properties. For example, rather than retrieving the entire data set for an individual customer, you can query for the customer’s phone number, name, or website. To do this, check out the instructions for enabling individual property endpoints on GitHub.   

Get Familiar with Third-Party Tools 

Our documentation references two useful API-related platforms: Postman and Swagger. Postman was created as client for testing API requests and responses and has grown to include functionality for building APIs, creating reports, and generating documentation automatically. You can find more information on Postman in Harmony Core tutorial two in Github

While documentation generation was a recent addition to Postman’s suite of API tools, Swagger has focused on API visualization from the very beginning. In a Harmony Core environment, you will have automatic access to Swagger-generated documentation for your endpoints, but you may have a use case for one of the other tools listed on their website

There are plenty of additional tips scattered  
throughout the Harmony Core tutorials on GitHub
so we encourage you to check them out! If you have  
questions on getting started with or furthering your use  
of web services, be sure to talk to your account executive  
or join us for a session of Harmony Core Office Hours.  
We have more best practices to share from previous  
Harmony Core implementations


1 Under the hood, Entity Framework Core translates OData queries into Synergy Select class operations.


When is a page not a page? And when should it act like one?

By Liz Wilson, Posted on February 12, 2021 at 11:30 am

Liz Wilson

The Synergy developer interested in RESTful web services may have noticed a few intriguing things about this liminal era between Web 2.0 and Web 3.0. For starters, a page refresh is not guaranteed each time you navigate to some new corner of a website or app. When it comes to the “traditional” concerns of HTML, Javascript, and CSS—despite what The Offspring may claim—you no longer have to keep ‘em separated. The list of ways that frameworks like Vue, React, and Angular have changed both user and developer experience is extensive, and taken together, all these changes allow for unique and dynamic websites and applications.

That said, while innovation has the potential to take us further from the traditional experience of clicking a link and waiting for a new page to load, there are a few characteristics of those webpages from the early 2000s that the front-end folks would be amiss to innovate away from. Here are just a few!

1. Specific, Descriptive Title Elements

The HTML title element, demarcated by the <title> tag, is meant to provide a succinct description of the document that the browser has just rendered. If you are one of those people who has anywhere from 5 to 50 browser tabs open at any given moment, you probably rely heavily on page titles, as they appear in the tab next to the site’s custom icon.

A specific and descriptive page title is not just beneficial for compulsive tab openers like me, however. Unique titles with more, rather than less, information can improve the search engine optimization of your site. Additionally, page titles are often the first component that screen reader users will refer to in establishing where they are in a site. So adding a company name next to “Home” or “About Us” is a helpful enhancement, as is including information about changes to the page’s state.

For example:

<title>Error – password invalid – Acme Corp: Login</title>

The title element lives with other metadata in the “head” of the document, so it’s not displayed on the page and is therefore relatively easy to neglect. And when you’re working with tools like Angular and React to create single-page applications, you’ll find yourself with one HTML file in your project folder, which means just one <head> section where a title element would obviously be placed. Fortunately, most of these frameworks and libraries have developed tools for generating dynamic page titles.

ASP.NET Core Razor Pages

To ensure that your page titles are being updated dynamically, use the ViewData attribute either in the page’s model (as demonstrated in the documentation) or its .cshtml file. In either case, make sure that if you use Layout, the title element is reading from the ViewData dictionary. If you follow the standard instructions for creating a Razor Pages web application, this is the code you will see in the _Layout.cshtml file:

React

For a similar effect in your React app, install the React Helmet node package. Once that’s done, it’s a simple matter of importing Helmet and adding the document head information within <Helmet> tags within components as needed.

Angular

Similar to React, Angular projects contain a single index.html file, and that’s it for documents with the traditional head/body structure. Angular’s data binding can’t access anything outside of the body tag, so in order to display different titles as the user navigates around the app, you need to use the Title service, which is a very simple class consisting of two methods: getTitle() and setTitle(). The Angular documentation provides clear examples of how to incorporate this class into your application.

2. Semantic/Logical Headings

Whether your site is built with HTML and “vanilla” JavaScript or the client-side framework your cousin’s cousin created last week, at the end of the day, a document object model will be created by the web browser from HTML—whether that HTML was manually written by you or not. The DOM is a cross-platform interface that represents HTML as a tree structure by organizing all the markup’s elements, attributes, and text nodes into objects and creating a logical hierarchy from these objects. The technology was developed in the early days of JavaScript to enable client-side interactivity, and nowadays, the DOM also serves as the foundation for the browser’s accessibility tree, which is a critical layer that allows screen readers and other assistive technology to make sense of the contents of a website. Objects within an accessibility tree contain information ranging from what the specific element is (e.g., heading, input, etc.) to whether the element has a state (e.g., checked or unchecked, collapsed or expanded).

With that in mind, while current design trends indicate that the amount of text on each page remains in decline, it’s still a good idea to create a logical hierarchy of information and use different heading elements accordingly. This will not only benefit assistive technology users, but also the large swaths of us who have been conditioned to look for a big ol’ heading in a prominent position on the page. So even if the page is not technically a page, make sure the main heading is contained in a heading tag (probably an <h1> or <h2>) and the information that is less important is organized under the subordinate heading levels (<h2>, <h3>, <h4>…).

3. Logical Focus Order

In the same way that you may need to apply more thought with new web architectures, it’s very likely that you will have to expend some amount of effort to manage keyboard focus to replicate the way that focus operates in regular old HTML documents. In a traditional website (barring questionable use of CSS), a keyboard user can tab through each page in such a way that mimics the visual flow of information: left to right, top to bottom. In a single-page application where new HTML documents are not actually being loaded in the browser, there is nothing that would necessarily prompt keyboard focus to jump to an element at the top of a new page, because there is no new page. The Angular website (built, naturally, with Angular) provides us with an example of this. If you tab to the footer section from Home and select About, rather than hopping up to something intuitive, like the links at the top of that “page,” your next tab will take you to the next item in the list of footer links.

There are other potential issues relating to mutable content, including focus effectively disappearing, or users getting shot back up to the top of a section if a button is replaced by some other UI component.

Again, today’s popular libraries and frameworks propose techniques for providing a good experience for keyboard users:

To conclude, there is no reason for the not-pages that make up your single-page application to look like they were built in 2006. However, a case can be made for ensuring that certain aspects of the early web experience are not thrown away with the bathwater.1


1The bathwater consists of jQuery, Flash, and frames.


I’d Like Some Information with that Information, Please

By Liz Wilson, Posted on October 29, 2020 at 5:16 pm

Liz Wilson

I started using Microsoft Teams daily when I was hired by Synergex back in May. While there were some features of the user interface (UI) that took a bit longer to master, I was able to discern most of what Teams was telling me about the status of my coworkers immediately. I looked at the green dot and intuited its meaning as “Available,” and by a similar process, came to the correct conclusion that red communicates the opposite state.

My general comfort level with user statuses in Teams is due to the design pattern that this UI component follows: the placement of a status icon next to, or partially on top of, the user icon. I’m a millennial, so I was exposed to this pattern early on via AOL Instant Messenger and saw it again in a more sophisticated form when Skype started its ascent to mass popularity during the early aughts.

Design patterns are powerful because they provide users with context. The widgets and components of an application that follows design patterns are immediately imbued with meaning by the user, while a layout that shuns convention risks a discouraging and confusing user experience. For example, the “infinite scroll” design trend, while still used in social media feeds, has fallen out of favor in the context of website landing pages, partially because visitors expect to arrive at a footer and don’t enjoy finding themselves lost in an unorganized (and data-intensive) sea of content.  

Context-Independent Components

There is, however, a limit to what users can understand about your application using background information gleaned from previous experience. To create a comprehensible and easy-to-navigate UI, components should provide enough information about themselves to make sense regardless of the varying expectations and abilities users bring to the table (i.e., the context from which someone is accessing your application). In regard to my earlier anecdote, I made the correct assumption about the green, yellow, and red dots in Teams right away. On the other hand, there was one status icon that meant nothing to me at first, as it resembled a sideways magenta jellyfish. Thankfully, in anticipation of this type of ambiguity, as well as the very real possibility that some Teams users may be color blind1, Microsoft included a description of each status in the tooltip, so by simply hovering over the magenta jellyfish, I learned that a) it was not, in fact, a jellyfish and b) it was the “out of office” symbol. Mystery solved.

It doesn’t take a visual impairment (or cluelessness, in my case) for accessibility issues to arise, just a lack of information about information. Take abbreviations, for example. New employees may not be familiar with the acronyms that populate the tabs and menus of your application. By providing a mechanism for identifying the full meaning of abbreviations and acronyms in the user interface, you’re lowering barriers to accessibility. This strategy is discussed in the Web Content Accessibility Guidelines and applies to mobile, web-based, and desktop applications, as well as traditional websites. Form validation is another area where a “more is more” approach to information is appropriate. I can’t count the number of times I’ve submitted a form and the only indication I’ve received that something isn’t right is a grayed-out submit button. Often it takes several trial-and-error attempts before I realize that the form wants me to format my date differently or add punctuation to a new password. In this situation, technically speaking, I’m receiving just enough information to have a sense of what’s going on, but not nearly enough to make an informed decision about what the application wants me to do next. Designers and UI developers can inject extra information into each field to guide people towards correct formatting and data types, the result being that users can successfully submit a form regardless of the context they’re working in (vision impairment, device dimensions, etc.). On a related note, individuals who use a mouse to navigate and fill out forms can see where the pointer has landed and enter data accordingly, so to provide a comparable experience to keyboard users, you can highlight form fields with a border as they receive focus. Once again, the WCAG website outlines this technique in greater detail.

There are hundreds of additional scenarios where context-independent components would enhance user experience, so rather than attempting to list them all here, I’ll recommend checking out Microsoft’s Accessibility Insights, an application and browser extension created to help developers make their applications as accessible as possible. The tool is open source, free, and available on Windows, MacOS, and Linux.


[1] According to the National Eye Institute, approximately 1 in 12 men are color blind.


Don't miss a post!

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

Recent Posts Categories Tag Cloud Archives