I really like how Appian is evolving over the last coupe of years since i've stared using it. It is good to see regular release with new feature but there are a few that I'm really missing in Appian and could be game changer.
At the same time i would like you community what you are looking for to be added to Appian?
My most missing features:
1. More flexible filtering options for Grid. I would like to filter by any column in place having only values that are available if filter is added on other column. It should work similar how you can do it in Excel or in most tables on the web with simple JS dll.
2. More control over Grid appearance. It would be good to be able to decrease the font size, spacing, padding and margin to make table more compact. It also would be good to prevent word wrapping and have more control over column width if text is long.
3. Possibility to write expressions as Java/Python code within Appian if there is such need.
4. Dedicated component for navigation sidebar/breadcrumb navigation
5. Possibility to upload files from shared directories
6. More control over Export to Excel for the record list
Discussion posts and replies are publicly visible
1. Freezing of top row in grid.
2. More formatting of the Excel download options as it is difficult to get a thousand separator in Excel sheet export.
3.when error occurred on the screen sending a print screen logic via Appian.
4. Flexibility of creating the Interfaces without a specific column layouts.
5. PDF Export options
appianspace.com/.../
Furman said:More flexible filtering options for Grid.
Most of the things you list here are possible when you manually create your own filters on-form, FWIW.
Furman said:It would be good to be able to decrease the font size, spacing, padding and margin
Decreasing font size is pretty straightforward by using Rich Text component and simply setting font size to small. Cell padding is already reduced (to a certain extent) by choosing "dense" spacing for a grid.
Furman said:Possibility to write expressions as Java/Python
Interesting, though I'm not really sure what this buys or how it would work.
Furman said:Dedicated component for navigation sidebar/breadcrumb
The nice thing about being able to make your own custom components is you can customize it for yourself much more than any generalized OOB component would be able to accomplish.
Furman said:Possibility to upload files from shared directories
I'm not sure what this means - do you mean on some automated basis, without the user having to upload on-form? I believe there are plug-ins that can already help with this, but I haven't messed with them.
Furman said:More control over Export to Excel for the record list
Agreed - and by "more control" you really mean "any control".
FWIW, I have my own list of feature request / enhancement items. Several of them exist as posts and/or comments here, i.e. if you search "[Feature Request]".
I fully agree with statement that Appian should send print screen when error occurs. It would be also good to have something similar to programming langue's as try catch for each node.
In terms of excel you are right. Business always expect results in nice formatted Excel
Nice try...
Mike thanks for replay comments and links.
To the above list i would like to add nother points:
1. Error handing in process models - something simillary to try... catch that you may know from different programming languages.
2. Generic logging approach - setup logging for entire app and then use it whenever you want - something similar to C# Log4Net
3. Multiple test case scenarios for UI - if you have UI with multiple ri then it would be good to be able to create multiple test scenarios and easily switch between them to validate if your logic still works.
4. Possibility to test UI on DEV environment as different user. Quite risky but useful if you have different privileges' level or need to check maker/checker functionality as a single user.
Furman said:create multiple test scenarios
I really like this one. I feel like this is a victim of different evolutionary paths between interfaces and expression rules - expression rules kinda "accidentally" got a way to store different default values (though it's a bit more of a pain to load one of them), whereas interfaces have a really easy way to store and load only one set of default values.
Furman said:test UI on DEV environment as different user
Yeah - my usual approach is to declare a local variable early in an interface, i.e. "local!currentUser", which by default is based on the rule loggedinuser(), but which I can set to a different username to test other username-based form rendering approaches (group membership, etc). But some things simply aren't testable just by passing a different username (folder security, rule security, function security), so it would be neat to have a "test as username" function for designers with the appropriate level of security. I suppose it might just be too complex to figure out how to prevent someone from potentially abusing that.