search

FriskByBergen / friskby

3 stars 9 forks source link

Merge friskby.no and http://friskby.herokuapp.com/ #170

Open semafor opened 7 years ago

semafor commented 7 years ago

friskby.no is informative, but it ignores the fact that there are devices out there, sending data to a server with means for visualization of those data. http://friskby.herokuapp.com/ shows some data, and is super fast and well written, but it doesn't really say anything. If these are to be merged, you'll need to mix the information and data together in a carefully planned way.

Questions friskby.no should answer:

I also think friskby.no should utilize the full width of the viewport, and be so called responsive.

I can implement these changes after a discussion or green light.

joakim-hove commented 7 years ago

Hello;

this - might be beyond my pay grade on this questions; but my overall answer is yes - this sounds great! I think your points are to a large extent addressing how the friskby information is presented to the user - i.e. how the site works - and that is the most important! I have some minor technical comments/thoughts:

  1. I have no knowledge/familiarity with the friskby.no page.
  2. The friskby.herokuapp.com page is a Django based web application, what I have thought about - as moderately distant plan- is that the content on friskby.no should be moved to the Django application; and essentially be presented as django views. When this move process is complete the friskby.herokuapp.com should be moved (DNS wise) to friskby.no

I always suggest small steps - so my suggestion would be to start with merging the two sites, and then doing the necessary SSL / DNS / ... trickery to serve the new site from https://friskby.no

oyta commented 7 years ago

I would say that your thoughts, Jonas, are absolutely in the direction the Friskby site must be heading. @njberland could comment on his vision for the two sites, but we have talked about this before, and I think the big lines are aligned with your comments.

I have thought about creating a mockup for discussion, but your input covers most of it. I also support Joakim's comments. Start off with a Django view in a subdirectory .../newsite, and when equal or better than the current view we can replace the current front end. And so on...

I have some comments that are a matter of taste, so you all can agree or disagree, however I think this is healthy with different opinions at this stage:

Is the Bergen air healthy right now? Could be answered using a trendy gauge where the particle count is normalized, where 100% is very bad and 0% is fine. Is the air healthy, near where I live? Could be answered enumerating all the devices' readings using a smaller version of this gauge.

I totally agree with these features! The gauges you link to are quite nice, even thought I am not a big fan of speed-o-meter like gauges. Maybe I'm more of a minimalist. Maybe a bar with different(?) thresholds is sufficient? It is easier to keep it clean an tidy, and implementation can be done by an low cost SVG (not a big argument :-). And when it comes to thresholds, we should look into how the government defines their thresholds. The official laws are stated in Lovdata here and here.

What is the trend like? Is it getting better or worse? Maybe a super simple chart for Bergen.

Yes - this could be on the landing page. Could we also do a map or a drawing that shows in a nice way the amount of particles? E.g. an map (static image) of the city/area and an overlay where no or ok amounts of particles is transparent/no color and areas that are polluted are e.g. red or some gradient dependent on how bad it is (basically a heat map). For more details we can have pages for each sensors, detailed maps with overlay charts on click etc (as you also mentioned).

Responsive

Absolutely. It must be. Agree with you on the rest as well.

In addition we had a timeline to playback the historic values and pollution. And maybe one day in the future we can predict the pollution as well? Go back and forth in time. Maybe the charts are enough history and predictions can be a part of those? For more inspiration we can let us inspire by some of Yr.no's ways of showing predicted data. Anyhow - we are not there yet :-)

I don't have the final "go", but I support the ideas.

semafor commented 7 years ago

Thanks for the feedback!

Could we also do a map or a drawing that shows in a nice way the amount of particles?

That's a good idea. I actually researched a bit how to show varying amount of particles, and it seems like this is a difficult problem. A gradient might work---it could also be ambiguous. So maybe we use playful figures like in this example? Anyway, we should definitely try to use a gradient first.

The friskby.herokuapp.com page is a Django based web application, what I have thought about - as moderately distant plan- is that the content on friskby.no should be moved to the Django application; and essentially be presented as django views.

I also support Joakim's comments. Start off with a Django view in a subdirectory .../newsite, and when equal or better than the current view we can replace the current front end.

After some thought, I think it would be good to create a static site to serve friskby.no using e.g. hugo. Arguments for why:

  1. friskby.no might have a blog (in fact, it has one right now, albeit quite inactive), then you'd end up implementing a blog CMS in Django. Tools like hugo is made for this.
  2. It's easier for people to contribute to the content of friskby.no, if, for each change or addition, they do not have to know python or Django. Git and markdown (maybe HTML) will do fine.
  3. Ensures dogfooding of APIs. We have to create APIs to serve the static friskby.no---as opposed to the current way of including data in the HTML directly. This benefits people wanting to use friskby's data.
  4. Minimize the exposed surfaces in the, arguably, most critical piece of software in the whole project. The django app server is receiving data from devices, and it implements a REST API. Add a blog and CMS to that, and you increase the number of things that could go worng. Also, in the case of huge amounts of traffic to friskby.no, the app server would only have to be able to answer REST requests. I.e. fewer things to cache/optimize.

The official laws are stated in Lovdata here and here.

Perfect, thanks!

And maybe one day in the future we can predict the pollution as well?

How hard would it to do prediction? It doesn't have to be perfect, could be very hand wavy (current trend?).

pgdr commented 7 years ago

Many good points, Jonas, that most of us agree with.

The only issue I have with Hugo is that it introduces yet another wsgi-thingy. Where is it hosted, stored, who maintains it etc? Mostly questions arising by the fact that I don't really know what Hugo is (or isn't).

I totally agree with your point on dogfooding; we should start designing an API asap.

When it comes to prediction, it should be feasible to do a decent prediction based on current trends and weather forecast. Perhaps @flikka can contribute towards this goal.

semafor commented 7 years ago

The only issue I have with Hugo is that it introduces yet another wsgi-thingy. Where is it hosted, stored, who maintains it etc?

It is not wsgi, but literally HTML-files. So, for the web page to function, hugo isn't actually needed. It's a HTML-file generator, not intended for dynamic serving.

As for hosting, friskby.no appears to already be able to serve HTML, but whoever is in charge of that system would know for sure. If the current friskby.no has a /var/www, it will be sufficient for the proposed hugo solution.

Note: work on the merger can continue merrily without a migration to hugo.

joakim-hove commented 7 years ago

I have now read about Hugo, looks nice. It can also be deployed to heroku - I think.

If we go that way I think the current friskby.herokuapp.com should become totally 'silent' - I.e. not serving anything but API stuff and the Django admin pages.

harloff commented 7 years ago

Friskby.no is powered be weebly a very simple and intuitive CMS hosted service. What is the rationale for moving this ?

2017-02-28 11:09 GMT+01:00 Jonas Groenaas Drange notifications@github.com:

The only issue I have with Hugo is that it introduces yet another wsgi-thingy. Where is it hosted, stored, who maintains it etc?

It is not wsgi, but literally HTML-files. So, for the web page to function, hugo isn't actually needed. It's a HTML-file generator, not intended for dynamic serving.

As for hosting, friskby.no appears to already be able to serve HTML, but whoever is in charge of that system would know for sure. If the current friskby.no has a /var/www, it will be sufficient for the proposed hugo solution.

Note: work on the merger can continue merrily without a migration to hugo.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/FriskByBergen/friskby/issues/170#issuecomment-282997873, or mute the thread https://github.com/notifications/unsubscribe-auth/ABZddM0mly0-3YLgvn26AfuiFgUKqheuks5rg_JxgaJpZM4MMgq8 .

-- http://harloff.no mob 93257417

semafor commented 7 years ago

Friskby.no is powered be weebly a very simple and intuitive CMS hosted service. What is the rationale for moving this ?

The main one is that you can put the entire thing on github, which is makes it easier to change for those without access, giving ownership to the community, etc. Also it's what the cool kids do these days.

But maybe the source code for the site is online already? In which case that point ^ is moot.

joakim-hove commented 7 years ago

I am not at all familiar with Weebly, but the main advantage as I see it is the ability to interact through JavaScript with the server holding the data - my hunch is that this will be simpler in a solution we have control over ourselves.

Treating the site as code with version control, testing and so on is also a clear advantage - in my opinion.

harloff commented 7 years ago

The fact that friskby.no is a bit out out of date is a problem now as we are going to send an application to spv.no tomorrow. Is it possible to create a webpage with the the map only that we could iframe on friskby.no as a quickfix ?

harloff commented 7 years ago

I see that iframing the complete friskby.herokuapp.com does not work now because of the headers Refused to display 'http://friskby.herokuapp.com/' in a frame because it set 'X-Frame-Options' to 'sameorigin'.

pgdr commented 7 years ago

The easiest is probably for whoever owns the domain friskby.no to DNS forward it to friskby.herokuapp.com. It's not a very big task to implement a map and a chart on the friskby.no site, but more than a couple of hours on the evening before.

harloff commented 7 years ago

We dont need it tomorrow, but maybe for next week. There is to much content on www.friskby.no, that we cannot throw away by just redirecting.

2017-03-29 21:54 GMT+02:00 Pål Grønås Drange notifications@github.com:

The easiest is probably for whoever owns the domain friskby.no to DNS forward it to friskby.herokuapp.com. It's not a very big task to implement a map and a chart on the friskby.no site, but more than a couple of hours on the evening before.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/FriskByBergen/friskby/issues/170#issuecomment-290206013, or mute the thread https://github.com/notifications/unsubscribe-auth/ABZddPsly1k4JCOPYvcv4xLaSlW0_cNNks5rqrbhgaJpZM4MMgq8 .

-- http://harloff.no mob 93257417

pgdr commented 7 years ago

I agree that there is valuable information on friskby.no so what about taking a picture from friskby.herokuapp.com and use as a link to friskby.herokuapp.com?

semafor commented 7 years ago

To migrate friskby.no to a github hosted, editable-by-all Friskby team members, I'll* need the following:

* I say “I” because I can only talk about myself here. Maybe someone else can do a migration without these things. :smile_cat: