New blog posts [1]

  • 18 January 2019
  • 3 replies
New blog posts [1]
Userlevel 4
Badge +1
For as long as I can remember people have been expressing their wish for this new feature. If they could somehow quickly gauge whether or not they should open a tab page somewhere in their application to see if there’s data in there… wouldn’t that be great? With the increasing adoption of smartphones and mobile apps for businesses this need is becoming more manifest. This is why I’m excited to announce that such a feature is now an integral part of the Software Factory, as of version Pyxis – G9.8. Welcome to Badges!

There’s this paradoxical thing about badges to me. They seem like such a small addition, but after I learned to identify them, they suddenly popped up everywhere, like little pixies:

New private messages and pull requests on Slack

There are two unread emails

There’s an update for an installed app on an iPhone

Visual Studio 2015 has three Extension and Product Updates

If you’re wondering what tab page in your browser loaded an ad which just shattered your eardrums…

Apparently badges got some huge potential. It’s important therefore to dig a little deeper and figure out exactly how badges are implemented in the Software Factory, and why it was done that way.

Badge basics

The examples above all share these three common characteristics:

  1. Notification – A badge is a notification about something that has changed or updated externally. An essential point here is that badges provide new information.
  2. Encapsulation – What’s changed or updated is not immediately visible.
  3. Relevance – A badge is an indication of something that requires attention. The flip side of this is that if no badge is displayed on some item, it can be safely ignored. This is their true paradox: badges only start shining at their full brightness… if they don’t show up! This benefit cannot be underestimated. Badges save time.
When translated to the Software Factory, these characteristics emerge like this:


  • Badges depend on data in the application which is subject to change.
  • In the absence of push notifications, a badge is polled periodically. Therefore the model contains a setting for how often this needs to happen.
  • To accommodate for a wide range of specific uses for badges, a new application logic concept BADGES is introduced which generates a badge stored procedure for each entity (tab/task/report).
  • Each variant contains a definition for a single badge. Tab pages for example look at the badge which is defined for the detail variant which is shown when the tab page is selected.
  • A badge does not depend on user state, such as which filters are applied to the data inside a tab page. In some cases it does make sense to model a (locked) prefilter alongside a badge. The canonical example there is a list of active work items.


This determines where badges are shown, which is anything someone can click on with the effect of displaying new data: live tiles, listbar items, tab pages, etcetera.


This one is all yours!

If you’re looking for candidate variants where badges could be useful, then remember that the power of badges is in enabling people to safely ignore things. So, every time you open a work screen or a tab page just to find nothing there, and you feel like you just wasted your time, your first thought should be: ‘badge!’ Oh, and if there are more than 6-7 badges on someone’s screen, that may be too much of a good thing – they lose their effectiveness when there’s nothing left to ignore. Here’s today’s free cliche for you: Less is More.

Let’s get started!

The single prerequisite is that you’ll need to upgrade your Software Factory to G9.8 so badges become available.

Now, let’s say you’d like to add a badge to some subject, or one of its existing variants. For this, you go to the same place where you would define your general settings such as default screen types. Badges can be defined right on the first tab page:

The interval is specified in seconds. If no interval is given, a default value of 300 seconds (5 minutes) is assumed. The interval is interpreted as a guaranteed minimum period of time between successive identical calls to a badge stored procedure. An interval of zero activates non-default behaviour in which badges are retrieved only once, until the underlying table is refreshed.

Note that there’s also an extra checkbox under the Performance tab page, like for the other three application logic concepts which apply to entities.

Adding badge code

Next up is adding a control procedure and template to write your functionality. There are two badge specific parameters:

  1. @variant_id/V_VARIANT_ID – Badges are specific for variants, but at most one badge stored procedure exists for each tab, task or report. This is why badge stored procedures – unlike other application logic concepts – have a @variant_id parameter, so you can branch on its value and write code for each specific badge.
  2. @badge_value/V_BADGE_VALUE – This is the badge value to display. Right now this is assumed to be an integer value between 0 and 99 for compatibility reasons, but the range of possible badge output values may be expanded in future versions of the Software Factory.
There are also parameters for each possible target reference column, so the badge value of a tab page can be determined by its active parent record.

The generated code may look similar to this:

And finally, this is the end result in the deployed application (in Dutch):

The prettiest [8] I’ve seen in a long time, don’t you agree?

Wrapping up

Even though I think the current design for badges in the Software Factory is sufficient to meet a great range of existing business needs, Team PI is still working on some improvements. So make sure to keep your GUI updated to the latest version. And: this is a great time to help us by sharing your feedback with us, so we can identify and prioritize requirements for future iterations.

Enough talk for now, don’t let me hold you up any longer. You can now safely return to developing at maximum speed!

3 replies

Hi Henk,

Great feature, i've got it working partly on a task.

My task (no variants) is set on two different locations:
  1. As a tile in the menu (shown);
  2. As a regular task assigned to a table (not shown).
For some reason the badge is shown only at the tile menu. And is missing at the other location. Even though it's the same task.

Does anybody know what i'm missing here?
Userlevel 6
Badge +5
Hi Henk,

Great feature, i've got it working partly on a task.

My task (no variants) is set on two different locations:
  1. As a tile in the menu (shown);
  2. As a regular task assigned to a table (not shown).
For some reason the badge is shown only at the tile menu. And is missing at the other location. Even though it's the same task.

Does anybody know what i'm missing here?

Hi Koen,

I think it's not possible to display a badge on a regular task. You can put the task in the menu, and display the badge there, but not on a tab task.
Userlevel 4
Badge +1
For some background, here is a list of ways in which tasks and reports are exposed to the end user, and how this affects badges:

1) Context menu - here badges are not shown because it involves a call to the back-end database and a context menu should not wait for this before opening. To fix this, the UI needs to store badge values before any context menu is displayed. This is a known issue, but I recommend reporting it again so we can better assess its severity.
2) Ribbon - reasoning analogous to the context menu, see above.
3) Task and report button bars - buttons on these components display icons only, no text. We've tried auto generation of a graphical representation of a badge value but none that was aesthetically pleasing enough to publish. Unfortunately, the third party control used for displaying button bars does not support this out of the box either. Also a known issue, but with no clear cut solution as of yet.
4) Menus (tiles, listbar, treebar) - implemented.

So no, you have not missed anything, and I'm sorry to say that currently there are no workarounds. If you'd like us to prioritize this work item then it helps to report a new issue through TCP.