App Builder thoughts

💡
This is an initial log of feedback not intended to be publicly shared

API Previewer App

First concept, build an app that shows API output next to tickets for the Zendesk API.

Disclaimer, this is an actual app in development/review for the marketplace by my company, so a fun expertise to build this again with the App Builder.

Things I wanted to test

  • How does this behave
  • Can it render decent UIs
  • Does it know how to make API calls

Experience

  • Going from initial draft to working prototype was fast
  • iterative process really helps thinking about the app logically
  • ran into some issues where moving some elements behind tabs required some persistent nudging and rephrasing
  • Often while iterating on e.g. the 2 action buttons the app would forget the (finally) working tab bar options

Stopped development testing after a persistent Error getting response. Click to try again. Even after 24h the issue persisted. I presume because of either reaching a memory limit for the context (I iterated a lot), or it crashed because of me asking for the icons?

App I build by hand I tried to replicate

Gaps

I found myself trying to reset the context. Like "Go back to version 4" or STOP in order to go back to a working version of the app.

Modal View app

Second app was an attempt to replicate what I needed to build for a customer this week. They wanted to collect feedback from agents on how AI worked and for that they:

  • show a modal on ticket submit with status solved
  • gather feedback in three custom fields
  • store on ticket
  • solve ticket

Things I wanted to test

  • Show modal view
  • interact with ticket fields
  • interact with ticket events

Experience

Where to start. At first it went well.

My initial version showed a modal but only in the ticket sidebar.
Some gentle nudging made the bot understand that there is such a thing as a modal view but it kept trying to add it as a separate modal.html file instead of inline html.

When I convinced the bot by copying actual code examples from the documentation it did do an inline html element for the modal, but it never got invoked or shown on the preview app in test mode.
I assume this is a limitation of the current SDK

Gaps

  • The bot invented fake modal functions
  • It never was capable of intercepting the solved state, the if clause for that one kept pulling from fake elements like get(ticket.solved).
  • It also kept trying for anevent it would received on ticket.submitted which does not exist. I could to get that element out of the code, even though I convinced the bot to use another way of checking for solved state.

In the end I gave up since I assume modal options are not part of the current scope. Same as intercepting submit.

Alert on specific users

An app we build for a customer shows a modal alert on specific customers tagged with system. There are users that are the result of web forms being submitted to Zendesk and up on e.g. mailer@domain.com users for all incoming email, and those users should not being modified for GDPR risk (We know, bad architecture but the customer can't easily change this)

Modal was not an option so I decided to replicate this app with a client.invoke(notify) function instead.

Things I wanted to test

  • Interact with user profiles
  • Use notify or modal to alert users

Experience

Even though the prompt specified user profiles the initial app got deployed as a ticket app. I convinced the builder to move to the user profile (and got a very friendly thanks back!) but try as I might, I could not get the app to show up in test mode on the user profile, even though the conversation told me it should

Gaps

  • A way to inspect or modify the manifest file would be nice
  • It used a toast provider to try to show alerts at first before I reminded the conversation the invoke(notify) function existed

Lookup Fields

Next test.

An app that looks at lookup fields in a ticket, gets the custom object record and shows the data of all records next to a ticket.

Idea was to render a richer preview than Zendesk does (e.g. image urls as actual images, tags e.a.). I build such an app in the past so had an idea on the complexity of it. (Very complex)

Things I wanted to test

  • Interact with ticket fields
  • render complex UIs with variable data
  • use Zendesk APIs in complex flows.

Experience #1

The initial description of me was high-level. I wanted to see how good the builder could reason with Zendesk objects.

It failed.

  • It assumed the lookup field returns actual data of the object
  • I had to remind it that the custom field only contains a record ID
  • I had to explain it that it needs to pull the ticket field /api/v2/ticket_fields data via API to get its relationship
  • Explain that you need to call the custom object API to get custom record data
  • That Zendesk needs IDs and that the strings in the custom fields are not always usable and should be modified, e.g zen:custom_object:object_name

Gaps

  • Serious gaps in Zendesk knowledge
  • Bad notion of identifiers for API calls
  • Didn't handle API errors well.

Experience 2

Knowing these gaps in Zendesk API logic, I decided to restart with a lot of knowledge in the initial description.

Here also I got some weird failures. My initial description confused the system to start with all ticket fields instead of those in the ticket. The result was a working app that showed wrong data. I could not get this initial bias/bad start out of the rendered code and it kept resetting to this bad design.

Gap

  • A way to say STOP forget what you are doing would be nice.
  • Once it goes the wrong path you can't easily reset

Experience #3

I tried a final time for this one. I wrote an initial prompt with a lot of detail. But then it got stuck on a non-existing ticketFields object as part of its logic I could net get out if its rendering

Gaps

  • If it goes the wrong way it can't be 180-d to a better logic
  • It uses non-existing variables
  • It lacks a bias towards Zendesk APIs.

Movie App

Final test was an app to work with the oMDB API. I had experience with this API from my blog building Bot flows.

Things I wanted to test

  • Make external API calls
  • Get and Set ticket field data
  • Add ticket comments
  • Show a rich preview

Experience

This one went very well. The initial version after my prompt was spot on and iterating on the design and features went well.

There were some errors like failures on the button actions due to a non-existing Toast Provider, which I fixes by asking for client.invoke(notify).

I almost got this to a fully functional demo app.

Some weird behavior

  • For demo purposes I had hardcoded the API token. Halfway through it used a different token all of the sudden
  • it refuses to output ticket comments in html, no matter the prompt

The biggest failure was reminiscent of my first test. The moment I ask for icons it errors out and refuses to load anything else.

Overall impressions

I'm impressed. This really shows potential!

  • Very quick way to iterate on ideas
  • If you prompt right, and know your Zendesk you can get very far in building functional apps.
  • The app lacks Zendesk specific knowledge of the APIs so some things that for a developer like me are just known facts, are unknown to the app builder
  • it's iterative by design, but no easy way to go back to a previous known good state
  • limited to, I presume because MVP and EAP, to only support apps and no support for modal or other context.
  • no way to access settings, so API tokens have to be added as part of prompt.
  • no way to stop a prompt. You just need to wait until it fails or succeeds.

Overall, I described it to a colleague as "this feels like talking to a good junior developer with potential. You need to give it a lot of attention and context, you need to check the code when it fails for just unknown nonsense, but it shows promise.