If you attended the recent ed tech extravaganza, aka Bett, you will know how easy it is to become carried away when you see a new product. You may well be tempted to take advantage of any special Bett prices, but it’s worth taking a step back. The key questions should always be:
The consequences of pupils arriving late or missing school altogether can be long-term and life-changing, as we saw in our article entitled The importance of being there. There is clearly a great deal to be said for MATS to get their attendance and other data in as early as possible, but it would be even better if pupils at risk could be identified before absenteeism and other poor habits become entrenched.
Ofsted. The mere mention of the organisation is enough to strike fear into even the stoutest of hearts. It’s very easy for senior leaders to inadvertently create even more workload for their staff in order to demonstrate to inspectors that the school has everything covered. Sometimes, an increase in workload cannot be avoided. Unfortunately, however, when it comes to inspections some of the advice ‘out there’ is almost designed to lead to a great deal of unnecessary work. One thing a MAT can do is lay down a few rules for its schools which, while perhaps not reducing the anxiety of an inspection, may at least keep the workload under control.
One of the advantages of having several schools under one umbrella, such as in a local authority or a multi-academy trust, is that you are able to draw on a much wider pool of data than would otherwise be the case. In effect, you can avoid the 'bubble' phenomenon.
Headteachers may balk at the potential loss of control they may experience if their school joins a multi-academy trust. However, there are plenty of potential advantages of doing so. An obvious one is economies of scale in terms of the bulk-buying of items like printer paper and other essentials. Perhaps less obvious, though, is the potential to afford higher specification communications systems, including wireless technology -- both through each school and between schools.
We are delighted to inform you about the new Self-Healing Xporter - an initiative which aims to address communication issues within Xporter. In the unlikely event of a problem, Self-Healing Xporter allows Xporter to analyse its environment & do everything possible to fix the problem and re-establish connectivity to the outside world, vastly cutting down on any support time required to resolved issues. These being;
- Xporter’s ability to connect to the MIS being interrupted.
- Xporter’s ability to access the Internet being interrupted.
Let’s look at these in a little more detail.
A typical problem that occurs with running background tasks, such as Xporter, is that it isn’t allowed to access network drives and doesn’t by default have any proxy configuration. However, this is not unique to Groupcall Xporter and you will find that any company using a background application will have the same problems. Meaning we have to do a couple of 'tricks' at installation. Specifically, we copy the proxy and MIS connection settings for the user that runs the installer and store them in Xporter’s configuration. The problem here is of course that over time both the proxy and MIS settings that Xporter has become invalid.
We have looked into some options and probably the most key of these is being able to tell at a distance that something is wrong. To do this we needed to make our Xporter Heartbeat (which reports health to Groupcall Dashboard and picks up repair actions) more intuitive. We did this in our spring Dashboard release, and the Heartbeat will now search for alternative proxies. What we’re trying to do here is get that link back to Dashboard as resilient as it can be.
We’ve also looked at the MIS connection issue and discussed it to a great extent. We’d never want to do anything automatic in the MIS – it’s just not our data to touch. For example, even if we could guess the correct SIMS server name, we could easily get the wrong database and that again is absolutely a risk we can’t take.
However, what can’t be done automatically can at least be made easier. We’ve recently produced an Xporter Repair Installer; if run interactively by a user at the school on the Xporter PC then it will refresh the installation by updating the proxy settings and reconnecting it to the MIS. We’re happy with this because it means somebody at the school has a final say on the settings Xporter has detected. We’re also working on enabling the Heartbeat to fix a wider range of issues in Xporter without requiring a remote session to be set up.
So what we have at this point is some tools to make fixing a problem easier, and some changes to make sure that Dashboard is able to pick up any errors from schools even if the proxy has been changed.
And I’m sure you can see our overall plan here; armed with a reliable connection to get the error logs from schools and a suite of tools for the most common unattended fixes all we need now is for something to analyse those logs and queue up automatic repair actions automatically. I’m sure we have a product for that too… oh, of course, Dashboard!
So with that we end up with the building blocks for something really quite cool, which we’re calling Self-Healing Xporter. Run behind the scenes & given a bit of guidance from Groupcall Dashboard, Xporter can now effectively come of age and start to look after itself, all on its own.
For more information contact us on 020 8502 7344 or email firstname.lastname@example.org.
A couple of weeks back, we released our spring version of Groupcall Dashboard. I thought you might find it interesting to know a bit more about how this really happened and give you a glimpse into how both product vision and customer feedback can shape exactly what we produce as an end product. Probably it gives you a bit of a glimpse into how Groupcall operates sometimes too!