Alteryx Designer Desktop Ideas

Hey there,

 

The performance profiling option on the "runtime" tab is very helpful to identify bottlenecks on a long-running workflow.   However this is missing (along with the entire "Runtime" tab) if I change this to a macro.

 

Given that the only way to build relatively complex dependant chain jobs is to wrap them in dummy batch macros (using a macro like a sub-procedure with flow-of-control on the master-canvas) - most of our work is done in Macros - so it would be helpful to be able to performance profile them during testing.

Right now in order to pass a parameter to pre/Post SQL we need to make a macro as a work around.

It would be really great if this was a native capability for the output tool so we don't have to replicate all the output too fields as macro inputs

Hello,

It appears that Alteryx does not accept .svg (or other vector image format) for icons (I think to custom macro icons), image in comment, etc...

I think that would be a great idea, especially to manage web integration and support of different resolutions.
here an example of a svg logo I made :


As you can see you can zoom in/out without loose quality.

 

If the workflow configuration had a run for 'x' number of iterations option it would make debugging macros a lot easier. My current method consists of copying results, changing inputs and repeat until I find my problem which feels very manual. 

  

As seen in This Discussion Post,  the idea here is to be able to add a link to example workflows in macro descriptions - like the ones seen in native tools.

 

Filter Tool

Many thanks to @jdunkerley79 for demonstrating how this can be done by manually editing the macro's XML - specifically by adding a child element to the <MetaInfo> section, like so:

 

      <Example>
        <Description>Open Example</Description>
        <File>\\aSERVER\aRootDir\path\to\Alteryx\Macros\Date Wizard\Date Wizard Examples.yxmd</File>
      </Example>

One small caveat is that it doesn't support truly relative paths.  @PaulN explained in the discussion post that a relative reference here would search in the sample folders.

 

"Alteryx default behavior is to look for examples under .\Alteryx\Samples\02 One-Tool Examples or Alteryx\Samples\02 One-Tool Examples (or .\Alteryx\Samples\en\02 One-Tool Examples)."

 

Having said that, trying to reference a macro example in the same folder (using a relative reference) will throw an error given the following situation:

 

Package Structure:

Date Wizard.yxmc XML edits:

 

      <Example>
        <Description>Open Example</Description>
        <!-- THIS WORKS -->
        <File>\\aSERVER\aRootDir\path\to\Alteryx\Macros\Date Wizard\Date Wizard Examples.yxmd</File>
        <!-- THIS DOESNT
        <File>Date Wizard Examples.yxmd</File>
        <File>.\Date Wizard Examples.yxmd</File>
        <File>./Date Wizard Examples.yxmd</File>
        -->
      </Example>

This shows a link in the Macro description but yields an error (shown below) when it is clicked.

 

Example Link ShowsError

 Once again, this works fine with an absolute file path reference.  

 

Here is ultimately what I am suggesting:  Can we add an option to the Interface Designer (that updates the XML) and have it allow relative paths?  Allowing relative paths would obviously be essentially to maintaining the macro's ability to be "lift-and-shift" when packaged/moved/uploaded to servers/galleries etc.

 

I'm assuming the option could look something like this, similar to the "Help" file -only it would show link in the macro description...

Interface Designer Suggestion

In conclusion, this would be very useful in providing links to example workflows for custom macros that may be complex and/or not self-explanatory.

 

Cheers,

 

Taylor Cox

I've recently been delving into using the interface tools and there are a couple of glaring issues for me as a developer/designer, all having to do with the UI, ironically (yes, I used that correctly!) with the interface tools. The irony here is that the interface tools utilise a poor user interface.

 

Firstly, I finished this video to ensure I was indeed doing things correctly, and I was.

 

The UI for designer's interface tools is incredibly sluggish. In order to rearrange tools, each time you create a new one, you have to push the up arrow for each tool and you have to traverse the groupings.

This will take forever. I counted 36 clicks.

 

Instead of this, I suggest two changes to the interface designer.

 

1. 1. Allow a control-click in the interface designer layout view so that multiple elements can be selected and they can traverse the groupings and be moved together. When one has, say 4 elements in 2 nested groupings, that is a lot of clicks to get your new element to the top. Having to do it with its radio-button partner: pretty much infuriating.
2. ONE at a time, children. No control-clicking. That would lead to pandemonium?Allow control-click in the tree view as well. The fact that we can only click one item at a time and move it one slot at a time is incredibly time consuming. It seems a no-brainer to at least allow a control-click here.
   • Bonus: Include the ability to jump to the top and/or pop out a level with left/right arrows in the tree interface. 

I know not everyone is building macros/apps and dealing with this, so I have little faith that this will jump to the top of your queue. But this is a painful part of the UI. I don't know if your UX designers could easily fix this or if it is more pain on your end than the pain you're giving me, but I just want to say: This hurts. 35 clicks every time I add a new element with no option to 'move to top' like you (wonderfully) do in the select tool is a big drag on my time (hint: maybe add that sort of functionality too; the select tool manages this stuff so well!). Which is supposedly valuable. In theory. But it certainly doesn't feel that way when I've spent 10 minutes clicking an up arrow (and yes, my UI is slow. And I may be exaggerating, but not by much!). 

Thank you for your continued improvement!

 

-Çædric Justice
Alteryx Developer
Cambia Healthcare

 

It would be helpful to be able to embed a macro within my workflows so in the end I have one single file.

 

Similar to how Excel becomes a macro enabled file, it would be great if the actual macro could be contained in the workflow.  As it stands now, the macro that I insert into a workflow is similar to a linked cell in MS Excel that points to another file.  If the macro is moved the workflow becomes broken.  I often work on a larger workflow that I save locally while developing.  Once it's complete, I then save the workflow to a network drive and have to delete the macros and reinsert these.  It also makes it challenging if I were to send a workflow to someone else... I will have to give them instructions on which macros to insert and where.  Similar to a container, they could be minimized so to speak to their normal icon, and then expanded/opened if any edits were needed....then collapsed when done.

 

Thanks for the consideration.

Despite being an Alteryx user for 2 and a 1/2 years this is something I have only recently came across but it does not appear that you are able to use debug mode appropriately with macros.

What I mean is, I have a macro input which drives a series of drop down boxes. In debug mode my drop down boxes will not populate. Now I understand why, Alteryx doesn't know what the input is so it doesn't generate the meta data for the debug mode drop downs.

What I suggest Alteryx do is automatically convert your macro inputs for file browses for the purpose of debug mode (I had to do this myself manually and it was a tedious task, not only to set up but then maintain two separate versions, one essentially an application and one a macro).

Or, by default debug mode uses the macro input data to run through debug mode as.

Ben

When building an Alteryx Macro - one of the tough parts is that the input data you put into the Macro Input is used for testing, but you cannot set the type.

 

So for example - I want to test with the value 1, and Alteryx automatically assumes this is a Byte.

However 1 is just a useful test value, but I need this to be an int 64.

 

Can we provide the option to strongly type the macro inputs - this way, we can give advanced users the ability to control the type on Macro Inputs, and not run into this sort of issue with test data implicitly defining the type?

 

Note: this is similar to the idea here:

https://community.alteryx.com/t5/Alteryx-Product-Ideas/Set-data-type-in-Text-Input-tool/idc-p/115209...

 

Would be great if anytime a tool (macro tools in particular such as "Data Cleansing" tool) is copied all items from the copied tool are retained to the new pasted version of the tool. Would expect in the instance of the Data Cleansing tool for example that in lieu of not showing the fields that were in the copied from tool to be shown similar tool in which they show but noted as "Missing" and then as the new copied tool is attached to a like data source (likely same data source elsewhere) they then are checked or not checked and no longer showing as "Missing". 

 

This would allow these tools to be copy/pasted and repurposed vs wiping out as they won't be associated right away on the pasting process until manually moved into the proper place on the respective new or updated workflow.

 

 

This is similar to a prior idea now marked complete "Allow macro metadata to persist until next run".  I tried the check box solution and still have the same issue, running V11.

 

What we NEED is for tools that derive columns like CrossTab to retain metadata from the most recent run and thus pass that metadata downstream for further tools and development.

 

Use case:

I have several cross tabs and before V11 I could run the flow once to push metadata downstream, then add or modify tools downstream and the derived fields from the cross tab stayed available in those tools to be recognized and referenced as I add more tools and logic. Now in V11 I am finding if I click on a tool or add a tool downstream the metadata for the derived columns disappears.

 

I attached pics to illustrate where I have 6 CrossTabs and decided I needed to add a summary downstream.  I had to run the flow to get metadata populated which is normal and I added the first summary, then inserted another summary and immediately the derived column metadata was lost in all paths after the crosstabs.  so ended up having to re-run the flow 5 more times for each summary tool added. then I had to re-run it 5 more times to adjust column names in selects after downstream joins.

 

I end up wasting a lot of time having to re-run a sufficient test file to feed all the variety of data necessary to generate all columns between most edits or new tool adds.  What used to take ~5 minutes to do now takes ~35

 

I recall seeing and discussing this issue previously and hoped the check box would resolve but It does not fix the issue.  

 

We see similar issue for tools downstream from other tools where the columns are derived or uncertain until that tool runs, such as, transpose, Joins and Unions.  I recall some discussion at user groups and in the community but the only reference I found this morning of seeming relevance is the one I mentioned above.

 

The autorecover feature should also backup macros. I was working on a macro when there was an issue with my code. I have my autorecover set very frequent, so I went there to backup to a previous version. To my great surprise, my macro wasn't being saved behind the scenes at all. My workflow had its expected backups, but not my macro. Please let any extension be backed up by autorecover.

 

Thanks!

Currently - in order to run a series of Alteryx processes which have start-finish dependancies, you have to hack this by putting each sub-process into batch macros with fake inbound and outbound controls and a fake control parameter.   Additionally, alteryx forgets the mapping of parameters if you move stuff around, and you have to re-link it all up again, running each step 1 by 1 until the next one fails.

 

some may say "just use Block until done"

- this only partially solves the issue if your dependency chain is one deep (e.g. create the table; and then send a summary of errors found in the table)

- this doesn't create any ability to encapsulate flows to create simplicity - so it drives the user towards having increasingly bigger and more complex canvases

 

If we could create a new macro-type or container-type which just allows start-to-finish dependency chaining like a sub-procedure, and which just passes on what was in the input stream directly to the output stream - this would materially improve the ability to simplify flows; and at the same time it's a cheap and easy way to allow for detailed dependency and flow control.

 

Happy to talk through this live with the team if that makes sense?

 

Thank you

Sean

 

I frequently make analytic apps for my clients that requires them to enter information or parameters to the workflow via a prompt before running. The user could be entering codes that will affect a certain filter or it could be a prompt to browse to the new source file required to run the workflow. In order to make adjustments to the workflow itself, I need to work in Debug mode so that I can see the data as it passes through each node in the workflow. Once I am done making all of the changes in debug mode and I am satisfied with how it works, I then have to remember each change I made, and copy and paste each tool and its contents over to the workflow that I am debugging. This is a pain because it is like I am fixing the workflow twice. A good solution to this would be allowing the user to apply changes made in debug to the workflow you are debugging, so that there is no duplication of efforts!

It would be great if we users could have the ability, ideally in a simple interface (maybe workflow option) to create .yxi macro installers. This would allow us to create and really simple, quick and straightforward way on installing macros in Alteryx rather than having to copy into certain directories or add through the user settings.

 

I know we can edit the XML on @AdamR_AYX CREW Macro installers etc. but this would make it really simple for single macros.

 

I'm assume this might already be on the road map, but will be useful to discuss.

 

YXI Files Intro Blog: https://community.alteryx.com/t5/Engine-Works-Blog/YXI-Files-in-Alteryx-10-5/ba-p/20773

 

Discussed briefly on Twitter by @Joe_Lipski, @chris_love @jdunkerley79 @danielbrun2 but probably better to bring the discussion here: https://twitter.com/Joe_Lipski/status/811907135516852224

I have some fairly long running analytic apps on my private gallery.  We have many different users who will run these apps and I would like to send them an email when the app is complete so that they don't have to keep checking back for results.

 

I came across a few different posts that explained how to use a text input named __cloud:UserId to determine the user id of the person running the app and then to query the MongoDB for that user to retrieve their email address.  These posts were very helpful, as I do have it working in my analytic app.  However, I tried putting all of this into a macro so that I didn't have to copy/paste every time I needed the current user's email address.  Unfortunately, the __cloud:UserId text box does not seem to work if it is in a macro. 

 

Please extend the Workflow Dependencies functionality to include dependencies of used macros in the worflow too. Currenctly macros are simply marked as dependencies by themselves, but the underlying dependencies (e.g. data sources) of these macros are not included.

 

We have a large ETL process developed with Alteryx that applies several layers of custom and complex macros and several data sources referenced using aliases. Currently the process is deployed locally (non-server) and executed ad-hoc, but will be moved to the server platform at some point. 

 

Recently I had to prep an employee for running the process. This requires creating aliases and associated connections and making sure that access to needed network locations is in place (storing macros, temp files, etc.). Hence I needed to identify all aliases and components/macros used. As everything is wrapped nicely by a single workflow, I hoped that the workflow dependencies functionality would cover dependencies in the macro nodes within, but unfortunately it didn't and I had to look through the dependencies of 10-15 macros.

Current State:  When a macro contains nested macros the only method that reliably works to share them is via yxi (which I fondly refer to as my wixies). 

 

Future State:  Allow macros published to the gallery be their own tool palette so that when I or any user connects to the server the macros are there and just work, no import, no visible install just a single set of tools that work on that server. 

Side task - also get export to yxi 

 

 

Pardon the length of this post, but I have been working with Alteryx since version 2.0 (11 years) and have been accumulating a wish list ever since.  Some of these suggestions have been made in the past but have yet to be embraced.  This is the first post for the first 'idea' but, as I said, this is a wish list that has grown since I was first introduced to Alteryx. More posts will follow.

 

I will break this into sections to hopefully make the suggestions easier to categorize and digest.

 

Application interface - Since I was introduce to Alteryx, the application interface (what is presented to users) has remained rather stagnant and, with the rumored push to adopt HTML as a replacement for pcxml, could benefit from the following additional settings. I suggest these based on the fact that dot Net classes for interface controls are readily available in Windows which allow for manipulation of each of the controls attributes.

 

1. The ability to set 'style' attributes for each of the interface tools in the application interface (font-family, font-style, font-size, font-weight, color, etc. This could be presented to the developer as an additional (perhaps optional button) in the Configuration panel for each interface tool as below:

These settings would be specific to the type of interface tool and to how the individual tool would layout and/or be styled relative to the application interface window. One layout option, applicable to most interface tools, would be where the label would be relative to the object itself (top, bottom, left, right). The CSS could be stored in and interpreted from the XML of the yxwz file referencing the ToolID of the Node in a section of the XML hierarchy called <CSS> or something standard.  An option to alter the default CSS could be displayed with a radio button control so that if not selected, the tool would fallback to the default system CSS of the tool.  This default could also be set in System settings so that a consistent interface could be defined across the enterprise.

 

2. Moving to the actual window that displays when the application is opened, a lot of the same concepts could be applied to the Interface Designer pane.

Attributes that could be set could include position on screen when opened, width and height of the window, and all the attributes of a dot Net form.  The same radio button strategy used for individual interface tools could be employed to use or not use system defaults.

 

3. In the UI, it would be nice if there was additional flexibility in how the interface tools could be laid out.  Along with the relative position of labels for each control, being able to layout controls horizontally as well as vertically would allow for a more organized interface.

 The Radio buttons would work as normal with the Text Box controls inside each Radio button and only displaying when the button is selected.

 

I realize a lot of the current development in Alteryx is focused on the new Alteryx Connect and being able to attach to more data files and services. But, if there is still also a concerted effort to move from what could be considered a legacy proprietary mark up language, pcxml, to a more robust and universally accepted mark up, html and css, then, in my humble opinion, expanding the options for developers to design more user friendly and customizable applications to a standard 'style' across the enterprise, both on the desktop and in the gallery, is a worthy endeavor.

 

Thanks for your attention.  More to follow.

 

Dan