tag:joecritchley.svbtle.com,2014:/feedJoe Critchley2014-11-15T09:05:08-08:00Joe Critchleyhttps://joecritchley.svbtle.comSvbtle.comtag:joecritchley.svbtle.com,2014:Post/6-apps-for-simple-living-in-san-francisco2014-11-15T09:05:08-08:002014-11-15T09:05:08-08:006 apps for simple living in San Francisco<p>In San Francisco, it’s pretty easy to conduct your life from the palm of your hand. For three months, I got the chance to live the simple life. Depending on how you look at it, this is either super convenient or excruciatingly lazy; but either way, here’s the apps that are at the top of the pile.</p>
<h2 id="1-a-hrefhttpsprigcomspriga_2">1. <a href="http://sprig.com">Sprig</a> <a class="head_anchor" href="#1-a-hrefhttpsprigcomspriga_2">#</a>
</h2>
<ul>
<li>
<strong>Synopsis</strong> Healthy food, rapidly delivered</li>
<li>
<strong>Best point</strong> Delivery time</li>
<li>
<strong>Worst point</strong> Food presentation</li>
</ul>
<p>I ate several unhealthy takeaways in the first couple of weeks. To ensure I didn’t go back to the UK three times larger than when I left, I needed something that balanced convenience with healthiness. </p>
<p>Sprig delivers healthy meals to your door very quickly. The ingredients are locally sourced, the logistics is distributed, and the food is made the same day. It’s an integrated service: cooking, curation, delivery. Their pricing was incredibly simple: $10 for a meal, $2 for delivery, tip included.</p>
<p>The first experience with this app was strangely magical. I paid for the chicken (there’s a choice of 3 meals at dinner), and it arrived at my door within approximately 10 minutes. <em>Ten</em> minutes.</p>
<p>It felt too good to be true, so I asked for the meal’s nutritional info (they’re happy to give you it). It turns out everything was as healthy as claimed, even to the point where they use a selection of good cooking oils. I was intrigued to see how they managed to get the food to me so quickly: a <a href="http://www.quora.com/How-does-Sprig-work">Quora answer</a> revealed quite a lot.</p>
<h2 id="2-a-hrefhttptrycaviarcomcaviara_2">2. <a href="http://trycaviar.com">Caviar</a> <a class="head_anchor" href="#2-a-hrefhttptrycaviarcomcaviara_2">#</a>
</h2>
<ul>
<li>
<strong>Synopsis</strong> Restaurant food, delivered</li>
<li>
<strong>Best point</strong> San Francisco’s quality restaurants</li>
<li>
<strong>Worst point</strong> Easy to overspend</li>
</ul>
<p>When it came to weekends, it made sense to treat myself to something a bit more special. If no one was around for a restaurant trip, why not bring the restaurant to your door?!</p>
<p>Caviar allows you to choose food from a restaurant, and they pick it up and deliver it to your door. Being less integrated than Sprig, expect longer and less consistent delivery times. But you do get to track your location of your delivery via GPS.</p>
<p>The quality of San Francisco restaurants really excels this service. In particular, I highly recommended Citizens’ Band and Little Delhi.</p>
<h2 id="3-a-hrefhttpspostmatescompostmatesa_2">3. <a href="https://postmates.com/">Postmates</a> <a class="head_anchor" href="#3-a-hrefhttpspostmatescompostmatesa_2">#</a>
</h2>
<ul>
<li>
<strong>Synopsis</strong> Anything from anywhere local, delivered</li>
<li>
<strong>Best point</strong> Anything can be delivered to you</li>
<li>
<strong>Worst point</strong> Really expensive</li>
</ul>
<p>Postmates is similar to Caviar, but is for delivering <em>anything from anywhere locally</em>. You can provide instructions for a custom location, and then you pay for the item once the driver provides the receipt.</p>
<p>If you’re with a group of people who are wanting to get something delivered from around the city, then Postmates might be your answer. If you’re by yourself, it’s delivery price are off-putting (you’d pay $10 delivery for a $4 coffee).</p>
<h2 id="4-a-hrefhttprelayridescomrelayridesa_2">4. <a href="http://relayrides.com">RelayRides</a> <a class="head_anchor" href="#4-a-hrefhttprelayridescomrelayridesa_2">#</a>
</h2>
<ul>
<li>
<strong>Synopsis</strong> AirBnB for cars</li>
<li>
<strong>Best point</strong> Reasonable pricing</li>
<li>
<strong>Worst point</strong> Having to trust the owners</li>
</ul>
<p>It was time to spread my wings and hire a car. Being quite picky with cars, so I wanted to approach this a bit differently.</p>
<p>RelayRides is AirBnB for cars. For my last month, I hired a MINI Cooper S from a friendly chap. The pricing is very reasonable. However, if you want to make sure you’re well covered insurance wise, that will set you back another 40% of the cost of the rental.</p>
<p>On a side note, if you’re new to California, I highly recommend hiring a car for as long as possible. San Francisco’s public transport isn’t as bad as people claim (<a href="http://thetransitapp.com/">Transit</a> can help you there), but there’s so much to see outside of SF, and I wish I’d had one for longer.</p>
<h2 id="5-a-hrefhttpgetbrandidcombrandida_2">5. <a href="http://getbrandid.com">BRANDiD</a> <a class="head_anchor" href="#5-a-hrefhttpgetbrandidcombrandida_2">#</a>
</h2>
<ul>
<li>
<strong>Synopsis</strong> Try clothes on at home, decide if you want to buy</li>
<li>
<strong>Best point</strong> Personal assistance</li>
<li>
<strong>Worst point</strong> Browsing always means chatting to an assistant</li>
</ul>
<p>I was told that clothes were cheap over there, so I used it as a chance to freshen up my wardrobe.</p>
<p>There’s a new wave of apps changing the e-commerce sector. One of those, BRANDiD, is a very interesting concept. It blends IM personal assistance with the ability to try on clothes at home—only paying if you want to keep the items.</p>
<p>They’re very accommodating: they were happy to pick up unwanted clothes in the evening after work, and there was seemingly no limit to how many different items and sizes I could get delivered.</p>
<h2 id="6-a-hrefhttpwwwdoormanitdoormana_2">6. <a href="http://www.doorman.it">Doorman</a> <a class="head_anchor" href="#6-a-hrefhttpwwwdoormanitdoormana_2">#</a>
</h2>
<ul>
<li>
<strong>Synopsis</strong> Evening delivery service</li>
<li>
<strong>Best point</strong> How necessary this kind of thing is</li>
<li>
<strong>Worst point</strong> Tips included, but drivers sometimes look like they are expecting another one. </li>
</ul>
<p>As I was living in the city and commuting down to Cupertino, this meant I could never be around for deliveries during the day. I searched for a service I’d heard about called Luna, but it turns out they were acquired by a competitor, Doorman.</p>
<p>At $19/month for the monthly plan, you get anything delivered to your own postbox at their HQ. And, when it’s convenient in the evening, you can get it all re-delivered to your home address. All drivers went above-and-beyond: one guy was even happy to wait around when I was late getting off the shuttle.</p>
<p>—</p>
<p>These services might seem quite steep in price, but I think these real-world services are often more valuable than the digital services we pay for. Reducing stress through simplicity is sometimes priceless.</p>
tag:joecritchley.svbtle.com,2014:Post/portals-in-reactjs2014-07-08T05:38:02-07:002014-07-08T05:38:02-07:00"Portals" in React.js<p><strong>(Another day, another bit of terminology made up by me.)</strong></p>
<p>“Portals” is a pattern that I’ve recently tried in a React project, which allows a component to control another part of the existing DOM entirely.</p>
<p>It passes a string reference from a component, to match a DOM element’s ID attribute elsewhere. I can imagine this is useful if you don’t want all your apps to be aware of properties, essentially decoupling the component tree from the DOM tree.</p>
<p>This is currently a one-time experiment. It is an extension of the <a href="http://jsfiddle.net/LBAr8">ReactLayeredMixin</a> pattern, which itself renders some DOM to a new element on the page. However, instead of creating a new DOM element, you link to one by passing an ID of an element as a string, and that is used as a <code class="prettyprint">document.getElementById(this.props.portal)</code></p>
<p>It’s actually quite similar to <code class="prettyprint">yield[:whatever]</code> in Ruby on Rails views and layouts.</p>
<p><strong>Warning:</strong> <em>this will probably only work if you plan to mount the DOM portal before the triggering component.</em></p>
<h2 id="demo_2">Demo <a class="head_anchor" href="#demo_2">#</a>
</h2>
<p>You can try this on JSFiddle:</p>
<p><a href="http://jsfiddle.net/joecritch/fU9Bp/">http://jsfiddle.net/joecritch/fU9Bp/</a></p>
<h2 id="thoughts_2">Thoughts <a class="head_anchor" href="#thoughts_2">#</a>
</h2>
<p>If you have any thoughts on this, please tweet me. I’d love to know if you think this is a huge anti-pattern, as I’m actually finding it quite handy.</p>
tag:joecritchley.svbtle.com,2014:Post/blog-over-bird-22014-07-01T16:11:51-07:002014-07-01T16:11:51-07:00Blog Over Bird — #2<p>Alright, folks. I’ve racked my brain for a few more things to say. I’ve almost tweeted half of these, but I’m finding it a lot easier to [write / waffle] on here.</p>
<h2 id="disposability-vs-maintainability_2">Disposability vs. Maintainability <a class="head_anchor" href="#disposability-vs-maintainability_2">#</a>
</h2>
<p>I’ve been inspired by Ryan Florence <a href="https://twitter.com/ryanflorence/status/483044575439646721">saying such a thing</a>. It’s something that I considered today, even on client work. I think a disposable interface could do wonders, especially when coupled with a stable server API. More experimentation, ‘n all that.</p>
<h2 id="foxcatcher_2">Foxcatcher <a class="head_anchor" href="#foxcatcher_2">#</a>
</h2>
<p>How did this film slip under my radar? I can’t wait to see it. You should check the video clip on <a href="http://www.imdb.com/title/tt1100089/">IMDB</a>, and be mesmerised by Steve Carrell’s performance. Apparently people at Cannes were loving it.</p>
<h2 id="the-kids-are-all-right_2">The Kids Are All Right <a class="head_anchor" href="#the-kids-are-all-right_2">#</a>
</h2>
<p>I seem to be on a film-a-night during the week lately. One of the more recent movies was <a href="http://www.imdb.com/title/tt0842926/?ref_=nv_sr_1">The Kids Are All Right</a>. If you haven’t seen it yet, here’s what you should do: watch it, then watch the trailer afterwards, and see how badly they portray the film. <em>“Don’t judge a film by it’s trailer.”</em></p>
<h2 id="burner_2">Burner <a class="head_anchor" href="#burner_2">#</a>
</h2>
<p>I came across this little gem from Jeff Escalante today. I couldn’t sum it up better myself: <a href="https://github.com/jenius/burner-api">“Host a file for one download, then burn it”</a>. It’s apparently “SnapChat for Nerds” at the minute, because you’ll have to cURL your way round the API. But the <em>concept</em>, there’s definitely something in it.</p>
<h2 id="slack-vs-all-the-others_2">Slack vs. all the others <a class="head_anchor" href="#slack-vs-all-the-others_2">#</a>
</h2>
<p>We’re quite fond of switching our group messaging apps at Strobe. Over the past few weeks, we’ve been using Slack. I love the characterful interface — it’s a pleasure to look at. But it does make me think: we probably didn’t need to switch. Flowdock did the trick. As did HipChat. Hell, probably Campfire would have been fine, if it wasn’t for its pricing. But, yet, the “fashionable” side of the tech/app industry strikes again.</p>
tag:joecritchley.svbtle.com,2014:Post/blog-over-bird-12014-06-30T14:21:44-07:002014-06-30T14:21:44-07:00Blog Over Bird — #1<p>Even though we do have Twitter, I miss the days of the informal blog. I figured I’d give myself a break from tweeting for a few days, to see how many valuable points I can put out there.</p>
<h2 id="react-controllable-components_2">React: Controllable components <a class="head_anchor" href="#react-controllable-components_2">#</a>
</h2>
<p>Throughout the day, Chris and I were discussing the idea of reusable components in React (our current go-to library for any hefty UI development). The ideal scenario is that a component in isolation should be able to be controlled, as well another external component being able to control it. In React, there are two opposing objects, state and props, which means that this ideal scenario cannot be achieved directly. So, we hunted around, and came across this—<a href="https://github.com/matthewwithanm/react-controllables">https://github.com/matthewwithanm/react-controllables</a>. It provides the best of both worlds for this situation.</p>
<h2 id="react-immutability-helpers_2">React: Immutability helpers <a class="head_anchor" href="#react-immutability-helpers_2">#</a>
</h2>
<p>On a current React project, I need the ability to not re-render a component when its state doesn’t change. This is an issue for arrays that are assigned by reference. But, wha’d'y'know, React has a set of immutability helpers, allowing you to performantly create a new array, modified from the old one. My favourite so far is the <code class="prettyprint">$splice</code> directive: <a href="https://gist.github.com/joecritch/476806f0174ed74791ec">https://gist.github.com/joecritch/476806f0174ed74791ec</a></p>
<h2 id="nq-guilty-by-association_2">NQ: Guilty By Association <a class="head_anchor" href="#nq-guilty-by-association_2">#</a>
</h2>
<p>This is one for the Manchester people. I’ve been a couple of times to this new bar in the Northern Quarter called Guilty By Association. For what seems like a low-key venue (you won’t notice it immediately, but it’s opposite Fred Aldous on Lever Street). The music is Hip Hop—new and old. And, according to Friday night, they take requests over Twitter… or perhaps that was just a one-off! Anyway, it’s a great addition to the Northern Quarter. Check it.</p>
<h2 id="keynote-the-informal-proposal-tool_2">Keynote: the informal proposal tool <a class="head_anchor" href="#keynote-the-informal-proposal-tool_2">#</a>
</h2>
<p>This morning at Strobe, I was on a last-minute dash to wrap up a proposal for a new project. Armed with some low-fidelity material (basic wires, photographs of our notes), I wanted something as equally low-fidelity that didn’t get caught-up by wording. So this time, I went for 16 pages of snappy summaries and photos. I think this opens up room for more personality. Of course, this isn’t to say that it works yet… but novel proposals is something I’m going to spend more time on.</p>
<h2 id="idea-timebased-todo-list_2">Idea: time-based to-do list <a class="head_anchor" href="#idea-timebased-todo-list_2">#</a>
</h2>
<p>I often create ‘crash-course’ to-do lists for an ultimate GTD hit that I so often need. (I’m quite unorganised when it comes to my personal life). I love the Clear app’s UI, including the addition of task reminders, but it’d be so cool if dragging a new task in between two others added a reminder time that was in-between its neighbours (with more refined control of the particular time in between that range, depending on where you drop it). I feel a Framer prototype coming on.</p>
<hr>
<p>I had another idea too, but I’ve decided to keep that one behind closed doors for now!</p>
<p>Anyway, that’s it for now. Maybe see you tomorrow, depending on much I have to talk about!!</p>
tag:joecritchley.svbtle.com,2014:Post/transclusion-in-react2014-02-13T11:52:52-08:002014-02-13T11:52:52-08:00Better component transclusion in React with 'outlets'<p>As a believer of Facebook React’s <a href="https://twitter.com/meteorjs/status/433244564665950209">principles</a>, here’s an explanation of how React handles transclusion, and how it can be improved.</p>
<hr>
<h2 id="what-is-transclusion_2">What is transclusion? <a class="head_anchor" href="#what-is-transclusion_2">#</a>
</h2>
<p>In terms of UI development, transclusion is when a child component is declared from inside of parent component, and the child component is agnostic to its parent. This allows for a nested, flowing and declarative component hierarchy.</p>
<h2 id="basic-transclusion-in-react_2">Basic transclusion in React <a class="head_anchor" href="#basic-transclusion-in-react_2">#</a>
</h2>
<p>React is able to handle basic transclusion out of the box using the <code class="prettyprint">this.props.children</code> property, which is an array of all components that have been declared directly inside of the current component, like so:</p>
<pre><code class="prettyprint">var MyExample = React.createClass({
displayName: 'MyExample',
render: function() {
return (MyComponent(null,
React.DOM.p(null, "This paragraph is transcluded into MyComponent.")
));
}
});
</code></pre>
<p>As you can see, the <em>specific</em> rendered position of the child paragraph (which in this case is a child component of MyComponent), isn’t described by the MyExample component; only MyComponent is concerned about <em>where</em> it is rendered. Conversely, MyComponent would look something like this:</p>
<pre><code class="prettyprint">var MyComponent = React.createClass({displayName: 'MyComponent',
render: function() {
return (
React.DOM.div(null,
React.DOM.h1(null, "I want my sub components to go below this title."),
this.props.children
)
);
}
});
</code></pre>
<h2 id="outlets_2">Outlets <a class="head_anchor" href="#outlets_2">#</a>
</h2>
<p>This is a useful technique, but it has a limitation: you can’t define multiple outlets for transclusion. For example, you may want a component that has a header and footer, as well as some body content. You want to be able to declare all of these directly in the parent component, but each part needs to be rendered into different locations of the child component.</p>
<p>The simplest option to allow you to define outlets in your component is by using <code class="prettyprint">this.props</code> directly, and providing your component through that, e.g.</p>
<pre><code class="prettyprint">MyComponent( {header:React.DOM.div(null, "header"), footer:Footer(null )}, "some children")
</code></pre>
<p><strong>Update:</strong> I did write a <a href="https://gist.github.com/joecritch/8755865">mixin</a> to use the outlets as children, and for them to get outputted before the render function of the child component. But, after discussing this people on the #reactjs IRC, it’s probably better to use outlets as simple properties (as above).</p>
<p>This raised an important issue when dealing with JSX: remember that whenever you write some JSX component markup, all you are doing is calling that function. So you can pass in other components as properties to that component.</p>
<hr>
<p><strong>Side note: React mixins are awesome</strong></p>
<p>When I was writing the (now redundant) mixin above, I didn’t realise how React handles lifecycle methods of a component which has attached mixins. I searched for a way to call the equivalent parent methods from within the mixed component. Well, it turns out that React <em>automatically</em> runs all lifecycle methods from all mixins and the component. Boom!</p>
<hr>
<p>So yeah, you can now have fun with more outlet-led transclusion, and create some reusable interfaces.</p>
tag:joecritchley.svbtle.com,2014:Post/this-thing-called-mooch2013-12-20T09:20:41-08:002013-12-20T09:20:41-08:00This thing called Mooch<p><a href="http://strobedigital.com">Strobe</a> have just come out of — approximately — a 4-week sprint to produce a very rough social web app. <a href="http://trymooch.com">Mooch</a> <strong>(<a href="http://trymooch.com">trymooch.com</a>)</strong> matches its user’s intentions (e.g. play football today, drink a beer tomorrow) with one another, allowing them to converse and form a plan.</p>
<p><em>Below, I’ve briefly explained why we started this in the first place, what our goal was in this sprint, and also opened-up our retrospective notes from this afternoon.</em></p>
<hr>
<h2 id="where-did-it-come-from_2">Where did it come from? <a class="head_anchor" href="#where-did-it-come-from_2">#</a>
</h2>
<p>The overarching concept and reason for this kind of product comes from the early days at Strobe, where we decided that, at some point in our future, we wanted to ‘make product’. Over the months, we started to take the ideas more seriously, spending several evenings in The Mill pub in Ulverston, littering their tables with planning materials.</p>
<p>Then, in the spring/summer of 2013, we dropped our client capacity slightly, to make room for developing the concept further. We made a native iOS app, an API, and even our own app delivery platform. But, more importantly, we had <em>lots</em> of lightbulb moments. (For example: realising that plans can only be driven through conversation, rather than upfront form-filling.)</p>
<p>And then, in the biggest move since we started Strobe, we actually reserved some serious time in our schedules for this product. What was a vague idea in the back of our heads at the start of the year, is now booked into our schedule for a significant period of time.</p>
<hr>
<h2 id="the-purpose-of-these-last-4-weeks_2">The purpose of these last 4 weeks <a class="head_anchor" href="#the-purpose-of-these-last-4-weeks_2">#</a>
</h2>
<p>This was always going to be a “see what happens” kind of sprint. We didn’t want to do this in a predefined fashion; we wanted to focus on one thing: improving <em>naturally</em> as a product team. Our background is in freelancing for larger digital companies, and whilst we were dealing with the same technology and methodologies from these clients, it’s another ball game to practice these internally, with no one to play ‘doctor’ to but yourselves.</p>
<p>We feel like we did grow naturally. We’ve come a long way in the past 2 months: we’ve got our own little hideout in Manchester’s centre, and we no longer have to be around each other 24/7. Now, we disagree with each other a lot less, we rarely do head-desks, and we are hugely positive about our current position.</p>
<hr>
<h2 id="what-it-is-what-it39s-not_2">What it is; what it’s not <a class="head_anchor" href="#what-it-is-what-it39s-not_2">#</a>
</h2>
<ul>
<li>Mooch is a name that Chris suggested one day after coming off the Metrolink. Whether we keep it or not, that depends on brand direction in the upcoming sprints.</li>
<li>We chose to make it using web technologies because it gives us what we want at this stage, but in a state were we could constantly mould it.</li>
<li>It’s not a ‘big launch’. We’re going to attempt to scale-up its user impact on each sprint.</li>
<li>Most importantly, this isn’t <em>the product</em>, but more the concept we have engrained in our heads from the past 12 months. We haven’t even fully discussed what we’ll be up to next year, because we’ve formed a common vision that we can pick ‘bits’ from and grow some products.</li>
</ul>
<hr>
<h2 id="our-retrospective-notes_2">Our retrospective notes <a class="head_anchor" href="#our-retrospective-notes_2">#</a>
</h2>
<p>Today, we had a retrospective. We decided to give you a glimpse into our own conversations, by summarising what we want to change next time (this list was spawned from a fails/wins session.)</p>
<ul>
<li>We want to have more boilerplates for prototyping. One click Framer.js kind of thing.</li>
<li>We want to put more product responsibility at prototyping stages, to steer away from any dictation from within a visual editor like Sketch.</li>
<li>We need a new router. BT Home Hub’s don’t cut it when you’re working in a development environment with static IPs and custom DNS settings.</li>
<li>We want to focus on unified setup. Make sure every maker knows one machine from another.</li>
<li>We’re going to set an alarm for a ‘mini-meet’ at the end of each day. (We don’t actually stand-up or scrum because we’re too lazy.)</li>
<li>On that note, we’re going to buy some bean bags, so we can get away from our desks during mini-meets.</li>
<li>We want to use a ‘thought-box’ style workflow. Each maker has their own little Trello column, where they store pending thoughts, ready to be pruned at the end of each day.</li>
<li>Always have the mindset creating ‘Inception’ cycles during sprints. Before each feature, check we’re doing it in the shortest method possible to achieve validation on it.</li>
<li>Use a JavaScript style guide, because Chris and Joe write JS quite differently.</li>
<li>We should use the app more ourselves, and talk to people who we match with to ask for feedback.</li>
<li>BE MORE MICRO-SERVICE ARCHITECTURE.</li>
<li>Standalone iOS web apps have some extremely curious bugs. We’ll probably opt for PhoneGap next time we want to write some web app JS.</li>
</ul>
<hr>
<h2 id="holiday-time_2">Holiday time <a class="head_anchor" href="#holiday-time_2">#</a>
</h2>
<p>We’re off to drink wine and eat cheese on crackers. All the good stuff. In the meantime, we’ll be having a good think about our next sprint. (We’re actually doing that right now, but when it’s just after a Xmas party, things aren’t at full pelt, yet.)</p>
<p>Have a good Christmas everyone.</p>
tag:joecritchley.svbtle.com,2014:Post/the-throttle-project2013-12-12T15:16:27-08:002013-12-12T15:16:27-08:00The Throttle Project<h2 id="an-intervention-for-the-pace-of-written-conte_2">An intervention for the pace of written content, inspired by <a href="http://theslowweb.com/">The Slow Web</a>. <a class="head_anchor" href="#an-intervention-for-the-pace-of-written-conte_2">#</a>
</h2>
<p><em>Imagine if we knew when to expect written media to be delivered and consumed. What if we shared a common period of time each week, where we spread the word and exchanged feedback?</em></p>
<p>Frankly, I can’t keep track of the sheer amount of written media broadcasted in my network. It floods my social feeds on a constant basis.</p>
<ul>
<li>Product releases</li>
<li>Product reviews</li>
<li>Life-changing advice</li>
<li>Strong opinions on techniques</li>
<li>Long-form articles</li>
</ul>
<p>We feel obliged to consume this kind of content as often as possible, and to spread it through our porous networks. But we need to take our passion for it, and look into a more sustainable delivery mechanism.</p>
<p>A couple of services try to tackle a similar issue — there’s Buffer, Read It Later, RSS — but these only solve the issue on a personal level. Social services (mainly Twitter) are still saturated. So, even if you are going to “read it later”, it still appears in your social feed, and takes up valuable mind-space at that initial point.</p>
<p>I enjoy the pace of other forms of mass media and entertainment. Knowing that music and films normally get released on a Friday or Monday is a warm feeling. You can easily integrate this into your schedule. You might not necessarily be able to consume the content straight away, but at least you know when to <em>not</em> look for it.</p>
<h2 id="where-to-begin_2">Where to begin? <a class="head_anchor" href="#where-to-begin_2">#</a>
</h2>
<p>Right now, I believe that setting aside a time period each week to exchange this content within our communities could be a solution to this issue.</p>
<p>I <em>could</em> be specific right now, by proposing a weekday for everyone. But that wouldn’t be based on any real user insight for the concept. I’m more interested in the following:</p>
<ul>
<li>Do you agree that it’s a problem?</li>
<li>What kind of industries are you involved with?</li>
<li>Is choosing a day a good approach?</li>
</ul>
<p>I’ll leave you with two things:</p>
<ul>
<li>A hashtag: <a href="https://twitter.com/search?q=thethrottleproject&f=realtime">#TheThrottleProject</a>
</li>
<li>And a conversation on Branch: <a href="http://branch.com/b/the-throttle-project">http://branch.com/b/the-throttle-project</a>
</li>
</ul>
<p>Let’s see if anything happens.</p>
tag:joecritchley.svbtle.com,2014:Post/bring-back-the-baseline2013-10-06T11:01:53-07:002013-10-06T11:01:53-07:00Bring back the baseline<p>Here is an explained technique we use at <a href="http://twitter.com/strobedigital">Strobe</a> to bring the baseline to web typography.</p>
<hr>
<h2 id="situation_2">Situation <a class="head_anchor" href="#situation_2">#</a>
</h2><blockquote class="short">
<p>An awkward invisible fence that surrounds our elements, stunting vertical rhythm.</p>
</blockquote>
<p>The web’s box model doesn’t support baselines for vertical measurement between other objects.</p>
<p><img src="http://f.cl.ly/items/0b1v3s0f2N1x282F0X1F/before.png" alt="Awkward spacing"></p>
<p>When inspecting an element, you’ll notice a certain amount of dead space that we can’t control. (See the space around the text in the blue highlighted area above.) This is caused by a combination of cap height, descender height and line-height artefacts. This is an awkward invisible fence that surrounds our elements, stunting vertical rhythm.</p>
<h3 id="in-print_3">In print <a class="head_anchor" href="#in-print_3">#</a>
</h3>
<p>Print designers use baselines to embrace a natural vertical rhythm. After all, it’s the centrepiece of typographic elements. But this is because the option is there, within InDesign for example, to perform this kind of measurement.</p>
<h3 id="our-task_3">Our task <a class="head_anchor" href="#our-task_3">#</a>
</h3>
<p>In a recent project, the fantastic <a href="http://www.area17.com">AREA 17</a>, a design agency in New York & Paris, presented a flat visual to Strobe which utilised the baseline heavily. We were tasked to build this. However, the last thing we wanted to do was scatter ‘magic numbers’ all over the place.</p>
<hr>
<h2 id="solution_2">Solution <a class="head_anchor" href="#solution_2">#</a>
</h2>
<p><strong>So we came up with a solution that has the effect of a flowing baseline.</strong></p>
<pre><code class="prettyprint">p { font: 1em/1.5 sans-serif; }
p:before, p:after { content: ''; display: block; }
p:before { margin-top: -1.08em; }
p:after { height: 1px; margin-top: -0.41em; }
</code></pre>
<p>Utilising pseudo elements, we can essentially push the paragraph element out of its container. This has the following effect on the box model:</p>
<p><img src="http://f.cl.ly/items/1g002n1w3c0X2x1L2Y1y/after.png" alt="New example"></p>
<hr>
<h2 id="demo_2">Demo <a class="head_anchor" href="#demo_2">#</a>
</h2>
<p><strong><a href="http://codepen.io/joecritch/pen/ldxAv">View demo</a></strong></p>
<p>In this demo, you’ll see how multiple columns work, how we can support lists, and how relative font sizing works.</p>
<p><strong>Note:</strong> When working with relative units, it will occasionally round incorrectly, and the baseline will be out by 1 pixel. It seems to be down to the browser, but if anyone can propose a fix for this, awesome!</p>
<hr>
<h2 id="conclusion_2">Conclusion <a class="head_anchor" href="#conclusion_2">#</a>
</h2>
<p>We’ve used this on a few projects now, and we’ve started to employ native baseline measurements at design stage. It’s massively exciting, and it feels like the correct way to measure.</p>
<p>It’s not <em>perfect</em>, such as the 1 pixel issue above, but we think it’s worth using it in most cases.</p>
<p>Let us know what you create with your newly found baseline.</p>
tag:joecritchley.svbtle.com,2014:Post/kill-the-icon2013-10-03T13:41:32-07:002013-10-03T13:41:32-07:00Could we kill the icon?<p>Moving away from abstracted & physical representations, and more towards our digitally native environment.</p>
<p>When it comes to user interfaces, I don’t care too much for the concept of <em>skeuomorphism</em> anymore. It’s become too ambiguous, and the conversations surrounding the term tend to focus on textural skins and theatrical graphics.</p>
<p>But ever since Apple released their latest major revision of their mobile OS, now that we’re starting to lose those textures, I’ve become obsessed with the idea the <strong>abstraction</strong> and <strong>influence</strong> on the interface. I posted the question on Twitter:</p>
<blockquote class="short">
<p><em>“How would user interfaces look if we had no preconception of their analogies? No magnifying glasses for search; no cogs for settings.”</em></p>
</blockquote>
<p>And then, with that tweet, I realised I had unintentionally focused on icons. It’s icons that are <em>still</em> the problem. Even now, while the digital space is becoming more native, the icons still sit there… out of place.</p>
<p>I’ve read <a href="http://connortomas.com/2013/04/in-defence-of-the-floppy-disk-save-symbol/">other people’s comments</a> about how the floppy disk icon is a good thing. Seriously? Think about it. That’s holding onto the past; and providing a lack of recognition for young people, who will literally have no idea what one is.</p>
<p>So I started sketching. </p>
<p><img src="http://f.cl.ly/items/2v1V1b2e3D2s0S0h0M0o/photo-3.jpg" alt="Sketch of icons"></p>
<p>And then I started categorising.</p>
<hr>
<h2 id="warning-pointless-contrived-categorisation-ah_2">Warning: pointless, contrived categorisation ahead. <a class="head_anchor" href="#warning-pointless-contrived-categorisation-ah_2">#</a>
</h2><h3 id="metaphors_3">Metaphors <a class="head_anchor" href="#metaphors_3">#</a>
</h3>
<p><em>Home, Settings, Tools, Search, Favourite</em></p>
<p>These are icons that we’ve decided to associate loosely with our digital world. As an icon, they have a slightly different meaning when applied to a UI, as opposed to the physical world.</p>
<h3 id="predecessors_3">Predecessors <a class="head_anchor" href="#predecessors_3">#</a>
</h3>
<p><em>Video camera, Phone, Floppy disk, Calendar</em></p>
<p>These are products that have provided a very similar purpose to the pure digital form that’s available on unified products of today (e.g. mobile phones).</p>
<h3 id="internals_3">Internals <a class="head_anchor" href="#internals_3">#</a>
</h3>
<p><em>#Hashtags, @Mentions</em></p>
<p>Apps like Twitter have started to create their own internal iconology. This utilised recognition of their core content, and applies it to the UI.</p>
<h3 id="conventionals_3">Conventionals <a class="head_anchor" href="#conventionals_3">#</a>
</h3>
<p><em>Reply, Share, Reload</em></p>
<p>These are the evolved version of internal icons; ones that have become highly recognised and conventional, making their way from old browsers, to modern iOS apps.</p>
<hr>
<h2 id="ok-let39s-stop-there_2">Ok, let’s stop there. <a class="head_anchor" href="#ok-let39s-stop-there_2">#</a>
</h2>
<p>There’s probably more (such as how we perceive drawing the silhouette of a human, and expect people to know its various meanings each time). But that’s not where my thoughts are right now. Instead, this soon made me realise how all of these categories are abstractions the UI itself.</p>
<hr>
<h2 id="so-could-we-kill-the-icon_2">So, could we kill the icon? <a class="head_anchor" href="#so-could-we-kill-the-icon_2">#</a>
</h2>
<p>We have modern tech, such as multi-touch, at our fingertips, for users to gesturally provide their own “icons”; we have three-dimensional, fluid graphics, to provide an environment; and then we also have the power of language provide semantics. Maybe we don’t need a symbol to tell us what something is about to do.</p>
<p>Imagine letting go of the Xerox-inspired GUIs altogether. Imagine a native digital medium, instead of holding onto physical entities. It’s not going to be easy; but it will be the future of the UI. </p>
<p><strong>Contextually aware, transparent user interfaces</strong> is what we should strive for.</p>
tag:joecritchley.svbtle.com,2014:Post/duties2013-09-29T13:51:20-07:002013-09-29T13:51:20-07:00Duties<h2 id="defining-ourselves-not-so-industrially_2">Defining ourselves not so industrially <a class="head_anchor" href="#defining-ourselves-not-so-industrially_2">#</a>
</h2>
<p>I’ve just got back from <a href="http://www.frontendlondon.co.uk">FEL One Day</a>, a new mini-conference, hosted by <a href="http://www.madebymany.co.uk">Made by Many</a>. As well as me being one of the speakers, we got to enjoy seven well-crafted talks. A thoroughly good show.</p>
<p>One of the talks, by <a href="https://twitter.com/jongold">Jon Gold</a>, developed the discussion about our job titles in the Internet, Software and Design industries. This got a lot of attention from the audience during Q&A: with suggestions from people who have coined the term <em>polymaker</em>; as well as a general consensus that reusing <em>creative technologist</em> in the new-age tech startup world may actually be a good idea.</p>
<p>But Jon’s talk also touched the idea that our titles overshadow our duties. I think it’ll always be hard to find that one true job title. And maybe that’s fine. Maybe we can describe what we do and why we do it, and leave it there. After all, that has more heart than a job title by itself.</p>
<p>Furthermore, if you provide a multi-layered service to your clients, then choose a suitable sub-line for that particular direction of service. For instance, <em>front-end development</em> might be suitable for a client who’s wanting to grow a solid JavaScript codebase; but <em>UI development</em> might be a better fit for the more visually architected projects.</p>
<p>Our aura as makers in these industries will still exist without job titles, and, possibly, will be even brighter still.</p>
<p>I think, at least at <a href="http://www.strobedigital.com">Strobe</a>, we’ll be winding down on job titles, and focusing on our duties.</p>