This is a companion discussion topic for the original entry at https://developers.home-assistant.io/blog/2019/10/05/simple-mode.html
This is a companion discussion topic for the original entry at https://developers.home-assistant.io/blog/2019/10/05/simple-mode.html
Should all users be able to switch on-the-fly between simple-mode and an advanced-mode to be able to be able to temporarly expose more advanced settings and functions in the UI only when needed?
Example of software that does something similar is Kodi (formerly XBMC), it allows users to switch settings levels on-the-fly to hide or show more advanced options inside its GUI. For this purpose Kodi has 4 tiered settings levels where each level unlocks more advanced settings; those settings levels available in its GUI are: “Basic”, “Standard (Default)”, “Advanced”, and “Expert”.
Inside Kodi’s GUI, the “Settings level” can be changed using a button-icon in the bottom left on the GUI under the settings section, clicking that button in the GUI shows the currently selected setting level and allow the user to change setting levels on-the-fly, and it just as easy to change back. More info on that user-experience in their wiki => https://kodi.wiki/view/Settings
The purpose of this option inside the GUI is that a normal users can have the settings level set as “Standard” 99% of the time so that they don’t have to be exposed everyday to more advanced settings that not used most of the time, but they still always have the option via GUI to simply change the settings level to advanced or expert in order to expose and change settings classed as such if for example given advice in the cummunity forum to change an advanced setting for a specific thing and then be able to quickly change back the settings level in order to hide those more advanced settings again.
6 Likes
That’s not a bad idea at all. We’ll consider it 
5 Likes
It will be problematic if the advanced mode allows you to configure things in ways that the simple ui can not present. But we already have that with automations that don’t follow the pattern that the ui understands.
As this is my first post, I have to mention that I am a big fan of HA and really appreciate how all of you have been developing this great software in the past! I have been trying a lot from Mediola, FHEM, Openhab, ioBroker and finally got hooked on Hass.Io. I feel the simple mode is the next step on the developing path I have been seeing in the last 9 month towards a more intuitive to use software.
One thing I have been missing for a long time, is an easy tasker / scheduler. Every app like Dyson, Mediola etc. has an easy userinterface to do that. On Monday I need the light to go on at 8.00 Sundays at 10.00. Very typical usecase I am still strugelling with to setup up in HA. Is that meant by time trigger automation? To be honest today I don’t even know where to pick the weekday.
1 Like
That’s probably a better topic for it’s own thread and not here.
If you feel it should be moved that is fine. My point was mainly in terms of I feel this one userstory should be implemented in the simple mode. Should I put this request somewhere in github? (As I was telling still a Newbie)
I agree with you, it must be simple for new user. It doesn’t necessary to implement all features for noobs, but at the moment it’s a pain. I spend a whole day to configure a single switch, that’s frustrating but ok for me, 'cause it’s my hobby. At this state I can’t recommend hass to my friends although it’s a good system.
Finally it doesn’t matter which version it is, the main thing it works good
Good suggetion. Will try it out. Any idea when Days will be included in the automation front end?
Simple answer: Yes.
Having only some of the available options in the GUI, and requiring users to go edit a configuration file for others is a non-starter with all but us geeks.
Having the GUI present a blank form field into which the user needs to write (or paste) code is a non-starter.
Automations are the heart and soul of a home automation system. It’s absurd to think the masses are going to write code to do this. They want (for example) what duesseldorferjung describes; a GUI way to select days, day-of-week, etc. Things everyone would naturally want to do.
Of course, some things can’t be “dumbed down” enough for raw beginners. Hiding details in “advanced mode” is a great way to balance that. But advanced mode still needs to be a GUI.
An advanced user is NOT a developer. Two totally different skill sets. Think of the accountant who is an advanced Excel user, but doesn’t have a clue about how to code a spreadsheet application in whatever language Excel is written in.
2 Likes
Although not simple it extremely flexible and will save you many separate automations if you have complex week schedules. Have a look at Schedy. For lights you can use the switch actor. http://hass-apps.readthedocs.io/en/stable/apps/schedy
I would also very much like to see an easy to use drag-and-drop flow-based visual editor for automations (and scripts) included by default in Home Assistant web-GUI.
Its type of visual drag-and-drop coding (also known as graphical programming blocks) tools for programming automation flows via the web-GUI much easier for people who are new to scripting automations. There are several editor frameworks that could be used to achieve this; Node-RED being one, though I personally prefer the interlocking-blocks style of “Blockly” and “Scratch Blocks” which makes coding look simple.
However I want to highlight that my main point here is to express that I really want a such drag-and-drop flow-based visual editor for automations (and scripts) to not just be an option that can be installed but that it should be be included by default with Home Assistant and preferable even pre-installed by default in Hass.io
Blockly (Blockly technology) upstream code is maintained by Google:
Scratch Blocks builds on Google’s Blockly technology mentioned above and simply it even more
Example of an open-source home automation software that specificly uses Blockly to simply programming of automations and scripting via drag-and-drop in its web-GUI is Domoticz
2 Likes
But…Node-RED is already useable quite easy in HA 
I think this thread is not so much about new features like a visual scheduler (of course that would make sense and be a great addition, necessary to get casual users) but more about which type of settings are exposed to the user, be it GUI or text config…
For example a standard user would be able to add users, set his theme but maybe not change stuff that might break things or confuse him, that would be exposed through a higher level like advanced or expert. Of course he can get there easy but he will also be aware that he is now in expert mode and should take care while he can be confident to not break to mich i standard mode. Also casual stuff is easier to find in standard mode instead of being buried betwenn 1000 other settings.
Who is Simple Mode supposed to be for? Who’s the audience for Home Assistant in Simple Mode, who are the people it’s not able to reach without Simple Mode?
I guess what I’m asking is, why would someone inexperienced with home automation choose Home Assistant in Simple Mode, instead of just sticking with HomeKit or Amazon Alexa or Google Home?
Because to me, it seems like maybe that’s not a large audience. “The masses” or the “non-power users”, why are they leaving HomeKit? (Or Amazon, or Google.) Devices in these ecosystems are easy to find, ready-made products, and installing them into the associated controller is reasonably easy.
These ecosystems are promoted by major vendors that people have made big commitments to (Apple, Google). “Regular” people in those ecosystems are pretty happy with what they have. What’s missing enough or making them unhappy enough to look around for a replacement that’s not just a different flavor from the Big Three? Enough that they’ll find and be interested in a (by comparison) small little open source tool?
Note: I’m not suggesting that the effort isn’t worthwhile. I think it’s a very reasonable goal to have Home Assistant’s “out of the box” be better, easier to understand. And to have it be highly usable for core functionality without seeing a single line of YAML.
But I do think it’s worth thinking about who that’s for. If it’s for “the masses”, and Simple Mode is all they will ever use…I don’t think there are that many of those “masses” out there. I think those folks will stick with HomeKit, etc.
I would suggest that perhaps Simple Mode should be more about on-boarding—a process or temporary stage—rather than a permanent user interface mode. I suspect that’s the real goal here, to make getting started easier and more approachable.
(Having just gone through my first two weeks of “onboarding” with Home Assistant, I can say that the default Simple Mode was actually more confusing than Advanced Mode. Indeed, it took me a few hours to even figure out that there was a Simple mode, which I was trapped in, and that’s why the user interface looked different from all of the doc and third-party tutorials…)
1 Like
This raises an excellent point - especially if someone typically uses the simple mode, they may not be aware, or even forget, that there is advanced mode and that it might be necessary to do what they want.
If I might throw another option into the mix: it would be helpful to have either a toggle switch, or at least a reminder, on each page that has features hidden in the the advanced section. This could either be in addition to, or replace, the global advanced mode.
1 Like
I just had this experience going from version .103 to .107. Having skipped .96 where advanced mode was introduced, I had no idea it was even a thing, despite being a Home Assistant user for years. So when my Lovelace raw edit resources went away with the new dashboards, and it directed me to edit them under the “Resources” configuration tab, which did not exist, it sent me down a rabbit hole of investigation which was only resolved by asking on the Discord channel (Thanks Tinkerer!).
Now in this specific case, I’d argue the advanced setting should not be set on this new Resources tab because the alternative is the yaml case which is, by the guidelines set here, more advanced. In this particular case it makes no sense, and in my case, not knowing there was an advanced tab, just lead me down all sorts of “breaking changes” investigations to try to figure out how to resolve an issue that was just being hidden from me in a way that was undocumented.
But I believe that points to a larger issue here that will continue to recur as new features are hidden under advanced.
I’d make the argument that admin users should always default to advanced, where non-admins shouldn’t.
Or the argument that there’s no such thing as a “simple” option within configuration - you’re doing non-user-facing type things in there that are explicitly back-end.
However, I think both of these arguments are somewhat wrong/missing the point - overall you want new admins to not need to dig into yaml or whatever to be able to still set things up easily - this is a good thing.
The breakdown here comes from the fact that now that I know there’s an advanced setting, I’m never going to turn that off, because I’m going to be missing features I need, like the above example. And nobody working on, documenting, or talking about new/existing features in HA, unless they’re specifically aimed at a simple mode, are going to be working in non-advanced mode, so they’re going to be pointing to those features when they explain how to do things. So unless I want to be super confused, advanced mode is a requirement.
And since there’s no clear way for me, as a admin, to know what features are simple and what are advanced, whether I’m trying to get help or give it, I can’t for sure know if the things I’m talking about are “advanced” or not.
Now I’m a relatively advanced user who would’ve always been in that mode had I known it existed, but I’m speaking to a broader case here.
The problem I’m highlighting is that any simple mode user will have a much much harder time whenever they run into a problem, because majority of help they’re going to find will be from advanced mode, for the reasons noted above.
I guess thinking through this, I’d argue that global simple/advanced modes shouldn’t exist because they’ll only serve to confuse. If you’re an admin who has access to configuration settings, then some number of them shouldn’t just be hidden from you somewhat arbitrarily with no ability for you to know which. Things like auto-discovery, integration and automation editors, etc. greatly improve the approachability and workflow of HA, and IMO are the right way to reduce and hide complexity while still allowing for that complexity behind the scenes. If I really want advanced mode, I’m not in the GUI at all.
So the simple/advanced mode, despite it’s totally good intentions, only creates a discoverability/usability roadblock that adds to the matrix of understanding/explaining how to do things in the HA GUI.
So IMO - Admins with configuration settings need access to everything within the GUI rather than some of it being hidden. That’s the simple side. Editing files by hand is the advanced side. User-facing, daily use simplicity is better handled through users and dashboards that are authored by the admins to not be complex, because they’re aware of their needs and their users and can appropriately show/hide the information as necessary. But having a HA wide simple/advanced will continue to confuse admins as new/existing features are hidden behind advanced, because they won’t have insight into why a dev put something there that they then need.
To be clear, I’m speaking only about the specific hiding of GUI elements behind a global “advanced” setting. All of the rest of the intent of simplifying HA through the GUI for users is 100% the right way to be going. However, I think this one bit actually creates more complexity accidentally.
3 Likes