Juto is a product by The Appworkshop, an app builder which allows clients to build a customised app, choosing from a range of available plugins. Currently it mainly deals with forms – for example the app manages employees' leave requests, and their transition from 'New' through 'Pending' to 'Approved', with the option to trigger an action at each transition.
The project
The product consists of two parts – the App builder, with which clients create their app, and the app that is produced, which would be the final product for the client. To date I have been involved in the app builder side of the project, with the focus being on the usability and functionality.
The team
There are 3 other Javascript developers working on this team, with myself working as both a developer and the UX designer.
My initial task was to complete a UX audit, to identify the main pain points, and where the biggest gains were to be made. Due to budget constraints, there was a focus on quick wins – tasks that could be implemented quickly while still having maximum input, although bigger issues were noted for dealing with when possible.
For this task I focussed on the main configuration screen, making the layout more logical, removing content where possible, and hiding some sections until they are activated.
I also removed some possible dead-ends and confusing navigation throughout the journey, combined some screens together to make the process feel shorter, and worked on adding helpful helper text where necessary.
Permissions interface
The most recent task I worked on was wireframing then building the permissions interface.
This involved building both the UI and the functionality,
creating a way of naming the permissions so a query can be constructed to find which roles have permission to see the ‘Active’ stage, for example.
Once a user has selected both the Form and Stage to be edited, the relevant permissions are displayed below. Clicking ‘Authorise role’ activates a modal displaying other available roles, while clicking the ‘x’ on the active roles removes it, with a confirmation of the action.
The initial whiteboard sketch
The interface
The mobile permissions screen
Entities
The goal is to enable users to add and manage databases. As usual, we started with a conversation around how this might work. This irons out many blocks early on, as getting feedback from other team members is always beneficial.
This task has three aspects – App Admins being able to define and manage the database schema, and being able to add entities from both the admin and app sides.
- Users can create a database, defining the schema via a 'palette' (which had already been created for another part of the app)
- Users can modify, duplicate and deactivate databases
- To prevent issues with entries added to the databases, the schema can not be amended once an item has been added
- Database entries can also be added, edited and deactivated.
The UX journey, for how databases are defined and managed, and how entries in those databases then look.
Here users can add entries to the database. The fields are taken from the schema defined when the 'database' is created.
The list of databases created by this user. The schema can no longer be edited once an item has been added to the database, but databases can be duplicated (and deactivated).
