Appian 16.2 Review
Great seeing everyone at Appian World this year! It’s always a blast catching up with old friends, past clients, and talking shop about the latest techniques with Appian. My personal favorite had to be the Appian integration with Amazon Alexa, but Baxter came pretty close! I can’t wait for the day when clients start requesting those types of integrations!
Appian always releases a large feature-packed upgrade ahead of the conference, and 16.2 lived up to the hype! As always, I’ll be presenting my strongly opinionated overview of the release below, highlighting the most impactful features, how I believe they’ll be used, and what they say about Appian’s product roadmap.
We’ve got a lot of ground to cover, so let’s started!
I’m incredibly impressed with how Sites has evolved over the past couple releases, and 16.2 added the ability to embed Record lists along with Reports and Actions. I love the balance between simplicity and controlled customization that Sites now provide with custom branding and font awesome icons, and I’d strongly recommend using Sites instead of the Tempo interface when introducing an MVP or 1st app into an organization.
At this pace, I think Sites will be the primary interface for the majority of Appian apps 1–2 years from now. Right now, the interface is still constrained by only allowing 5 tabs though. Workarounds exist of course, but I’d love to see Appian introduce dropdown menus or some other intuitive way to navigate to more information.
Coincidentally, the Tempo interface suffers when too much information is available, and I’ve seen clients with 20+ Actions or 40+ Reports that are incredibly difficult to navigate since there are no options for grouping them and minimal filters available. Appian still hasn’t cracked this nut. The environment should feel simple yet robust when a client is starting out with 1–2 apps (close to what Sites is now) and scale to an easily navigable, dynamic command center for an organization as the platform model takes off. Universal search would be a good starting point for the latter example.
Appian was pushing Quick Apps pretty darn hard at Appian World, but I’m still a bit skeptical of approach. Quick Apps is basically a wizard walkthrough to simplify and speed up the creation of super simple applications. Geared toward business users, Quick Apps creates a ton of Appian objects to do basic CRUD operations on a record, with a fairly pleasing UI, and a couple other bells and whistles.
Here are my initial thoughts:
- It’s a great tool for demos, Business Analyst-use, and possibly bootstrapping a first application. It automates the construction of commonly used aspects of an application like the record dashboard, basic editing of data, etc.
- But I don’t recommend using Quick Apps in Production. Aside from the worries about accidentally creating a malicious application or memory hog, I believe end-users creating TONS of apps in Prod without them being considered, vetted, and tested by IT is messy and shortsighted.
- Generators are used in web frameworks all the time (Ruby on Rails especially), and there’s always a balance between “stand up something quickly” and “now I need to customize”. Unfortunately, enterprise software almost always falls towards the latter for any serious application:
- -> Sensitive information is being used, so permissions need to be finely tuned among stakeholders.
- ->DBAs want complete control and approval over the schema.
- ->Best Practices or a coding style guide is strictly enforced.
- From a first pass through the code generated by Quick Apps, I haven’t loved what I’ve seen:
- ->Appian’s Standard Object Names don’t appear to be followed in all cases. I saw constants that weren’t all uppercase and variables that weren’t camel-case. Mismatched naming conventions and coding styles hinder maintainability and lengthen developer ramp up times.
- ->Some undocumented/private uses of expressions (mainly if()) have turned up in some generated code.
- ->Each Quick App generates TONS of Appian objects, but common rules like ‘displayUser’ are then duplicated for each subsequent quick app. Sounds like another a maintenance nightmare.
- Each app has an “Activity History” which will be duplicated across apps and feels like a feature that should be built into the base product, not simply generated via Quick Apps or built by
Inline Rich Text Images
Inline images/icons are a great way to make a Record or Report stand out and are particularly effective at displaying categorical data to users (statuses/priority/performance). When the user first sees the field, they can read the text, but over time, a quick glance at the icon color/shape tells them everything they need to know. This UI paradagm is particularly useful in grids where users are scanning down a column. I plan to opt for inline icons over simple text quite frequently.
Hierarchy Browser Component
This new component allows end-users to better navigate any tree-like data structure, which Appian has traditionally struggled with. Previously, a designer had to use some combination of grids and links to build out a clunky solution that they would have to train end-users to operate. I’d recommend keeping this component in mind for selecting tree-like or parent-child structures over a grid, custom picker, etc.
Execute Smart Services in SAIL/Web APIs
Definitely the biggest paradigm shift for designers in 16.2, most Smart Services can now be executed from SAIL, instead of just processes. There were a couple plug-ins that have provided a similar effect in the past, but this is a huge shift for OOTB development. For instance:
- The a!writeToDataStoreEntity() function can be used edit scalar or grid data instantaneously, instead of on form submission. Reports can be used to edit data dynamically without needing to kick off a process.
- The a!startProcess() function could be used to start asynchronous processes directly from an interface, instead of via process model routing.
- Functions like a!completeTask() and a!cancelProcess() can be used in interfaces where end-users administer or cancel active tasks/processes.
- Web APIs are now “writeable” since they can call a!writeToDataStoreEntity(), and developers can now RESTfully start a process via a!startProcess().
I am curious about how error handling works, if say a database insert fails or a user doesn’t have permission to change a document, but can’t wait to see all the interesting use cases and design decisions that these new expressions will spur. Previously, Appian expressions guaranteed that they wouldn’t have side effects but that seems to have changed. There’s a good chance that applications will soon be labeled as pre-16.2 and post-16.2 because of the large deviation in how they’re built.
Cross-Browser Process Modeler (Preview Edition)
Designers can now use the process modeler from any browser, SAIL forms are available from debug mode, and the process modeler has a slick new look. I appreciate these improvements immensely, mostly so I can develop from my Mac via Chrome without painful workarounds. Kudos to Appian for releasing this feature in preview mode, rather than holding out til all the functionality is present.
My only hesitance is that the re-skinning of the process modeler misses an opportunity to improve and simplify the process modeling experience and reduce the ramp up time for new users to learn the interface. I’ll probably touch on this in a future post, but there’s ample opportunity for streamlining the experience (node inputs vs. outputs, multi-select nodes, number of nodes to learn, etc.).
Data Type Updates
- Data types are now updated on import without deleting the old version. This improvement will help remove an extra deployment step that’s commonly needed.
- Appian objects that reference the data type are now updated automatically, except for process models. Another improvement to simplify deployments and make Appian designer’s lives easier.
Testing Appian applications has come a long way in the past couple years. 16.2 continued the trend with some useful new features, and, in addition, the Appian CoE recently released an automated testing suite for Appian built with FitNesse and the excellent Selenium web driver.
- Complete Task & Start Process Smart Services — These new Smart Services replace the popular Task Puppeteer plug-in and can be used together to automate the user tasks of a process to run tests or “fast forward”.
- Batch Testing of Expression Rules via Smart Services — Expression rules can be tested in bulk at the application level or via process model.
- FitNesse — I’ll do a deep dive into the FitNesse automated testing suite in a future post, but I’m super happy to see Appian getting behind a particular automated testing approach. I’ve seen clients build their own version, but they were always worried their css selectors or xpath would breakdown with every Appian release. I’m excited to play around with the Fitness tool and answer the question: is Appian finally ready for behavior-driven development?
Best of the Rest
- Tempo is 25% wider — Screen real estate is always important and widely varied these days. I’m glad Appian is now more responsive to wide screen displays.
- Good for iOS — Appian is now compatible with Blackberry’s Good technology for iOS. Good is really popular in enterprises so glad to see the support.
- folder() — File this improvement under **FINALLY**! The folder() function now supports “documentChildren” and “folderChildren” properties, so the Custom Content Functions plug-in isn’t necessary for basic document retrieval.
- For Admins
- ->Import/Export configurations from the Admin Console
- ->User Management via the Admin console including bulk actions
- ->Application Import history is now available in the Admin Console
Whew, that was long! And I didn’t even cover everything! Too many features and too little time!
I’d love to hear what you think of Appian 16.2 and my review!