Method of Action

our blog!

Learning made enjoyable

Method of Action is peer to peer education for people who want to get things done. Learn by doing, participating and teaching.

Getting pre-launch traction with web games

by Mark on April 9, 2012 9:57 PM on Advice

The path travelled between an idea and a minimum viable product is often ruthless. Depending on the scope of your project, it takes between a couple of weeks and a couple of years to get anything out of the door. Few people possess the focus and determination required to get-to-launch, and I'm certainly not one of them. I have a graveyard of half baked ideas littering my hard drive, but Method of Action was something that I really wanted to deliver, so I knew I had to set some intermediate checkpoints before launching our own product.

I often describe Method of Action as an intersection between Codecademy and Project Euler, but for design. Every course has a series of challenges that you must achieve to complete the course. Most of the challenges are simple design tasks such as design a newsletter, or design a blog post, but some of the challenges are games that require you to achieve a minimum score.

Even though I set out the games as mini-launches that would help us maintain high spirits, their success caught me by surprise. Never in my wildest dreams I had imagined I'd have 20,000+ people to be notified when we launched, or 9,000 followers on Twitter. So I'm writing this out for fellow entrepreneurs who might want to take this approach for pre or post-launch marketing.

As a sidenote, I have a profound dislike for telling others what to do. Every startup has it's own specific limitations, be it funding, location, market or talent. Your best course-of-action depends on your constraints. Please read this from where it comes: a two person bootstrapped team in the middle of nowhere where the only word-of-mouth marketing is going to come from what we do ourselves. The games are also part of our product, so even if we launch an unsuccessful game we are working towards the completion of our product.

KernType

kernscreen.png

KernType was our first and most successful game. It received more than 625,000 uniques in its first two weeks:

kerntype-uniques.png

It was featured by some big names like Salon, Kottke, FastCo, BoingBoing and Computer Arts. This might seem like the brunt of the traffic, but if you actually look at the referrers, big name blogs don't send that much traffic. Most of it comes from people sharing it on Twitter and Facebook.

kerntype-referrals.png

To promote it we posted it on Hacker News and Reddit, and it quickly made it to the front-page of each site. From there it took life on its own.

A nice surprise was a site I had never heard about: Design Made in Germany. Fortunately they are not too strict about the Made in Germany part, because KernType was actually made in Cancún.

KernType took about two weeks part time to program. I am a terrible programmer and I'm sure any decent front-end programmer could have done it in half the time. Even though I used the Raphael library to get it done (which provides a single API for SVG and VML, which older versions of IE support), I just didn't know how to get around some issues with Internet Explorer 8 and below, so I released it as a modern-browser game.

Funnily enough, I didn't receive a single complaint about IE, but Android users were very vocal about their disappointment because older versions of Android don't support SVG.

ShapeType

shapetyper.png

We were high on the success of KernType, so trying to take advantage of the momentum I quickly mocked up a new game where you control bezier curves to match the shape of a letter. We released it three weeks after KernType and promptly posted it to Reddit and Hacker News. Both tanked.

shapetype-uniques.png

Fortunately it still took life on it's own, and it was a moderate success on it's own right. It had 300,000 uniques in little over two weeks, the big surprise now being StumbleUpon and Dirty.ru.

shapetype-referrals.png

ShapeType took about one week to program. Even though it was more challenging than KernType I had gained fluency in Javascript, but my knowledge about geometry wasn't up to par and I had to spend a lot of time learning about bezier curves and I struggled mightily with simple stuff like the Pythagoras Theorem.

Color

colorsc.png

We took a break from games for some time in order to focus on the actual product, it would give me time to think about the next game. We wanted to create something that unrelated with typography, so I brainstormed a bit with my co-founder (and partner) about our next step. We settled on a game of color.

color-uniques.png

Again, we posted it to Reddit and Hacker News where it quickly gained steam and went viral again. It had nearly 400,000 uniques in two weeks, this time the surprise came from Tumblr, which had even more referrals than Twitter.

color-referrals.png

Color burned me out a bit. We had mocked up the game mechanics for an initial game, and after two weeks I had a pretty functional prototype. The problem was that it was incredibly boring. Our previous games gave the sensation of creation, even if you are just moving letters or nodes around you end up with a nice looking result. With our initial prototype you would just click on colors and get a score, it felt too much like a quiz.

We went back to the drawing board and made some one-day iterations on ideas, but they turned out either too difficult to implement or too subjective to be scored automatically. We settled on what is essentially a timed color picker with some cool features, such as colorblind assistance. This time I used D3 in addition to Raphael. It took me an additional two weeks to push this out of the door, so in total I used four weeks part-time to launch this game.

The aftermath

The job isn't finished once you release a game. There will be a couple of small bugs that often prove challenging to solve, or really good suggestions from users that we can't help but implement. I have learned to set aside at least a week of answering e-mails and fixing stuff once we release a game. Having your inbox flooded and your Twitter popping up with mentions is quite distracting.

We have also received emails from design educators telling us how convenient our games are for teaching design concepts, which is very encouraging as we know we are on the right path.

All in all, we have amassed more than 2.1 million unique visitors; 200K FB likes and 200K tweets and we are very pleased with the results.

total-uniques.png

The accumulated referrals are quite a sight, the amount of traffic that social media sends our way is just mind blowing, it dwarfs the accumulated traffic from aggregators, which come in at a distant second

total-referrals.png

We have 20,000 sign-ups for people to be notified when we launch. The conversion rate is a bit on the low side, but it is deliberate as we didn't want to push too hard on notifications. Method of Action will rely on community generated content, so the quality of our product depends on the quality of our users. I could have easily added a sign up form at the end of each game, but we linked to our landing page instead. By doing this we—hopefully—filter those truly interested learning about design.

What we did wrong

We discussed our last game too much before implementing it. I didn't realize it, but pitching a game is a tricky proposition. If you think about it, Tetris is a puzzle where you must accommodate colored blocks to form lines. Angry Birds is a game where you sling birds into blocks, which then collapse to crush pigs. Doesn't sound like too much fun.

There is no point in discussing how a game will work, unless it's very similar to an existing game. It is better to simply implement your idea as soon as you can and iterate from there.

From a SEO perspective, another mistake was putting the games in their own subdomains. I believe that self-standing content that doesn't share navigation or purpose is meant to have a different Top Level Domain, or if it's related but not within your main audience or purpose then it should reside in it's own subdomain. Domains such as store.diesel.com or developer.apple.com are good examples of this.

However our games are actually part of our product, so we should have used something such as http://method.ac/challenges/kerntype/. By not doing this we are missing out on a tremendous amount of PageRank.

How to create a successful game for your own product

Before Method of Action I used to create small games and quizzes for my personal blog (in Spanish). I'd read, for example, that people have trouble distinguishing people from a different race than their own, hence phrases like "all asians look alike". So I would gather some pictures off a yearbook and implement the experiment in the browser. You can find the experiment here (Flash SWF, in Spanish). At the very least people were engaged with the quizzes and the point made was very clear, even for the most uninterested users.

What I gathered out of these little exercises is that any kind of information asymmetry can be leveraged into a game. Anything that you know and I ignore can be transformed into a pleasant learning experience.

These are contrived examples, but I find them immensely more interesting than what big brands are doing today. They pay creative agencies tons of money for what is essentially a generic branded game that has little to do with their domain.

Show respect for your users

Edutainment has reputation as being boring, and for good reason. Most edutainment is mind-numbingly dull, and when you intersect edutainment with marketing it's a recipe for disaster. One brand of dog food had a game where you had a virtual dog, you could feed it chicken, chocolate, or their own dog food. If you made the wrong choice (you can guess what), the app would lecture you on why it was wrong.

Users don't want to be lectured, they want to be entertained. Even then, users hate wasting time. When I'm done playing a game I often feel remorse. I should have been doing more important stuff. When you throw education into the mix that feeling disappears because you are actually learning something.

You must also try to find the right difficulty level. I must confess we go by feeling, but it might be a good idea to test on a couple of users before releasing into the wild. A game that is too easy is a boring game, too challenging and your users feel annoyed.

Make it challenging for yourself

I have a developer friend from whom I learned one of the best lessons in programming: for every project you do, incorporate a technology or constraint which you haven't used before. For KernType it was CoffeeScript and full keyboard support, for ShapeType it was geometry and seeing if I could produce something attractive with an ugly color scheme (still unsure if I succeeded with this!), for Color it was D3 and color blind assistance.

Incorporating new constraints and technologies added the right amount of challenge to the projects, it made them interesting without being frustrating. I have learned a lot along the way.

If you are a programmer you might be surprised to learn that none of the games use Object Oriented Programming, at all. My mind was damaged by Basic decades ago, and my toolset only includes functions, loops and conditions. I'll make sure my next game uses OOP, even if this is not evident on the font-end it will hopefully improve my delivery times.

Every marketing approach burns out users

You might remember the time when apps used to be invite only, either because of real scaling concerns, policing on community quality, or just plain nasty artificial scarcity. It turned out to be a great marketing tool, people would give them out on their blogs, trade them in forums, or even sell them on eBay. Of course, that approach is now dead, and when I encounter one of these websites I promptly hit my back button.

Nowadays the craze is in the LaunchRock kind of invite: if you share it on Twitter and Facebook, you further along the queue. This approach worked for the first few startups to use it, but frankly users can only get so excited about a product that doesn't exist yet. I get exasperated every time some of this spam shows up on my timeline.

I'm sure that if many startups used the game approach to launch, interest would decrease. A well made game has value in itself, but time is a limited resource and novelty would wear off, making it a losing proposition.

In summary

Make it entertaining for others, and challenging for yourself. Don't lecture, entertain. Don't push too hard on promoting your product, let the context do the promotion.

Color, a color matching game

by Mark on January 24, 2012 10:56 AM on Design

Color is a new game for Method of Action.

colorsc.png

Probably the most interesting aspect of the game is the color blind assist. Each primary color is represented by a geometric shape, and the morph between the shapes represent intermediate colors. Try it out even if you don't have any color perception deficiency just to see how it works.

I will follow up with a post on how to choose a good color palette, check out how complementary, ternary and quaternary colors work because it's important in choosing a good palette.

Check out color - a color matching game

KernType, a game to practice your kerning

by Mark on October 9, 2011 10:17 PM on Design

KernType is a game that will help you understand letter spacing and kerning, custom made for Method of Action. Give it a spin, in a couple of days we will write an article on kerning which will explain the why's of kerning.

kernscreen.png

When Method of Action launches, you're going to need at least 90/100 to pass this mission, so get practicing!

Are developers better at predicting design outcomes?

by Mark on August 7, 2011 3:18 PM on Design

I like proving full feeds, but this post has some interactivity that won't work from a feed reader. Check out the post at Method of Action

A week ago I set out an experiment with the hypothesis that designers and developers (or any other profession, for that matter) are equally competent at predicting the comprehension of symbols. Wayfinding symbols are the real world equivalent to icons in user interfaces, and since there is much more research done on wayfinding, I used it to demonstrate my hypothesis.

The research comes from a long defunct German site (2007) called get2testing, which is available thanks to the Internet Web Archive. The author compiled the results from various peer reviewed studies from academic journals and standards organizations.

I don't want to ruin the experiment for you, so if you want to find out the results of the study, complete the test and the answer will be displayed. Your results won't count towards the total, but it's a fun as a game.

Keep on reading →

You're already a pretty good designer

by Mark on July 27, 2011 8:17 PM on Design

I'm a seasoned hacker that is able to tackle immensely complex problems with aplomb. I'm able to untangle spaghetti code and weave it into beautiful patterns. I envision systems and code them with the same grace a jazz pianist improvises music.

But I can't design for my life. Please help.

I've heard this story a couple of times in the ten years I've been working with programmers. Programming is a damn hard craft to learn. My mind is blown by the level of complexity software has achieved given the basic elements of programming—variables, conditions, loops, functions and objects. At times, it feels like you have a quarry, wood, rope, a saw, and a chisel and then an architect asks you to build a cathedral.

The programmers' approach to building a cathedral would involve using his tools and raw materials in order to build more advanced objects. Let's imagine the work of this craftsman: he'd grab some wood and stone in order to create a hammer, then he'd devise some pulleys to get rocks out of the quarry, he would build platforms and scaffolds to reach unaccessible places, he'd fabricate a crane to stack the stone, and so forth.

Our craftsman follows the architect's plans religiously, and painstakingly chisels every stone so that every brick fits in perfectly. He polishes the wood into a huge sculpted door that would accommodate God himself. The massive columns wouldn't fall in a thousand years.

Once finished, he steps back and mesmerized by the beauty of it all, he thinks 'Hey, I built this cathedral all by myself, perhaps if I tried designing my own cathedral I'd get all the praise, instead of this lazy hack who just handed me the layout and waited for it to be built'.

Of course, when a programmer first tries his own hand at designing, he will likely notice that it looks pretty clumsy, there are a couple of reasons for this, but—all in all—the odds are stacked in his favor. It is absolutely necessary to identify the shortcomings of the programmers' mindset in order to overcome these obstacles. Later on I'll detail what works out in his favor.

1. Being familiar with the implementation difficulty encourages compromises

I'm a designer by trade, I have a degree in Information Design. But—as often happens— ignorance instills confidence, and I jumped into programming expecting it to be a challenging hobby, but it actually sucks you in and you come out a different person. I'm not a competent programmer by any measure, but it is an activity I enjoy throughly. I've built memela.com entirely on my own, you can also see my portfolio. Here is my StackOverflow profile. The paradox of learning is that the field is just so huge that you must admit you're not able to master it in your entire lifetime.

When I first started programming, I'd start sketching a general idea on paper, and when I'd grow bored of it, I'd jump into Textmate and bang some code. Sometimes I'd encounter that a particular feature was difficult to implement, so I'd go back to my sketch and rework it so it was easier to implement, even if the user experience suffered in the process.

This, I think, is the biggest mistake programmers make when designing their own products. This is a form of technical debt that is incredibly expensive if done repeatedly, but it's very tempting when you've been struggling with a particular problem for some time.

Nowadays I separate the designing and programming phases completely. I start by sketching on paper, then create a pixel perfect mock-up and then I finally start programming. If there is something that I find hard to implement, I ask for help, making me a better programmer in the process.

The equivalent of our medieval craftsman would be noticing that the doors of the cathedral are a lot of work, so he replaces it with a standard sized door. Soon enough the cathedral is inaugurated and there's an unsurmountable bottleneck when the crowd tries to enter the cathedral.

2. Data modeling clouds your understanding of use cases and tasks

Nailing the data models is the hallmark of a competent software architect. It sets the foundation for clean, understandable code. Unfortunately, it also provides a data centric view of the entire project; and when the software architect designs the graphical interface, it looks a hell lot like the models with a CRUD interface slapped on.

Programmers get a lot of unjustified heat for designing these kind of interfaces. Very few people understand why data modeling shapes a very strong mental model of how the interface should work. This problem is often painfully obvious in backend administration systems, where the programmer is left on his own because designers are busy on the public side of the application. Often programmers rely on automated admin tools because—despite being a crucial component—clients don't want to pay for it.

The key to escaping mental model contamination is thinking in terms of use cases and tasks. Whereas duplication and redundancy are the bane of good data models, it often is the opposite for use cases. In some supermarkets you will find mayo next to the tuna, a cereal island next to the milk refrigerators, and Clamato next to vodka (as well as in the usual places). Let me use information where I need it, not where the data model dictates it should be.

3. Most design is written about and taught from the perspective of art

When I was younger I would ask people how to dance, they would often suggest to "feel the music". Once you feel the music you can start moving your body along with the rhythm, or so they said. "Just tell me how to move my feet and my arms", this would invariably turn out wrong, because I'd just flail my arms at my own pace. A sad spectacle that I'd prefer to forget.

It wasn't until the Rockstar type of games started coming out that I finally understood what they meant by feeling the rhythm. There is a bass that marks the predominant rhythm and some other instrument that marks a secondary rhythm. You pace a range of pre-defined movements to these instruments and boom, you're dancing half decently. But alas, this revelation came too late and I'm still a terrible dancer.

Perhaps you have already asked a designer where to get started with design. I'm pretty sure his advice was to observe things carefully, notice the details, copy things you like to understand how they work. This is good advice, but it's the same thing you would tell someone learning how to draw.

This is what I call art oriented advice and it's the same kind of advice I was being dispensed when I asked how to dance. It's useless to logical minds because when you like something you just don't know what you're supposed to be looking at. It comes naturally to people who have some art experience because they are used to observing proportion and balance.

People often make of design some sort commercial spawn of art. It is not. Design is a discipline in itself, related to engineering, that uses some of art's syntax (in the case of visual design). It is different from engineering in the sense that engineering looks after the efficiency and robustness the product, and design looks at the interaction between the product and a human being.

Now, let's get to the good stuff:

You are already a pretty good designer

If you have been programming for a number of years, you probably have very good design and architectural coding skills. These skills are connected to visual design at a high level of abstraction. The connections are so strong you can face off two masters of their own field and it will make sense to senior designers and programmers alike. In fact, I'm going to face Edsger Dijkstra against Charles Eames .

Design depends largely on constraints.
The ability of discerning high quality unavoidably implies the ability of identifying shortcomings.
Innovate as a last resort.
The competent programmer […] avoids clever tricks like the plague.
Who ever said that pleasure wasn't functional?
There should be no such thing as boring mathematics.

Everything you already know about design and architecture in programming can be applied readily to visual design, with few exceptions. The problem is that your skill set is domain specific. You don't have the bridge to apply what you know about software design into visual design.

You are already creative

Perhaps you have bought into the bullshit that creativity is a state of mind, an eureka moment that bursts into flash of brilliance to produce something that has never been done before.

I'd go as far as saying that the popular conception of creativity is actually harmful to good design, as it relies on established conventions in order to function. There is a time and moment to innovate, but it should never be done for innovation's sake.

Creativity is being able to create things. Objects that can be shown, discussed and built upon. In this sense programmers are much more creative than many so called creative professionals out there.

Your systematic mind can be used to your own advantage

One of the most difficult concepts to teach young aspiring designers is the ability to think in systems. If I requested a button in 99designs (without more context), people would jump at the chance of creating shiny realistic buttons. You probably know what is wrong with this scenario: you can't design a button without knowing how the rest of the design looks.

This is something that takes many years to mature in a designer, because the relationship between visual elements is not as obvious as it is in code. I'm not only talking about consistency, but the profound understanding that each element competes for attention, and that by making an unimportant element "shine" you are detracting from the rest of the elements.

You already have attention to detail

In a scale from 1 to 10, how sinful is choosing a poor name for a variable? Now, in the same scale, what number would you chose for code where every variable had an awkward name?

This is attention to detail. Knowing that the details make the product itself. I'm constantly amazed by the discipline of some programmers, their code is carefully formatted, comments are succinct, and the structure is evident by just looking at it.

So, how do you get started learning design?

Design education is quite different from other disciplines. It needs to be so, because design is concerned as much with skill acquisition as it is with knowledge acquisition. It is project oriented, because that is how design is professionally articulated. Design is not subjective, as people often say, it's meant to solve a problem, and the problem may have different solutions, some better than the others.

The actual structure of design education is centered around the design critique: the teacher explains some concepts, then asks his students to articulate something visual around those concepts adding some constraints, and then the final work is discussed as a group.

The actual critique mechanics are quite interesting. Every student lays their work on a large table, and the teacher will chose one, and ask other students what they think about it. At this point, authorship isn't important. It's likely the teacher and his peers don't know who made it. The objective is not criticizing the student, it's criticizing the piece of work. So a student volunteers an opinion, and the teacher validates it. After a small round of opinions, the teacher gives some insight and moves on to the next piece.

I've been thinking long and hard on how to replicate this experience online in a way that scales. I'll extend it to other disciplines, but the initial course will be on design for programmers. If you are interested sign up to be notified when we launch, or just follow our Twitter. We will be writing more on this blog about the relationship between design and programming. Keep tuned.

Update:

This got picked up by /r/programming. The course will be free, and here are the mechanics:

  1. There will be progressively more difficult missions. So you start by designing your own business card, then a logo, then a letterhead, and so on.
  2. You read the related content, so in the case of a business card you'd read on alignment, balance, typography and the specifics of business cards.
  3. You submit your mission for review, more experienced users decide if they approve or fail your mission. Approving missions gives you access to more difficult missions (i.e. designing an icon)
  4. Once you're advanced enough, the easiest way to gain access to the last missions will be reviewing the work of new users.
  5. I make money recommending related services. So, if you'd like to print your business cards online, I get a cut.

The racial performance gap explained

by Mark on July 26, 2011 10:23 PM on Education

In 1974 Phillip Uri Treisman, a calculus teacher at Berkeley, received the visit of two graduate students. The purpose of their visit was to videotape Prof. Treisman's class.

He had been rated as either one of the ten best or ten worst teachers in Berkeley, and he didn't know which. They wanted to study if other teachers could identify good teachers from the bad ones. Prof. Treisman couldn't know if he was in the top or bottom 10.

Prof. Treisman had been had been trying to get his students interested in Math through collaboration and creative problem solving, innovative techniques at the time. The students had met his experiments with certain reluctance: "is this going to be on the test?" they would ask. He had no idea if he was a good or a bad teacher.

Turns out he was one of the good ones, as he was given a grant to study why there was a performance gap in Black and Hispanic students. It was a problem that had been bothering some time, and he was willing to tackle it head on.

He would start by surveying his colleagues for possible hypothesis, and he found four widely-held beliefs:

  1. Minority students are not as motivated as other groups
  2. They come unprepared, as they often enter university with fewer credit hours of science and math.
  3. Their families lack a strong cultural and intellectual background, and thus lack understanding of the importance of higher education.
  4. That the income gap reflects on the educational gap, and if those variables are controlled there would be no performance gap.

All these beliefs sound reasonable, however, when they started looking at actual data, they noticed they were entirely wrong. Being an elite university, minority students, especially black students, had to make huge social sacrifices to be able to get accepted into Berkeley. Motivation was not the problem, it was disorientation.

They were also surprised to find that, among Black students, calculus grades correlated negatively with good math grades in high school. Black men with high SATs often faced academic dismissal. It was the students in the middle range who were the best math students in university.

They interviewed the families of the students to find if that was the cause of their poor performance. What they found was a strong network of support, that they had made a conscious effort into getting their kids into college, and quite a few of them were college graduates too.

Perhaps the most unexpected finding was that family income was negatively correlated with performance. This is because many of the poorest students come from families where the parents would work in public schools and don't earn much, but had a long standing tradition of education.

So, after going through all the data and interviews, they were at a blank state again. They decided to do some ethnographic research: follow the students around, videotape them in the least conspicuous way possible, let them grow to their presence.

So they decided to follow a group of Chinese students and a group of Black students. Black students would go to class, take notes, study eight hours per week, and then fail. What was surprising was the difference they saw with the Chinese students:

They studied calculus for about 14 hours a week. They would put in 8 to 10 hours working alone. In the evenings, they would get together. They might make a meal together and then sit and eat or go over the homework assignment. They would check each others' answers and each others' English. If one student got an answer of "pi" and all the other got an an answer of "82", the first student knew that he or she was probably wrong.

It was interesting to see how the Chinese students learned from each other. The would edit one another's solutions. A cousin or an older brother would come in and test them. They would regularly work problems from old exams, which are kept in public file in the library.

Based on these findings, Prof. Treisman obtained funding for creating what was essentially a "learning group". Berkeley had previously tried to enroll minority students in optional preparation courses, but he knew that minority students dismissed them as something for underperforming students.

His learning group was—in essence—a place to tackle problems to together.

Most visitors to the program thought that the heart of our project was group learning. They were impressed by the enthusiasm of the students and the intensity of their interactions as they collectively attacked challenging problems. But the real core was the problem sets which drove group interaction. One of the greatest challenges that we faced and still face today was figuring out suitable mathematical tasks for the students that not only would help them to crystalize their emerging understanding of the calculus, but that would show them the beauty of the subject.

We were able to convoke the students in our orientation that success in college would require them to work with their peers, to create for themselves a community based on shared intellectual interests and common professional aims. However, it took some doing to teach them how to work together. After that, it was really rather elementary pedagogy.

The results of this program were surprising: Black and Latino participants outperformed not only their minority peers, but their White and Asian classmates as well. Black students with Math SAT scores in the low-600s were performing comparably to White and Asian students whose Math SATs where in the mid-700s.

Here is Prof. Treisman's first hand ccount (PDF) if you're interested in learning more.

What is Method of Action

by Mark on July 26, 2011 10:11 PM on Design

Method of Action is an educational website that will launch with three different courses: design, entrepreneurship and gardening. Every course is composed by 50 different "missions". Each mission will accompanied by insightful articles or video that establish best practices for the task at hand, recommending books for further reading, or tools that can help you accomplish your goal.

You can then submit your completed mission, and more experienced peers will review it, giving a passing or failing grade. If you succeed, you will gain points that give you access to more difficult missions.

As you gain experience, you will be able to review and help less experienced users.

Philosophies

Information ≠ knowledge

I read a lot, I have this huge collection of data in my head, and whenever people say something like "I'd like to open a restaurant" I catch myself wanting to say "Well, it's not easy, a study says that says 60% of restaurants close their door within a year". But I know it's the Asperger's in me. So I think about stuff that actually helps like "Well, I read an article that says that the second cheapest wine is the most demanded, because nobody wants to be a cheap bastard. So restaurants bank on this and put their highest profit wine there, which means that you get less bang for your buck".

It's an interesting tidbit, but it can't compare to the actual advice a real restaurateur could provide. His interest would be genuine, his answers heartfelt, and his advice spot-on. Knowledge enables you to connect with people and things at a much more intimate level.

There's a tremendous amount of beauty in things if you have deep knowledge about how they are built, be them organic or man-made. When I moved to Canada a brought along a European style coffee maker. My uncle—an engineer—was fascinated with the mechanics. He took it apart and studied every piece. I had always thought it was "nice" but my uncle found a much more deeper functional beauty.

Knowledge is acquired by actually doing things and reflecting upon it. Proactively thinking about how you can improve what you did.

You will eventually need feedback loops

You can get pretty far with just doing, but there comes a time when you will need someone to tell you how to advance. Imagine you are a solitary but extra-motivated person who wants to sprint as fast as Usain Bolt. Running seems straightforward, just move your damn legs as fast as you can, right?.

Well, it doesn't quite work out like that. You would start out by making impressive milestones, you would cut a couple of seconds every month on a 100m dash. But eventually you would hit a ceiling and you would have no idea how to surpass it. Here is where expertise comes into play, a good coach would be able to catch weaknesses in your strides, coach you on nutrition and muscle building.

Even without hitting your ceiling, it's always comforting knowing there are people watching, giving you tips on the general mechanics.

Who is behind the project

We are Mark and María

We met while working at Vostok Studio, a prestigious design agency based in Madrid, Spain. We worked together during two years for clients such as BBVA, BeBanjo and Minube.

In 2010 we decided to move to Toronto, Canada. Mark would embark in a close collaboration with Uproot, a UX development agency working on high profile projects for Rubbermaid, CBC, Bell and McDonald's Canada; while María worked full-time with Linking Paths, an international web development shop split between Reykjavik, Bilbao, Madrid and Toronto.

María brings serious communication and project management skills to the table. Her passion is making text and visual information understandable. You can find María's work at mariamunuera.com

Mark's has been awarded the University Student of the Year 2008 in the Journalism category by CNN/Expansión magazine for designing and programming the website for the United Nations Information Centre in Mexico City.

He also earned 2nd place in AbreDatos 2010, Spain's national Open Data contest, for designing misparadas.com, a web application that tracks public transportation in real-time. In 2011 he released memela.com, an html5 drawing application that has been featured in Chome Experiments, a Google curated html5 showcase.

Mark is in charge of one the most popular design blogs in Spanish, Duopixel. Duopixel has more than 30,000 unique visitors per month, and has been featured in the book "Blogs, Mad about Design" by maomao publications.

Mark's skills lie at the intersection between design and development.
You can view Mark's work at duopixel.ca