Applies to version: 2016.1.x; Author: Grzegorz Straś
“So what does this thing do anyway?”
In an ongoing quest to make Designer Studio more intuitive and easy to learn, we have decided to alter some of the terminology that we use to describe workflow components and certain features in Designer Studio.
In our minds, the ideal user experience is when you open a configuration window for a feature that you’ve never used before, and you automatically have a pretty good understanding of what every widget is for. Obviously, depending on the complexity of the feature in question, this is sometimes more and sometimes less possible (which is why we have info buttons and the F1 manual). Nonetheless, the purpose of every button and field should be at least somewhat apparent at first glance.
To this end, it is important that all terminology in Designer Studio (used to describe workflows as well as the features of the tool itself) is descriptive, accurate, and above all – consistent.
With all the training sessions we’ve held over the years, be it in person or online, we’ve managed to gather plenty of feedback on the terminology that we use in Designer Studio. In general, most of our naming choices fall into one of the following four tiers:
Microsoft tier – The terminology used by Microsoft across their products (and most importantly: SharePoint) is understandably the highest possible level of canon, and we wish to abide by it wherever possible.
Understandable tier – This large group ranges from all the super-obvious terms that are completely self-explanatory given the context in which they are found, to the ones which need a few words or sentences to describe (usually through an info button next to the relevant widget). We would like the vast majority of the terminology we use to fall into this category.
I’ve-seen-something-simillar-in-another-BPM-under-a-different-name tier – Some functionalities are known under different names in other BPM solutions. We want veteran IT specialists who use Designer Studio for the first time to instantly feel at home. Therefore, we have no problem with adapting our naming convention to match the ‘industry standard’.
Outdated tier – Much of our older terminology was either directly translated or adapted from Polish. Unfortunately, as time went on, some of these became problematic. Terms and concepts which need copious amounts of text (and in extreme cases – hand gestures) to explain also fall into this category. Either way, a rework is more than necessary.
The language changes in WEBCON BPS 2016 mainly aim to address the terminology that falls into the bottom two tiers. Certain phrases from the ‘Understandable’ tier where also given an upgrade, mostly for consistency purposes.
Here are the biggest terminology changes we introduced, along with a short explanation for each:
|Older versions||New in BPS 2016||Reason|
|Workflow element |
(8.1 – 8.3)
|Workflow instance||Consistency with Microsoft and industry terminology.
The first iteration (Workflow document) was directly adapted from Polish, it was changed to ‘element’ in order to avoid confusion with electronic media files (Word, PDF etc.)
In BPS 2016 we are retiring ‘Workflow element’ in favor of ‘Workflow instance’ – a commonly used and familiar term across the industry.
|Document type||Form type||A form type dictates which of a process’ form fields will be available on the SharePoint form (i.e. the contents of a workflow instance). The old term was a direct adaptation from Polish and poorly reflected its actual purpose.|
(sometimes also referred to as ‘signature’)
|Instance number||Outdated adaptation from Polish.
Consistency with the move to ‘Workflow instances’.
Each workflow can have a defined template for uniquely numbering its workflow instances.
|Associated documents||Related instances||Consistency with the changes mentioned above.|
|Associated document types||Associated form types||Consistency with the changes mentioned above.|
|Document subtypes||Form subtypes||Consistency with the changes mentioned above.|
|Global security||Permissions||Consistency across Designer Studio.|
|Company||Business entity||Term commonly used within the industry.|
|Action kind||Action type||The old terms – ‘kind’ and ‘type’ – were very ambiguous. The first was meant to refer to what an action does, and the second to the circumstance which caused the action to be executed.
From now on:
Action type – The effect of the action (e.g. Invoke Web Service, Change field value)
Action trigger – The cause of the action (e.g. On path, On entry to step).
|Action type||Action trigger|
|Variables||Constants||Constants are extra fields that can be defined within Designer Studio to store specific values to be freely used in most configuration areas (e.g. SQL queries). Their original purpose – when they were still called variables – was to assist with creating flexible configurations in Designer Studio that would use different values defined within the ‘variable’ depending on the environment (DEV/TEST/PROD). However, the value definitions themselves were… well… constant.|
|Tag, Reference tag, Brackets, ‘Moustache’, Alias.||Variables||Reference addresses to system metadata lacked a consistent name. See more below.|
Variables, the artist formerly known as ‘Reference tags’
The concept of ‘tags’ is in essence extremely simple and intuitive. What was problematic however, was that they were always an “under the hood” and “inside” thing, which rarely needed explaining to IT specialists who grasped the idea almost instantly. Unfortunately, this resulted in the lack of a standardized name, and spawned multiple unofficial monikers.
So what are they?
Variables, previously known as tags, are references to various metadata in the system – from the values of specific form fields, to the name of user that is currently logged into SharePoint.
In Designer Studio configuration menus, Variables are represented by colorful blocks:
Underneath, variables will appear as text in curly brackets – this is the form in which variables are saved in the database:
Whenever a query/script/action is executed, all of their variables are instantly substituted with corresponding system data, appropriate to the given context.
Over the years, variables had many different unofficial names. The most colorful of these nicknames is definitely “Moustache”, which alludes to the curly brackets inside which their text form is contained.
With the newly renamed ‘constants’, the term ‘variables’ became available again – and so we have decided to officially christen our old ‘Reference tags’ as Variables across the system.
There are two more language-related issues which I would like to address:
BPS translator (https://bpstranslator.webcon.com/)
Brand new and shiny, BPS translator is an application where other SharePoint power-users (like yourself) can suggest new translations for various BPS-related components of the SharePoint interface (e.g. pop-up messages, Web Part configuration settings).
So if you would like to participate, and help make the end-user interface more user-friendly, be sure to check out the Getting Started page and request an account.
In case you are looking for a way to make the processes you design support multiple languages, you should definitely check out this article:
The article talks about how to use these: buttons found throughout Designer Studio to enter custom translations when defining process components (e.g. when you create a picker-type form field named “Favorite cheese”, you can make it appear as “Queso favorito” and “Lieblingskäse” in Spanish and German browsers respectively).