The poll at post 5 of this thread seems to provide strong evidence that Textual only users are indeed in the minority. 93% of users use the GUIs, 8% of those would prefer GUI only.
What is not known is how many of that 88% would change their vote if the UIs were actually up to the task (see the PaperUI-ng Design Study).
This poll also meets with my experience helping users on this forum. The non-technical users, who will become the majority of OH users if this hasn’t happened already, will prefer the GUI to text based configs every time.
I also voted for GUI and text, also I personally use text files nearly always. Reasons for my vote: Sometimes a GUI is nice for checking things and I see the benefits if a GUI for new users.
It probably depends in the used bindings. I could probably configure my handful of Hue devices using the GUI. On the other hand I would not even consider this for my several hundred KNX channels.
So no, I would not change my vote to GUI only, regardless of the GUI changes.
There’s 3 types of lies: lies, damn lies, and statistics
These numbers don’t mean much. How many openHAB users are there world wide and how many of those are active on the forum and actually read this thread and took time to vote? I think we’re talking about a minority here. So based on this pole we should not draw any conclusions.
Also, I agree that there needs to be a GUI for those who prefer to use a GUI. That’s why I voted ‘both’. I also use both, but if I’d need to choose between either GUI or Text, then I’d choose Text.
I’m fine with the text export/import proposal. That would work for me.
There are no statistics presented. Just raw unmanipulated numbers.
Based on myopenhab.org usage somewhere around 20k I think.
About 150 according to the poll. Which is probably about 50% too small of a sample size for a population of 20k. And the people who voted are volunteers instead of randomly selected. But that doesn’t completely invalidate the poll entirely. It still presents useful information. But the disparity between the “both” and the “only one way” votes is large enough that I would not expect them to flip with a larger sample size.
So in the absence of perfect information we should reject any information? I’m sorry but I cannot agree. We will never have perfect information. And I’m not saying the above is proof that text only users are the minority. I am saying it is evidence.
And as another piece of evidence I sited my considerable experience helping people on this forum.
Are these proof? No. I never claimed they are. But they are evidence and to just blindly reject them because they are not perfect is not helpful or useful.
Do you have any evidence to support the counter argument?
My comment was not intended to mean that I would expect a lot of people to change their vote. I literally meant I don’t know. It could be none, it could be most. Maybe some GUI only votes will move to the both category. I can’t predict it except to say that I would expect the numbers to change somehow.
No. The poll question is " How should the configuration be done in future? "
And the single thing which is clear, is that the configuration should be done via GUI & Text. The minorities are the people who want the configuration should be done via one or the other.
I voted GUI & Text, not because i intend to use the GUI anyhow, but because a GUI should exist for others.
Your assumption would be less wrong, if the question had been “How do you plan to configure openHAB?”. The single thing i use the PaperUI for is installing addons. I could use text in that case, i did not yet.
According to my opnion the there is a relation between number of things/items and preference for text. I wouldn’t use text for 20 things and i wouldn’t think of using a GUI for my 200+ things.
Can we just repeat the poll with the correct question and more differentiation regarding what is meant with “GUI”? As I have posted above, GUI can also be a text field. Does textual configuration means the command line, does it mean physical existing files?
There should be an option to configure a custom command after an backup. And a configuration when a backup should happen (on regular base/ on change of…).
A lot depends on what is in the backup.
In the openhab database, the configuration and current data seems to be mixed.
I’m personally interested to keep the configuration, that can be backup’ed with every change. (I have that now as I do all changed on a local computer, upload it to a source control system and download it to my openhab system. )
the data for temperature etc, that is for me inside another database, that is installed on another machine. I don’t need openhab to take care of that backup. Graphics of our statistics we mostly visualize using grafana. Mostly because grafana is really good at this and will always move faster then openhab when it comes to graphs.
As I have posted above, GUI can also be a text field.
yes, yet then you force people to work on the openhab system, which is if you ask me a bad practise.
you force people to use your editor.
You will never be able to keep up with other editors.
And most people have their prefered editor.
yes your text editor will get some tracktion, yet I think it will also remind people that prefer to work on text files that they have a prefered text editor.
If you want to support text files, I think a good interaction with real text files would be a much better investment of your time then trying to create your own editor.
Does textual configuration means the command line, does it mean physical existing files?
For me that is what it means.
I edit on another machine then the openhab machine. I commit it to a source control system and then upload it to openhab, that is my prefered way of working with every system I work with.
That gets a little challenging for external databases like InfluxDB and MySQL. It makes sense fot the embedded dbs like rrd4j and mapdb though since that data is stored in user data. But it should be optional. A user may not want to restore or save that in a backup.
It’s the visual studio code editor, no code changes so easy to update periodically. Perfect for newbies that want to batch edit things or items.
You are not the target audience. You will be the prime user of a backup service with some custom triggers (import on git change or editor save action etc).
You are not the target audience.
For me this thread was started so that we can talk about the way the configuration can be done, to no longer pollute your design discussion with discussions about textual configuration.
I do consider myself a target audience for the conversation around configuration.
Where you like that or not.
You will be the prime user of a backup service with some custom triggers (import on git change or editor save action etc).
The way you describe it, is not what I want.
I will never give openhab acces to my source control system.
like I said, I want to configure it outside openhab (even another machine) upload to a sourcecontrol system of my choice. Download my configuration to the openhab machine and then import it to openhab. I will never upload changes from openhab to my source control system. When you call it a backup system, I assume you don’t understand this scenario.
So much this! I used to take care of three openhab instances which were remote. On my machine I would try my changes and then merge them according to the remote systems. The systems then synced their configuration through a simple accessible file share (cloud) - so no interaction with the system were needed. I will have to give up support for these instances if the GUI import/export is coming.
@David_Graeff:
What you seem to forget is that the possibility to structure configuration in different files provides flexibility and freedom. It’s not that I want to edit one huge file - nobody finds stuff there. I have split up the configuration as I seemed appropriate and therefore I am very quick in finding the place to change.
Textual configuration provides freedom of distribution and freedom how things are configured. This will all vanish with a GUI solution.
What saddens me the most that the textual configuration fans acknowledge that there is a need for a gui yet the gui fans seem to ignore any valid point that is made.
I provided a solution and practice that could make both fractions happy yet there is no discussion how there can be a solution that fits for both or how it can be improved.
It’s all “GUI is so much better” and that is not common ground for improvement.
But it should be optional. A user may not want to restore or save that in a backup.
yes
I think it even should be two different backups: backup data and backup configuration.
That can be executed together or both alone
It’s not that I want to edit one huge file - nobody finds stuff there. I have split up the configuration as I seemed appropriate and therefore I am very quick in finding the place to change.
I do understand your scenario. I just want you to think of your requirement more as a separate service and the required capabilities for that service to meet your ways of doing things. A constructive way is a list like:
When I do that I want an import to be triggered.
When I do this I want an export to be triggered.
That’s all.
Nope. I have stated in multiple posts and in the Paper UI NG topic that there will be a Thing/Item/Rule/Scheduled-Task storage association field that was invented to exactly meet your requirement.
Another field will be “annotation” that stores a / the comment for a textual defined Thing/Item/…
When I do that I want an import to be triggered.
When I do this I want an export to be triggered.
Depends what you call “do this or do that”
I’m not looking for an automatic trigger (others might be)
I now push a button to download the configuration, that would still work for me.
yes you sometimes give the impression you understand and then you call it backup during multiple conversations/discussions with me, which gives a much bigger impression of not understanding/
I have stated in multiple posts and in the Paper UI NG topic that there will be a Thing/Item/Rule/Scheduled-Task storage association field that was invented to exactly meet your requirement.
So far I have not seen any concrete examples, and I think that is why people worry;
I do hope that even that association can also be configured in text.
