quintel / etmoses

Online decision support tool to create local energy situations for neighbourhoods, cities and regions with a time resolution of 15 minutes created and maintained by Quintel – Not maintained
https://moses.energytransitionmodel.com
MIT License
11 stars 3 forks source link

Follow up on #1267 -> Interface for splitting into groups of > 2 #1284

Open grdw opened 8 years ago

grdw commented 8 years ago

Follow up on #1267

The current code that exists in #1277 already has the technical possibilities to split technologies into groups larger than 2. However, I saw some discussion still about how to achieve this; interface-wise.

@antw way was to have an 'extra options' button where you could specify how large the groups were going to be.

@dennisschoenmakers idea was to just have the 'Extra options' menu and alway use that interface.

grdw commented 8 years ago

I'm a bit worried about "why would a user split it into groups of X?". Why not pick the largest groups the technology can split in; where that would be the maximum amount of profiles for the amount of units?

@ChaelKruip

ChaelKruip commented 8 years ago

Why not pick the largest groups the technology can split in; where that would be the maximum amount of profiles for the amount of units?

I think that makes a lot of sense and is essentially the 'minimise concurrency' option.

@grdw are you suggesting to offer the user two options:

antw commented 8 years ago

I think it would be useful to gather some metrics instead of guessing. Maybe we can find out what proportion of LESes have technologies using the "min" concurrency setting?

If that number is above some threshold we might consider splitting technologies into the maximum number of groups instead of into two. My reasoning being that we should probably support this if it is a common use-case. If it is rarely used, I prefer splitting into two – or giving the user a choice, as suggested by @dennisschoenmakers – since this has the advantage of better performance (and, personally, I think it is more useful).

At the moment, I think @dennisschoenmakers' suggestion is the best compromise, but I'd like to see some hard data. :smiley:

grdw commented 8 years ago

are you suggesting to offer the user two options:

Well I don't want to create a whole button 'fest'. I also think 3 buttons is already a bit of the max per technology. Maybe add a toggle which says Min / Max. As in, smallest group and largest group you can split the technologies in? I would love it, if we could just keep one 'Split' button per technology item and have "something else" determine how large the groups would be.

My reasoning being that we should probably support this if it is a common use-case. If it is rarely used, I prefer splitting into two

Yes. I think splitting into two would make more sense. If someone wants to split in three technologies though, someone has to get pen and paper and do the units by hand.

grdw commented 8 years ago

I think it would be useful to gather some metrics instead of guessing. Maybe we can find out what proportion of LESes have technologies using the "min" concurrency setting?

By running

TestingGround.count

TestingGround.where("technology_profile LIKE '%concurrency\"\:\"min\"%'").count

in the console I get:

Environment Total Les's Les's with min concurrency %
staging: 592 47 7.94%
production: 189 29 15.34%
grdw commented 8 years ago

Allright how about:

screen shot 2016-07-18 at 13 30 52

This is what the user initially sees. Than when he hovers the button. It will show a input box with the number 2 next to it:

screen shot 2016-07-18 at 13 56 08

It will also automatically focus on the input so a user can start typing immediately. Than the user can hit split?

antw commented 8 years ago

Is it fair to assume that the total number of people who really wanted min concurrency was probably lower? Some may have been experimenting, others may have just wanted more technologies instead of true min concurrency. Maybe? :grinning:

Personally I think those numbers are low enough to drop the idea of defaulting to splitting into the maximum number of technologies.

I'm not sure about the decision of splitting into two, or bringing up an input to allow the user to choose...

If someone wants to split in three technologies though, someone has to get pen and paper and do the units by hand.

... is a good point. We have to judge how common that use-case will be and weigh that against the simplicity of just splitting into two. I'm not sure what to do. Any thoughts @ChaelKruip or @dennisschoenmakers?

antw commented 8 years ago

Allright how about: [...] This is what the user initially sees. Than when he hovers the button. It will show a input box with the number 2 next to it:

To be honest, I dislike things appearing when hovered, or form fields being automatically focused. Why not just display the input always? It's a bit ugly to do that, I guess...

Still, I like the simplicity of that approach rather than making a whole box appear.

antw commented 8 years ago

Maybe...

screen shot 2016-07-18 at 13 03 33

Still feels like that's going to add a lot of "noise" and clutter to the page though.

grdw commented 8 years ago

Personally I think those numbers are low enough to drop the idea of defaulting to splitting into the maximum number of technologies.

Environment Total Les's Les's with min concurrency % unique users
staging: 592 47 7.94% 11
production: 189 29 15.34% 16

I think a small percentage of the users is using it, on production you can tell a lot of people just fiddled with the feature one or two times. On the staging environment it's probably me and Chael testing that are clouding the results a little. 😆

To be honest, I dislike things appearing when hovered, or form fields being automatically focused. Why not just display the input always? It's a bit ugly to do that, I guess...

Hmm, I get your point.

Still feels like that's going to add a lot of "noise" and clutter to the page though.

Yes, it's getting a little "Airplane-cockpit"-ish.

One moment I'm getting an idea.

grdw commented 8 years ago
idea

I think we can remove some clutter if we move the 'Toggle Advanced' to the bottom, and with the bottom I mean, a 'bar' or in this case three little triangles, which you can click upon which will expand the box to show the advanced features. Coming to think of it, maybe we should move the split functionality to the advanced features?

ChaelKruip commented 8 years ago

Great ideas going on here guys! 👍

Any thoughts @ChaelKruip

I think that the whole concurrency thing was meant to be able to explore the extremes of it. I think we should allow the user to easily minimise concurrency. Splitting a technology recursively will be a pain, especially if the user also has to chose a different profile for each new product of the splitting.

I think we can remove some clutter if we move the 'Toggle Advanced' to the bottom

I like that!

Coming to think of it, maybe we should move the split functionality to the advanced features?

I think it is too important for that and would mean an additional 'click'.

grdw commented 8 years ago

especially if the user also has to chose a different profile for each new product of the splitting

I manage to already solve that problem in PR #1277 . However, we're sort of discussing what might be practical when it comes to "How do we split a technology into what groups of which sizes?". In the current PR #1277 you can only split them in groups of 2.

I think that the whole concurrency thing was meant to be able to explore the extremes of it

Well, yes. But we're sort of diverting from that idea based on the usage statistics.

ChaelKruip commented 8 years ago

Well, yes. But we're sort of diverting from that idea based on the usage statistics.

The fact that I hardly use my fire-extinguisher doesn't mean that I think it should be replaced by a damp cloth 😈

antw commented 8 years ago

The fact that I hardly use my fire-extinguisher doesn't mean that I think it should be replaced by a damp cloth

That I might burn my toast doesn't mean I want to buy a fire truck. :grin:

grdw commented 8 years ago

I hardly use my fire-extinguisher

I'm already building a delete LES method, don't worry.

dennisquintel commented 8 years ago

My 2 cents:

Situation:

You might have a bunch of technologies attached to a end point, say: 20 heat pumps.. They all got the same profile, representing 'maximum concurrency'.

Currently:

Now, you wanna test 'minimal concurrency' and you wanna split those 20 heat pumps into 20 'different' heat pumps with all the same characteristics with 20 different profiles. This puts stress on the calculations and makes the technology table a lot bigger.

Alternatively:

You wanna test 'minimal concurrency' and you select a 'new profile' called 'average of all the others'. Now the outcome of the calculation is exactly the same as currently, but you do not have the longer technology matrix, and you do not have this 'darn split' issue.

(disadvantage is this alternative of course that you might want to split technologies because of differences other that load profiles, but I am not sure that happens.)

ChaelKruip commented 8 years ago

You wanna test 'minimal concurrency' and you select a 'new profile' called 'average of all the others'.

I like this idea a lot but I think the EV's make this impossible. The EV profiles encode not kWs but the availability of the EV and its necessary charge level. It is unfortunately impossible to 'aggregate' these profiles into one because they describe causal events which cannot be 'averaged'.