Citizen Developer Focus

This year a lot of the focus is going to be on Learner Progression for Agilebase – building the pathway which allows beginner Citizen Developers to progress to become Software Architects.

That will involve training materials, community events etc. as well as features.

In preparation, we’ve had a second look at a few developer features of Agilebase to make them easier to understand and use for beginners – with the added advantage this helps seasoned developers too.

Join addition is automated

Simply put, it removes the need to learn about the concept of joins before being able to use them.

In detail: currently, when editing a view, you can add any field to the view from its parent table. But what about if you want to add a field from another related table? You can do that, but if the table’s not yet joined, you have to first go to the joins panel, add the join, then return to the fields panel so you can add the field.

With today’s release, Agilebase will give you the option of adding not just fields from already joined tables, but also those which are related but not yet joined. It will automatically add any join necessary.

People can then look at the joins panel to see what the system has done and learn more about the concept.

As an example, if you’re editing a view based on contacts, you may want to add some fields for the address for each contact, like City and Postcode. Now, assuming the contacts table has a relation to an addresses table, the system will allow that easily in one step.

Note for people who do know about joins: only ‘upward’ joins from a table to a parent table (e.g. contacts -> addresses) can be automatically added. Downward joins (addresses -> contacts) still need to be added manually. The reason is that they can change the behaviour of the view, adding more rows to it if there are multiple contacts for each address.

Setting up workflows is simplified

The second usability upgrade comes from  the experience of watching citizen developers set up new workflows. We’ve found that one step is often missed – adding a filter to the workflow view so that the workflow only runs once per record. Without this, the workflow will run over and over again on the same records.

Adding that filter has now been automated. As soon as the developer creates a date field to record workflow run times (prompted as part of the workflow setup process), a filter on that field will be added.

Of course, advanced developers may want to set more complex criteria for filtering and they can still do that.

Setting up a field to represent a list of users is simplified

When someone selects the ‘users’ option in a text field, the system automatically turns the field into a dropdown.

Field names are prevented from being renamed accidentally

When development mode is toggled on to edit a view, you can edit a field in the view by clicking the pencil next to the relevant field name.

That allows field properties to be edited, such as the list of possible values for a dropdown. However it was also allowing the field name to be edited. It was found that people were changing the fieldnames thinking they would only be changed in the one view, whereas they were changed throughout the entire system.

Field name editing has therefore been disabled from within views. Note you can still set the name of a field just for a single view – you’ll be prompted for that when adding a field to a view. And you can still change a field name throughout the entire system, you just need to edit the field from within its parent table, rather than a view.

Other improvements

Pinned items persist across sessions

If you have pinned views and tables when you log out, they’ll still be there the next time you log in. That helps you remember what you were working on and allows you to start up where you left off.

Thanks to Richard of Little House Consultancy for suggesting this improvement.

Bugfix concerning large field names

Entering very long field names was causing errors. Thanks to Claire and Luke at the West of England Combined Authority for alerting us of this, as well as other minor usability improvement opportunities.

Creator and creation time are now shown in lists of views as well as lists of tables

This allows you to quickly find e.g. views which you created yourself, when you want to work on them.

Workflows can delete files

Workflows allow you to edit data in the system automatically, based on rules. One aspect of this editing was left out, the ability to delete a file from a document field, which can be useful for complying with GDPR requirements for example (removing data when it’s no longer necessary).

Thanks to Neil at Lewis Pies for requesting this.

Print friendly pages

Although people rarely need to print physical copies of screens these days, it is common to want to send information to people outside the organisation or people who don’t have a login.

That can now easily be accomplished using the web browser’s ‘print to PDF’ feature. Just open any record and use File -> Print.

Note this feature is in beta testing – please help us by trying it out and reporting any issues.

Thanks to Rebecca at Polychromatic for implementing the idea for us.