Desperate to stand out
A friend of mine is a designer. She’s not specifically a graphic designer, but she has a great talent for graphic design too. I recently showed her my Codekana web page, as well as those of other products in the same or a similar space. You see, I was quite proud of the web page and its ‘bold’ look, although I knew it was a tad too aggressive. But she nailed it when she said what she thought: “it looks desperate to stand out”. Ouch! That kind of feedback can be hurtful at first, but it’s definitely the best kind of feedback you can get. She elaborated a bit on what things made her thought that, and they were all spot on, of course.
I’ve received some other “actionable” feedback about the web page. The awesome Andy Brice, author of the best-selling package for wedding seating plans and the mind behind the cunning write-ups and experiments over at SuccessfulSoftware, gently reminded me that I didn’t mention what languages Codekana worked with in the whole web site. What an oversight! Of course, I promptly fixed that. The supported languages are C/C++/C# in the current version, although I will be adding support for other languages in the future, and improving the support for the current ones. Andy also sent me some excellent suggestions on the product, which I plan to address Real Soon Now. And he also posted about Codekana on his blog, which is very helpful (thanks Andy!). It doesn’t look like I will be getting married any time soon, but I will definitely try out his software if I ever get to that point 🙂 Also, Andrey Butov, while busy releasing a new version of his Blackberry spam filter, found the time to have a look at the Codekana web site and let me know that the colors were just hurting his eyes. He couldn’t look at it for over 30 seconds.
I will redesign the web site around all this feedback, tone it down a bit, and try to give it a more relaxed and professional look while keeping a distinct look. But I’m happy I went a bit over the line: if you are learning something, you need to allow yourself to overshoot.
I now have at least a handful of different large areas of work, including marketing and improving all my products, web design, tweaks to the sales offerings, and what not. For each product, I have dozens if not hundreds of suggestions and requests that are waiting for some attention. My to-do lists are pretty daunting. So of course, now comes the moment of prioritizing tasks.
As a first priority, I decided to work in Codekana 1.1 during August, and I finally released it last week (see the list of changes in Codekana 1.1). A 1.0 is always a bit rough, and giving it some quality time is very important to get closer to “product/market fit” (as the amazing Marc Andreessen likes to put it – if you haven’t already, and you are into startups in any way, I suggest you read every single of his blog posts about startups and entrepreneurship). All in all, 1.1 is a more solid product, and I’m already looking forward to 1.2 with a few more improvements.
In any case, I expected low sales in August, as I had in August ’06. But it turns out they have been very good – ViEmu has been equal or better than in previous months, and Codekana sales have been ok-ish for a first month. Now September is finally here, with everyone back at work and hopefully even better sales.
Although there are a couple of things I want to work on in the next few weeks, I have finally come to the conclusion that my next major product release will be kodumi 1.0, my always-work-in-progress text editor, and the final goal towards which I’ve been working for well over two years now. I have also decided that I don’t want to rush a 1.0 and release a text editor with nothing special over the many offerings out there – it just wouldn’t make sense. With advanced syntax highlighting courtesy of the Codekana engine (which will also be part of the editor), I now have almost all the core functionality needed for a standard modern text editor, but I have decided against taking that route. There are some parts of the core new tech I want to get up to speed, in order to release a product that Stands Out on its own without requiring aggressive colors and huge fonts on the web page.
The short term priorities include some work in new releases of the ViEmus, a bit of marketing work here and there, a bit of blogging, and some tweaks to the sales offerings. Of course, I will release new revisions of all my products while I work in kodumi 1.0, but the main focus in the mid- to long-term now is to get kodumi out of the door.
Wish me luck!
September 5th, 2007 at 7:25 pm
Good luck with kodumi, I can’t wait to try it out.
September 5th, 2007 at 11:05 pm
Thanks for the good wishes! I can’t wait myself either 🙂
September 6th, 2007 at 7:13 pm
Best of luck with Kodumi.
Btw, any chance it will be available for us Linux users?
September 6th, 2007 at 7:17 pm
Thanks Max. About Linux: in the longer term, definitely.
I take a serious multiplatform approach to development – that’s why I have been able to host ‘ngvi’, the vi/vim emulation core behind ViEmu, inside Word & Outlook, Visual Studio, SQL Server, and the current kodumi prototype. The code is totally system independent.
My reason behind this is that, by definition, platform-dependency is not part of the essence, and I like to distill the code to its most essential elements. It also has technological and possible business advantages, but that’s just a side effect.
Also, Windows for sure and most probably OS X versions will come first, because of the commercial viability of the platforms.
September 20th, 2007 at 8:02 pm
“I was quite proud of the web page and its ‘bold’ look, although I knew it was a tad too aggressive. But she nailed it when she said what she thought: “it looks desperate to stand out”. Ouch! That kind of feedback can be hurtful at first, but it’s definitely the best kind of feedback you can get. ” — in the same spirit, the multiplicity of syntax highlighting colours is way too intrusive, and the vertical indentation lines just add confusing clutter. Just because your lexer can pick out keywords etc doesn’t mean you must do so. Syntax highlighters emphasise the wrong thing anyway, a better model is folding or something like Knuth’s literate programming. Emphasise the semantics rather than the keywords – for example, procedure calls should stand out, not the curly braces. I’d say that the comments should be the boldest text, except for the fact that in almost every program the comments end up no longer reflecting what’s in the code, yet readers believe the comments even when the code differs. If you don’t believe me, read this:
i = i + 2; // INCREMENT LOOP COUNT BY ONE!!!
🙂
October 1st, 2007 at 3:07 pm
gotal, sorry for the delay in answering. Thanks for the feedback. Indeed, I agree with the general principle, although I don’t agree with the specific conclusions you draw.
Indeed, one shouldn’t hihglight what can be detected – stuff which should stand out should be highlighted. I do believe highlighting control flow is very helpful – not because I can detect it, but because you get accustomed to seeing loops in red, “if” blocks in green, “else” blocks in brown, etc… some useful extra hints: a ‘break’ that breaks a switch statement is colored in blue (as the switch block), while a ‘break’ that breaks a loop is colored in red (same as loops and ‘continue’). This helps you see at a glance whether a loop has an early exit or not. The end result is that, once accustomed, you need not read the code to understand the control flow. That’s why I think this highlighting is closer to semantics rather than to syntax.
Other points are important, and I do plan to provide a lot of extra coloring possibilities in future versions. I don’t agree with the comments thing, as they are often/usually out of sync, but I understand where you’re coming from.
Watch out for future versions, as this is a general area I want to focus on, and I think it’s going to be pretty cool & useful!