One of the most effective features we’ve added to the agileBase platform to improve performance is the ability to cache views. That can dramatically speed up views which do lots of number crunching.
A typical example might be something like looking at a product list report which contains all the stats about sales per year, costs, average customer feedback etc. If those calculations look at millions of data points, the view may take a good few seconds to load, but when cached, can be accessed immediately, for sorting, filtering and charting, which makes the user experience a whole lot more friendly.
The only potential downside is that until now there’s been no way for the user to see how fresh the data is. For example if a new product is added it won’t show up in that view until the cache is refreshed, which could be from 10 minutes until up to a day, depending on how the administrator’s set it up.
Now, a message appears at the top of a cached view, showing when it was last cached, when it’s next due to be auto-cached and most usefully, a button allowing the user to manually refresh the data whenever they need to.
If you’re looking at a view which you know is cached but there’s no message there, don’t worry, that’s because it’s only shown when data in the view may have changed since the last refresh time, which the system can detect.
As always, please let us know any feedback you have so we can carry on improving the system in the best way possible.
The ability to interoperate and communicate with other software is fundamental to the value a cloud system can offer, which is why most providers, including ourselves, use APIs. These allow different systems to talk to each other using a common language.
There is normally some means of controlling the number of data transfers, otherwise a small (or indeed large) number of customers could accidentally swamp the system with a massive number of requests, negatively affecting themselves and everyone else. Here’s an example of how one service applies bandwidth management to avoid this:
With the agileBase platform, communicating with third party software is really easy – custom APIs can be enabled by an administrator with one click for each view and tools such as Zapier then allow you to send and receive data from common cloud software tools with no need for programming.
That’s led to an increase in the number of customers using the API and a ballooning of what they’re using it for. We love seeing that, but it does mean that we now also need to think about how to protect customers against the possibilities of mis-configurations in third party systems that perhaps make them ‘overly chatty’. We need a way to smooth out demand.
For example, we’ve had one or two situations where the system has been flooded with requests from a third party due to a bug in their system that caused repeated requests for the same information in a continuous loop. Say for example a request takes on average 1 second to process and the system receives 2 requests per second. Well that means that the number of requests being actively processed at one time is pretty quickly going to spin out of control!
When that happens, people using the data being requested will of course start to experience a slowdown and lack of responsiveness. If it goes on for long enough, all other customers and users will also be affected. As a customer, you obviously don’t want your service to suffer due to events unrelated to your use and outside your control. We’ve often been praised by users for the responsiveness and speed of the agileBase platform and we’re keen to keep it that way!
Smoothing data flows
To help avoid this possibility, we now employ a couple of simple bandwidth management measures.
Queuing – API requests are queued for each customer. This means that only one request can be processed at a time, to stop lots of requests coming in at exactly the same moment, which can happen just by chance if they’re all coming from different sources.
Each customer has their own queue, so one customer’s requests won’t affect another’s.
Traffic shaping – after a request for a large amount of data, the system will pause for a short time before processing further requests for a customer. The period is related to the number of records requested. 1000 records will cause a delay of 0.5 seconds, topping out at 5 seconds for 10,000 or more records.
Additionally, for particularly intensive API calls which may have a detrimental effect on other users if used too frequently, we have the option, in consultation with customers, of rate limiting. That means setting a maximum frequency for calls, e.g. once every minute, 10 minutes or hour. In fact, if you like, you can set this yourself, to protect you from third party apps you may use overloading your systems. The option is available in the API settings ‘sync’ screen under the manage tab for a view.
With these measures in place, we’re confident that businesses can take advantage of the possibilities opened up by allowing easy communication with other cloud software, without needing to worry about whether there may be any detrimental performance effects. We encourage people to look into the possibilities of setting up syncs like these examples from customers:
exporting data to Power BI to allow consolidated reporting from many sources
transferring invoices and other financial data to an accounting package like Xero
A small but welcome feature for many people today – when adding a comment to any record, if you include any URLs, they will be recognised as such and appear as links. People can then click through to open the website or document you’ve linked to.
Last month we introduced a way to simplify data entry screens by contracting blocks of fields under each heading on the page. The user can expand and contract the blocks to suit them and see just the information they’re interested in.
It’s been gratifying to hear that many customers love that functionality, so we’ve spent a bit more time finessing it to make it more useful for more people.
An administrator can now configure whether each block (i.e. section) should be initially expanded or contracted based on rules. So for example you could set different blocks on a form to expand based on where the record is in a process. So now, the state of a block is set by
Whether the user has manually expanded or contracted a block. This always takes precedence, blocks stay expanded/contracted for all records the user opens until they log out
What an administrator has set as the default state – see below
If no state is set, all blocks will normally be expanded, unless there are 10 or more blocks in the table, in which case all will contract
Setting up the rules
As an agileBase administrator, it’s easy to set up rules for whether to expand or contract each block the first time a record is loaded. It uses exactly the same mechanism as for most other agileBase user interface rules, such as hiding or showing fields or tabs, locking or unlocking fields etc. Here are the steps:
Create a view from the table you’re working on. Add filters to it so any records which should be initially expanded are included in the view, any which should be contracted are excluded.
For example, in a sales enquiry, you may want to expand an ‘outcome’ section if the status is set to ‘closed’. Create a view ‘closed enquiries’ with the filter status=closed.
In the fields tab of the table, find the separator field that marks the start of the block, ‘outcome’ in our example
Click ‘field options’ and for the ‘expand if record in view’ option, select the view you just created
Please carry on sending feedback, we look forward to hearing from you
As a modern cloud-based web application, the agileBase platform has always worked on all manner of devices, from laptops to tablets to phones.
However there’s no doubting that for relatively complex apps built on the platform, the experience on a computer is the best – on a phone for example, there’s more scrolling, swiping and pinching, not to mention reduced typing speed, making tasks a bit slower to complete. That’s fine when looking up info or adding a comment to a record out in the field, but you wouldn’t want to use it for everything all day.
We’ve been mulling over various options for improving the mobile experience for a long time. Recently, we were delighted to get the opportunity to try out some ideas in the real world due to a customer request from Lewis Pies. To go with the introduction of a new purchase ordering system built on agileBase, the Goods In dept. wanted to be able to book in incoming stock quickly and efficiently.
Following some brainstorming and meetings with Lewis Pies staff and partner Little House Consulting, we came up with a solution that’s gone down really well and which MD Wilf Lewis is ‘really excited about’.
In brief, the system replaces the standard ‘form’ interface with popup prompts designed specifically for mobile use. These new prompts mean that only one tap on the screen is necessary to kick off data entry for a number of fields, which pop up one after the other. Each prompt has large text and a specific keyboard or data entry type used on the tablet (for dates, numbers etc.). A massive amount of time is saved compared to having to scroll around, tap into fields, hide the keyboard in order to find other fields etc. Help text is shown for each data entry prompt.
How does this fit into their working day? Neil George, Company Platform Developer describes the process:
Goods in will operate by replacing the current paper system with the tablet solution:
use the agenda calendar view to action each goods in record which needs to be assigned to a booking in slot or not.
use the tablet interface to complete technical and vehicle checks of overall order.
book in each delivery line by using field prompts of quantity, quality check, expiry date, batch code and sign off.
each line has a unique ID which is used throughout the technical traceability system.
sign off delivery by photographing and uploading the delivery note provided.
All delivery data is now accessible at a click of a button!
How can this be applied to other situations?
Facilities like these can be used by many other customers and applications that may require tablet devices.
As an administrator, to try it out, just tick the ‘required’ or ‘prominent’ tickboxes for any fields that you want prompted under a tab. Then, when a user clicks on a row under the tab, all those fields will be prompted for immediately. This feature appears only when a tablet or other mobile device is used, and only when a row is selected in a tab.
Finally, being used in a warehouse environment means a certain amount of protection is necessary for the devices themselves. Lewis Pies are grateful to Tetratab for providing devices to help when developing and testing the system.
Addendum – options for mobile apps
Here are some of the options we considered before building the above. Although this time we went for the third option below, all options are always under consideration for future developments in our roadmap and we may well revisit them for further developments in future.
Creating a native mobile ‘app’
Apps are typically seen as providing the best possible performance and user experience, if well designed
Expensive and time consuming to develop
The need to create and test two variants, one for Apple iOS and one for Google Android devices
Reduced flexibility – agileBase’s three core characteristics are ‘fast’, ‘friendly’ and ‘flexible’. Flexibility is the main killer here. In agileBase, adding a field, altering a view or tweaking business rules is as easy as pie, but those changes could break any app which relies on a fixed way of working
Building a bespoke web app for a particular purpose
In this case, that would be building a bespoke ‘goods in’ user interface, separate to the standard agileBase interface, perhaps using the API to communicate with the main system
Relatively quick development
The ability to tailor the user experience for the particular needs of the users
Lack of re-use. The app would have no life beyond it’s relatively narrow use case
The app would need maintenance and support in addition to the the main system
Adding mobile-only features and changes
In the end, this is what we went for, as described above.
Very quick development
Can potentially benefit many use cases, not just the one app under consideration
The initial solution may not fit all needs, further development may be needed for some other applications.
We look forward to working with other customers on mobile interfaces – please get in touch if you have any ideas you’d like to try out!
A while ago we introduced two factor authentication (2FA) to the agileBase platform, to improve data security. This helps to secure your account even in the case when you password is stolen, guessed or hacked.
We used SMS text messages to send codes to you when logging in from a new device or location, as this technology is widely used and understood. However, we now have an improved way of doing this using a two-factor app.
you don’t have to have phone reception to use it. That makes things like logging in from abroad easier
it’s more reliable – the phone network can sometimes delay or block messages
How do I set this up?
Really easily. Just log in, click on your user icon at the top right of the screen and select ‘edit profile’, then tick ‘use two factor authentication. A three step wizard will take you through the process.
Download an authenticator app if you don’t already have one. Luckily the technology is all standard and interoperable. Any app which works for one service, such as agileBase, will also work for others like Google or Twitter, so you can manage 2FA for all your logins from one app.If you don’t have one yet, we recommend www.authy.com as they backup things for you so you’re not stuck if you lose your phone.
agileBase will show a QR code (barcode) to scan. From your authenticator app, press the plus button or choose ‘add account’.
That’s it, your app will now show a code. To confirm everything’s working, you’ll be asked to enter the code shown.
Why’s that again?
If unconvinced that setting up 2FA is a really good idea, here are a couple of cases to highlight:
As an administrator, you can’t set up two factor for someone – the user has to do that themselves as they need their own personal phone or device. However, if something goes wrong, such as their phone breaks or is lost, you can disable it for them. In the settings for a user with 2FA enabled, you’ll be able to un-tick the option.
A word of warning – as the administrator, you are responsible for data security in that situation. Two factor authentication is of no use if a hacker can just contact an administrator and request it be turned off for a particular user. Please follow your internal procedures and at least use common sense, e.g. if you know the user well, speak to them rather than rely on an email.
Today we launch a new feature that turns complex data entry pages into simple and easy to grasp screens.
Why do we need to do that? Simply put, the power and complexity of the applications customers (and ourselves) are building on the agileBase platform has increased so much over the years. As more features are added, screens become bigger.
As you may know, you can group a collection of fields together into a block by adding ‘separator’ fields. This new feature simply allows a user to expand or contract a whole block of fields by clicking on the heading.
Blocks which have been contracted will ‘remember’ they’re contracted throughout the whole session, until the user logs out, whichever record the user loads.
This is what a page can look like with all blocks contracted
compared with the same page with everything expanded:
With blocks contracted, it’s much easier to see the structure of the page – the person looking at it can then expand out any blocks they’re interested in.
Now as the first release of this feature, the implementation is reasonably basic – everything starts expanded as normal and it’s down to the user which blocks they’d like to contract (the system does remember their selection as long as they’re logged in). We’re sure there’s plenty of scope for making even more improvements and we’d like to hear what you have to say.