(Another day, another bit of terminology made up by me.)

“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.

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.

This is currently a one-time experiment. It is an extension of the ReactLayeredMixin 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 document.getElementById(this.props.portal)

It’s actually quite similar to yield[:whatever] in Ruby on Rails views and layouts.

Warning: this will probably only...

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.

Disposability vs. Maintainability

I’ve been inspired by Ryan Florence saying such a thing. 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.

Foxcatcher

How did this film slip under my radar? I can’t wait to see it. You should check the video clip on IMDB, and be mesmerised by Steve Carrell’s performance. Apparently people at Cannes were loving it.

The Kids Are All Right

I seem to be on a film-a-night during the week lately. One of the more recent movies was The Kids Are All Right. If you haven’t seen it yet, here’s what you should do: watch it, then watch the trailer afterwards...

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.

React: Controllable components

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—https://github.com/matthewwithanm/react-controllables. It provides the best of both worlds for this situation.

React: Immutability helpers

On a current React project, I need the ability to not re-render a component...

As a believer of Facebook React’s principles, here’s an explanation of how React handles transclusion, and how it can be improved.

What is transclusion?

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.

Basic transclusion in React

React is able to handle basic transclusion out of the box using the this.props.children property, which is an array of all components that have been declared directly inside of the current component, like so:

var MyExample = React.createClass({
  displayName: 'MyExample',
  render: function() { 
    return (MyComponent(null, 
        React.DOM.p(null, "This paragraph is transcluded into MyComponent.")
    ));
  }
});

As you can see, the specific rendered position of the...

Strobe have just come out of — approximately — a 4-week sprint to produce a very rough social web app. Mooch (trymooch.com) 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.

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.

Where did it come from?

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.

Then, in the spring/summer of 2013, we dropped our client capacity slightly, to make room for...

An intervention for the pace of written content, inspired by The Slow Web

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?

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.

• Product releases
• Product reviews
• Life-changing advice
• Strong opinions on techniques
• Long-form articles

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.

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...

Here is an explained technique we use at Strobe to bring the baseline to web typography.

Situation

An awkward invisible fence that surrounds our elements, stunting vertical rhythm.

The web’s box model doesn’t support baselines for vertical measurement between other objects.

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.

In print

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.

Our task

In a recent...

Moving away from abstracted & physical representations, and more towards our digitally native environment.

When it comes to user interfaces, I don’t care too much for the concept of skeuomorphism anymore. It’s become too ambiguous, and the conversations surrounding the term tend to focus on textural skins and theatrical graphics.

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 abstraction and influence on the interface. I posted the question on Twitter:

“How would user interfaces look if we had no preconception of their analogies? No magnifying glasses for search; no cogs for settings.”

And then, with that tweet, I realised I had unintentionally focused on icons. It’s icons that are still the problem. Even now, while the digital space is becoming more native, the...

Defining ourselves not so industrially

I’ve just got back from FEL One Day, a new mini-conference, hosted by Made by Many. As well as me being one of the speakers, we got to enjoy seven well-crafted talks. A thoroughly good show.

One of the talks, by Jon Gold, 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 polymaker; as well as a general consensus that reusing creative technologist in the new-age tech startup world may actually be a good idea.

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...