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:

Notification

• 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.
  

Encapsulation

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.

Relevance

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 48] 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!