Unfortunately it is not possible to use the “Cell” from the Standard Library (Cells) in the Fixed Grid/Canvas Layout. Just like in the Masonry section of the “normal” layout. What is the reason for this, and is there any way to use it anyway?
I’m no expert but the difference between a cell and a card is just that. You use cards in the fixed layout and cells elsewhere.
As for a reason, I think that cells are a fixed size whereas cards can resize based on the availalble screen realestate.
I think this should be clarified in the documentation. This is the only thing I’ve been able to find that sort of describes a cell, and it doesn’t mention the layout aspect at all:
- Basic: a component which can be placed within other components (e.g.,
oh-slider)- Standalone Card: a component placed inside a container styled to look like a separate visual element (e.g.,
oh-slider-card)- Cell: a container styled to look like a separate visual element which will expand to show the component when clicked (e.g.,
oh-slider-cell)- List Item: a component placed inside a list type container meant only to be displayed as part of a list and which will not display properly on its own (e.g.,
oh-slider-item)- Specialized components: many of the available page types in the MainUI (e.g., chart pages) have their own series of specialized components
I’m still trying to figure out exactly what the difference between a card and a cell is, and reading different topics only confuse me further as I find both cards and cells that can expand. I haven’t been able to figure out how to configure the slots (or whatever the mechanism is) of a oh-cell so that I can make the content that should be displayed when it is expanded and when it is not.
It might just be me that’s slow, but I really feel that there’s a gaping hole of missing information on this subject.
The card is far more flexible, with more available slots and better style customization:
The cell is intended to be significantly more “low-code” and so has reduced slot and style options, but more built-in features such as the trendline:
It is not true that the cells cannot be used. They are just intended to be the “quick set two or three options and get a reasonable UI going” for beginners. As such, the UI configuration wizard, restricts their use to the cell grids of the standard layout pages and that is what they are optimized for. If you switch over to the code tab of the page, you can manually add oh-cell or oh-X-cell in any part of the page that can handle any other component.
If you really want a cell, then all you have to do is use the UI wizard to add any basic card such as an oh-label-card then switch to the code tab and replace oh-label-card with oh-cell. You can then switch back to the design tab and configure the cell as you would any other component. I suspect, however, if you do this you will find the results unsatisfactory, and eventually you will switch back to using the equivalent card instead.
Thanks, @JustinG.
You provide a good deal of information that helps “lift the mist” somewhat. But, shouldn’t most of this be in the documentation? Also, isn’t the idea that “if you want a component that expands when you click it, use a cell” pretty close to misleading?
The layout rules are highly confusing to me, even if there’s no technical limitation and that you can technically add a cell in a grid. There must be some “logic” behind this, why it is done the way it is, and that’s the part that eludes me. If this logic was documented, I think it would be helpful, so that people can understand why you can use cells one way and cards another way.
I’ve already looked at the reference documentation for the components, but they don’t explain anything about the things that confuse me. They are more like a manual that explains how to use something, not the guide that tells you what you need to use.
I’m also struggling to find out exactly what slots are available for what components. It’s not documented in the “reference documentation”, which it probably should be?
It helps to not confuse what UI wizards provide and “rules”. The UI wizards are streamlined to make it easier for new/inexperienced users to accomplish basic tasks. They are not intended to be (and cannot be) the final word on what is possible. They are at best a starting set of guidelines. To move beyond those basic guidelines you need to turn to the experienced community.
The “logic” is that of the design philosophy of the UI maintainers. What appears in the wizards, what counts as advanced or not, what can be styled and what is fixed, all this follows from the what the maintainers originally envisioned and what modifications have been made over the years since then. Your “logic”, stemming from your lifetime of digital experience and preferences, is different, as is mine. So it’s up to us to find the commonalities in logic and, if we can, suggest (or better yet, provide) alternatives where we see need for improvement and a feasible solution.
Yeah, probably. But if you look at even just the last few months of posts across the whole forum you will see that there are numerous complaints that the help docs are (among other issues):
- too technical and too long to be accessible to novices
- not detailed and technical enough
I’m not sure if what you refer to as “UI wizards” is when you “edit” a layout in the UI, or if that is something that is shown during first startup/that I haven’t found. Just to make sure, this is what I’m referring to:
I do switch to the “Code” tab at times, but I don’t do most of the work there - for several reasons (YAML is terrible to work with, I don’t see the results of what I do). Is what you’re saying that using the “Design” tab is only meant for beginners? What happens if you do something in the YAML that is “illegal” in the “Designer” and then switches back to the “Designer” to do something else - will it cope, or are you “forever bound” to using YAML exclusively for that page then?
I understand how it comes to be, and why we all think differently. What I was trying to say was that I assume that there is some “logic” behind the choices that have been made, that someone has had some kind of “vision” about how the “typical user” is supposed to use this. I always try to “get” what that logic/vision/idea is when I work with a tool, because it usually makes things easier to figure out, but in this case it still feels like I haven’t “gotten it”. That’s why I’m thinking that maybe it would be beneficial if some of this logic/vision/idea was explained in the documentation, so that it was easier for people to “get it”. But, maybe what you’re saying is that there is less coherence/logic in the design than I imagined, and that it’s more a “somewhat random” result of what different individuals have done? If that’s the case, it explains why I’m constantly banging my head against the wall when I try to “get it” 
Yes, understandably so I would say, since OH is quite complex and the documentation is an essential tool for people that try to figure out how to use it. It will probably always be “room for improvement” in the documentation, so one shouldn’t think of all such input as “complaints”. People see what doesn’t work for them, and report that, which as I see it should be a part of the “evolution” of the documentation. But, it can be hard for any one person to keep an overview over all the viewpoints and ideas, so I see that there are many challenges on the road from idea to implementation.
But in this case, when we talk about a “reference documentation”, I don’t think most people expect that things are pedagogically explained in a “reference documentation”, that’s not something you use to learn how things work, that something you use as a reference when working because you can’t remember everything. So, I still think that it might be a good idea if the slots were listed there. That said, the “reference documentation” is automatically generated, so maybe it’s not trivial to generate that.
What I am saying is that once a system reaches a certain level of complexity (and the OH UI is far past that threshold) it is nearly impossible to build a graphical user interface that is suitable for both beginners and advanced users. The Show advanced box in these wizards (or edit dialogs, or config widows, or whatever term you prefer), is a start at an attempt to bridge this gap but it still only gets you so far. At some point an advanced user is going to have to resort to the textual editing because it is just not within the development timeframe or developer team size to create a UI that can handle the vast array of possibilities for even a few of the available components.
I do not recall ever encountering a situation where edits in the code tab have broken the UI editor. The UI editor will display compatible values for its fields or remain blank (if I recall) and it simply ignores fields it has no input for.
Absolutely not. 90-95% of the inital UI development was by one dev, and he remains an active maintainer of the UI repository. There are now a handful of UI maintainers, but they all still coordinate when it comes to major decisions and the original dev’s input still carries a great deal of weight. I’m saying it seems you don’t see the design logic simply because it is so far different from what you would have done. The original dev is very conservative in his design philosophy, believing firmly that error-proofing and stability provide the best user UX for the most users and that configuration limitations are one key component to achieve this. As a result, the amount of configuration that the average user can do via the UI is more limited than some people expect/prefer, but this does result in a UI that is very, very hard for the novice/average user to break in any critical way. It does also mean that advanced users that want to work outside those narrow boundaries sometimes have a little more work to do.
It’s probably not too hard to add slots to the automatically generated reference documentation, and it would help a little. However, slots are also often something it would be hard to really make clear without a full picture of the structure of the component, so I’m not sure that auto generated slots in the refs would clear up much. If you look at the f7 docs, for example, even there they often just have to explain the different slots by showing the rendered html:
So, whenever, I have a question about slots, I go to the vue files themselves to understand both, which slots are available and what each will do. I’m an advanced UI user, however, and that seems like a reasonable expectation for the level control I’m looking for when I get to that point in UI configuration.
I don’t have a problem with that, making UI is labor-intensive and slow and there must always be a “balance” between the effort and the “payoff”.
But, I think we’re talking slightly past each other, because I wasn’t criticizing that you can’t add cells to a grid in the “designer”, I was saying that the fact that you can’t, make me feel that I haven’t quite grasped the idea, the concept of cells versus cards. What I’m really after is why was it designed this way, what is it with the concept of a grid, a cell, a card or whatever that I don’t understand which explains why cells have no place in a grid.
Maybe I would have done it differently, but I’m not so sure if that’s the important part here. I’m usually able to grasp many different “logic designs”, regardless of if they are how “I would have preferred them” or not. In this case, I still feel that I don’t “get it”, and I think that a section in the documentation about the ideas/philosophy behind it would make it easier for people to understand. If you work long enough with something, you will usually always get to a point where you “get it”, but I think that the sooner people get there, the smoother everything works. As such, it would be helpful to get some insight into it described, instead of each user having to deduce it for him/herself.
Are there slots added by OH, or are they always just inherited from the f7 component? If they are inherited, or maybe in any case, would it be helpful with a link from the documentation of each OH component to the corresponding f7 component it is based on?
I have no problem looking up the slots in the f7 documentation, but until now it wasn’t clear to me that that’s where I would find them.
This seems to indicate that there has at least been a plan to document the slots at one stage?
As a side note, it might be a good idea to offer a “split screen” when in “Code” view when editing pages, like in the widget designer. I find it much easier to modify the code when I see the result immediately, instead of having to toggle “Run mode” constantly. You have to be very familiar with the syntax and how all this works to be able to just write YAML and have it behave like you intend to “out of the box”.
Is there a cheat sheet for the things that can be used in an UI ? Like a pin-up poster pdf where you can spot at a glance whats possible ? And how you get that in your UI.
I am really lost with all that oh-card-cell-container stuff.
Not that I am aware of.
There really are very few “you can’t” rules. You want to put an oh-toggle-card in the background of an oh-cell? You can do that, you will just likely discover that it doesn’t look the way you were hoping it would and the click interaction is weird. On the other hand, there’s a very small chance that’s exactly what you want, so it’s not actually prohibited.
There are a few things that you truly can’t do: you can’t put an oh-data-series inside a oh-cell and expect it to do anything because, obviously, the data series must be part of a chart. But other than situations like that the system is fully flexible.
As I said above, the UI editors and options tend to be based around suggestions of the most common or most likely to produce desired results, but if you want something less common you can achieve that too with a little work.
An oh-cell is just a card, but it’s a card that has already had many of the settings, styles, and child components preset for you. That’s really all there is to it. In fact you can use the widget system to build a nearly exact replica of the cell (and some have) if there’s one of the preset options you’d like control over instead.
I fully agree, there are very few true limits here. I was just hoping for an at-a-glance overview of things. I am a visual learner and was hoping for such a quick guide that shows e.g. inheritance or some other clustering of whatever there is. As opposed to spending hours of reading through all the docs and frameworks mentioned in there.
I’m a big fan of this sort of thing too. In this case, however, I’m not even sure what information could be summarized in such a way. The component reference page already sorts them by the basic functional “families”, and I don’t know what else is consistent enough to represent visually in a clear way.
There’s a passing mention here:
that the “cell” class of widgets are very specialized and aren’t meant to be added outside a oh-cells container:
- cell widgets, examples:
oh-cell,oh-knob-cell,oh-colorpicker-cell: These widgets are fixed-size cells that you can only add to anoh-cellscontainer widget immediately below anoh-blockin a layout page - they will either perform an action - switching a light on & off - or expanding to reveal additional controls
I’ll admit it’s easy to miss.
Fully agree on the need to expand individual components’ doc pages with more examples, slot descriptions etc. It’s a thankless job.
Some random factoid- my first iteration with this design (components/slots) was HABot and there the slots were very much controlled: HABot Walkthrough (5/n): The Card Designer
(you could only add certain slots to certain components right in the designer and you got a description of each) but with so many components for the main UI that wasn’t flexible enough to reproduce so you have to figure out the slots and what they represent, possibly assisted by documentation.