sitemap2 = s2
Sigh. Because I suggested same-like things before to the core and Kai denied. And he has the last word on core changes. I want to avoid the situation that the community comes up with a name like âawesome-sitemap-openhab-open-hab-hab-openâ and then Kai says: No âopenhabâ cannot be part of that. Why do you always need to make things complicated?? Really. So much noise. Every-single-time.
Why donât you easily name it: sitemap2, next generation then sitemap3, and so on⌠?
Although it doesnât get much love it seems I like this a lot! Makes me smile.
Kai has it explained in the announcement for the reintegration of ESH:
Core should still be a framework that can be reused like esh was.
No need to discuss any further.
openHAB Distro and Releases can overrule that with whatever fancy name one wants to have.
I think that will easily turn into a mess when it comes to questions and you canât separate which version is affected really.
Maybe users donât know the version they are using or use the wrong numbering while asking questions.
A different name can clarify this in a very simple way.
You have never mentioned that.
I canât look in your head.
If you leave out crucial information, I will ask questions til I understand.
You have a clear vision (which I like)
You have an idea how to go forward, yet the way you have worded things in the past, it was impossible for me to see the difference between what you want and what has been set as guideliness for openhab.
In the last month I took many of your wishes a general guidelines and I found out later, it was only your own wish.
Since then when you donât make that difference I leave out crucial information like the one above, I will ask clarification. As I want to understand why we are doing things.
I read that when it was published yet I did not understand that part as we canât reuse words of openhab. Even now, I can see it can mean that, yet I have to read it 5 times before I see that.
This is no strictly âcanât useâ from what i read.
But above it was mentioned that there is the thought/will/need to add an rest api endpoint for this sitemap implementation, so anyone who implements the framework would hav a rest api that has a rest/FANCYOPENHABSITEMAPNAME/item
in their api implementation.
So if it gets to implementation scenarios like the rest api, it should be a clean naming available.
I know we are all openHAB users and hopefully more or less proud to be part of the community, so this seems not necessary sometimes.
But from a framework perspective the argumentation is perfectly valid.
Get away from any names about âsitemapâ It´make sno sense to me, unless you alread know what a sitemap is. And it âsmellsâ too much about html stuff (homepage, links⌠you name it).
Insted, name it for what it really is, (used for):
Front-end User-: layout/dashboard/panel/design/homeview/mainview/etcâŚ
I would suggest to keep the âFront-endâ, for specific telling the user, where this design is beeing used.
If an user does not know which version he is currently using, he better should do something other than home automation, such as growing flowers or vegetables.
I donât care about the new name. Use what ever you want.
I like your idea, but front end is a very, very, very heavily used term for everything a user sees/interacts with. You will never find a post or documentation about it, because you will always find hundreds and thousands of threads. IMHO would that be one of the badest choices.
Why no homeui option in the poll? I like it, its clean and self explaining.
Where is the option ânone of the aboveâ in the poll? Iâm not saying that I have better ideas or anything, but if you want to keep this an open discussion, that should also be an option that people can select.
The name can be changed at any time later on. But the name (or a first suggestion) is required tomorrow already (the poll runs out midday).
CoCo or coco could be a nice name. Stands for Control-Cockpit.
I suspect you refere to a Google search or something simular. And I agree. But using a âknownâ name, would minimize the need to search Google for it
Whats important is to keep this a simple and as clear for the user (admin) to understand. Sitemap does in my opinion not really qualify for either simple or clear.
The whole system should be spiltted into two pieces, (interfaces). One back-end, (the admin) and one front-end (the user). Both interfaces could be optional regarding designs, but admin doesnt have to, in my opinion.
Front-end should be as flexible as possible, from the very simple âsitemap likeâ design to the more advance âSVG designs, floorplanning etcâ. But both should be build on the same core-enige (back-end).
Whats the different behind control the system (admin ie PaperUI), and control the system, (user, ie BasicUI/Habpanel)?
Thats why I dont like the word âControlâ. From the tech advance user, both are controlling the system
For me itâs just a nice âart wordâ and a suggestion, not a must have.
Although iâm not an advanced user i try to control my smarthome, ie if temperature is to hot. With one view in my cockpit i can see it. , but thereâs no need to use it. Maybe iâm thinking about another Name.
Cheers,
Peter
How about:
OSCAR = operation surface, control and review
.
And the the successor of PaperUI could be called:
.
SAM = setup and maintenance
Thank you for participating everyone. I like the cool sounding abbreviations some of you came up with. (We were looking for a boring label here though, no secret undercover project name )
Looks like âdashboardâ won. My personal favourit was âsite-layoutâ, but it is how it is.
The question now is:
Do you define multiple dashboards or is there only one dashboard but you have multiple dashboard instances?
I would say, that we use the plural form. Going from here:
- The REST interface would be called âdashboardsâ.
- The documentation talks about âConfigure one or more dashboardsâ.
How are the different elements within a dashboard called (think of what we had in sitemaps)?
Frames, Groups, Items, Atoms, Elements, Components, Modules, Containers?
Cheers, David