The main UI works fine in a web browser anyway. I don’t use sitemaps anymore.
And I and a lot of other people don’t use Main UI pages at all and solely rely on sitemaps … so what does that tell us now, besides being pretty off-topic here? 
Just to add my two cents here.
As a first time user, I would love to see a page with screenshots of all available UIs with a link to a short introduction (video) so I can see what I will get and then install my UI of choice……
2 Likes
I know. And BasicUI is super fast.
The issue is. Its not easy to work with, unless the user have at least read and understood everything about sitemaps.
Dilemma is, BasicUI/sitemaps is the first priority in the openHAB app, which most certain would be of interest for the user.
Personally I use both the MainUI and basicUI. BasicUI because I can do this superfast when testing new devices, simply by copy&paste from sitemaps files. Second because its highly useable for the app.
But its a hassle having to deal with two (or more) different UI´s all depending needs.
But BasicUI do not look as fanzy as MainUI can be made.
Also it depends on, if the user want mobile app display only. (many will only use their phone).
Perhaps it would be worth to look at how other systems manage this. Google Home fx.
The huge question is… What is a “Thing” actually?
If the “Thing” is a devices, it can hardly be situated in different places, at least not at the same time.
So maybe openHAB should work more intenst on the term “Device” before actually define and place the “Thing”.
Exactly!
Now somebody has to detamin whether its called, “equipments” or “devices” 
or create locations by simply checking the model‘s locations.
For NEW USERS it might be confusing to add locations by
- navigating to the model tab
- click „add location“
- provide a label, e.g.“attic“
- enter „attic“ in the category (I know, it is not mandatory, but new users don‘t)
- click on „semantic class“ and select „attic“ the third time.
An „add location from Semantic class“ button (needs to be renamed if this gets implemented😂) would be nice so that you simply check the locations you need and they are added in one go.
That might reduce irritations in the way of adding locations as of today, is faster, but it is just a 80% solution as
- the user needs to do the linking of rooms to the floor level by himself
- it does not cover locations not available in the model
- may want to provide a translated label of the location
Hi Andrew,
then I think you can guide me how to do it with this request so that I can do it myself the next time.
I really have NO clue where/how to start.
But maybe we look for a different PR as this one already is rejected.
That’s the tradeoff, indeed. Sitemaps are easier to learn (mostly because there’s only few syntactical elements) and can be implemented in native controls by the apps (because their description is technology independent), but are somewhat limited in their look’n’feel (again because there’s only few syntactical elements). Thus both sitemaps and Main UI pages have their use for certain user groups: sitemaps are well suited for beginners (easy to get initial results, amount of options to choose from is not overwhelming) and pages more of an advanced topic (much more freedom of page creation at the expense of more complexity).
Because of that, my suggestion on the ‘BasicUI in setup wizard’ discussion would be either
- installing BasicUI by default without choice or
- integrate sitemap rendering support into MainUI (as mentioned here)
@ysc has mentioned the downside of the latter in his comment already; the upside would be sitemaps becoming a first class UI citizen again. At the moment one can configure sitemaps in Main UI, but not show them there, which is a bit confusing, I think.
As I was a new user I would have loved to have a MainUI I could have started with. Instead of creating a sitemap file (which took a long time of try&error iterations), I would have simply clicked on „add new cell“ and clicked through the cell‘s or card‘s config dialog and would have been finished with my first 10 devices within a by far shorter time.
I can understand that exisiting users want to use still BasicUI, and I honestly do NOT want to argue or discuss here against Basic UI.
All I am focussing on is to make the first experience for a new user as comfortable and professional as possible. I am convinced that a file based config file for a new user is not the right approach and should not be our recommendation to new users.
Even the argument that Basic UI is „fast“ I do not understand. If we talk about an „average“ complex GUI which has 30 custom widgets and is setup in a responsive layout as a PWA on my mobile phone, it takes less than half a second until the screen appears, all popups are lightning fast and there is no delay when switching on a lightbulb. For a new user that performance should be fine.
Again, there are power users here who definitely have a requirement for Basic UI, but this is not the focus of this topic.
You may not be aware of it yet, but one can create sitemaps in Main UI.
1 Like
True. Thanks for pointing that out. After having a look at it, I still think the MainUI is more appropriate despite the great improvement of sitemap.
EDIT:
Is the Tip mentioned in bold in the beginning still correct?
TIP
Sitemaps have existed since the first versions of openHAB. Therefore you will probably encounter a lot of examples referring to them throughout the documentation and in older community discussions. 
Keep in mind that the main UI is not currently able to display them. If you are a new user, it’s probably a good idea to start customizing your Overview page first.
“Equipment” is the term that comes from the upstream library upon which the ontology of the semantic model is based I believe. And because of history and how these terms and concepts permeate everything, changing terms like this is a pretty big deal.
Yes, that is true, Main UI is not able to render sitemaps. But why not mentioning that Baisc UI + Android app + iOS app do it properly ?
And what is the most controversial in this tip is mainly the last sentence even if the “probably” avoids misleading fully the user. It was explained by others just before in that topic that starting creating pages in Main UI is not obviously easier for a new user than simply creating a sitemap page. I believe there is clearly no consensus on that.
If we accept that these hypothetical basic users that we are trying to cater to are not going to want to attempt textual configuration of a sitemap, then I think in a 1:1 comparison the creation of a MainUI widget is mechanically slightly easier and conceptually noticably easier. This is not a knock against stiemaps, just the way things are currently arranged.
This is the purely mechanical process that I outlined in my post above as the quick start steps for going from having an item to having that item in a widget on the overview page.
- Display Item in UI",
- Select Page from Page List Left panel > Settings > Pages > Overview or click here (links directly to the Overview page editor)
- Add Block, Row, and Column Click on the Add Block, Add Row, and Add Column buttons in the editor
- Add Widget Click the gray rectangle and select a card appropriate for the intended item (for example, a toggle card for a switch item)
- Configure Widget Click the black menu button above the right corner of the widget and select Configure Widget
- Select Item Click on the Item field and select an appropriate item from the list then click Done
- Save Page Click Save in the upper right corner of the editor
- View Home Page Click here to return to the Home Overview Page
If we translate that to creating a sitemap element instead it would, I think look something like this:
- Display Item in Sitemap
- Navigate to Page List Left panel > Settings > Pages or click here (links directly to the Page list)
- Create new Sitemape Click on the blue + and select sitemap from the options
- Start sitemap Click on New Sitemap button in the design panel
- Add Element Click the Insert Widget Inside Sitemap button and choose the appropriate element for the intended item (for example, a switch for a switch item)
- Select Item Click on the Item field and select an appropriate item from the list and fill in other configurations as desired
- Save Sitemap Click Save in the upper right corner of the editor
- Return Home Click here to return to the Home Overview Page
- Open BasicUI Click on the panel icon in the upper-right hand corner and select Basic UI from the options
- View Sitemap Select the newly created Sitemap from the list of options.
For the first several steps there is just little difference other than having to also create the sitemap instead of using the already created overview page. But because Basic UI is a separate UI the last steps are quite different and probably a little jarring to a new user: “Why do I have to leave this UI just to view the UI element I just created?”
It’s a bias to be sure, but because, no matter what, new users will be using MainUI for administration of their systems keeping the initial introduction to UI creation in that same environment, I think is just a little easier and more comfortable.
2 Likes
That’s correct, and exactly what I referred to here. Question is just what conclusion to draw from it:
- ‘Because Main UI doesn’t show sitemaps it’s more complicated to use them, thus discourage their use’ or
- ‘Because Main UI doesn’t show sitemaps it’s more complicated to use them, thus let’s make Main UI show them’
I’d find it awesome if the latter happened, because both sitemaps and pages would then be supported by all major interfaces (Main UI, Android app, iOS app).
If maintenance effort is an issue, maybe it would be worth a try to actually see whether loading times are much different between BasicUI and Main UI and - if they don’t differ too much - move BasicUI development into Main UI sitemap handling?
I don’t think either of these conclusions have to necessarily follow from the idea that sitemaps aren’t integrated directly into the MainUI. This topic is about first impressions. Just because sitemaps aren’t presented immediately upon opening your first view of OH doesn’t mean they are discouraged in the slightest.
But what about when it comes to: How do we present OH in a way that scares off the fewest curious users who give it a quick try? In this case the least scary option is to not get into multiple different UI choices from the very beginning, but to demonstrate one example of how easy it is to begin to put together a UI. If a first-time user sticks around to become a full-time user, then either through the forums, or MainUI itself or the help docs, they will easily discover these other UI options and if they seem like a good fit for their use case explore them.
I, personally, don’t even feel there is a forced dichotomy here. I mainly use MainUI, but I keep BasicUI around because one of my kids prefers the sitemap of his room devices when on his phone.
I agree
by the way Justin your help sidebar is really looking good! 
But I guess openHAB should be using the term, which suits the potentional user best?
Are you volunteering to change the name everywhere it’s used across at least three repos and reimplementing and taking on the maintenance of the upstream library?