WYSIWYG Dashboard Editor

Feature Requests
1

Like the title suggests, a WYSIWYG (What You See Is What You Get) Dashboard Editor would help bridge the gap between the users who have a coding background and those who don’t. Being able to drag/drop cards and then configure each card after they’ve been placed would make creating dashboards easier for everyone. Retaining the YAML configuration for each card would keep the coders happy as well.

Ensuring that the cards stay where the user wants them would be paramount - it would essentially remove the “Vertical Stack” and “Horizontal Stack” cards, since the cards wouldn’t move once they have been placed.

I understand that this is easier said than done, but I hope that it can one day be added into Home Assistant. I appreciate all that the Nabu Casa team does in advancing HA into what it is today, and what it has yet to become.

2

don’t forget to vote for your own idea!

1 Like
3

The problem is that you are not seeing the big picture.
Your devices are not the same, so WYSIWYG on your phone will not be WYSIWYG on your partner’s phone and definitely not WYSIWYG on your computer.

Either your drop the WYSIWYG idea and use an adapting setup, as now, or you use the WYSIWYG and each and every device will have to be configured separately.

1 Like
4

The bigger picture is catering to a few, perhaps an ideal at the expense of everyone else. I don’t need my dashboard to fit every screen. Look at all the help requests and tutorials on dashboard creation. It reveals a healthy community but it also reveals a problem.

Dump CSS. The dashboard should be a canvas defined by a background image. I have one that is 800x480 for my kiosks on the system I am currently using. I pick a background/device I want to display on, select a new item, drop it exactly where I want it, define it, align the object to a grid, resize, align objects to other objects, tops, centers, middles bottoms, left and right.

I want to transition to HA but the one thing holding me back is no gui for dashboard creation. I am trying to duplicate one of my kiosk dashboards on HA. I could create my current kiosk dashboard from scratch in about five minutes. With everything exactly where I want it. It has about 35 items on it. It has been about a week on the HA version and I think I am at item #4.

The frustration and aggravation just isn’t worth trying to fit every screen your dashboard will never see. And from what I can tell the upcoming implementation of drag and drop is nothing like what I have described here.

I think the css choice was a mistake and would be painful to correct. But imagine all that frustration disappearing.

5

I’m an avid HA user, and still will be tomorrow, but…

I’ve been an amateur (not formally educated) computer “nerd” for appox 25 years. I love what computers and iot devices can contribute to my life, and I love the creative process of figuring stuff out.

The gist of my, soon to be, three decades trying to “learn on the fly” is this;
Now fully functioning “Open Source Systems” that are “linux based”, and “community driven”, are not inclined to develop functioning GUI for non technical users.

My thoughts on why
The heroes
It is the technical educated crowd that initiates the process of identifying the problem that they need to solve using a computer, collect ideas that they want to implement, builds the system and then works out the kinks and issues of the span of years.

This bunch of happy fellows write code for a living, or are formally trained in the art of doing so. And they don’t feel that there is a need for a GUI. Because for them, adding a border, aligning a block of text, creating an API, configuring a VPN is for them second nature, it is for them non-essential. They even “see” the end result better by viewing “the code”.

The reason
And this is not strange. We all do this with the things we know by heart. A mechanic knows in his or her heart how to “debug” a car that sounds strange. But they can’t write a GUI for it. A firefighter knows what smell certain materials smells like when burning, but they can’t write you a textbook on it.

The solution
This is why GUI developers are a thing.
They work the gap between the coders and the end users.
And sometimes, when things really “explode” and go mainstream and actually succeed, a coder realizes that not all users are savvy tech coding superheroes, and they develop a GREAT GUI.

This sadly doesn’t happen very often, and I think may of us that have been around the tech community for two or more decades have witnessed this happen several times with great ideas and great software that have been extremely promising, but failed to make the transition from the “tech entusiast” project to a product for all.

The Good Example
I want to end this with a homage to the early (as in really early!) days of Android as an OS; Then, on the forum XDA, avid technical users (developers) knew what Android would become. And they, almost everyone of them, went ALL IN on two (2) fronts; Developers listened, talked, got feedback in the main forum thread, and then they spoke “code” with each other in another thread.

The goal was the end product. The goal was to remove the “code” from the user. The best builds where the builds that needed no coding. Not the other way around.

This was, and still is, the only time in my online life when this worked. And I’m still trying to get the Home Assistant community to function this way. But, no creator/developer/maintainer so far has understood this.

But, if this project won’t succeed with the GUI issue, another will, and this project will fail over night.

With sincere love
Kaherdin

1 Like
6

It is not that the developers would not like a good simple WYSIWYG editor for dashboards, but it is extremely cumbersome to maintain.
With text setups you can expand the functionality with just making a new parameter and it would work in all settings right away.
With a WYSIWYG editor you would need to program every possible combination into the editor.
It is fine with a WYSIWYG editor when you only have 4 modules, which gives 2^4 =16 possibilities, but once you have 50 modules, then it comes to 2^50 = 1125899906842624 possibilities.

7

Hi Wally
What you right now clearly demonstrated is what I tried to communicate in my last reply in this thread;
“Coders” are one type of individuals. GUI developers are another.

One way of mitigating such obsessive workload on a “GUI-maintainer” is to implement a simple set of rules for all developers that wan’t a GUI for their contributions within a “product”. And then… enforce such rulers before “allowing” them a “stamp of approval”. This would require the core “product” (in this case we are talking about ‘Home Assistant’) to have a framework in place for how GUI:s are to be created (obligatory rules).

But the gist of my chain of thought are rather on the bigger picture…
I am in now way, shape or form saying that ANYONE within this community isn’t trying to achieve it, but it is clear as day that a “product” will not be used by someone that can’t use it.

This has, for me, been a frustration to watch over the years.
Iv’e seen tools been developed by amazing people, and then that Tool has been open sourced. Such a Tool can gain a certain amount of traction within a sphere of people that share the same knowledge base as the creator/contributor. That is of course because they know how to modify, improve and tweak the Tool.

At some point in time the Tool gains popularity and the sphere increases to people that don’t know how to modify and tweak the Tool.

Here we have the beginning of the end, or the start of a great product that has the possibility to dominate within it’s area of “products”.

At this point one of two things happens;

  1. Stagnation, death and copied by lesser worthy

If the Product never backtracked and implemented a level of “ease of use” by giving contributors a way of giving the new users what they need (a GUI) and the Product stagnates. Later, the solution the Tool presented was implemented into lesser products but with a simplified GUI

I initially was fine with this when I saw that happening the first times, but soon learned that the copy was superficial and the underlying thousands of contributions to the original Tool where not copied. The Tool never recovered the loss of traction and eventually the github repo/corresponding place of dev, shut down.

  1. Evolution

The Product implements (or implemented) a GUI and the Product lived on to become someting even greater. I hope that was the vision of @zsarnett but I have understood that he has moved on to new adventures as of this year.

I for one would rather see that Home Assistant lives on and that the contributions of integrations continues. But since I am no developer I’m relegated to the sidelines on this. What I can share are my experiences…

…I now realized I sound like my former elementary history teacher.

1 Like
8

The problem here is the same with HTML and editors.
There are no WYSIWYG HTML editors that work with the users window size.
It is a fake WYSIWYG that either allow the screen to be too big and then add scrollbars horizontally or the usable width for WYSIWYG is artificially limited to some really low value that for sure fits all, like 800 or 1000 dots in width regardless of the users high resolution screens.
HTML have been around for about 30 years and there is not a real WYSIWYG editor available yet that can handle the usage of all windows sizes.
Even when you use a HTML editor, then you will find that many features still require you to do text editing of HTML, CSS, Javascript or other types of elements, because the editor do not have the capability to do it in GUI mode.

HTML have survived, because it was the best solution and YAML will survive for the exact same reason.

1 Like
9

You are soo right. I have built websites since before the frames were introduced in html, and I use much less wysiwyg now than when it new. I have always used Dreamweaver as editor but mostly used the code window, and nowadays the Wysiwyg in Dreamweaver is just a complement, all professional building is done in the code window.

10

I’m not referring to yaml or HTML or PHP or any other code.

I’m talking about a GUI that many contributors already implement into their contributions.

1 Like
11

You might get a GUI, but it will not be WYSIWYG with fixed locations of elements.

12

That is a shame because it is already being done elsewhere.

1 Like
13

Probably, but it will be with a severely limited capability compared to HA then.

14

Have a look at ioBroker then you know what bmiller means. I had exactly the same issues when starting with HA.

15

I look at ioBroker and see a drag and drop interface (vis) with fixed resolution or a tiled, HA style, interface that can be scaled, but without drag and drop (Jarvis).

You are asking HA to solve a problem that is really not theirs to solve.
This is a problem with the world.
Ask one of the standardization organisations to define specific resolutions, then HA, websites and everything else have a foundation to build on, but without it the foundation is fluent and so must the things you build upon it be.

You view the world from only your point and so does many others.
You think you agree on fixed resolution with drag and drop, but in fact none of your resolutions you think you agree on might be the same.

16

Go and have a look at ioBroker. They have solved this issue! You create a new page for each device you would like to have create a new page has to be defined by pixel size right at the geginning (eg 1240x1080). Means each device/user gets the absolute desired and correct fitting UI.

Unfortunately ioBroker isn’t as big as HomeAssistant and is lacking some features. Measn it is never as complete as HA. I am using ioBroker as well just for fun and inspiration.

1 Like
17

They did not solve it.
They just put a huge workload on the user, which is required to design a page for each resolution they want to use.
It is not even per device, it is per resolution, so having two screens of different resolution would mean you would have to have two setups to move the window from one screen to the another.

You can’t really say ioBroker is WYSIWYG.
It is WYSIWYG on one resolution ONLY and a mess on all others.

18

What Home Assistant needs is something like what OpenHab has:

19

It already has that.
It is a grid layout and, like the OpenHAB dashboard, it function for one screen setup, not for all.

20

I’m coming here from HomeSeer which has a really good implementation in HSTouch.
It’s not perfect by any means, but it sure is a hell of a lot easier for the end user. Sure, you need to make a screen for each resolution, but I can set up 3 highly detailed complete screens in 30 mins. And everything is exactly where I want it to be. I’ve spent the last 4 days and have maybe 5% of the functionality on my Dashboard. Not dissing the current implementation, but want to point out, that not every user wants to learn a programming language. One other advantage to HS is that the screens run as an agent application, so I can have a screen open on startup without a browser open. It was essentially my desktop background.

To thwart the “Well why did you leave Homeseer then?” question, I have my reasons, but the product works well. Here is a screenshot of my desktop screen. It is only partially working now since I’ve moved my Insteon PLM to Home Assistant.

Screenshot 2024-08-11 222321
Screenshot 2024-08-11 2223211920×1051 155 KB