Picasso, and the Courage to Fail.

Le Mystère Picasso (The Picasso Mystery) is a feature film length documentary that documents Picasso’s painting process. The unconventional presentation and surprisingly engaging “plot” aside, there’s one thing that really captured my attention: Picasso’s willingness to fail.

In more than one instance, you can see Picasso starting off with a rough idea, then slowly fleshing it out so that it reaches a state where everyone in the audience would have been happy with – and it is at this point of time that Picasso surprises us, by putting bold strokes to the canvas and undoing what seemed perfectly fine (to us the amateurs). Sometimes he succeeded in making things work out in a new way, while other times the work turned out to be less than satisfying. (Coz’ really, how many times can you overwrite a canvas before everything starts falling apart?) But failure doesn’t deter Picasso; if anything, it invigorates him and spurs him to be bolder each time.

“It took me four years to paint like Raphael, but a lifetime to paint like a child.” Picasso was known to say. Perhaps that’s just what it is: the bolder you are, the stronger you are.

Constructing Fictions, Part 2: Thoughtful HTML & Content Structure

(This is the second part to my process of reconstructing my Fictions homepage. Here’s the first part, in case you haven’t and want to read that first.)

It seems there are two distinct approaches to laying out content in web design: content first, versus design first. I’m not about to start arguing which is the better approach, but I do know I’m using the former approach with this project.

The Typical Process

The typical development team approaches content development by first coming up with either the wireframe or mockup, or frequently both. Based on what they understand about what the page does, they imagine the steps the user goes through before coming up with blocks of content laid out in an interface that is hopefully easy to use. After which the designers and/or developers take over to code things up.

My Preferred Approach: HTML First

I’ve, since many years back, established my personal process – one that places emphasis on the HTML. First, because I’m in the privileged position of knowing my content (it’s my homepage after all), I’m able to, from the start, divide the content into 3 main sections: an About Me section, a Works section that lay out my existing works, and finally a Connect section that invites users to connect with me. Without worrying about where the individual content blocks are laid out at this stage, I dive straight into the code and come up with the below:

 <article id="home">
    <section id="intro" class="tcenter rel">
      <a href="/"><img src="images/uebyn-logo.jpg"></a>
      <p>is the pseudonym I adopt as an artist, no less because it emphasizes my individuality, which I hope is expressed in my works.</p>
      <p>I consider myself a <em>narrative artist</em> working primarily with words, stories, colors and type.</p>
    <section id="projects">
      <h1 class="sans">Projects</h1>
      <span class="year">2014 -</span>
      <span class="year">2011...</span>
      <span><a target="_blank" href="http://minimal-english.uebyn.com">Minimal English</a></span>
      <span class="year">2008</span>

First complete version of the HTML

The reason I’m starting with HTML is because I know that HTML is the foundation of the Web. No, it’s not CSS, which styles the webpages, nor is it Javascript, which improves the interactivity of the Web. Give anyone a most simple web browser – say a Lynx or a smart watch – and he should, without gorgeous styling and cool animation, be able to browse the base text content without any issues. By coding up the HTML content from the start, I’m essentially ensuring that I’m laying down the right foundation for CSS and Javascript, much like a professional painter smoothens and cleans the wall before applying paint to it.

More Appropriate HTML

I find that by focusing first on HTML content, you are more likely to choose the right HTML code for the occasion, whereas diving headfirst into the visual design encourages one to skip over code. As a simple example, every page should have a <h1> header that explains what the page is about. If you start coding with the design or mockup in mind – say for instance with the final design of the page here,

Fictions, Final Design

it’s easy for you to forget that fact and not code the header in. When you focus solely on determining the right code for the content though, you’re less likely to be distracted by the visuals and more likely to remember to hook the page to a top level <h1> header, like all pages are supposed to. By focusing solely on the content, I feel more capable of coming up with semantically correct HTML that describes the content accurately and in a way both search engines and visually impaired users are able to digest easily.

That Being Said.

In most of my working environments so far, starting off with mockups has been the norm. In fact, in many cases, that’s all I get; no actual written content or information architecture is provided by anyone else, and I’m expected to come up with the code based solely on the text (if any beyond Lorem Ipsum) in the mockups. While not ideal, this is one of the ways bigger teams manage the development process, and I’ve learnt to make the best of it. In fact, this gives me an opportunity to polish my copywriting skills and test out how well I can write HTML with just the mockups at hand. (Which I’ll find out when testing the accessibility later. More of that in another post.)

Structure and Semantics Matters.

At one of my previous companies, I was given access to the information architecture of the website I was to code HTML for. These were prepared by the project managers who knew the content and were required by the process to come up with an Excel sheet laying out all the mandatory content.

In spite of that, the content provided was organized from a top level and could not possibly provide all the necessary details needed in a properly coded HTML page. At the end of the day, it is still the HTML coders who make the final decisions as to what the HTML content should be for each individual page. By breaking the HTML into distinct sections, each with a header that describes the section, and using the right tags to describe each and every element on the page, the HTML coder is providing a digestible road map to the content that is to be consumed by the user, even if the user does not have the capability to interpret the content visually.

HTML Matters.

The reason I’m spending so much time talking about this is that I see a disturbing trend of professionals in the industry putting all their focus on the Javascript side of things without consideration for the most fundamental technology of the Web. By taking the easy way out and using <div>s everywhere and using <span>s to emulate buttons and links, they are increasingly ripping the Web of its universal accessibility and making web content bad.

Moving On.

So now that I have my typography and HTML in place, I’m ready to move on to the design. In the next post, I’ll describe how I decide on my layout and colors, by designing in the browser.

Handwriting Fonts: Why Not?

I’m reworking the “theme” of this blog (though given that it’s for my personal use and is so severely customized it probably can’t be used anywhere else, one can hardly call it a real WordPress theme) and have decided to use handwriting fonts for the comments section. Yup, as long as it’s a user comment, it will be shown in handwriting font.

If it had been my company’s blog, I’ll never have suggested that idea. Handwriting fonts? How legible can these fonts possibly be compared to the standard serif and sans-serif fonts? What about non-native users of English? Isn’t that going to make things more difficult for them? Don’t you think about the user experience?

Then again, this is my personal blog, and there’s absolutely no commercial implications resulting from any creative decision. If you can’t make bold decisions on your personal sites, where else can you make them? That’s why I have a category of posts under this blog called “Experiments”. So readers of this blog should probably guess that I’m happy to experiment with things, even if they sound wrong or crazy. And obviously, there’s always a good chance of experiments going right and becoming part of my repertoire. No risk, no gain.

For this particular experiment, I’m quite happy with the results so far. Given the concept behind the blog design, it makes sense to make use of handwriting fonts to capture the feel of gallery visitors actually leaving their hand written remarks behind, possibly on a guestbook. I’m have also sort of randomized the style of comments on top of using handwriting fonts, to make them more “real”. Given that this is an experiment and not quite the norm, I won’t be surprised if visitors to my blog get turned off and click away. Then again, I’m sure there will be others who adore the idea. You can’t please everyone, and I’m not about to try.

So until I actually finish the theme, here’s a screenshot of the comments section, using handwriting fonts:

Screenshot of the Future Comments Page of This Blog, Using Handwriting Fonts

Pretty cool, right? No? Whatever.

Growing Old Ain't Exactly a Bad Thing.

So my faux leather work bag is starting to come apart, with the zip semi-functioning and bits starting to come off the skin. For the first time in my life, I’m considering spending more than a hundred bucks on a new bag, possibly something in its hundreds. Maybe branded.

No, it’s not because I’m starting to become brand-conscious. It’s just that once you cross a certain age, you start to recognize the importance of good products. Products that last and save you from having to think (too much). A typical faux leather work bag, it seems, lasts about a year before it begins to show signs of breaking down. At which point you need to start worrying about when it’s going to fail you and when you need to get a replacement (soon) before it finally breaks beyond repair one fateful day, probably the day when it’s raining dogs and cats on you and you can’t zip your bloody bag shut.

Now, suppose I spend 300 dollars for a good leather bag that lasts 3 years; I won’t have made any loss as compared to having bought three 100 dollar bags instead. Further more, I save time from having to shop for a replacement every time one breaks down. And to get a bag at 300 dollars that lasts for 3 years essentially means 100 bucks to a year, or about $0.30 a day. Not that crazy, is it?

This reminds me of my decision, years ago, to finally go for a Macbook. By then, I had gone through about a decade of struggle with Windows, all for the misguided principle of going for cheaper products whenever the option was there. But I was seriously sick of all those software incompatibility issues, viruses, frequent breakdowns and having to pay for multi-language input options. Not to mention having to download all kinds of addons to have access to the Unix shell and other open source goodies. So I doled out the extra cash, bought myself a Mac and well, never looked back.

The thing about being raised in an environment where most decisions are made based on money is that you often don’t realize how irrational those decisions are, not until you finally grow up and are able to make reasonable logical decisions independent of your ingrained habits. And these are the times when you actually feel: hey, growing old ain’t exactly a bad thing after all.

Old Boy: Lessons Learned

Rewatched Old Boy by Park Chan-Wook, it being one of my favorite films. Having known the plot beforehand, and this being the first time I’m watching it in years (watched the horrible remake of it about a while back, which probably prompted me to watch the original one this time round), I was able to see things from a fresh perspective and notice things I didn’t before.

Among the many things that impressed me was the long shot of the protagonist (aka “Monster”, played by the amazing Choi Min-Sik) against a gang of triad members.

Old Boy: Long Shot Fighting Scene
Choi, aka “Monster”, up against dozens of gangsters in this famous fight scene.

Through this long shot, where the camera pans from left to right and back, the opponents launch at Choi from all angles, using different weapons and at different speeds, almost like you can imagine happens in a real life fight. And Choi dodges and counters, and sometimes fails to dodge and is hit from the sides and back. More than once, Choi falls – and is immediately surrounded by his opponents who jump on him ruthlessly. Immediately, though, he would climb back up to retaliate and gain the upper hand. All these, a full two and a half minutes worth of fighting scene, was shot without a single cut. In short, this entire scene is choreographed down to the finest details and rehearsed over and over again until that one shot is perfect. It must have taken hundreds of retakes in order for the flow, the rhythm, the angles, the realism to come off right.

There are so many other things that can be said about this film, but there’s another one that I’d like to highlight here, namely the “flashback” scene when Choi was trying to remember what he saw and shouldn’t have seen when he was younger. Whereas the typical flashback scene separates the present and the past into two discrete units, in this case the flashback is beautifully intertwined with the present. As the younger Choi scribbles on the blackboard of their old classroom, so does the present Choi sit in the same classroom, watching him from his seat – the present self and the past self sharing one timespace in memory. As the younger Choi runs up the stairs in pursuit of Woo Jin (the villain), so does the present Choi run up the same stairs, following the former. In short, a beautiful visual presentation of the recollection process, where the present self attempts to catch up with the past.

A Unified Work.

But Old Boy is not just about doing old things in new ways. From the intense music to the surreal backdrop to the stylish cuts and frightening realism (I’m reminded of the tooth extraction scene), there is a strong sense of coherence that ties up the film and earns it its strong reputation as a film.

We’ve all seen films where the premise was good, but finally degenerated into an incoherent, disappointing piece. In my view, it’s the attention to details and willingness to go all the way to ensure total artistic uniformity that makes Old Boy such a fine piece. Now that’s a good lesson to be learned.

Stop Using the Vertical Line in Your Titles.

I used to like the use of the vertical bar or pipe in <title>s of subpages. Like, “About Us | Your Company or Blog Name”. It just looks cooler, I thought. Until I started learning about accessibility and started using Voiceover to listen to webpages.

What looks cool to us visual users turns out to be something downright annoying to the visually impaired user. Instead of the “About Us, Nike Sports” we’re expecting to hear, one hears “About Us, Vertical Line, Nike Sports”:

(If for some unfathomable reason, your browser refuses to play the audio, you can download it here:

If you think it’s no big deal, try listening to it on every single page of the website. (Or try replaying the sample audio above ten to twenty times.) Not only will you start getting annoyed, but you will be thinking, “What kind of idiot coded this page?”

I know I was an idiot, and I’m glad I’ve turned over a new leaf. If you’re like me before, you should stop using the vertical line now. Instead, you can use “:”, which the screen reader gracefully ignores. So “About Us: Nike Sports“ will be read exactly the way it reads. It annoys no one, and it saves you from being labeled an idiot.

.no-js Happens. Seriously.

I was one of those guys who did not really believe in the need for a .no-js class. After all, this is not the 90s anymore. Who browses the Web without JavaScript these days?

So one day, I was on this horribly packed train and decided to take a look at my homepage. And guess what? Thanks to the sheer number of people tapping to the network at the same time, JavaScript (more specifically Modernizr.js) failed to load, for like half a minute. And thanks to the fact that I do follow best practices in development, the page looked just fine, exactly the way it would have looked if a user disables JavaScript on her browser. Only after a while, when it finally loaded Modernizr, did my page resume the way it should look with Javascript. Holy shit. Imagine if I didn’t write CSS that caters to the no-js scenario. My homepage would have looked like crap. Or, worse, given the user the impression that it’s working just fine when things broke without JavaScript.

So now I’m a believer. Never assume the user has JavaScript.

Creative Collaboration, and the Future of Work

A job interview I sat for a while back, for the role of frontend engineer. We've had about fifteen minutes of chat over the hottest frontend tools and processes any self-respecting frontend developer ought to know, and I decided to move on to the collaborative process between designers and developers:

Me: So may I know how the developers and designers work together at your company?

(The interviewer is a polite and serious looking man who is nonetheless dressed casually in a hoodie, which to me is always a good sign indicative of the open nature of the company. Let's call him Mr. Hoodie.)

Mr. Hoodie: The designers come up with the mockups on Photoshop and then pass the PSD to the developers to work on.

(Photoshop for mockups is a tad old school, but to each his own. I personally prefer Sketch and its vector counterparts, but a PS pro will obviously prefer the swift maneuvers of the good old Photoshop. Oldies are goodies - I'm not deterred in any way.)

Me: I see. So then the frontend developers will convert the designs into HTML and CSS?

Mr. Hoodie: It depends. Sometimes the designers will produce the HTML and CSS.

Me (arching my eyebrow): That's interesting.

(And it sure is. So they are not so much graphic designers as actual web designers? Not quite the norm, but totally understandable considering the nature of web design. What then does the frontend developer do? Pure JavaScript?)

Me: So in any case, if the frontend developers have any questions, they will defer to the designers right?

Mr. Hoodie: That's right.

Me: How big is the design team? Do they sit near the development team?

Mr. Hoodie: We have about 6 to 7 designers. No, they are in a completely different department, near the marketing team. The engineering team is on another level.

(That sounds completely like red alert to me. How can the designers not sit close to the frontend developers? How then can they discuss and collaborate? If we're actually shooting this script, the sound of sirens will start blaring in the background already.)

Me (cautiously): I see. So how would you describe the working relationship between the designers and the developers? Frequent discussions, or minimal and only as needed?

Mr. Hoodie (cool as a cucumber as always): Minimal and only when needed.

Cut to black. In my mind, the interview is as good as over.

Specialization: Clinging on to the Industrial Revolution?

Doesn’t the act of splitting the production process into different stages, each the responsibility of a professional, remind you of a factory? Think Charlie Chaplin and his Modern Times – you can easily change the factory setting to an office setting and the workers to web designer and developers, and everything will pretty much be the same. The web designer finishes a piece of her work (in this case a PSD), and passes it to her co-worker the developer. With a factory, chit chat and discussions are largely frowned upon, because it slows down the production. In the case of companies like the one above, it’s pretty much the same. “Everything is in the PSD – the dimensions, the grids, the colors. So just proceed and don’t ask redundant questions” is what I get out of the way they arrange the teams. How sad that we’re still – in this Internet Age – stuck in the past.

Working Products are Passe, Emotional Products are In

(I’m sure I read this somewhere, but I can’t remember where from. If anyone who reads this knows, please remind me so I can give proper accreditation. )

In a day and age when production speed is spectacular and global competition a constant, coming up with products that work just as well, faster than your competitors ain’t gonna cut it anymore. Think smart watches – does the fact that Samsung released the smart watches earlier than Apple did means it became the best selling products in the category? No – modern consumers want more. We don’t want subpar products – even totally functional products – released sooner. We want cool, amazing products that speak to us, and we’re willing to wait and pay more for them.

The way I look at it, as global competition intensifies, the only way for any company to become successful is to spend resources on creating brilliant products that speak to the emotions, not release average products sooner than their competitors.

Creative Collaboration: A New Process?

Businesses may need to redefine and re-measure their processes in the future. Instead of thinking about feature delivery all the time, they may want to factor in time for creative collaboration and exploration among their employees – the chit chat and discussion that was so frowned upon in the past. Just like Google’s ‘20% time’, some of these experimentation may turn out to become extremely valuable offerings for the company.

Together Time for Developers and Designers

The interface of the application is often the single factor that hooks the user to it. Given two time management tools that perform similar functions, one of which looks more gorgeous than the other, the gorgeous one clearly stands out. The company can (and likely will) charge more for it too. So why wouldn’t the company encourage the designers and developers to work together closely to come up with appealing interfaces? The designer may be able to come up with aligned beautiful forms, but the frontend developer knows and can challenge the limitations of the browser. When they work closely together to brainstorm and experiment with ideas, who knows what sparks may fly?

The Future of Work?

It won’t be easy for sure, since businesses can’t measure creativity. A team of designers and developers brainstorming in a room may or may not come up with something good, just as the occasional good idea can come out of that five minute discussion with a co-worker. The point, however, is this: let us get used to the idea of being creative and wild with ideas. While scheduled brainstorming sessions may not always turn up something, it helps exercise our creative and collaborative muscles. As with anything in life, the willingness to commit to something will eventually lead to results. And the organization that is willing to start building their creative arm now will, I believe, lead the future.

Constructing Fictions, Part 1: Typography

Lately, I’ve found some time during my vacation to rebuild my fictions homepage. And in the process, I started thinking that maybe I should share my development process, because there’s always something to learn from someone else’s process. I’m hoping that someone out there will find my process interesting, maybe even intriguing. Because developing a personal homepage is different from building a commercial application – the priorities are different, the timelines are different, and the motivations are different.

First things first: Typography

I’m a believer in the merits of using typography as a base for web design. What’s more, because the fictions homepage primarily serves as a landing page for my fictional works, text and typography necessarily becomes the focus. Also, with a typical web application, the focus is always less on the typography than on the grid – one can use Bootstrap without giving a hoot about the typography and still deliver a decent looking web app. Since this is a personal project, I see it as a good chance to approach design differently, typography first.

Georgia and Arial.

Choosing the right fonts is surprisingly easy in this case. Since it’s a single page, there’s little reason to put the burden of loading an entire font family on the user just to make things look good. Georgia and Arial are the default fonts served by all Windows and Mac machines, and don’t require users to load new fonts. And since everyone is using web fonts these days, going back to Georgia and Arial can actually make things look fresh.


Determining the leading is necessary because it sets the vertical rhythm and makes it easier on the eyes. In my case, I first wanted to start out with a base font size. Because there are less paragraphs on my page than headers, I decided that I will not go with the default 16px/1em on browsers, and decided to go with 18px/1.125rem instead. As for the line-height, I picked a number from my modular scale that looks right: 1.235. As thus the leading for my homepage will be 1.125rem x 1.235 = 1.389375rem, or 18px x 1.235 = 22.23px.

Px, Em or Rem?

There seems to be an increasing number of people who advocate not using Rem or Em in favor of Px. I personally prefer the use of Rem, because it respects the user’s font size settings and makes calculation simpler for me. Unless I need to establish a relationship between say, a header and its corresponding paragraph, I prefer to take out the complexity of cascading styles and use Rem in favor of em.

Mix n’ Match

I’m in no way a typography geek, so most of the time I simply rely on my instincts. If I feel two fonts go well together, then I’ll use them. There’s no exact science involved whatsoever. The recommendations on Typekit help somewhat, but in this case, since I’m using Georgia and Arial, I simply relied on my instincts. I do know, however, that I want to use sans serif for the headers and serif for the text, so the experimenting started from there.

Big Types, Small Types

I did not want my synopsis paragraphs to stand out too much, because I want users to focus less on the synopses of the fictions and more on actually reading them. So I had my <p>s and <span>s at the base font size of 1.125rem/ 18px. The font sizes of the other elements are decided somewhat arbitrary, using the leading as a foundation. The <h2> headers, for example, have font sizes that are 4x that of the base font size, while the titles of the works have font sizes at 2x the base. These decisions are based on the relative importance of the elements, as well as whether they ‘look right’. If the <h2>s didn’t look right at the font size of 4x the base, for example, I’d have drop it to 3x, or maybe some other value, while taking care to keep the leading consistent.

Next Up: Content Hierarchy

After the foundation, i.e. the typography has been set, the next step will be defining the content structure. since the relative importance of each content block affects how it is laid out. More importantly, knowing the current hierarchy well helps in the writing of semantic HTML code, which is extremely important for users who are visually disabled. In my next post, I’ll explain my process of tying content to typography, as well as writing thoughtful HTML. Stay tuned.

Improvisation, Experimentation, and Art.

First, An Anecdote.

This other day, I was creating my first vector-based illustration on Sketch. The goal is to come up with a fitting illustration to accompany my short story.

As the short story is basically about communication, I started running a few ideas around my head. Communication in the modern context means smart phones and the Internet, and immediately the idea of a WiFi station and the beams that are emitted by it came to mind.

And so I plunged into Sketch and started creating circles upon circles, each overlapping one another, so that eventually this whirlpool like image appears:


The idea was that by masking this image with a triangle, I will get a triangular shape symbol that everyone can tell symbolizes WiFi communication:


But once I put this image onto the background of my story, it became clear that this image is not going to cut it, even before I started positioning and resizing it, or even adding colors:


I can’t explain it, but it just didn’t feel right. it doesn’t look good as a background image, and it’s only going to look worse if I shrink and multiply it to be used as a background pattern.

As a result, idea number one is abandoned, and I had to start thinking again.

Classic Telephones, Telephone Wires, and More.

Now, if the image of WiFi communication doesn’t seem right, how about old telephones? You know, the kind with handset and dials? Now that sounds nostalgic, and probably fun to draw too.


Now, I’m by no means a professional artist, so I needed something as a guide. And so I downloaded the image of an older model of a telephone and I started outlining it with the Vector tool. After breaking up the phone into a few components (the dial, the front face, the side face, the handset and the top face where the handset rests), I started outlining them, sometimes with the Vector tool, other times with the Oval or Rectangle Tool, fine tuning them with bezier curve handles so that they look similar to the original image.

At a certain point, though, I decided too much details was gonna kill me, and that I preferred the rough sketched out look anyway, so I stopped trying to replicate the details of the real telephone image, and left my illustration at this:


I don’t know what professional illustrators who use pricey Wacoms and towering iMacs think, but I am very proud of my first vector illustration, ever. Like I said, I prefer the rough look of it, so I left the dials looking non-circular, as though they had been hand drawn. I didn’t know why, but I felt like a dull shade of red will match the color scheme, that’s why the dials became like this. And while I had removed most of the unsightly lines resulting from overlapping of layers, I left some of them behind because I didn’t want it to look too ‘perfect’, or too professional. I wanted it to look like it was sketched roughly with a pen or something.

And, Finally.

I placed the above image as a background for my story, decided it looked forlorn, and so decided to come up with another image, this time of a modern mobile phone. A mobile phone is simple enough in terms of shape, though, so this time I just sketched it out without a reference image.

Finally, I put both images onto the page, played around with the size and positioning without any plan in mind, and through some random serendipity of sorts, came up with this mashed up combination of the two images:


And that was it, my first vector illustrations for my short story that I personally like a lot. The background image was based on the original red that colored the dials, but I went through a couple of color options (yellow, orange, brown) before finally settling on this red.

But more importantly, I arrived at this final result without any form of plan in place.

No Plan, Ma!

You might have noticed how I emphasized a few sentences throughout the above description of my creative process, such as:

  • “it just didn’t feel right”
  • “I had to start thinking again”
  • “played around (…)without any plan in mind”

While it is true that I wanted to share my creative process (especially as it was a first vector illustration experience for me and it was very enjoyable), I wanted to make use of this opportunity to share what I think is a very important part of the creative process, i.e. experimentation, failure, and instincts.

In an older post of mine, I lamented about how the Web has become boring. Part of the reason, I think, is the over-emphasis on productivity and accuracy. In an average web development team these days, words like ‘timeline’ and ‘budget’ are a constant. Every single feature or functionality has to be measured in terms of time and money. Even designers, who are supposedly the ‘creative ones’, are told to quote the number of days they think they will be able to come up with a mockup or concept. In such a factory-like environment, it is no wonder that designers and programmers — pressured by time — have to start reusing existing templates and plugins so as to deliver. The result is an endless copying and reusing of existing ideas, which, in my opinion, culminates in the current, boring Web.

Commerce Allows Little Room for Experimentation and Instincts.

The way I see it, the main reason behind the above is that most of the design and development teams these days are profit oriented. Time and money dictates the direction and pace of the project, and there really isn’t no room for things that can’t be measured, like experimentation and failures. And because design is, in many ways, a problem solving discipline, it isn’t surprising that designers are expected to explain how their designs solve existing problems.

Art, on the other hand, is a different animal.

With art, we value things like subtlety, imagination, room for interpretation, and so on. Experimentation is necessary, because it tap into the unknown subconsciousness of our minds. (I am reminded of Dadaism and their works evoked by dreams and sometimes, drugs.) And gut feelings and instincts? These are all important, without which we may never get the excitement that comes with the sudden improvised acts by Jazz giants at live performances.


Again, We Need More Art.

This probably isn’t the first time I’m saying this, and it won’t be the last.

In this world where everything is measured and calculated, we need art to save our souls, to prevent us from turning into the very machines we invented. While it is important not to waste time unnecessarily, it is critical for us to let go at times. And though plans can take us places, sometimes a day without plans surprises us in ways we can never imagine.

And so if you feel like improvisation and experimentation is in your blood, make art. Whatever your art form is, and whether or not your art gives you prosperity, make art. For in this increasingly mechanized world, art liberates your soul and makes you more human.