Make "getting started process" more inclusive and friendly

[mtheoryx]

There are 2 things going on with this issue, and I want to get the opinions of users, contributors, maintainers.

Assumptions

1. The code respository itself, and we as the community, are trying to be as inclusive as possible. We have a good code of conduct, positive reactions, lots of help, and frequently mention this repository on streams as a good way for a person to get into FOSS development.

2. We have a very inviting name for the project! ⚡️🌋🌔 The cutest IoT dashboard of your dreams ☁️

3. We want to encourage people to have ways of easily trying it out, seeing the cuteness, and possibly using it or even hacking away and contributing back here.

Simulating defaults to false

Currently the SIMULATING env var defaults to false. So even our docker-based workflow would require SIMULATING=true docker-compose up instead of docker-compose up and the new user would need to have already read about that env var.

Quickly pulling down and trying out something, sometimes I don't even read all the docs, especially if there is a good readme with Docker.

Feedback wanted

Propose Default SIMULATING to true (can do this in a different issue)

Default dashboard is empty

Right now, there is a defualt dashboard that the user has to rename from dashboard.json.sim to dashboard.json if they would like to see each of the supported components. This, by itself, isn't terrible, and I know we do have a mention about this in the readme, but...

As mentioned above, if you're brand new, and you don't run into the SIMULATING env var issue... you're still gonna have a pretty empty dashboard with not a lot of "help" on what the project is, does, or how to use it.

Feedback wanted

Propose Detect presense of dashboard.json. If absent, and SIMULATING=true do the copy over for the user so they can see the cuteness right away!

[mtheoryx]

@mpaarating @escherina @noopkat What do you think?

[mpaarating]

I'm definitely in favor of this. I've typed SIMULATING=TRUE so many times. I don't see any particular drawbacks either.

[mtheoryx]

@mpaarating To your point,

Users can, of course, modify the .env file to their liking since it's currently gitignored, but that would be another step required to simply achiever the goal of spinning this up, and seeing some results quickly.

[noopkat]

I am completely favour of all of this. Let's do it. My only requirements if someone sets this up:

1. Any "stickers" should come from a secure source (eg. https URL) and should preferably be public domain or cc non attribution
2. I forgot the other thing but I'll edit this comment if I remember it 😅

[toolboc]

This is a great idea and would certainly make new users feel very welcome to electric-io upon seeing data flowing out of the box!

That said, I am worried about an issue where a user deploys locally via docker, makes changes, and then realizes they want to change to live data, but discover that the dashboard data is not persisted if they spin up a new container. Maybe we could add a named volume to the default docker-compose?

[mtheoryx]

Hmm, that's an interesting question.

So, as it stands now, we do use a volume in the default docker-compose, so it should be persisted if they go that route.

So, here are the current tradeoffs:

1. They do the simple thing and docker pull the container and just spin it up. If they make changes, they won't be saved that way.

2. They check out the repo and use docker compose. That does have a volume and should persist changes they make.

But in instance 2, as you mentioned, switching back and forth from simulating to live could cause issues.

So perhaps we could have a dashboard file just for when simulating, and a different dashboard if they are not simulating (that should also persist as they configure and tweak their layout).

I don't want to over complicate things if we can avoid it. However, I always live by: Prefer simple over complex, and prefer complex over complicated.

[blfuentes]

Here a quick feedback from a newcomer:

I followed the instructions of the Native Installation section(configure device in IoT Hub, clone repository, npm install, set the _CONNECTIONSTRING env property and npm start)

Then I tried to place some cards and configure the parameters, but there was something confusing about it. The Device Id dropdown had 3 values, none of them the name of my configured device and it wasn't displaying any data at all.

Then I realized while reading the Docker Installation and also CONTRIBUTING section, what the SIMULATION env property actually does. I set it to false and obviously it worked as expected

It would be good, in my opinion, that the Installation section shows some info about the SIMULATION env property or links to it(sorry if already exists, I couldn't find it...) the same way it does with the Locking your dashboard and the E_DITMODE property