Search

Designing a Great Widget

What Is a Widget?

A widget is:

  • a small, single-purpose application
  • at-a-glance information
  • quick access to simple interactive functions

Why Do Widgets Matter?

Widgets add value to end users by giving them faster access to the specific workflows, tasks, and data that are relevant to their role and responsibilities. As part of our UX strategy, widgets help us simplify the enterprise—helping users be more productive, effective, and satisfied.

How Do You Design a Great Widget?

  • User-Centric Design: Ensure that your widget is intuitive and simple, with clear functionality. Use Infor’s SoHo components for UI. Be sure that your widget supports all themes to ensure seamless integration across platforms.
  • Performance-Oriented Development: Optimize performance with limited initial data loading, efficient server-side paging, and minimizing unnecessary requests. Consider the settings’ impact on performance and use; respect published configurations if settings are implemented.
  • Quality and Compatibility: Conduct thorough testing for bugs, crashes, and compatibility with different size configurations and platforms. Avoid embedding third-party libraries or causing side effects to other parts of the DOM.

Widget Design Checklist

The Infor Design System’s enterprise component library is a framework-independent UI library consisting of CSS and JS that provides Infor product development teams, partners, and customers with tools for creating user experiences that are approachable, focused, relevant, and productive.

When creating a widget, you’re required to use SoHo Components to build your UI.

This checklist includes guidance to help you avoid common pitfalls when designing your widget. This is the same checklist used when reviewing widgets for approval to be included in the widget catalog.

  1. Widget must support all Infor themes: Light, Dark, and High Contrast.
  2. Widget must work without issues in Ming.le Homepages and in Portal 2.0 Workspaces:
    • Themes render differently in these two products. Ming.le Homepages uses our Classic theme, inherited from our legacy SoHo components. OS Portal uses our new Uplift theme. There are key differences in typography, color palette, and iconography.
    • Use the latest SoHo components to ensure that your widget renders properly in both products.
  3. Widget should support different sizes: 1×1, 1×2, 2×2, etc.
  4. Widget should work well on a mobile device, inside a web browser, and in the Infor Go mobile application.
  5. Widget functionality must be simple, clear, and easily understood by users.
  6. Widget should not have multiple calls to action in a small space. This especially applies to the 1×1 widget size. Multiple calls to action will cause issues on mobile, where the touch targets are much less forgiving.
  7. Empty states must have more specific messaging that better reflects the underlying data and current context to help guide the user to the best next action.
    • Avoid generic messaging, such as “No data found to display.”
  8. Don’t create a widget for super-specific filterable categories like “Projects Ending Within 30 Days.” Instead, create one widget that can be configured to show this kind of data.
  9. Don’t include the user role in the name of the widget.
    • Do: “Safety Overview” Don’t: “Manager Safety Overview”
    • Do: “Candidate Summary” Don’t: “Manager Candidate Summary”
  10. Don’t specify the type of data in the name of the widget.
    • Do: “Tasks”
    • Don’t: “Task List”
  11. Don’t reinvent the wheel when building your widget:
    • Do: Use SoHo components to build your widget.
    • Don’t: Use custom CSS or other third-party components.
  12. Don’t use more than 4 fields in a 1×1 widget list row. Don’t simply display information. Add value by providing meaning to the information and suggesting the next action to the user.
  13. Widgets with search or filtering mechanisms must have functionality that is clear to the user. Don’t add search or filtering to a list if the list is static and only provides a small number of entries.
  14. Don’t include content that requires horizontal scrolling within the widget, such as large tables or a data grid.
  15. Display only relevant information that provides actionable insights to the user. Hide everything else.
    • Showing every available piece of information will overwhelm the user—so they may just ignore the widget altogether.
    • The data displayed should inform the user just enough to take the desired action.
    • You can give the user the choice to add more data points if they want to and/or if possible.
  16. Follow the UX writing guidelines on design.infor.com when formatting numbers, dates, currency, etc. (Please email us to request access.)
    • If the copy in the widget needs to be translated, be sure to account for different character counts with the real estate available in the widget

Widget Development Checklist

This checklist includes guidance to help you avoid common pitfalls when developing your widget. This is the same checklist used when reviewing widgets for approval to be included in the widget catalog.

  1. Widget must support all Infor themes: Light, Dark, and High Contrast.
  2. Avoid hardcoded colors. Colors must look good in all three required themes.
  3. Widget should load an initial 10 to 15 data items and support server-side paging with the option to load more. Maximum records are 100.
  4. Widget must be developed with performance and response time in mind, use as few requests as possible, and minimize the data loaded up front without user interaction.
  5. Widgets with settings must support publishing:
    • If settings are used, the widget must respect the publish configuration that specifies which settings are enabled and visible, etc. If you have actions available in the Widget Title bar, or inline configuration that depends on settings, you must read the API documentation carefully.
    • This also applies to a widget that is not published but has published information on a published page.
    • If the widget doesn’t respect the publish configuration, user settings must be turned off when published. In that scenario, set enableSettingsWhenPublished to false in the manifest.
  6. Don’t store too much data as settings. Basically, only store key-value pairs. The page size must be kept to a minimum. There’s a maximum size per page that will prevent the page from being saved if it’s too big.
  7. Avoid polling for data updates:
    • We don’t recommend polling. Instead, implement the refresh action in the Widget Title bar.
    • If polling must be used, then make sure to use long intervals. (For example, default interval 15 minutes, and minimum 5 minutes.)
    • If you implement polling, you must use the activated and deactivated event on the IWidgetInstance so that the widget isn’t requesting new data unless it’s visible and active on a Page.
  8. A widget shall be a small application that provides quick access to information or functionality. Avoid making the widget too complex, it shall not be a complete application.
  9. Split the widget into multiple components instead of one huge file. One component per file.
  10. Small methods, low complexity.
  11. Don’t use global variables.
  12. Access only public documented homepages APIs.
  13. A widget is only allowed to make changes to the widget DOM element and its children. There must be no side effects affecting other parts of the DOM.
  14. Don’t include:
    • third-party libraries
    • JavaScript libraries <script> tags
    • a link in CSS files (it would affect all widgets)

Read the full Infor Widget SDK Developers Guide.

If you’d like to have access to the full design.infor.com site, please email us. Please include your company name, and the names, titles, and email addresses of the people who need access.