17May / 2013

What? New Google+ is beautiful? You must be joking

 at Times wrote in his post The Tragic Beauty of Google+:

The service, which was already pretty darn slick, is now among the most attractive and engaging web apps I’ve ever seen. … it (Google+) now has its own style and signature features. … It’s fun to use.

No. It’s not. It sacrifices the usability of the product in exchange of a superficial look of pretty.  The design stands in the way of presenting the content.  It is easy to whip up a “beautiful” page by throwing together some nice fonts and high quality pictures.  But engaging? Fun to use? I don’t think so.

Here are the three major problems I noticed.

First, images are out-of-proportionally big.  They steal the attention away from the texts. Here is the What’s Hot page.

Image too overwhelming

It looks pretty because of the two high quality photos which have taken up the majority of screen real estate.  You eyes will inevitably look at Larry’s face and the new Android Studio but did you notice much of the text at all? Did you realize that Android Studio is based on IntelliJ IDEA? (That news is, in my opinion, probably the most important and positive one for the Android developer community.)

Here is what I get if I hide all the images.

Image too overwhelming no image-

Do you notice the text content better? Do you realize how huge those images were?  Sure this can’t be a good design unless Google+ wants to become the next pinterest clone.

The second problem is that the reading experience is weakened even further by endless demands for actions.  Google+ constantly asks you to do things. Lots of them.  Now, go ahead and count how many actions you are suppose to do in the following page.

Too noisy, too many actions

 

I found 27, how about you? This does not even include the 3 drop down lists which will certainly give you more work.  And we are cheating a bit here. The space taken up by “Where did you go to school?” block could easily pile in another 10+ actions if it’s a normal news block.

Third problem, the lack of discipline in using the whitespace.  Whitespace is one of the most powerful, visually pleasing and least intrusive way to bring orders and visual hierarchies to a design. Yet what do you think of the whitespace in this Best of #Python page?

Best of #python

What is this?! The only thing that seems to be useful is this one single line: “Hy: Lisp subset that compiles to Python”. The rest of the screen space? Wasted.

Let’s take a step back and think about what’s the goal for Google+. It’s fundamentally a river of short messages that might be interesting to the user.  I imagine most of the times people would just scroll through and see whether something catches their eyes. The new Google+ fails to deliver an experience that maximizes this goal.

PS. Even at a pure visual design level, Google+ is still not up to the standard. The vertical alignments, margin between elements within one block would use more refinement. The avatar is inconsistent. Sometime they’re round.  Most of the times square. But arguing design for design’s sake is missing the point here. It has to be functionally useful first. Without that, it’s a castle on the sand.

Posted in design

Permalink 19 Comments

05May / 2013

Those decision making moments

What represents a good entrepreneur?   Some would think a talented engineer furiously coding on a clever algorithm; or the CEO in his suit winning some award.  I think those are only a tiny fraction of startup life. They are not as interesting as one might think.  If you are an experienced programmer and you know what needs to be done,  you just go ahead and code the solution out.  It’s like a good walk in a park.  Enjoyable but nothing fancy.  Winning awards? It’s an important milestone but not a good indication of the process.

I think it’s the ability to make good decisions.   By definition, a good entrepreneur is the one who makes most important decisions right.  A corollary is that for a startup with two founders, it’s about make the right decisions together.

The two founders should come out of the debate with a better  idea, one that weren’t there in their mind before the debate started.  This would require the two founders to sit down,  carefully listen to what the other is saying,  comb through what works and what not, acknowledge the weakness of his own solution and, usually as a by-product of doing all the above, creatively come up a brand new idea that takes the best parts from both while avoiding the known problems. If you can do that, you’ve got a winning team.

PS. When people say a solo founder is really hard,  they probably mean solo founder doesn’t have someone to bounce off ideas with.  Hence he may miss the opportunity to get to a better solution.  So in my opinion, if you are a solo founder, go find yourself a strong advisory board, have someone you trust and use them to tease out the best ideas that weren’t in your mind.

 

Posted in culture, design

Permalink 1 Comment

07Apr / 2013

What’s wrong with TechNZ’s evaluation process

I’m on the advisory board of the dental software company Software Surgery.  We have had such a frustrating experience applying for a TechNZ funding that I believe New Zealand needs a government grant/funding option designed specifically for software startups.  The current system is probably well designed for manufacturing products but they are just unsuitable for software projects who can use helps from the government.

To evaluate a software startup’s worth, I’d look at three things: idea, founders and the market.

The idea is simple: dentists are still referring patients to each other using paper based forms. Every year, there would be patients who “fall through the crack” and, as a consequence, their treatments were delayed. Bad things happened. The dentists get severe penalty. Yet dentists are among the most busiest people in all professions. They are constantly under time pressure and unhappy patients.  Stacy’s software makes it really easy for dentists to track and follow through a case to make sure the referrals have been taken care of.  Clear problem. Well designed solution.

Solid team. Stacy, the CEO and founder of the company has sold his previous company in 2003; He is building the product using his own money from selling the previous one.  Before taught himself design and programming, Stacy spent more than 15 years as a dentist.  I haven’t seen anyone who have so much in-depth knowledge in programming, design and dental industry.  Talking about domain knowledge and startup experience, I wouldn’t expect anyone better than Stacy to take on a dental software.  Besides We also have John Hamilton, who sits on the Dental Council of New Zealand as another advisor.  John has to write reports for different medical cases due to “referral accidents”. He has personally made sure that the software is usable and provide the tools and workflow dentists would use. And no more.

The market: there are more than 2000 dentists in New Zealand. More in Australia, UK and around the world. Most dental clinics have computers but no one so far can track referrals, check updates, provide great tools to attach X-ray pictures. Mature market. Ready for the product.

Yet, as we went through the TechNZ process, we have to answer questions that are just utterly unfit for software projects which moves really fast and the margin to replicate is near to zero.  My favorite one is a table to fill in a year-to-year “revenue project for 7 years”.  7 freaking years!  I believe the people working in government’s Economic Development Unit have the best intention to make sure that tax money are not wasted.  But with the wrong framework and process, they are wasting time and money.  Even worse, they are not solving the problem but they have become part of the many obstacles that an entrepreneur needs to overcome.

The following is the email Stacy sent to withdraw his application, which gives an excellent view on the different between a software project and a typical ‘industrial’ project.

———————————————-

I’d like to withdraw the grant application, because now that I’ve seen more of the process involved in the grant it’s become apparent that our project isn’t a good fit for it.

In the environment that we operate in, key attributes are agility and responsiveness. Once users get their hands on our product, we’ll need to be able to rapidly and probably quite dramatically adapt our plan and processes to what we discover. Very small details which can’t be predicted can alter how we need to proceed. For example, it may be that users see value in some aspect of our solution that we hadn’t anticipated and we need to change our sales model to give away for free what we had intended to charge for in order to leverage that value. I could give you a list of imagined cases with a risk assessment and mitigation plan for each, but it would be truly pointless; what I can tell you for sure is that whatever we try to predict, the reality will be different.

I agree that there’s a need for diligence in administering grants – it’s just a question of degree, or the level of detail that is useful. At one extreme is a guy who has a concept but no clue how to build it or market it; at the other is a guy who spends 10 years planning out every minute detail and never builds anything (I’m referring to “paralysis by analysis” here). Real startup projects sit at various places on that spectrum, and the art is knowing how much planning is helpful and how much is a hindrance.

I’m an investor in this project, and I wouldn’t have spent a cent on it until I got a team together that I was confident would be able to adapt and solve problems across the full range – business strategy, sales, design, development and administration. The key difference is that I believe the greatest risk mitigation strategy in this environment is the team iteself; predicting the details of what the team is going to encounter may create the illusion of certainty at the outset but it quickly becomes irrelevant.

The other issue that I’m encountering is that the process is too slow for our project, and the time that I need to invest in creating the illusion of certainty is a risk to the project in itself. We’ve already started spending on it and because only expenses after the approval date are eligible, the value of the grant to the project has already changed significantly. In other words, the project needs to move rapidly and the grant process can’t move rapidy – so again it doesn’t seem like a good fit.

I hope that this makes some sense. It’s a complex decision and I can’t give you a rich understanding of where I’m coming from in a short Email unfortunately; but perhaps it will be sufficient.

Thanks to you both for the effort and time that you’ve put in, and no doubt there will be news about how things are going from time to time. I’m not arrogant enough to assume that it’s a sure-fire thing and my approach is the only one – but from what I’ve seen and experienced it’s the approach that I want to bet on.

Kind Regards

Stacy

Posted in startup

Permalink Leave a comment

10Mar / 2013

Limitation of open source projects

My friend Rodney wrote me an email responding to my previous post of “understand open source“.   His comments led me into some deeper thinking of the difference of open source and commercial software projects. And what they can learn from each other, which I will publish a post later. (Disclaimer: I’m an independent advisor to OceanBrowser, Rodney’s company.)

It is not my intention to draw a black-and-white line and assert “open source is all good and commercial software are just evil”. Quite contrary to that, I’m strongly against monoculture. Either it’s only open source or only commercial software.  Plus, these two terms not even exclusive to each other nowadays.  Android and Ubuntu are both large scale open source projects run by a commercial company, for commercial reasons.

So before I go on and share Rodney’s reply. Let’s remind ourselves that I’m also against the idea of over-generalization. So please read the following with a large grain of salt.

“So if I am missing a needed feature in a project and I do nothing about it, it is my own fault for not getting off my lazy arse and taking advantage of the participation opensource allows.”

Characterizing a user as lazy because they don’t want to get involved in this way isn’t constructive.  The world is full of complicated things that don’t work – there may be a mismatch of expectations, especially around suitability for purpose, quality, and reliability.  ”taking advantage of the participation opensource allows” could be a euphism here for someone disappearing down a rabbit hole of forums, testing and so forth that completely diverts them from the user from what they were trying to do.

“With a proprietary product, if I like it, the only way I am allowed to participate in it’s improvement is by buying it.”

Do you believe this?  Most of the people who have contributed to helping in the development of OB3 haven’t directly bought it – students, teachers etc.  It suggests that closed source developers are fixated on financial returns or money as an indicator of importance.  Which I would reject, at least in our case, the contrary position is it is about control and design, it can just represent a choice about how you want to build your vision.  Then there are all the projects out there where the product is closed source but big chunks of the underlying platform are open sourced.  Or ones which are open sourced with a close source commercial build for “enterprise”.

For the time starved user who reads the hype about some open source product, pours hours and hours into learning about it (event pit) installing and configuring, only to find that it is unstable and bug ridden, they are supposed to now fix it – or shut up?  I’m not the type that slags OS projects by the way…. just putting the contrary view here.

“So my buying dollars dont directly go to the improvement of that product”

It may depend on the type of product you are talking about, and how you define what is “improving the product” – is it just engineering?  If the product needs design, research, maybe you need a team working full time on that – and someone has to pay their salaries.Anyway,  better get back to work… above could do with more drafting.  This article reduces closed source/ commercial development to a caricature – not all closed source firms are evil money focused bottom line etc…

 

Posted in open source, startup, strategy

Permalink 1 Comment

16Feb / 2013

Understanding Open source

I have started doing some research on how open source communities are governed. My goal is to use today’s open source projects as a way to figure out how to run a community when the only force that put people together is love and interest.  I’ll publish my notes and whatever interests me along the way here.

This is an excellent short piece on why open source’s “success” is not what a “marketer” would expect.

With the opensource system, if you find any deficiency in the project, the onus is on you to redress that deficiency. Opensource projects provide you with the means and mechanism to not only remove inadequecies in any part of the project but also to improve the project. Without this positive feedback loop an opensource project dies. Opensource doesnt improve by advocacy, mindshare, or by having 10 million users, it improves by the participation and contribution from the user community.

What that boils down to is, if you see something wrong and do nothing about it, the opensource system hasnt failed you, *you* have failed the opensource system.

So if I am missing a needed feature in a project and I do nothing about it, it is my own fault for not getting off my lazy arse and taking advantage of the participation opensource allows. One of the things that really annoys me is the continual slagging of some of the other opensource projects that get more media time. It is ok slagging a proprietary product as often you have no other way of getting your neck into the user-development feedback loop. But slagging an opensource project is ignorant. The whole mechanism exists to empower the user. If there is something that would cause that person to slag a project then it means enough to them to do something about it. In simpler words, fix it! :)

As a rule marketers count bodies lol. With a proprietary product, if I like it, the only way I am allowed to participate in it’s improvement is by buying it. The more I buy, the more likely it is to be successful and provide me with something stable and persistent in the future to develop and deploy with. The more users that buy the proprietary product, add to that companies ability to improve that product. This includes not only the cost of the development but all the other stuff that goes along with it, like profit, marketing etc. So my buying dollars dont directly go to the improvement of that product, even so lots of users is good for a proprietary products future.

Posted in open source

Permalink 1 Comment

29Jan / 2013

Better way to teach beginning programming classes

As a programmer myself, I find it hard to believe that high school students would find programming boring. What?!! “Computing is one of the most exciting things that human mind can do“, how could it be boring?

Today my friend sent me this link, which kind of explains why.

Here’s a template for a first programming class: Use a book with a language name in the title. Start with the very basics like formatted output and simple math. Track through more language features with each chapter and assignment, until at the end of the semester everyone is working with overladed operators and templates and writing their own iterators and knows all the keywords related to exception handling.

If you’re a student in a class like this, you have my sympathy, because it’s a terrible way to be introduced to programming.

The author went on to say:

Once you’ve learned a small subset of a language like Python–variables, functions, control flow, arrays, and dictionaries–then features are no longer the issue. Sure, you won’t know all the software engineery stuff like exceptions and micromanagement of variable and function scopes, but it’s more important to learn how to turn thoughts into code before there’s any mention of engineering.

I’d even go so far as to say that most OOP is irrelevant at this point, too.

My real template for a first programming class is this: Teach the bare minimum of language features required to do interesting things. Stop. Spend the rest of the semester working on short assignments that introduce students to problem solving and an appreciation for the usefulness of knowing how to write code.

I believe this was the exactly how Little Schemer teaches programming.  That is, to treat learning programming as a training for problem solving skills instead of a way to memorize syntax.  I thought the problem has been solved when the book was published back in December, 1995 but apparently it has become almost too old to matter that much anymore.

 

Posted in code, education

Permalink Leave a comment

28Jan / 2013

Ward Cunningham answered “Do wikis have to be ugly? “

I have been bothered with the question “does community site have to be ugly to succeed” for a long time.  You see, most of the successful long running community sites are ‘ugly’. Think reddit, hacker news, slashdot or metafilter. On the other side, you have the digg redesign fiasco, although one can argue that whether the strong correlation here equals to cause-and-effect. But it is a fact that Matt, the owner of Metafilter, once redesigned the site to be more ‘web 2.0′ and noticed a significant traffic drop when he A/B tested the new design using live traffic.

Why?  Isn’t this against the human nature of appreciating order and beauty? Does it mean that all of our knowledge in fonts, colors or layouts are useless?  Or maybe there are something unique about community sites?

The father of wiki, Ward Cunningham, gave a talk about his new wiki idea a couple of months ago.  Something he said about the design of wiki finally answered that question for me. Here is what he said:

Someone came up to me and said “the idea of wiki is neat but do they have to be ugly? “.  My answer was “yeah, basically they do.  Because when you make it beautiful, then anybody that can not match your beauty has been closed out of the conversation. So I say clean and simple. “

It is my belief that each service/product needs to be optimised to serve its core need.  The fundamental role a community site performs is a platform to get “fresh and unique thoughts” from its members. Anything else is merely a tool to the end.   Counter intuitively, inhibiting the urge to make things visually appealing actually helps to achieve this goal.  Because the more attention people devote to tweak their look-and-feel of content, the less time they would spend to make it more intellectually interesting.  So accidentally, the ‘ugliness’ of the community site turned out to be a killer feature that helps to keep people focus on talking about their thoughts, even though I bet most sites didn’t start realizing that.

Posted in culture, design

Permalink 2 Comments

27Jan / 2013

There’s More to Life Than Being Happy

In September 1942, Viktor Frankl, a prominent Jewish psychiatrist and neurologist in Vienna, was arrested and transported to a Nazi concentration camp with his wife and parents. Three years later, when his camp was liberated, most of his family, including his pregnant wife, had perished — but he, prisoner number 119104, had lived. In his bestselling 1946 book, Man’s Search for Meaning, which he wrote in nine days about his experiences in the camps, Frankl concluded that the difference between those who had lived and those who had died came down to one thing: Meaning, an insight he came to early in life.

As he saw in the camps, those who found meaning even in the most horrendous circumstances were far more resilient to suffering than those who did not. “Everything can be taken from a man but one thing,” Frankl wrote in Man’s Search for Meaning, “the last of the human freedoms — to choose one’s attitude in any given set of circumstances, to choose one’s own way.”

Frankl worked as a therapist in the camps, and in his book, he gives the example of two suicidal inmates he encountered there. Like many others in the camps, these two men were hopeless and thought that there was nothing more to expect from life, nothing to live for. “In both cases,” Frankl writes, “it was a question of getting them to realize that life was still expecting something from them; something in the future was expected of them.” For one man, it was his young child, who was then living in a foreign country. For the other, a scientist, it was a series of books that he needed to finish.

via The Atlantic. This seems to fit with the concept of “Find something more important than you are and dedicate your life to it”

Posted in life

Permalink Leave a comment

25Jan / 2013

Segregating the old and the sick enables a fantasy

Z and I have always wanted to have our parents to live close and take care of them when they get older. It does not make sense, we have been told. You don’t want to see the long and slow decay. Then I saw this piece on NYTimes: you are going to die.

Plenty of people before me have lamented the way that we in industrialized countries regard our elderly as unproductive workers or obsolete products, and lock them away in institutions instead of taking them into our own homes out of devotion and duty. Most of these critiques are directed at the indifference and cruelty thus displayed to the elderly; what I wonder about is what it’s doing to the rest of us.

Segregating the old and the sick enables a fantasy, as baseless as the fantasy of capitalism’s endless expansion, of youth and health as eternal, in which old age can seem to be an inexplicably bad lifestyle choice, like eating junk food or buying a minivan, that you can avoid if you’re well-educated or hip enough. So that when through absolutely no fault of your own your eyesight begins to blur and you can no longer eat whatever you want without consequence and the hangovers start lasting for days, you feel somehow ripped off, lied to. Aging feels grotesquely unfair. As if there ought to be someone to sue.

We don’t see old or infirm people much in movies or on TV. We love explosive gory death onscreen, but we’re not so enamored of the creeping, gray, incontinent kind. Aging and death are embarrassing medical conditions, like hemorrhoids or eczema, best kept out of sight. Survivors of serious illness or injuries have written that, once they were sick or disabled, they found themselves confined to a different world, a world of sick people, invisible to the rest of us. Denis Johnson writes in his novel “Jesus’ Son”: “You and I don’t know about these diseases until we get them, in which case we also will be put out of sight.”

Posted in life

Permalink 4 Comments

22Jan / 2013

One fundamental difference between ElasticSearch and Solr

important update: The recent release of Solr 4 has addressed the difference mentioned below. Now Solr handles replication similarly to ElasticSearch. Even better, a transaction log has been added for durabilities. So please be aware that the information below is more a comparison between ElasticSearch and Solr 3.

Most of the articles comparing ElasticSearch and Solr fall into two groups.

The first group would give some performance test and declare one outperforms the other. Like this one from socialcast.  If you dig deeper though, you’ll realize that it’s not a fair comparison. The ElasticSearch’s read will waste too much time in routing with the default 5 shards settings;  For Solr, you are not supposed to call IndexWriter#commit for every write request anyway. The author also ignored the fact that Solr 4′s soft commit would make search while indexing a lot faster.

The second group provides feature-by-feature comparison like the Sematext one.  This does provide a more comprehensive view on what’s available in each package. Let’s be honest, most of the features can be implemented given enough time.  I’m sure ElasticSearch will have a proper SpellChecker soon and it won’t take too long for Solr to have a percolate feature implemented.  Unfortunately, this hides the fundamental architectural differences between the two, which is actually crucial for people to decide which one to choose.

Actually, there is only one fundamental difference here but it does have far reaching consequences on how each would perform. The difference is how the distributed replication works.

To understand this, you have to look at Lucene’s index on disk first. Lucene stores its search index in immutable segments and then as more documents are indexed, these immutable segments will be merged into new, and more efficient, ones.  Inevitably, this will incur non-trivial disk read/write. It’ll be slow.  Within Lucene, this usually happens when a commit call happens. (To keep things easier, let’s ignore the difference between soft and hard commit in Solr 4 for now. )

Both ElasticSearch and Solr use Lucene to store their search index but how the changes replicated to different servers differ.

Solr will copy the new segment file to different servers. This works great when you don’t need to add new documents to your search index too often.  But in the age of an endless stream of contents keep flowing in and the needs for near real time search, this decision is seriously holding us back.

You see, there is an inherent conflict on how often to call commit here.  If you want your new content to show up in other search shards, you want to call commit as often as possible so that new segments can be created and copied over. However, if you want to index fast, you want to avoid, or at least delay, commit at all cost so that you can keep indexing stuff without cleaning up the disks.

ElasticSearch solved this problem by sending the same document to be indexed by all the search shards.  To be more precise, all the replica shards. This way, you will never need to call commit to get your index shipped to other server. You can index as many as you like and still have all information available to all replica shards.

One important result of this approach is that ElasticSearch offers a much robust single server deployment by having a write ahead log. Even if you kill it brutally, you know the dash 9 thing, a single node ElasticSearch would still be able to recover, replay and keep going. Try that with Solr and you’ll have to manually fix the corrupted index.

Another important consequence  is that it’s relatively easy to have a High Availability built-in.  If the primary shard goes down, one of the replicas can take over and elect itself to be the primary without causing too much troubles because all replica shards have already had the same content.

There is one minor downside to this approach though. If your application has a high rate of modification to the same document, then that change might arrive at the replica out of sequence. This can be addressed by using versioning but I really doubt a search engine will have such a high modification rate.

I hope this clarifies things a bit. I also hope that now if you look at the feature-by-feature comparison, you would appreciate the differences better by understanding what’s the rational behind them.

Posted in code

Permalink 6 Comments