The reason there is polarization here is that the software meets the needs of some personas but not others. For @Lasse it is a great product and he has evolved to become the ultimate cheerleader and helps many others constantly. You will never convince him this is bad software because it’s perfect for his persona. For others here (mainly types of “common hobbyists”) it does not check all the boxes. No one here is wrong.
This is an interesting angle and needs some comments mostly from a philosophic point of view
For me - that have both biological and technical educations/experiences of a long life - mostly in the interface between technology and biology in aquatic life support systems - IMO - it is one thing that differ an aquarium controller from all other technical devices we use nowadays. It is the brain in a life supporting system but it is also a dumb technical brain without any own Intelligence. It means - in a certain time point - based of inputs it gets from sensors and functions - it will do exactly the thing you have programmed in for that situation. As it is a controller of a living system - with animal life as a parameter - it is important that it is flexible for many different situations
Because of the fact that every aquarium set up is different and that every aquarium will change, both chemically and biologically during time its is important for me that both software and hardware are as flexible as possible. This demand of flexibility may interfere with the interaction interface between human and machines and demand some learning periods. Some manufactures have solve this problem with easy controls for easy task and a demand of classic programming for more difficult tasks. GHL have solve this with pre-programmed modules there you combine these modules for special tasks. The different levels functions, the extra functions, the illumination, timer and dosing functions and the programming language of profilux is example of this. They can be combined in endless ways and include the powerful inverse function.
To make a function that only activate my top off during night hours is easily done without any knowledge of classic boolean algebra - just combine a socket function with a level function AND a timer function with help of Profilux programming language. Ok - in this case it could be better to have an extra line in the level function that say - only active during xx:xx and yy:yy - but it is an example of the principles.
I have been using Profilux since around 2009 and during this time I have only experienced a limitation that I can´t work around in one case - I can´t use the PL language with the 1-10 V interface which limit my wish of full flexibility with my wavemakers. However this will not alter my view of the software - it does what i should in a controller that is in use for a life supporting system. The connection between the software and hardware function is good too.
It is interesting to know that in each generation of main unit - GHL have put in a lot of offert to do them backwards compatible - most old hardware from at least Profilux 2 can be used by P4 and older main units can mostly use the new equipment - at least after the introduction of P3 and the PAB communication buss back in 2009. The GCC was developed for P3 back in late 2009 and it still going strong as major software. The new web interface and MyGHL has been developed during the last 5-7 years and works for P3 and upwards.
I will still say that GHL software construction fulfill the needs of both advanced and not so advanced users but you need to understand what you are doing because it is the brain of a life supporting system.
What upset - mostly americans what I understand - is the fact that the interface between the human user and the software need a learning curve there you get more understanding what you can or not can do with the controller. You need really understand - not only klick an virtual button and it manage itself - the system in order to use it.
There is for sure things that can be better in the interface between human and software but you can´t construct a main unit for a life supporting system the same way as you construct a interface to a phone or something just technical IMO
What I understand - UX - is about the interface between humans and the software (software is the programming that manage the hardware)
One of the first things a UX person would do is define personas for the users of your product. This is just a list of all the types of users that use your product, how they will use it, what they want to achieve, what will annoy them, etc.
IMO - this is not the most important with controllers for life supporting systems. The first question a developer must answer is to define what a aquatic life supporting system demand of your product. a list of all the types of things your product should solve and what an aquatic life support system demands for function fully out. What will kill your animals and so on.
A aquarium computer is not the holly graal that make you a good aquarist - it is only a tool for you in order to understand what you are doing
Sincerely Lasse
