Analytic Apps | Share Your Experience!

[joannallyson]

The User Experience Team at Alteryx is interested in hearing about your experiences with Analytic App Building in Designer.

I’ve included a few questions to guide your response, but feel free to share any additional information about your current usage of Analytic Apps:

1. Is there anything you find challenging about the current experience? 
2. What tips and tricks do you share with others when they’re learning how to build Analytic Apps?
3. What are some of the main reasons you’re building apps?

Thanks in advance for your help!

[patrick_digan]

@joannallyson 

1

1. Action tools are a big challenge for app building. They aren't very intuitive and take a lot of time to sort out exactly what's happening and why. They are so flexible and powerful that most people don't know how to use them or where to start. I prefer reference shortcuts.

2. Debugging apps is very problematic when you use action tools. Not being able to hit the run button and see you're data flowing through is hard to debug. The current debugging which is separate from your workflow can duplicate work and is also klunky. Reference shortcuts fix this.

3. I find it challenging that you can use User and engine constants in an expression editor but not question constants. This would remove much of the need for reference shortcuts. It would greatly simplify things. I can't stress enough how big this would be. idea here.

4. The fact that you can run apps in both designer and the server really confuses people whenever there are differences. Designer can display browses and files on the network whereas the gallery cannot. 

5. Not having the ability to have interface tools connect to each other is a challenge. for example, if you have a state and county lookup, I would like the county lookup to be filtered down once you select the state. idea here.

6. I find it challenging that you can't rename questions on the workflow configuration panel and can't provide test values in the tool's configuration window. It makes for a lot more unnecessary clicking around. idea here.

7. Perhaps slightly off topic, but there should be an easier way to combine steps than chaining apps. Chaining is very tricky and involves a lot of overhead since the 2 workflows have to often duplicate things. It would be great if there was a better way to go back and forth with the user (ie have 1 workflow with various stopping points where it collects data from the user. Keeping it all in one workflow would make it simpler). 

2

reference shortcuts are the way to go when building apps. They make it easier to build and debug.

3

All of our apps fall under the general idea of getting info from the end user and run the workflow based on that. So they're basically just a way to filter down the process to whatever subset the end user is interested in.  We do this via the gallery and api calls.  

[warrencowan]

Ok, wow where do I start, love apps...lots of positives, but lots of challenegs too. May require a few posts to dump it all.

Orchestartion / Automation

I run a series of analytic apps in order to orchestrate a multi step workflow, and the chained app experience wasn't sufficient, so I now run alot of my apps from the command line applying the relevant alternate values or config files to vary the execution for different customers and jobs.

I was dissapointed to find that the desktop scheduler wouldn't support the running of 'values configured' apps, and was also frustrated that the run another app on completion couldn't carry the same support for running the next app with values configured.

Would be great of the runner macros could support the same as these are a great go to for orchestration but unfortunately became quite redundant once I needed to run an app with preconfigured values.

Messaging / feedback

When you're running the app, you dont get much more than the ever refreshing green status bar, which can be a bit meaningless with long mult section wokflows as its just fills up and resets continually with each stage of the flow without giving you a real sense of how progressed the app is. Also the absence of any tool status messaging means you can't really get a view on any progress/issues (or lack of) until it's all over.

Tooltips / User guidance / Validation

Sometimes a question isn't enough to guarantee corrrect user input. Eg you want the user to apply a regex in a question text field, but need to advise them on the style/constraints/gotchas etc. I have tried appending labels for additional notes but it can get a bit cumbersome if you have lots of notes and instruction to give. Would be nice to add rich text / links / video / images etc for detailed guidance, perhaps in a tooltip. Some custom validation rules would be useful too, to flag a question that has been incorrectly filled in . eg...question is ''Add Domain", and the user forgets to add the http part or adds a trailing slash when you'd prefer them not to. Can save a user hours of wasted time and dissapointment.

UI

So the 90's called, they want their UI back :D. Sorry couldnt resist. But seriously the UI does feel a bit dated in the web whatever point 0 world we live in and given the fresh face of the new alteryx UI. When designing the form, having to move items around by clicking directional arrows (especially on large multi page forms) can get a bit tedious and is at odds with the drag and drop nature of using alteryx generally.

[DavidP]

Hi @joannallyson 

Thank you for this post and the chance to provide feedback. I agree with all the point already made here.

A couple of additions from me:

UI:

I find that only being able position interface tools in a single vertical column very restrictive. When building a UI you want to be able to place objects and containers next to each other and have more freedom in laying out your UI canvas with buttons, containers, dropdown, text boxes, etc. That way we'd be able to build much more user friendly and feature rich apps.

The idea to use something like the custom tool html SDK for App building really appeals to me (Idea posted here)

Introduce Label or Comment box interface tools that allow you to place descriptive text on the UI canvas. Being able to update this text dynamically from data fields would also be great.

In fact, wouldn't it be great if you had a mini App UI canvas inside the Interface Designer where you can drag and drop interface tools to design the layout of your UI like you would in the workflow canvas?

Interface Tool content driven from upstream fields:

This bit is REALLY confusing. 

Interface tools such as drop down allow you to fetch entries from the field names in the upstream data, but only if this information is static and available BEFORE the app is run, or from the last time it was run. By way of example, say you have a dropdown tool that is connected to the output of a CrossTab tool. If you run the App by clicking the magic wand before running it 1st as a workflow, there will be no options in the dropdown. When you've run it once it will remember the last run settings. But let's say you bring in a Dynamic Select to only show fields that contain the word 'Monday', that won't update in the App interface until you run it again as a workflow. Confused? So am I.

The key thing here is that ALL your app selections are and the options presented in the interface tools are made BEFORE the app is actually run, so if you rely on anything that actually gets generated or changed during the running of the App, that won't work.

I'll come back with more ideas later on.

[wwatson]

Challenges:

Apps on Designer do not behave the same when moved to Server.

Some tools like the directory tool and browse tool are not supported on Server Apps.

So you have to design Server Apps differently to Designer Apps.

Having to chain apps to pass the results of one to the next is a bit clunky. It would be better to allow the internal results to be cached for use in later parts of the workflow.

Tips:

Make sure the workflow works as a workflow before adding any interface tools.

Main Reasons:

To allow users to be able to enter data to filter the data before output and also to allow the users to enter email addresses to send the output to.

[cplewis90]

Hello @joannallyson,

I am loving this discussion post! I think apps are such an underutilized portion of the Alteryx toolkit. I agree with a lot of the sentiment from @patrick_digan. Here are my full thoughts below:

1) 

A - Ensuring action tools are applying to the correct part of the tool it's connected too can be quite a struggle and then in some instances doesn't work quite as intended. For example if I connect a text box to a formula tool to replace the value of a string that is hardcoded in the formula tool ("Replace Me") and I connect an action tool to replace that it also replaces the " marks in the tool as a default.

B - Debugging is quite the challenge and making sure the functionality is working as intended is very tough. I don't mind that a debug opens a new workflow, but it would be nice to be able to push any changes (that allows you to fix any problems) back to the original app. Without this aspect altering your app in a debug scenario becomes very cumbersome and requires you to make continuous notes of changes so you can make them back in the original app.

C - It is a challenge to have to use a secondary app to feed front end values to a list box or any other interface tool. Chaining apps is not always the easiest to debug or have it be successful and it would be much easier to allow on open any part of a workflow that feeds the UI components. 

D - The differences in the way UI components look and the way things operate in Designer versus on Server is definitely a challenge. At times I feel I can't develop something locally as it could present problems on server, so I am constantly saving versions to server and this can slow down development time and also create a more complex development cycle. 

E - A specific mention on a tool would be around drop downs. It is helpful to be able to use the first letter to go to the values starting with that letter in a drop down, but what would be even better is a drop down that is searchable. An end user could have so much more functionality in this type of drop down and would simplify use. You can find this idea here

F - Chaining apps secondary issue. In my apps I use a lot of the temporary files location (%TEMP% or [Engine.TempFilePath]) and when you chain apps, this variable does not cross over chained apps even though they are operating as one app. Trying to create files and ensure files aren't overwritten (if multiple runs of an app occur simultaneously) can be quite challenging when chaining apps. 

2) 

A - Requirements gathering on the front end is so helpful in the development process. Ensuring you understand the process of what the app needs to do and what a front end should entail allows you to mock up the UI and get feedback to avoid as much rework as possible. This can entail using a drop down versus a list box or tree file as a requirement may need to allow for multiple selections and not just one.

B - Multiple interface tools can update a single tool and you can also have multiple interface tools flow to an error message. This has been tremendously helpful for me and something I wish I knew from the beginning. 

3)

A - Automating Process

B - Standardizing metric data pulls

C - Simplifying analytics for end users (we incorporate data science algorithms with simple front ends to allow end users to custom build models based on selections)

[ChrisTX]

I agree with all of the previous feedback.

A few other items:

Is there anything you find challenging about the current experience? 

  1 - Inability to automatically save a log file from each run of the app.  Suggestion: for Designer Desktop apps, let us specify a folder where log files from apps will be stored.  On Server, let us specify if an App run history will be stored on the server, including a log file.

  2 - To an end user, the completion of a workflow is not very intuitive.  After the progress bar goes away, if the user chooses to not open any output files, they are returned to the window that prompts for parameters.  Give us an option to display a pop-up message when the workflow completes, including a note "Workflow completed with 0 errors", the start time, end time, run time, number of warnings, errors.  And a clearly labelled prompt for "Here are the output files created by the workflow.  Select the files you want to open.  Or click Exit to close the workflow."

What are some of the main reasons you’re building apps?

  To migrate to Server, for end user self-service.

Chris

[cgoodman3]

@joannallyson 

1. When debugging workflows changes the ability to make changes in the debug workflow and translate these back to the original workflow, for example I often find that if a workflow fails I need to make multiple changes to get it working but keeping track of these and migrating back to the main workflow isn't easy.

1. Chained apps having the ability to run another workflow downstream based on a condition

1. Many tools have been updated to have a HTML5 interface, but analytic apps provide a poor UX due to lack of a good UI

1. Nesting of interface controls isn't always clear and the arrow to move things around can be clunky

1. As others have said, being able to dynamically update values in things like a drop down box dynamically based on the new data read into the analytic app instead of solving it as a chained app

2. Use the debug tool

3. To have a UI for users to interact with and easily change input files, parameters without needed to open the workflow and modify

3. To host a workflow on Gallery to allow non-Alteryx users to use apps.