Commit 5131497b authored by Laura Kalbag's avatar Laura Kalbag

Add to RSS feed. Improve copy based on Aral's feedback

parent ac4cd7db
......@@ -57,21 +57,21 @@
<p class='post-date dt-published' datetime='2015-11-29 11:55:00'>29th November, 2016 — <span class='p-author'>Laura Kalbag</span></p>
<div class='e-content'>
<p>CSS is vital to <a href="https://better.fyi">Better</a>. The Better apps (<a href="https://itunes.apple.com/us/app/better-by-ind.ie/id1080964978?ls=1&mt=8">iOS</a> and <a href="https://itunes.apple.com/us/app/better/id1121192229?ls=1&mt=12">Mac</a>) use web pages for their content. They’re the same pages you see on the <a href="https://better.fyi">Better site</a>, but with slightly different templates allowing the apps to make appropriate use of their native technology. Still, the content you see on the apps is largely HTML and CSS.</p>
<p>CSS is vital to <a href="https://better.fyi">Better</a>. The Better apps (<a href="https://itunes.apple.com/us/app/better-by-ind.ie/id1080964978?ls=1&mt=8">iOS</a> and <a href="https://itunes.apple.com/us/app/better/id1121192229?ls=1&mt=12">Mac</a>) are native apps that use web pages for their content. They’re the same pages you see on the <a href="https://better.fyi">Better site</a>, but with specialised templates. Still, the content you see on the apps is largely HTML and CSS.</p>
<p>The pre-compiled architecture is fairly straight-forward:</p>
<ul>
<li>a common CSS file for styles that cover both the site and the apps</li>
<li>a site CSS file that covers site-specific design elements such as the navigation, footer, and site homepage</li>
<li>an app CSS file that covers rendering differences between the app(s) and site</li>
<li>a <a href="https://source.ind.ie/better/themes/blob/master/common/static/styles/common.css">common CSS file</a> for styles that cover both the site and the apps</li>
<li>a <a href="https://source.ind.ie/better/themes/blob/master/site/static/styles/postfix.css">site CSS file</a> that covers site-specific design elements such as the navigation, footer, and site homepage</li>
<li>an <a href="https://source.ind.ie/better/themes/blob/master/app/static/styles/postfix.css">app CSS file</a> that covers rendering differences between the app(s) and site</li>
</ul>
<p>Each of the CSS files is compiled into a global CSS file during the build process using first the common CSS file, and then either the app or site CSS files.</p>
<p>Each of the CSS files is compiled into <a href="https://data.better.fyi/generated/site/blob/master/styles/global.css">a global CSS file</a> during the build process using first the common CSS file, and then either the app or site CSS files.</p>
<h2>The opportunity</h2>
<p>When we first launched Better, the iOS app had a coloured frame around the content (see below). The frame was in the native app, and meant the content viewport size was slightly different than viewing the same content on the site in a web browser on the same device. It also meant the CSS required specific media queries to ensure more complex design elements, such as the statistics, would fit the viewport and still look good on narrow devices.</p>
<p>When we first launched Better, the iOS app had a coloured frame around the content (see below). The frame was in the native app, and meant the content viewport size was slightly different than when viewing the same content on the site in a web browser on the same device. It also meant the CSS required specific media queries to ensure more complex design elements, such as the statistics, would fit the viewport and still look good on narrow devices.</p>
<figure>
<img src="images/border-to-borderless.jpg" alt="Two screenshots of the statistics on the Cloud of Shame on iPhone 6" width="750" height="667" style="margin-left:auto;margin-right:auto;height:auto;border:1px #ccc solid;">
......@@ -81,7 +81,7 @@
</figure>
<p>In September, Aral removed the coloured frame from the app interface. Firstly this gave the interface a much cleaner and more spacious feel, but it also meant the viewport widths were exactly the same whether you were looking at Better content in the app or in a web browser on the same device. This gave me the opportunity to overhaul the CSS, removing excess rules and repetition mostly caused by a gazillion media queries.</p>
<p>In September, Aral removed the coloured frame from the app interface. Firstly, this gave the interface a much cleaner and more spacious feel. It also meant the viewport widths were exactly the same whether you were looking at Better content in the app or in a web browser on the same device. This gave me the opportunity to overhaul the CSS, removing excess rules and repetition mostly caused by a gazillion media queries.</p>
<h2>Changing the way I design for the web</h2>
......@@ -122,8 +122,9 @@
<p>This makes all font sizes scale up proportionally at 460px and 600px viewport widths.</p>
</figcaption>
</figure>
<p>With all font sizes scaling up from the root at 460px and 600px-wide viewports, every other rule using <code>em</code>s will scale up too. Thanks to the cascade, the scaling is always in proportion to the font size. This makes most media queries redundant, with exceptions only when tweakpoints are required between or above these viewport sizes. Scaling with <code>em</code>s requires fewer rules, and makes every rule proportional. It’s building on the existing flexibility of the web.</p>
<p>Then I took all the paddings, margins, max-widths, and anything else related to space or layout, and converted those units to <code>em</code>s, removing their media queries too. I generally used <a href="https://abookapart.com/products/responsive-web-design">the old <code>target/context = result</code> rule</a>. A <code>margin: 12px;</code>, with a root <code>font-size</code> of <code>14px</code> becomes <code>margin: 0.857142857em;</code>. The decimals are ugly, and harder to visualise, so I rounded units to the nearest .5 or .25 as I re-factored. This makes the <code>margin: 0.857142857em;</code> a much tidier <code>margin: 0.85em;</code>.</p>
<p>Then I took all the paddings, margins, max-widths, and anything else related to space or layout, and converted those units to <code>em</code>s, removing their media queries too. I generally used <a href="https://abookapart.com/products/responsive-web-design">the old <code>target/context = result</code> rule</a>. A <code>margin: 12px;</code>, with a root <code>font-size</code> of <code>14px</code> becomes <code>margin: 0.857142857em;</code>. The decimals are ugly, and harder to visualise, so I rounded units as I re-factored. This makes the <code>margin: 0.857142857em;</code> a much tidier <code>margin: 0.85em;</code>.</p>
<p>With barely any media queries, the CSS was easier to manage. It meant I could have a fresh look at the relationships between the type and the space, adjusting consistently across all the elements. When writing CSS, I first style based on the naked elements (<code>h1, h2… ul… p</code> etc) themselves. (<a href="https://www.smashingmagazine.com/2016/11/css-inheritance-cascade-global-scope-new-old-worst-best-friends/">Heydon recently wrote a great article on the benefits of this approach</a>.) Styling without classes is also necessary as most of our content is generated directly from markdown.</p>
......@@ -158,7 +159,7 @@
<h2>Better SVGs</h2>
<p>Getting all overexcited with stripping out unnecessary CSS, I decided to do the same with our graphics too. Last month I read <a href="https://abookapart.com/products/practical-svg">Chris Coyier’s Practical SVG</a> which helped me understand the ins-and-outs of SVG much better. To help grok as I was learning, I created a little find-and-replace script to scrub all the junk out of a generated SVG file to keep it nice and small. One of Chris’ simplest tips was removing excess decimals from the path points. This alone can halve the size of an SVG.</p>
<p>Getting all overexcited with stripping out unnecessary CSS, I decided to do the same with our graphics too. Last month I read <a href="https://abookapart.com/products/practical-svg">Chris Coyier’s Practical SVG</a> which helped me understand the ins-and-outs of SVG much better. To help grok as I was learning, I created a <a href="https://source.ind.ie/better/themes/snippets/23">little find-and-replace script</a> to scrub all the junk out of a generated SVG file to keep it nice and small. One of Chris’ simplest tips was removing excess decimals from the path points. This alone can halve the size of an SVG.</p>
<figure>
<pre><code>&lt;?xml version="1.0" encoding="UTF-8"?&gt;
......
......@@ -4,8 +4,17 @@
<title>Ind.ie Labs</title>
<link>https://ind.ie/labs/blog/rss</link>
<description>News and updates from the Ind.ie Labs blog</description>
<lastBuildDate>Fri, 29 Jul 2016 05:00:00 GMT</lastBuildDate>
<lastBuildDate>Tue, 29 Nov 2016 11:55:00 GMT</lastBuildDate>
<atom:link href="https://ind.ie/labs/blog/rss/index.xml" rel="self" type="application/rss+xml" />
<item>
<title>Overhauling Better&quot;s CSS</title>
<link>https://ind.ie/labs/blog/better-css-overhaul</link>
<guid>https://ind.ie/labs/blog/better-css-overhaul</guid>
<description>&lt;p&gt;Using ems, reducing repetition, and improving SVG icons.&quot;&lt;/p&gt; &lt;p&gt;&lt;a href=&quot;https://ind.ie/labs/blog/better-css-overhaul&quot;&gt;Read the full post on the Ind.ie forum&lt;/a&gt;.&lt;/p&gt;
</description>
<pubDate>Tue, 29 Nov 2016 11:55:00 GMT</pubDate>
<author>laura@ind.ie (Laura Kalbag)</author>
</item>
<item>
<title>A note about client-side-only JavaScript in Set templates</title>
<link>https://forum.ind.ie/t/a-note-about-client-side-only-javascript-in-set-templates/1277</link>
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment