Constructing Fictions, Part 3: Designing in the Browser

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

When it comes to web design, there are those who find the concept of designing in the browser unthinkable, those who think we should be deciding in the browser, and those who believe in designing mainly in the browser. Myself, I definitely belong to the last category.

First Things First: Growing the Concept

No matter the complexity of the page, I’ll mostly start off with hand drawn sketches. Sometimes, even before the design, I’ll have an idea, a concept that I’m hung on, and I’ll draw sketches related to that concept. Years ago, for example, I remember being intrigued by a picture book that depicted the story of some animals getting trapped in a pit, and I decided to use that pit as a concept for the design of a website. (Unfortunately, that website is already taken down and I didn’t take screenshots, so I can’t share the design here.) Other times, I’ll start off with a blank, then start brainstorming ideas for the design. For this blog, for instance, I started off by associating a blog with keywords like chronology, time, the blogger’s thoughts and changes over time, and so on, and then finally settling on the concept of a blog as a retrospective of the blogger’s “works of art” (i.e. his thoughts).

Scribblings on my sketchbook for this blog's concept

Scribblings on my sketchbook for this blog’s concept

Testing the Concept in the Browser

A concept is only a concept, and needs to be proven and tested. As a web designer(?), I don’t believe in testing a concept with any other thing than a browser.

With my Fictions homepage, I started off with the simple notion of wanting the Fictions section in a circle, most likely black background with white text. Why? Because webpages are typically so boxy, the first thing I wanted was to break out of that mold.

So with the HTML already in place, I made a quick circle (with simple background-color and border-radius) that’s anchored to the right. It then became apparent that the space to its left should be the Works section. With the simple notion that typography is the selling point here, I set a few larger-than-usual font sizes and quickly put them together to see how they looked:

Screenshot of first design draft of Fictions homepage

This, I would say, is my first design draft. At this point, I will decide if the design pleases me, and if I want to pursue it further. For Fictions, I decided that this was the direction I wanted to go down, so from there I started building on the draft and fleshing out the details, mostly with CSS and entirely on the browser.

Sorry, But No Mobile First for Me.

Yes, yes, sure I understand the arguments for a mobile first design. But from a creative standpoint, coming up with design ideas on a tiny canvas the size of a mobile viewport is way too limiting. In the physical world, there are artists who relish in the joy of making art on the smallest canvas possible. Well, I’m not one of them. I like to have a big blank canvas in front of me for me to play around with and splash paint on. To me, the standard desktop viewport is the digital equivalent of that canvas.

The only thing I will need to take note of here is that I will need to move some of the styles I already have into desktop-and-above media queries afterwards and modify the remaining styles to cater to smaller viewports. Which, really, doesn’t present much of an issue; since the desktop design and the mobile design typically overlap a great deal, it doesn’t require a lot of work. I’ll trade that effort for an interesting concept anytime.

Go with the Flow.

At this stage, I have a solid concept that is tested out on the browser and that I’m satisfied with. The rest of the work of writing CSS to flesh out the concept into a real design is relatively straightforward. As long as I have a solid concept as the foundation, it’s simple (though not, obviously, easy) to build up the design around it. In the case of Fictions, since it’s a single page, it’s even more straightforward. And because it’s a simple, personal project, I used this as an opportunity to try out the BEM convention of writing CSS. (I’m still not sold on it, but I can see its strengths.) In any case, as the design isn’t particularly complicated, I will not go in-depth into the code. Most professionals will know how to code it up quite easily, I’m sure.

Pleasant Surprises.

Oh, but allow me to share a small episode when I was designing Fictions. It was straightforward enough to design for the mobile version of the page, since the circular Fictions section didn’t fit on a small viewport, so I had everything boxed up again on mobile sizes:

Screenshot of Fictions on my Windows Phone

Screenshot of Fictions on my Windows Phone

What gave me a bit of a challenge was the in-between, “tablet” size. While it wasn’t narrow enough to ditch the circle, it wasn’t wide enough to show it in its full glory. After a bit of tinkering and testing (e.g. making the circle a box, placing it directly on top of the other sections like with the mobile viewport), it suddenly dawned upon me: why not hide the circle partially? That is, allow a sneak peak of the circle but hide it partially so that the user will be intrigued enough to click it. Like this:

Screencast showing how the About section focuses into view on click

Unfortunately, using LICEcap to capture this as a GIF seems to have dulled the colors.

I’m sure there will be UX purists who think hiding things from users this way is bad. Well, I’d like to think that engaging users is part of good user experience too, and a little intrigue never fails to engage users, isn’t it?

Good Design = Tried and Tested Design?

Frankly, I’m not sure. And clearly there is no right answer to that question. Often, when I read the reasoning and rationale of clever designers/developers on the merits of using tried and tested design patterns and layouts, I feel convinced. Yet I can’t help but look at bold, unconventional designs in fields such as product design and architecture and think, no, breaking out of the mold doesn’t necessarily bring about bad design. I got a feeling it’s because design on the Web is still at its infant stage, so the notion of bold, unconventional designs that challenge the user is not seen as viable yet. But when the Web matures sufficiently, things should change. Guess we will see.

Next Up: Injecting Interactivity

After I have actually implemented the design with CSS and tested the design on different screen sizes, the next step will be to inject interactivity into the page with script. In the next post, I’ll share my approach with Javascript for this project, including my preference for less script induced animation and more CSS based ones.

A Web Developer/Designer Preps for His Presentation.

Some time back, with a desire to let my colleagues understand more about what I do, and to share with them what I think is certainly “good-to-know” for them, I proposed to host a knowledge sharing session. Happily, many of them responded positively, and so I started preparing for it. While I did say it’s a knowledge sharing session, which is arguably more casual and certainly supposed to be shorter, to me it’s still a presentation. A presentation with slides to prepare, and a script to run over beforehand. Coz’ a poorly prepared anything is a pain to listen to, and being the first one to suggest such a sharing session at our office, I’m hoping not to turn them off. Too much, that is.

Writing It Down.

My approach to preparing such a presentation is to first write down the script. Imagining myself before an audience, I started writing out what I thought I would want to say to them. And then, over many sessions, I’d reread it and change things, like if something sounds too formal or some part sounds redundant. Eventually, when I’m somewhat happy with it (the script is always subjected to change), I’ll start creating slides based on the keypoints I want my audience to focus their attention on.

Developing the Slides.

Now here’s where I’m quite sure I do things very differently from other presenters around the world: I start to handcode my slides.

Yes, with the holy trinity of HTML, CSS, and Javascript, I started typing my keypoints down into HTML <section>s, wrapping them in either <h1>s or <h2>s, styling them with CSS and then running Javascript to give the appearance of transition between ‘slides’, which are really just HTML <section>s overlaying another.

At this point, even if you were a frontend developer, you’d probably think I’m insane. The proverb about the hammer and nail probably comes to your mind. But wait – I didn’t say I coded everything from scratch, ground up. Not every time any way. 2 years ago, for another internal presentation about the topic “redefining web design”, I wanted to let the teams know how powerful web design – i.e. using only the base web technologies and without relying on Photoshop and other graphics software – is becoming. So I thought, why not just build the entire presentation on HTML + CSS + Javascript? That will seriously show them the power of web design. In the end, though, nobody asked me anything about the “slides”. Guess that’s indicative of how good the webpage was at behaving like a Powerpoint presentation?

In any case, two years later, now, I needed slides again so I thought, why not reuse it? The best thing about “coding” my slides is that I’m not only using technologies I’m familiar with, but I am allowed to use experimental technologies. And I don’t need to give a shit about cross-browser compatibility. So I happily used flex-box to center my content, vw and vh to dictate the size of the slides, and rem to control the font sizes. All without backup styles like -ms-flex-box or em. All I need to do is to be sure I open the webpage/presentation on Chrome or Firefox. Feels so good.

Finally, I commit the code to Bitbucket to back it up, and then push it to Heroku so that I can access the presentation anywhere there’s a browser and Internet. Terribly geeky, perhaps. But totally fun.

Finally, Throwing Away the Script.

After that crazy part about coding my presentation, this is going to sound so boring. Still, when I actually begin my presentation (weeks from now), I know I’m going to throw away the script. That is, I’m going to ignore everything I wrote and reviewed over the weeks and just improvise. While that might sound a little counterproductive, I find this approach the best in terms of sounding natural and sounding like yourself when making the presentation. Memorizing the script sounds like important prep work, but I think it trips you up if you happen to forget stuff or if someone in the audience does something unexpected and throw you off guard. In my opinion, having gone through the script so many times beforehand, and with the slides to guide me, there is no longer any need to rely on the actual words in the script. So I’ll just go out, relaxed in the knowledge that I am well prepared, then converse to the audience and tell them what I want them to know, using the slides as signposts. Oh, and show off my design at the same time, of course. Duh.

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: a Fictions section that briefly describes my fictions, 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="">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 challenged 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/we (I’m guilty of it sometimes, too) are increasingly ripping the Web of its universal accessibility and making web content bad.

Moving On.

So now that I have my typography and proper HTML in place, I’m ready to build my design. In the next post, I’ll describe how I decide on my layout, 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 check with 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.