Archive for category Innovation
I just experimented with an interesting thing on Google Wave. I made my “Invite others” wave public. Now anyone on Wave can invite people using my invites. Pretty cool. Just a minute after I made the wave public the first person entered and used two invites. It feels quite awesome. Can people handle it all the way? Will someone come in and just use up all the invites? We will soon know. =)
Has anyone else done this? Are there lots of public invite waves out there?
I’m experimenting with tying that 3D Album I mentioned earlier to Flickr Searches. Looks like this for now
Work in progress, both the app and this blog post.
Last night, I was reading a book by Leander Kahney. It is called “Inside Steve’s Brain”. I was mostly inspired to buy the book because of Google Story, the other book that I read some weeks back. Though both the books cannot be compared, to be honest I think this book lacks the flow. The author just wanders all around. Seems like it is just a collection of all news articles over a decade collected into one book with absolutely no concurrency. I was kind of cheated by the title in plain words. I was expecting the author to have had at least some kind of personal talk with Steve Jobs…at least a jovial walk with Steve on the streets of Palo Alto. Anyway, this blog is not intended to be a critic of the book. I think there are some good take-aways in there. Below is one of them…
Though not very surprising, it was interesting to read how much time Apple spends on the design of each and every little component from hardware to software to packaging. I was amazed to read that Steve and his bunch of talented designers were designing just the scrollbar function of Mac OS X for many weeks.No wonder why Microsoft’s scrollbars sucks when you compare it with OS X. For Apple “no detail is too small”.
Steve on the Mac OS X release said “We made the buttons on the screen look so good you’ll want to lick them”. Very true indeed! :-)
One thing that intrigues me is how much detail oriented Apple as a company really is. I think the way their designers apply common world solutions for solving technical design problems, is what makes their GUI more intuitive. I think this is one aspect that distinguishes Apple’s user friendliness from others.
Here is a little story from Apple …
At one design meeting Apple guys were scrutinizing the three little buttons on the top left corner of every window. These were used for closing, shrinking and expanding. The designers had made all the buttons the same muted gray, to prevent them from distracting the user. But it was difficult to tell what they were for. Hard to communicate what these buttons did before the user clicks on it. There were many interesting suggestions to the problem and Jobs came up with what seemed to be an old and uninteresting idea…using traffic lights to symbolize each button function! The designers of course thought it was strange and boring BUT after a few weeks of trial, yeah it made all the sense to them…red meant close and green to expand.
The other thing that is very unique about Apple is their layman approach to problem solving. Steve Jobs remarked on Apple after taking over as its interim CEO in the 90’s, “I can’t find sex in apple machines anymore!” True eh? people got to relate more personally to the software they use!
The starting point of the iPod was not about a hard drive and a chip in a walkman. It was simply user experience! It meant concentrating on navigating content. FULLSTOP! Apple was paying so much attention to “saying no” to features that would make the iPod NOT simple.
Apple believes that the most important decisions you make are NOT the things that you do, but the things you decide NOT to do.
I think this is a very good approach for making things simple and easy. Less is more!
When it comes to user design and user design innovation, a lot of companies like to say and think that they are customer-centric. They approach their users and ask them what they want. This user centric innovation is driven by feedback and focus groups. But Jobs shuns laborious studies such as these where users locked in a conference room go through gruelling hours of no productivity. What one really has to do with the focus group is to just observe them and NOT listen to them.
What Jobs does is even much simpler. To Play with the new technology himself. He notes down his own reactions to it and gives his feedback directly to the engineers. Jobs believes that if the technology works for him it will work for others. Of course, one has to have a layman approach when playing around. Steve Jobs is neither an engineer nor a business expert. He is a master layman!
John Sculley the ex CEO of Apple says “ But unlike a lot of people in product marketing in those days who would go out and do consumer testing, asking people what they wanted, Steve didn’t believe in that. He said, ‘How can I possibly ask someone what a graphics-based computer ought to be when they have no idea what a graphics-based computer is? No one has seen one before!’”
Creativity in art and Technology is about individual expression. Just as an artist couldn’t produce a painting by conducting a focus group study, Apple doesn’t use them either. They try it themselves!!
I think this can apply for us as well. Toyota believes that every engineer should be a quality controller too. For us we got to design and test our own software and give critical feedback! More and more!! I see very many good ideas pop up during our internal design discussions and during development. Some of them get implemented straightaway. Great! But I think we just have to get better at it…better at critically analyzing what we do. I don’t mean to say that “we should start shitting on our own doorstep”, this is bad :-) I mean that we should do more constructive criticism of what we make…let it be design or coding. This I think will enable us produce easier solutions for our customers.
If Sony started believing on customer studies and feedback alone, they would never have released their famous walkman in the 80’s. The company did though invest a lot of money into market research before releasing the walkman. All the marketing research said that the walkman was going to fail dramatically. No one would buy it! But the founder Akio and his team believed strongly in their product and pushed it through anyway. It became one of the greatest hits.
It’s the same with Steve Jobs he does not require user groups because he himself is an user experience expert.
So why don’t we as visual/interaction designers and coders and salesmen spend more time on analyzing and testing the stuff we design and develop?
This will make our product easy to use! We got our core value in there, “We make it ez”
When Microsoft created Outlook 2007 they took a mysterious design decision. “Let’s use the suckiest HTML renderer in the world (the MS Word one) to render HTML messages. ” Now it seems they’re planning to stick to that decision in Outlook 2010. To make the world aware of the nuttiness of this some good folks has created a site about it: Outlook’s broken – Let’s fix it
On Twitter there are more than just a few people who has struggled with downgrading their e-mail designs to be at least readable in Outlook 2007. Which made the news about this fixoutlook.org site quite big on the Twire. And Microsoft saw it. And Microsoft responded. Check it out. In the respons you’ll find:
Word enables Outlook customers to write … visually stunning e-mail messages.
That’s probably why Microsofts own XBox Live Team starts all their e-mail messages with this:
Seems like the XBox Live team doesn’t use Outlook? Or maybe they just don’t know how visually stunning their e-mail messages can get using it.
Microsofts response also contains this:
Microsoft welcomes the development of broadly-adopted e-mail standards. We understand that e-mail is about interoperability among various e-mail programs, and we believe that Outlook provides a good mix of a rich user experience and solid interoperability with a wide variety of other e-mail programs.
It’s of course a bad-taste-joke. But I think that the part about how they understand that e-mail is about interoperability is true. Unfortunately that’s where this decision probably comes from. Microsoft fears broadly-adopted standards. The world is about as stuck with Microsoft Office as it is with Windows. Wherever Microsoft has a near-monopoly they take the opportunity to fuck the world. That’s what they do with Internet Explorer. That’s what they do with Outlook. But what can we do? Maybe we can try get the EU to force Microsoft to quit bundling Outlook with Office?
Recently we here in Bangalore were discussing different ways of doing things to make our software and work environment better. We were all convinced that one way to make our code better was for us all to help each other out to make our own work environment more fun to work. This was just one thing we all were convinced about anyway! Something to celebrate, Hurray!! :-) Of course, there were many different opinions about what it means to make it “better”.
At first sight we thought that it was our work processes that can make a difference in the way we write and perceive our code. Though, this influence can never be ignored, we believe that for a rapid growth company like ours, we programmers and developers also need to improve the way we think about code. We of course should be proud of what we have accomplished so far, but we got to remember as Olle would say, “it’s a marathon we are running for God’s sake!”. We need constant energy and effort to get it across the finish line.
We thought that for us and our code to look better, we got to think better. We got to be code designers and not monkey like application programmer. We need to get constant inspiration and fuel from other code writers and designers out there. We believe that the wheel has been already invented, i.e., someone else in the world would have already solved our problem at hand earlier and probably has a better solution! We just need to google for the right idea and steal it.
Steve jobs once remarked “Good artists copy and great ones steal!”
We steal better designs to be better designers!
So with the initiative from Jayesh we bought this book called “Design patterns: Elements of Resuable Object-Oriented Software” written by a geni called Erich Gamma (and 4 others). Ganesh started reading it first and gave us a nice 25 minute presentation this Monday morning when our internet line got down. We thought that it was a good start and wanted to continue evangelising our thoughts around code design.
We are thinking of doing a 3 blog series of “From Monkey to Man” depending on the popularity of this article. So please do give us feedbacks and counter arguments to encourage us write more on our reflections on Erich Gamma’s book.
Okay, thats enough of background info. Lets now jump start into what Erich sees in patterns…
Designing object-oriented software is hard, and even harder is designing reusable object oriented software.
How many times have you had the dejavu – that felling that you have solved a problem before but not knowing where or how? If you could remember the details of the previous problem and how you solved it, then you could reuse the experience instead of re-inventing the wheel again? The purpose of Erich Gammas book is to record that experience as “design patterns”
Gamma goes, design patterns capture solutions that have developed and evolved over time. Hence they are not the designs people tend to generate initially. They reflect untold re-design and re-coding as developers have struggled for greater re-use and flexibility in their software. Design patterns capture these solutions in a succinct and easily applied form.
Good object oriented designers will tell you that a re-usable and flexible design is difficult if not impossible to get it “right” the first time. Before a design is finished, they usually try it themselves, reuse it several times, modify it each time and then finally, you have a design that is “good enough” One thing great designers know NOT to do is to solve every problem from the scratch or from the first principle. Rather they want to re-use solutions that have worked for them and others in the past. When they find a solution to be “good enough” they use it again and again. Such experience & thinking is what makes them part of the greats.
Design patterns are NOT about designs such as a dictionary or a tuple or linked lists or queues that can be encoded in classes and reused as it is. Nor, are they complex, domain-specific designs for an entire application. They are descriptions of communicating objects and classes that are customized to solve a general or generic design problem in a particular context.
For instance, take the example of database connectivity, people have solved this in many ways and we do have our own standard. But do we really follow through the standards in all the places? Nope…the basics are that we need to connect to the DB once and only once per request and that it should be void of injection vulnerabilities. Why don’t we use singleton design pattern for this problem and the pattern will itself make sure to create only one connection even though your code attempts again and again?
The design patterns require neither unusual language features nor amazing programming skills or tricks. It can be implemented in Python although it might take a little more work than an ad hoc solution. But the extra effort invariably pays dividends in increased flexibility and re-usability. So, the question if is should we write the operation and function files in a procedural way? Nä, this is monkey work!
If we start designing our code with the back-drop of patterns in mind then we create more robust, re-usable and testable code.
Below are the arguments from Erich to use design patterns:
- Patterns make it easier to reuse successful designs and architectures.
- Expressing proven techniques as design patterns makes the codebase more accessible to new developers.
- Reduces the need for documentation
- Easier to maintain the system
- Put simply, design patters help a designer get a design “right ”faster and thus helps him/her reach the customer faster
I will stop here for now. In my next blog, I will talk about the details involved in design patterns…Erich has a solution for the three tier architecture (Model/View/Controller)!
Stealing is NOT bad afterall, it is clever! ;-)
Back in the days when I was owner of the vision, head of development and product manager of a dotcom startup I had this really great boss. He was creative, supportive, caring, trusting, fun, really intelligent, self confident and, well, he had most all of those treats you wish all your bosses should have. Yet, he used to do one thing that puzzled and even annoyed me at times. It was when we were preparing for a meeting.
I have this way of always trying to be on the offense and to own the initiative. Not always succeeding, of course, but I imagine that thinking positive will help. I guess I’m a incurably naïve.
My boss of back then also was one to want to own the initiative. But he, generally, had a different approach. He played it defensively. Covering all bases. To do that you need to be able to think negatively. There’s the source for my annoyance. I just have a hard time following the line of thought when it goes the negative way. When preparing meetings I had to endure my boss when he raised the arguments against our case. What if they say this? What if they argue that? To me it’s “So, what if? Our offer is excellent! Let’s focus on exposing that!” I don’t want to cover all bases. I don’t want to imagine all the shit that can happen.
Yes, I’m biased. But I honestly think that my general approach is better. Go full force with your thing! If you feel it’s not good enough to throw your full support behind it, then chose another thing. Make sure you work with something you really believe in. And hone your blade. But hone it for attack. For defence trust your reflexes. Apply positive thinking. Playing the Devil’s advocate just drains your energy resources. At least it has that effect on me.
Addendum June 11 2009: I wrote this article when I was a bit upset. I’m glad that I did, but still, I think I should have asked Joakim Ohlrogge to write instead. Here’s his take (pasted from the comments):
A thought: I despise DAs more than I like them. But the question is if it is really DAs I despise or if I despise idea-poachers. It’s hard enough the get ideas to fly even without having a sniper shooting them down before they take off. It’s often all too easy to come with a “what if” and I’ve experienced some people who make it their task to figure out every obscure situation that could possibly go wrong. There needs to be some rime and reason. You can always find something that goes wrong, after all, we work with software.
I would not want to be without DAs but I don’t want them to take up more time than daring enthusiasts do. Also, they are not there to prevent disasters, they are there to inspire different though paths. A DA can never replace the ability to respond promptly when “shit happens”.
Finally, after two bounces and three weeks of waiting, our first app on App Store is available!
I’ll keep this post really short!
Some good to knows!
The App Store review process: 4 stars out of 5
If you are curious about our iPhone application, please visit our app section @ App Store.
Projectplace for iPhone
It doesnt matter whether you have “designer” written on your business card. If you are reading this blog you are most likely involved in software development – if so, the short and simple answer to the above question should be “YOU BETCHA”.
Why, you might ask, do I make this argument? Well, because I feel that everyone involved in software development should feel, act and respond like a designer. Nobody is excused, nobody should be able to hide behind statements like “heck, I just write the code – what do I know about icons?” There is no excuse for not being a designer. You’re allowed to suck at it though. The minimum level should be that you feel like a sucky designer. Why is this important?
It is important because user experience and aesthetics matter so incredibly much that if you don’t take an interest in it, you should find another job. To sum it up:
Sucking at design craftsmanship is ok! Not taking an active interest in design is inexcusable!
As long as you are actively seeking responses from colleagues or other sources in matters of user experience and aesthetics – you’re doing a great job! Well, at least you’re improving. My point is: you CANNOT sit on your rump and wait for those who actually have “designer” written on their business card to come up with a fantabulous-expicalidocious design. Agile software development does not work like that. Your team needs to take design decisions based on what is technically possible right now, you need to take coding decisions based on an overall design rationale and you need to make everything look fantastic. And you need to do this just in time. Because if you don’t, somebody else will, somebody smarter than you.
So how do you work as a designer even if you are not a “real” designer? Its easy: you take an active interest in matters of design, challenge all assumptions and you communicate.
And what if you’re a “real” designer – how do you work with all the people around you suddenly claiming to be designers? Same recipe: you take an active interest in coding and/or implementation, challenge all assumptions and communicate!
If your team is laid back, good at their jobs and generally cool and nice people. This is easy. On the other hand, if your team has a few know-it-all schmucks who wont let other’s touch their territory. Fire those and start over with achieving a fantastic, innovative and cool design process where everyone is involved. It’s all about hiring the best and setting them free.
So, to end this little article, here is a short TODO for people who think they can be involved in software development without being designers.
- Realise I am a designer.
- Make my team realise that I will be a part of the design process whether they like it or not.
- Try to stop sucking at design