DEV Community: valeversa

NASA Space Apps 2021 - Registrations now open!

valeversa — Fri, 24 Sep 2021 04:40:40 +0000

The NASA International Space Apps Challenge is an international hackathon for coders, scientists, designers, storytellers, makers, builders, technologists, and others in cities around the world, where teams engage the National Aeronautics and Space Administration’s (NASA’s) free and open data to address real-world problems on Earth and in space.

This year's event will take place on October 2-3 and will also mark the 10th year of this hackathon!

For the second year, the event will be hosted completely remotely, but it will still be a lot of fun (I promise!) and will give you the chance to connect with like-minded people nearby, thanks to Space Apps's virtual locations.
If you're reading this from Berlin (or really anywhere in Germany), you're welcome to register for our virtual location here. Otherwise, you can browse the location closer to you or register for the universal event.

Hope to virtually connect with a lot of you!

NASA Space Apps Challenge 2019 - Are You In?

valeversa — Tue, 24 Sep 2019 11:56:31 +0000

The NASA Space Apps Challenge is an international hackathon for developers of all levels, scientists, designers, storytellers, makers, builders, technologists – EVERYONE! – that will take place in cities around the world, where teams will engage with NASA’s free and open data to address real-world problems on Earth and in space.

This year's challenges will cover 5 topics:

Earth's Oceans🌊
Living in Our World🌎
To the Stars ✨
Planets Near and Far 🚀
Our Moon 🌜

Space Apps 2018 included over 18,000 participants at more than 200 events in 75 countries. Let's try to beat those numbers, this year!

The global event will take place on October 18-20, 2019 – local and virtual attendance is encouraged!

Check out the event's map and register for the hackathon closest to you!

PS: If you are in Berlin, Germany, see you at our local event!

The Beauty of REM

valeversa — Tue, 30 Jul 2019 18:40:52 +0000

How to create a fully responsive web page with just two media queries.

While developing our web application, our team quickly realized the need for a highly responsive layout that would accommodate a wide range of browser sizes. Although our platform is almost entirely used on desktop, we still needed to come up with a flexible enough solution that was able to work on both large and very small screens (e.g. tablets, smartphones and very old desktop screens). Due to the complexity of our layout — which includes lots of tables, buttons, and modals — it was clear to us that working with media queries would be a strenuous task. While looking for alternative solutions, we stumbled across the possibility to create a truly responsive layout by scaling every component on our web page according to browser viewport width: vw.

html { font-size: 4vw; }

The concept of this approach is straight-forward: assign a specific font size to the HTML element you are working with (e.g. font-size: 4vw), and then define the size of every element in it using REM units.

.container {
  width: 20rem;
  padding: 2rem;
  margin: 2rem auto;
}

This way, the container is scaled up or down according to the screen width, due to its dependency on the parent’s font size.
More examples: the headlines of your page will have rem font size as well as paddings and margins, as will your paragraphs. Both elements are sized according to the window’s width.

h1 {
  font-size: 2rem;
  margin: 0;
  text-align: center;
}

p {
  font-size: .8rem;
}

There is one exception to the “use rem everywhere” rule: you can continue using pixels for elements that should not resize according to the screen width. For instance, you still want to define borders of your div using pixels because scaling this up would result in fat borders or buttons.

.container {
  border: 1px solid black;
  border-radius: 16px;
  width: 20rem;
  padding: 2rem;
  margin: 2rem auto;
}

Do we still need media queries?

The answer is yes. Specifically, you only need two of them. You need to define a breakpoint in which your components won’t get any smaller, and another breakpoint at which your components will stop scaling up and will maintain the same size no matter how much bigger the screen gets. Those two media queries only affect the HTML font size element, but all elements underneath scale magically.

html {
  font-size: 3vw;
  font-family: sans-serif;
}

@media only screen and (max-width: 550px) {
  html { font-size: 12px; }
}

@media only screen and (min-width: 1020px) {
  html { font-size: 24px; }
}

Once again, you can use pixels to make sure the minimum and maximum possible font size units are fixed.

Click here to view the full demo page.

Do you have a comment or just send kudos our way, get in touch with Valentina or Tom.

CSS Grid and IE11

valeversa — Mon, 06 May 2019 12:41:47 +0000

How a little Javascript helped us make peace with CSS Grid and IE11.

A few months ago, we decided it was time to re-work our core platform. The idea of starting from scratch was both exciting and challenging: how to choose sustainable technology and tools while making sure the team can handle them? On the frontend, the decision came down to three pillars: a) using a known naming convention for CSS classes: BEM, b) using an atomic component design approach, and c) ideally building every layout using CSS Grid. This article will focus on the latest choice and its consequences.

CSS Grid is a relatively new approach to layouts, and it has been proved simple for junior developers to learn. Wes Bos has a great free tutorial on this. Grid’s concepts were also flexible enough to meet our needs – our backend platform is mainly used on desktop, and our layout includes a high number of elements per page: tables, buttons, and a high volume of data to be displayed.

The decision to adopt CSS Grid worked very well for us, although very early on the process of coding our new layout, we stumbled upon an impediment: the need of building layouts that would work – and look good – on IE11 browsers. With 35% of our current users still browsing with IE11, we could not ignore the fact that CSS Grid does not work on IE as seamlessly as on Chrome or Firefox: IE browsers don’t understand implicit row-column positioning, so they display every element overlapped in the first column/row.

The very first solution that we came up with was to always use CSS to make the row and column positioning of each element explicit.

.header {
  color: yellow;
  font-size: 24px;
  grid-column: 2; /* explicit positioning */
}

Since we were working with reusable components, in most cases we could not add the above declaration directly to the element’s global CSS (e.g. not all headers will be in column 2 throughout the whole platform). A solution for this issue was to add specific classes directly to our code: this enabled us to keep all our elements in the right layout position – even in IE11.

/ adding block classes for IE11 (HAML)
%header.block--col2.block--row2

/* CSS for the element and the block classes */
.header {
  color: yellow;
  font-size: 24px;
}
.block--col2 { grid-column: 2; }
.block--row2 { grid-row: 2; }

This solution, while giving us the result we were looking for on IE11, made our markup incredibly complicated and hard to read:

/ before
.container
  .company-logo
  .side-menu.block--row2
    .menu-item
    .menu-item.block--row2
    .menu-item.block--row3
  .banner-area.block--col2
  .main-content-area.block--col2.block--row2
    .intro-bar
      .header
      .buttons.block--col2
      .info.block--col3
        .info-detail.block--col1
        .info-detail.block--col2
        .info-detail.block--col3
    .content
      .hero

This approach was error-prone, and the more complex our layout became, the more complicated it was to maintain it: we were in need of a more sustainable solution. Here’s where the idea for our grid-annotator polyfill was born: we needed a simple JavaScript that automatically annotates column and row positioning to our components if the browser is IE111. For every other browser, the script simply doesn’t kick in. After only a few hours hacking good old JavaScript, we had our first prototype. We could finally remove all these annoying block classes and this resulted in the markup becoming simpler and more maintainable:

/ after
.container
  .company-logo
  .side-menu
    .menu-item
    .menu-item
    .menu-item
  .banner-area
  .main-content-area
    .intro-bar
      .header
      .buttons
      .info
        .info-detail
        .info-detail
        .info-detail
    .content
      .hero

Of course, our grid-annotator doesn’t solve all CSS Grid issues on IE112: some of its other features such as repeat or grid-area are not addressed, but we might add them in the future.

While implementing the polyfill in our product, we noticed a small issue: obviously, IE11 loads the page before the JavaScript is able to untangle our grid columns and rows. This causes the page components to overlap for a split second. After discussing the issue with product managers and running tests on different computers, we agreed that the “glitch” was not compromising the performance of the pages.

If you are in a similar situation, feel free to take a look at the grid-annotator repository. Do you have more ideas or want to contribute? Do you have a comment or just send kudos our way, get in touch with Tom or Valentina.

This article was first published on Tom's blog.