I’m trying to find my way through the new OH3 interface. I came to the point where I didn’t really know how to correctly name the item labels to get an intuitive way of using the default home screen in OH3.
E.g. I got a temperature item in the office. The item is labeled Temperatur. This makes sense for the Locations tab but it doesn’t make sense for the properties tab, which groups all the semantically tagged temperature items together. In this screen I would have a ton of Temperatur items only differentiated by the item name. (which has a namespaced name not really useful for the average joe user)
You need to make your Item name work in both places which will probably mean adding the location to the Item name. Also realize that you’ll need to select from that list of all the Temperatur labeled Items in other places too (developer sideboard, rules, etc.). You’ll need a way to distinguish between them there too.
This is true. But from a UX standpoint this is a bad solution. There should be a possibility to add two labels. As you can see above when I’m inside a room I don’t want the room to be mentioned again on the item name.
This feels like it is about distinguishing admin-facing features from user-facing features.
Clearly every Item must have a unique name, likely to be some clumsy thing including location etc. But as you say, sometimes you will want a more user-friendly simple text.
In ancient OH2 world, there was an admin UI and a separate user-facing UI - it was easy to tailor the user UI to this kind of thing (sitemaps etc.allowed you tohave different ‘label’ text depending on the context you were looking at it).
But people would often waste time trying to “prettify” the presentation in the admin UI.
In the OH3 environment, the separate user-facing UI still exists and could be used.
Or, you can use the dual-purpose MainUI for both roles. But again don’t waste your time trying to force admin features into “pretty” user-facing formats. Configure them separately.
We welcome any code you can contribute to fix this “bad ux”.
But it’s important to understand that the mussel is really new. It’s not we’ll integrated into OH, at least not as well as it could be. And as always, you can’t have your cake and ready it too. You can’t have full control over everything and have everything auto generated.
Mmmh wouldn’t you call the non admin part user facing?
@rlkoshak Yeah sure it is pretty new and I get that. I just wanted to give some hints for improvement. And with a second label that better matches these “room” contexts the problem could be fixed pretty easily. So if I got some representation of the room the item (which knows it is in the room because of the semantics) would use this second label for rendering.
@rossko57 Sure I can have my own Sitemap and have fixed labels but isn’t the new semantic system added to get some meaningful auto generation. So these semantics could be easily used to decide between labels here.
I do I think understand what you’re driving at - it’s expecting automatic that maybe isn’t as easy as you think.
Example temperature sensor Item.
In one part of your display pages you might have a list of all temps in the house, you’d want labelling like
Living Room temp
Kitchen temp
In another part of your pages you might have a Kitchen page, showing lights, windows etc. Here you’d want a different label for the same Item
Lights
Temperature
That’s all perfectly reasonable requirement - and easily done by editing widgets.
What might the strategy, the “rules” be to achieve that automatically? How would you expect the UI to know that you want this to happen, and work this strategy out? What if other people don’t want it to happen?
Those aren’t insoluble problems, but may be more demanding than you think.
And I’ll add that it seems like a whole lot of work to address just one place Items appear. Everywhere but the locations tab needs the item label to be unique, both in the user facing tabs of the overview and in the admin parts of MainUI.
It’s only the Locations tab where theses unique names end up with some redundant information.
Well as a developer this would be OK for me. But my wife doesn’t agree on that. In the end we don’t use the whole auto generated stuff and go back to the normal sitemap we created manually.
These things seem subtle but in the end make the user experience. And in a room it is definitely weird to have “Room name temperature”, “Room name light” etc.
And that’s goes back to having your cake and resting it too. You want to take advantage of all the autogenerated stuff and have complete control over how everything is presented.
But OH already provides alternatives for you when the autogenerated stuff isn’t what you want. You can use sitemaps, HABPanel, or create your own Layout Pages in MainUI. In theses cases you have full control over how everything is presented.
I still assert that adding a second label is a lot of work, not just in the code but for the users themselves, to address a “prolblem” that only occurs on one tab of one page. But as I said, PRs are always welcome. I imagine it will involve creating a new well known Item metadata, the forms would need to be updated to define it, and the code that generates the cards would have to be modified and/or rewritten so only on the locations tab this alternative label gets used. It’ll have to deal with the cases of:
what if the user didn’t define the alternative?
what if the user only defined the alternative?
what if the user overrode the default list widget? Does defining this second label mean custom list widgets cannot be used? Can this second label only be used when the default widget is used? Should additions to the overall API be made so that a default list widget can know which tab it’s being used on and render a different label?
As rossko57 points out, implementing this is way more complicated than it might first appear, both from a coding perspective and from a users perspective. It’s not as simple as just providing another label.
An item has always two label states it is used in. (in all UI situations)
General labeling (Default and required)
Room specific labeling (Optional)
Thats about it. And yes auto generated stuff has to show a meaningful label. Inside a room ABC “Room ABC shutter” is not meaningful. (bad UX)
And for the what if questions. The label is required and the second label (room specific) is optional. That’s about it. Room specific widgets and stuff can use the second label if they want. If not they just use the default label and get the same as it is out now. Simple as that.
But I’ve understood it won’t be implemented.
From a UX perspective the current labeling is incorrect. And yes if there is auto generation it should be meaningful. And that is not easy I’m fine with that.
I’m not going to implement it. rossko57 isn’t going to implement it. Yannick probably isn’t going to implement it. But that doesn’t stop you or anyone else from implementing it, assuming that it’s feasible to implement in the first place.
I was searching a solution for the exact same problem. Maybe it is not too exotic after all
I have another suggestion to offer:
According to the documentation of the semantic model there are the so-called “verticals”, which are a kind of grouping outside the semantic model.
Wouldn’t it be a nicer solution to not differentiate between room or not-room but to have a non-semantic label (as part of the metadata)?
So in this case, when the admin creates a sitemap that shows the content of the group automatically, it is differentiated, if the group has the semantic class “None” and then show the non-semanitc label for all items.
Example: We could have a non-semantic group that is called “All batteries” that shows “Living room window contact” as non-semantic label and within the semantic class “LivingRoom” it would just show the default label (e.g. “Window Contact Battery”).
I would love to contribute a PR, but I am very new to openHAB and not into the codebase (yet). If you could maybe point out some classes of interest, I could give it a try. I’m confident giving me the right locations is pretty easy for somebody who has some knowledge about the codebase.
@droid , @IcyT I am 100% in line with what you’ve written above and it has annoyed me since my first try at OH 3 almost a year ago.
Today I made a small patch to the model tab pages (Equipment and Properties), so that they display relevant labels from the Location path they belong to and the Equipment (for Properties), if any.
With this small patch there is no longer the need to duplicate part of the location label into the labels of the Items belonging to this location, leading to unpleasantly redundant labels in the Location sub-pages I don’t think anybody can give a good reason why this would have to be done but I’m open for anybody to prove me wrong and I am sure we can find other ways around by relying on the model.
Code-wise the modification was really no difficult because a lot of the work has already been prepared in the web ui code. Now with a properly defined model, all 3 model tabs display something which I believe is consistent and therefore user-friendly, while being admin-friendly as it need less work to be performed (avoiding redundant entries). With this way of making pages I intend to rely only automatically generated model pages and some floor-plans (again for the ease of use). In fact the entire Model (Items and Things) is automatically generated from my ETS KNX project file (but this is another story).
Sorry the example is in French and quality no so great but I’m sure you can get an idea:
I need to do some optimisations in the code as this was more a proof of concept to check what could be wrong but hopefully I can file a PR in a few days.
I don’t argue against what you’ve done but there are a bunch of other places where the label is used that become pretty unusable when non-unique labels are used.
Settings → Items which doesn’t use the model at all
the developer sidebar which also doesn’t use the model at all
Items not part of the model (though those probably already will have unique labels)
Manually linking a Channel to an existing Item
Sitemaps using the Group element (though if one is using that they probably are not using the model in the first place)
Selecting Items for properties on custom UI widgets and rule templates
If you have five iItems all with a “temperature” label, in some of theses cases it will be impossible to tell one item from another essentially making that feature unusable.
This problem s far greater than just the Overview pages and I’m hesitant to endorse something that potentially renders so many parts of MainUI unusable.
Sorry to contradict but in all these administration pages, the item label is either displayed above the Item name, which is by definition unique, or displayed in a model tree, which provides context and disambiguation. Maybe this was not the case in previous releases (I remember having that issue) but in 3.2 it is, I just checked. I think it is good practice to have items names that are meaningful, given that it it’s what used to perform all advanced task and when you have installation with a significant number of items its impossible to manage otherwise.
Regarding Sitemaps for Group elements, as you’ve said the interest to use the pages when having a model is lower than before but they still have some good use. Anyway, it’ll be easy to automatically display the path within the model for those items that are part of it, like in the ‘Properties’ page in the screen recording above.
There are dozens of posts where people ask the purpose of the model, and the answer, including yours is something usually like: not much. ysc has done a tremendous work to put this in place in the UI but I don’t really understand why he has stopped short by not adding the few lines of code needed to reach this point where it actually become useful for the user and the administrator.
I tend to agree more with Rich on this one. Redundant item labels within an equipment group really offer no impediment to clarity at all, but redundant item labels across a category become unusable very quickly. Here’s just one example:
No user quickly glancing at this list is going to confuse the battery level of the sensor with the open status of the door regardless of what the label text says. And now, in my house door widget, which is automatically populated by semantic tags, I can see this:
which is, of course, clearer than if all the items where just labeled “status” and also, in my opinion, cleaner than if all the items had a label of “status” with the equipment appended to them because at that point the “status” is extraneous clutter.
I also disagree with this statement. The semantic model is not required for OH functionality, it’s true. It’s also true that the model was one of the less familiar features when OH3 was introduced, and out of the box its use is limited to just a few things such as the overview page and habbot. For some users it will never be useful and that’s ok, but in general as an OH system grows the model is extremely useful in many ways.
To name just a few:
As just shown above, I have numerous custom widgets populated based entirely on semantic tags. Rich has published many such widgets to the new marketplace for beginning users to just install and start using right away adding to the out of the box utility of the model.
I have several rules, that work with items via semantic tags.
The semantic model page makes the bulk addition of items through the UI so fast and easy that I was able to bring an installation of many hundreds of items up and running with just a few total hours of work with not a single text file.
Depending on the system administration I am doing at the time, the model page is a much more efficient way of moving between the items I am working with than even the items setting page itself.
That’s true on a full sized screen but not the case on a phone screen. There, the Item names get truncated at best, completely off screen at worst, and there is no scrollbar. And when you show non-semantic Items in the Model tree all you get is the Item label, not the name. But in none of the places I mentioned are the Items displayed in the model tree. It’s just a searchable flat list of the Items.
Not much yet. But I don’t even say that. It’s tremendously useful in a lot of places, mostly in the Overview tabs but not exclusively there. But the model is also not required. Where I say it’s not useful is in specific situations where someone wants to do X using the model and that isn’t supported.
It will be easy to chance BasicUI, the Android App and the iOS app to modify how it renders labels? The coordination across the three repos alone is going to be “fun”. That’s a large reason why sitemaps haven’t changed in any meaningful way in many years.
