Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

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

Open
semafor opened this issue Feb 26, 2017 · 15 comments
Open

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

semafor opened this issue Feb 26, 2017 · 15 comments
Assignees
@semafor

Comments

@semafor
Copy link
Contributor

semafor commented Feb 26, 2017

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:

  • 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.
  • What is the trend like? Is it getting better or worse? Maybe a super simple chart for Bergen.
  • Where are sensors currently placed? Queue dynamic map.
  • What is friskby? Use a heroku-like, icon based grid?
  • How can I contribute? Step by step instructions right there on the front page.
  • Who contributes? Sponsor-grid?

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
Copy link
Contributor

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
Copy link
Contributor

oyta commented Feb 27, 2017

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
Copy link
Contributor Author

semafor commented Feb 28, 2017

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
Copy link
Member

pgdr commented Feb 28, 2017

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
Copy link
Contributor Author

semafor commented Feb 28, 2017

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
Copy link
Contributor

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
Copy link

harloff commented Feb 28, 2017 via email

@semafor
Copy link
Contributor Author

semafor commented Feb 28, 2017 •
edited
Loading

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
Copy link
Contributor

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.

@semafor semafor self-assigned this Mar 12, 2017
@harloff
Copy link

harloff commented Mar 29, 2017

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
Copy link

harloff commented Mar 29, 2017

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
Copy link
Member

pgdr commented Mar 29, 2017

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
Copy link

harloff commented Mar 29, 2017 via email

@pgdr
Copy link
Member

pgdr commented Mar 29, 2017

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
Copy link
Contributor Author

semafor commented Apr 4, 2017 •
edited
Loading

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

  • certainty of what is valuable on friskby.no and what is absolutely required that friskby.no display,
  • knowledge and contact details of whoever administers the friskby.no domain,
  • access to the CMS of friskby.no,
  • a clear mandate to do the migration by <owners>.

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@semafor semafor

Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@semafor @joakim-hove @harloff @oyta @pgdr