In this example, the default action will be for the ‘percent of total’ macro to run since it is the left branch (and the detour tool is set to branch to the left by default). Now we need to connect one of the radio buttons to the detour to instruct the workflow to change course when that radio button is selected. This will hide the detail sitting within the button when it isn’t clicked by the user. I also recommend the ‘collapse group when deselected’ option. Then, go to the design interface and group the questions under the correct radio button heading. Name them after the functions / sub-macros. Secondly, radio buttons are pretty user-friendly as they allow you to group questions and you can choose to make them collapsible.Īdd two radio button tools – one for each of the branches/functions. go right instead of left) when the relevant radio button is selected. Firstly, we can configure the detours to change directions (i.e. The easiest way of doing this is to use radio buttons. We need to make this dynamic based on which function the user selects. Without adding any configuration or actions to the detours, the detour will simply ‘go to the left’ in all cases. Set up radio buttons to group the macro questions in the user interface Note: this means that there’s nothing stopping you from adding tools before or after the detour branches if you want to add steps that are common to both sub-macro branches.
For a detour to work, you also need to bring the branches back into one at the end of the alternative routes. Start by placing the detour tool where you want the branches to separate. I like to start by linking up the different tools in the workflow with the detour tool.
In this example, I want to give users the option to switch between two macros: ranking and percent of total. Let’s start by illustrating how a detour tool works with a simple two-branch workflow. Associating the detour with actions allows you to determine the path(s) to be taken depending on a user’s selection.īack to my macro suite example. You can manually check a box in the tool to change this to the right, but there’s little point setting up a detour without configuring it to act dynamically within a macro or app. In other words, any tools that follow the detour in the right branch will be bypassed altogether. Without any configuration the tool will default to the left. It splits a workflow into two branches (left and right), only one of which will be taken when the workflow is run. The detour tool lets you programme which ‘path’ a workflow should take in a particular circumstance. My aim was to allow the user to determine which macro to run and to only return the relevant results. You could also use the designer interface to group the queries to improve usability as a quick fix. In this example, it’s difficult to tell which macro the options belong to.Īt this point, it would be possible to construct the workflow to run all the macros and join the results at the end. This should result in all the user queries within the macros appearing in a fairly disorganised way, as you can see in the picture below. The first step was to combine all of the macros into a single workflow (without thinking about linking them up for now). This way, a user could toggle between different table calculation options through one interface (see picture below). In short, instead of having separate macro workflows, I wanted to bring several together into one tool. The focus was naturally on building the macros themselves, but over the past few weeks I’ve tinkered with the ‘suite’ aspect of the challenge.
Back in week 3 of the Data School, DS12 were set the challenge of developing a suite of table calculation macros.