As a follow up to my visit to Kokkinopilos recently, it was really interesting to see the differences from my first visit: not just in how the unMonastery have developed their relationships in the village, how the unMonks have moved along with their own goals, and how the digital tools we use have developed or become uncovered. Mazizone version 1 was introduced to me on my previous visit. I had also written a document from a training point of view as to the usefulness of and potential of the platform. This time I was introducing version 1.5.3 to the group, just missing out on the opportunity to deploy version 1.6 . I’ve been wondering about the huge difference between the two versions and the dramatic improvement in functionality, yet am still caught with a few thoughts about what the purpose of the system is. Just as a reminder, MAZI is Greek for ‘together’.
Software is all well and good. What’s the idea?
The thinking behind the mazizone has been to use a low powered computer (using a power bank or mobile phone charger) to create localised services on a network. More specifically, the Raspberry Pi (Rpi) has been chosen as the toolbox of choice, which is a great pick in my opinion – lots of development already available. My test device has been version 3 of the RPi, which has an onboard broadcom chip for broadcasting a wifi hotspot, enabling access to the local services as a standalone platform with access to the internet via ‘dual mode’ in the latest versions of the software. Connecting the unit to a router using dual mode resolves mobile phone problems that James and myself found when deploying our little lego devices. Mobiles want an internet access via the mobile network or via wifi – if the wifi network didn’t provide a gateway to the internet, then quite often nothing would happen or a google page would be delivered via mobile data. This didn’t inspire confidence in the people we are trying to offer the chance of local services to. An interesting side effect of resolving this cured another issue with the ‘captive portal’ which was meant to grab the web browser and point it at the mazizone front page. This had now been given a definite address: http://portal.mazizone.eu which makes sense. The dual mode worked great whilst in the Kokkinopolis schoolhouse, with only occasional gentle coaxing/prodding/reminding people for contributions. It just worked, and that is a core element for people in general to try something new in a world of new gadgets and apps appearing daily.
The 1.5.3 mazizone offers a cloud storage service using NextCloud (where we stored our photos), Etherpad for collaborative diary writing, Framadate for polling and doodle-like functions – this wasn’t used for some reason, even though we really needed to be working out some times and dates now and again. WordPress was there also, on this occasion not being needed for any particular purpose.
Local services are a great idea: but why, for who, and how are the services useful?
My original thinking about the first version of the mazizone concluded that some of the apps would be very hard to train people to use, and as the development of the package has progressed, this has improved the potential training scenarios. However, who would want to use this besides the unMonks in a schoolhouse with patchy internet access? It does seem that any community group with patchy internet access would benefit from the use of the platform, or no access for that matter. The bonus of complete ownership of information could really be fantastic, but the group would have to take a good look at making backups and copies of work completed. Ownership brings a different set of responsibilities. The package of applications still seem to be around performing tasks in meetings, which seems a little limited . I would hope that a different attitude would be taken to provide a different suite: an example could be a calendar, collaborative mind mapper and a simple timeline builder? These are ideas off the top of my head, but take the idea of collaborating and being ‘together’ a little further. There is also the Berryboot option, which would offer up quite an easy route to trying out all sorts of different systems on a Rpi. This potential opens up a cheap option to have an affordable, dedicated system set up in different environments, such as a multimedia system in a day centre or care home – this was a potential system I was thinking about some time ago, and had problems continuing, hands up – I admit it, no following up.
More thoughts and findings…
The bubble of a project needs to be burst by the people it was intended for, no doubt about it. The people that ‘break the shiny lustre’ offer up interesting insights and can provide robustness to an idea too. For the purposes of brevity and to avoid blathering unnecessarily, here is a small listicle of things I found working with v1.5.3 .
- Security issue: unable to turn off services completely. URLs are still available even if a service is turned off in the dashboard.
- Unable to make a Guest account in Nextcloud easily. Seems to be possible somehow, may be something to do in the dashboard?
- Notifications – what purpose do they serve other than as a pointless distraction?
- UI inconsistencies: Information icons change the pointer state to a n i-bar (for text insertion) rather than a hyperlink indicator. Setting the system date is strange, using what seems to be a text box turning into a drop down month grid.
- Too many people or apps (delete as appropriate). The apps together make for a sluggish working environment, and if a number of people were all together working on different functions at the same time, the likelihood of frustration as the system grinds to a halt is high. Uploading more than 4 photos to the nextcloud could take quite a while, given the size of the images on modern phones.
I’ve had a small look at the latest version, some initial thoughts.
- Version 1.6
- Includes an interview application with no clear guidelines/documentation as to what it does, how it does it and why?
- Unable to import dashboard settings from previous versions