August 20, 2016 - 2 comments

Working in the heart of the San Francisco startup scene

So I'm working in San Francisco temporarily, for a tech startup (what else?), who operate out of the WeWork building in Civic Center SF. I'm pretty impressed with the WeWork CoWorking Space, I really think it contributes to generating the vibe and success of its startups. In order to inform and inspire other cities, and particularly Barcelona (my adopted city) I write this post with some details about what it is like working in an SF startup environment.

Read more

April 9, 2016 - No Comments!

Quick Job Board with React Native

Part three of my “quick job board” series, this time for React Native — and deployable on mobile devices. This follows on from “quick job board in 48 lines of code” with Meteor, and the “quick job board with meteor and React” version.

The beautiful thing about React is the syntax and structure is very similar, regardless of platform — so the React Native for devices code is very similar to any web based version.

For this app we have 2 files: Index and Results. The app is only a single feed on one page, but I have broken the App into two components to keep the “pages” in separate files (as well as being better practice).

So, after installing React Native on your Mac and creating a blank app, Let’s create the index file:

index.ios.js

‘use strict’;
import React, {
 AppRegistry,
 Component,
 StyleSheet
} from ‘react-native’;

First we import the modules of React Native that we are going to use (above). Then we will "import" our Results page (below). The Results page we will create later.

var Results = require('./Results');

The index page is used simply as a navigation stack container. Our app only has one page, so this is fairly simple. We use React and NavigatorIOS as our "router": we give the page a title and set the contents (component) as our Results page (the one we imported above).

class jblyrn extends Component {
 render() {
  return (
   <React.NavigatorIOS
     style={styles.container}
     initialRoute={{
      title: 'Github',
      component: Results,
     }}/>
  );
 }
}

Now two small things are left on our Index page. We add a small amount of style to the page, to use Flexbox mainly, and we register our React app to the App Registry so that  xCode can compile it.

var styles = React.StyleSheet.create({
 container: {
 flex: 1
 }
});
AppRegistry.registerComponent('jblyrn', () => jblyrn);

Easy, no? Now let's build our job results page. Create a file called Results.js.  This is little more complex.

Results.js

First, we need access to the React components that we need, the same as we called above except we need a few extra modules this time:

'use strict';
import React, {
 AppRegistry,
 Component,
 StyleSheet,
 Text,
 View,
 ListView,
 TouchableHighlight,
 LinkingIOS
} from 'react-native';

We will use the Github jobs board again as our supplier. For now we will just set the URL to be fetched by our code later.

var REQUEST_URL = "https://jobs.github.com/positions.json";

Now we start to write our component. First the class and constructor:

class Results extends Component {
 constructor(props) {
  super(props);
  this.state = {
   dataSource: new ListView.DataSource({
   rowHasChanged: (row1, row2) => row1 !== row2
   }),
  loaded: false,
 };
}

With the contructor we are setting the initial state of the component, i.e. that the data hasn't yet loaded, for example. And we also set the datasource and type, which we will fill with data later.

Now we fetch our data. This could be written in one module, but I like to keep things separate.

componentDidMount() {
 this.fetchData();
 }
fetchData() {
 fetch(REQUEST_URL)
  .then((response) => response.json())
  .then((responseData) => {
  console.log(responseData)
  this.setState({
   dataSource: this.state.dataSource.cloneWithRows(responseData),
   loaded: true,
  });
 })
 .done();
}

The first method calls fetchData when the component has mounted, this is important. The fetchData() method then will use fetch API (More info here about this). All it does is call the Github API url we set above, parses the JSON response and places it in the dataSource variables we set in the Constructor, which will automagically create our Listview of jobs using the iOS Listview component. Magic! We also set the loaded state to true, because now we do have our data.

So, in order to let users know we are actually loading data, and the app hasn't crashed, we use a small method which shows a loading icon while the data is being fetched, and is triggered by our constructor "loaded" variable. For now just define these "renderings", which are called in turn in the main React.render method at the end.

renderLoadingView() {
 return (
  <View style={styles.container}>
   <Text>
    Loading Jobs...
   </Text>
  </View>
 );
}

Now we must also prepare the View template for each Job listing that is returned from Github, and will be placed in our Listview:

renderJobs(job) {
 return (
  <TouchableHighlight onPress={() => { LinkingIOS.openURL(job.url); }}>
   <View style={styles.container}>
    <Text style={styles.title}>
     {job.title}
    </Text>
    <Text style={styles.location}>
     {job.company} - {job.location}
    </Text>
   </View>
  </TouchableHighlight>
 );
}

This method makes use of various React components that will translate into Native ones. You can look up these React components with the Native link I pasted earlier, but briefly: Touchable highlight is a link, the web equivalent of the <a> tag; the View tag is the equivalent of the web <div> (a container) and Text might roughly translate to <span>, I guess - We can't say the coding world doesn't keep us on our toes!

The elements in curly braces are references to our styles component that applies the "css" to the view: eg. styles.container will refer to the styles object we define at the end. React uses objects to hold styling data. And the second type of data in our curly braces are the job list results: eg. job.title. Job is the object Github return to us. You can see what Github returns to us from their page here

Now we can pull the awaiting render methods together in the main method: When the data has loaded we call the ListView component (otherwise we show the "loading" component) and we pass to it the datasource, the Jobs View object we created and the stylings as "props", thusly:

render() 
 if(!this.state.loaded) {
  return this.renderLoadingView();
 }
 return (
  <ListView
   dataSource={this.state.dataSource}
   renderRow={this.renderJobs}
   style={styles.listView}
  />
 );
}

After that all that is left is to apply the styles, and export the Results component so that the Index page can reference it.

const styles = StyleSheet.create({
 container: {
 flex: 1,
 justifyContent: 'center',
 alignItems: 'center',
 backgroundColor: '#F5FCFF',
 paddingBottom: 30,
 paddingTop: 30,
 borderBottomWidth: 1,
 borderBottomColor: '#eee',
 borderStyle: 'solid'
 },
 title: {
 fontSize: 20,
 textAlign: 'center',
 margin: 10,
 },
 location: {
 textAlign: 'center',
 color: '#999'
 },
 listView: {
 paddingTop: 20,
 backgroundColor: '#F5FCFF',
 },
});
module.exports = Results;

You will need to compile this in xCode and run. You can even run it on your own device if you have an Apple developer account and watch the magic.

As before if you really have any problems, you can ping me - or - you can pull my repo. Sharing code is caring, er.. code.

Onwards, to React Desktop...

March 18, 2016 - No Comments!

UX Talk: Psychology in Experience Design

UX is focussed on user needs. And to discover user needs, we run through a “discovery” phase. But, what if people don’t know their needs? Or the needs discovered are distracted, irrelevant or not deep enough to really satisfy the designer.

A good experience designer wants to seek out deep motivations: Motivations that oftentimes the users themselves do not acknowledge. This is where experience design, for me, encroaches the territory of psychology.

My ultimate goal as an experience designer is to design experiences that enable the user to grow, to realise themselves: This requires that I know what the user desires, what their dreams are — what they want to become.

As psychologists know, desires are often buried in the subconscious, actively blocked by the conscious mind. So how can an experience designer uncover people’s deepest desires and make them a reality? Will experience designers need a degree in psychology?

Steve Jobs famously stated: “People don’t know what they want until you show it to them”.

Do good filmmakers “get out of the building” and ask their audience what they want to watch? Sure, there are industries that create products according to market research. But are these the really great products? Are films designed by committee the really great movies of all time?

I’ll research this and make another post.

originally posted on my Medium account

February 11, 2016 - No Comments!

How to do good without an effort

A friend of mine recently sent an email round with a list of links and plugins that allow us to "do good" via charitable plugins and tools, without any effort. Plugins like AdBlock for Good, and Tabs for a Cause which show ads that donate to charities.  Here in this post I dutifully repost this veritable goldmine of goodness. Please partake, and share with your friends.

Read more

January 20, 2016 - No Comments!

Why I learned to code

Imagine walking into a library and not being able to read. That is how I felt to be living in this age of information and data without being able to code. Data is everywhere, hence information is everywhere.

I work in tech, and as such I am privy to common knowledge (in the tech world) that many people are not aware of. Do you know I could reach out (into the internet) and pull together a very decent profile of everyone who is/has been in my vicinity with relative ease? People who “check-in”, or post messages using Geo-location on their phone, for example, are fair game online. A cross reference here and there and I have a decent file on you. Especially if you have a unique identifier (like a telephone number).

Snooping is of very little interest to me. But I do like the idea of being able to use code to gather information and empower me to make decisions. Small scripts (of code) — which can even be considered simple robots — are not difficult to create and can run a whole slew of boring tasks for you: searching for an apartment, ordering regular deliveries and so on. And once the Fridge starts to join the conversation, being able to “boss” my appliances around makes code even more appealing. (Right now, my Fridge is deaf and mute, but soon, oh so soon…)

I decided that code is important and learned to code. Except, like any language, it’s difficult to become “fluent”. It requires constant practice. So, I continue to study, and write minimal scripts, and sharpen my fluency, as I wait for the day when I find writing code as easy as writing these sentences, and I watch the world turn around me, and I say “wow, did I really make that happen?”.

First published on my Medium account.

November 29, 2015 - 2 comments

A quick job board with React, Meteor and Material UI

I recently wrote a mini-tutorial "How to write a job app in 48 lines of code" - and here it is again, but using React JS: Facebook's javascript love-child. This is slightly longer than 48 lines of code, but mainly because I also integrated a Material UI interface. I actually learned React to be able to use this UI library. React is not strictly necessary with the Meteor framework, as Meteor is reactive out-of-the-box - but I like Google's Material UI style, and it required React, so here we are.

Read more

September 9, 2015 - No Comments!

State of Workflow

What is my current workflow? I'm still working on it, but my target is for a neat I/O process - input - process - output. Currently, I'm following the GTD methodology of New, Next and Someday. I try to apply it to most things at varying levels of abstraction. i.e. My research, idea processing, planning and development all follow the same method.

Read more

September 9, 2015 - No Comments!

Automating all the things

Everybody has heard Facebook's mantra "Move fast and break things". Some people might even subscribe to it. The more time I spend moving fast, the more I realise I cannot move fast enough by myself. I've spent plenty of time sharpening my point to point computer control, and I've spent time organising my workflow so that I can move close to the "flow" of ideas to execution. The process is ongoing, and I'm pretty quick now (compared to how I used to be), and getting quicker. But it's still not enough. I need help.

Enter IFTTT or Zapier, Alfred2, and Workflow (iOS).

Read more

I'll state it here for the record: the businesses that build the "best" developer onboarding programs are those who will succeed in internet 3.0 - Derry Birkett

#fortherecord

All the internet 3.0 is belong to developers, #

September 1, 2015 - No Comments!

Early morning research links

Hyperlinks - love 'em or hate 'em - they are there. I wake up early trying to build something, and find even more awesome things to make even more awesome in my new product (whatever that will be).  Here are this morning's links. I might call these: Links with the Lark. Ahem.

Read more

August 5, 2015 - No Comments!

Today’s web tech roundup

Hello. Today I was chatting with a developer friend about - well, developer tech. Sometimes you just don't realise you've found dev link gold until someone else isn't aware of them. So I passed him some links, and I paste them here too - for all my developer friends out there.

Read more

August 4, 2015 - No Comments!

How I use Tasklist products

I use a variety of task lists every day. Many people might want to use only one app for all their tasks - but I've found it to be unrealistic, and possibly impractical. I've become comfortable using various different platforms to manage my different activities: some work better than others. Here is my low-down.

Read more

July 23, 2015 - No Comments!

UX is the result of design

I read an awesome post today from honest people who really get it, and the following quote from it sums up the difference between UI and UX that many people still do not get:

great design is more than pretty pixels. Great design is more than the neat gradients of your header or even the fancy animations of your hamburger menu. Great design is about the experience. It’s about how people interact with the stuff you’ve built and whether it actually helps people achieve their goals or not. As a community we are shifting toward this paradigm and as we explored this we realized that there will be lots of important roles to play as this shift occurs.

As Steve Jobs famously said:

Design is how it works

I still talk with founders and consultants who think I'd be a great UX hire because they like my "style". My "style" (graphic style, I infer) has nothing to do with UX. This is when I worry about taking the job. Read more

July 9, 2015 - No Comments!

Some Material Design Front-end Framework Options

I've been researching front-end frameworks based on Google's Material Design guidelines. I post here the most popular and developed I've found. At the moment they all seem to be in varying stages of advancement, with none a clear out-and-out leader (as Twitter's Bootstrap has become for example), and it is interesting to note how each framework owner interprets the defined guidelines that Material design recommends.  Here is a short summary.

Read more

"work on highly functional systems that are pragmatic and solve real problems for real users" - Teehan & Lax

 

Mission, #

June 19, 2015 - No Comments!

Two of my favourite web engineering projects

I opened my Prismatic feed today to find it closed, and replaced with investor bumpf. Not the best start of the day - but I went on to uncover their blog and I liked how open they are about their API development - so I'm adding them to my favourite engineering blog projects: I like intelligent projects where engineering and design go hand-in-hand. My other favourite design/engineering project is Artsy.net. I paste the links to their interesting stuff inside this post.

Read more

June 15, 2015 - No Comments!

Plain text is the best UX

As a UX designer I've evolved to understand that plain text, simple, humble text is the greatest possible user interface (yes, greater than voice - probably not so great as telepathy). Plain text, plain words, carefully constructed if possible - rich in vocabulary, and clear in intent is purest communication.

Read more

June 9, 2015 - No Comments!

How I use my computer

I'm a mac power user - which basically means I use the keyboard a lot and have optimised my workflow using tools I researched to get things done as quickly as possible without losing my "flow". I'm still working on this process, but here's how I am currently doing.

Read more