TinderBox – putting the personal into an application

I just got an excellent example of why talking like a human being works so well for micro-ISVs.

Tinderbox is a personal content management assistant/outliner on steroids for Macs that is consistently is on the short list for thay kind of tool. Here’s what Mark Bernstein, the creator of Tinderbox, wrote in his intro to a book on the product:

Tinderbox is personal in another sense, as well; unlike most corporate software today, Tinderbox was designed and implemented by a person – not by a committee, a corporation, or a focus group. That person is me: Mark Bernstein. I designed Tinderbox, and wrote just about every line of the tens of thousands of lines that make Tinderbox run. Tinderbox is the product of an individual vision. It wasn’t written to meet requirements or specs or to adhere to business rules. Along the way, there have been thousands of decisions – engineering decisions, artistic decisions, operational decisions. In the end, I made the choices.

Unfortunately, I’m presently a Windows developer; I get Mark’s emails in the hopes that one day he’ll do a Windows version.

If he does, I know he will stay true to his vision of what his app should be.


read more
Bob WalshTinderBox – putting the personal into an application

The Apple iPhone & why design matters.

By Bob Walsh

This morning I’ve been reading the live blogging coverage of Steve Jobs’ iPhone announcement both at engadget and at ZDNet and I’m struck by how by focusing on design Apple, Inc. has again taken us into the future we all want.

The hardware pieces have been around for years – but no one has had the guts to say, this is something new, and it needs to be true to itself. Apple Inc. (formerly Apple Computer, Inc.) has created something so incredibly well-designed it redefines what a phone is.

Way too often software designers are more like Peter Keating than Howard Roark in Ayn Rand’s Fountainhead: they build steel skyscrapers but stick a Roman temple, Victorian latticework and Gothic arches on it to make it “safe”, “popular” and “acceptable”. We have applications with Explorer panes, Outlook panels and toolbars not because those controls express what the application is, but because they make the app “safe”, “popular” and “acceptable”.

Micro-ISVs cannot afford to be safe because to succeed we need to produce apps that get people excited. Micro-ISVs cannot afford to be popular – we don’t want 10% of everybody, we want 80% of .0001% of the Internet to love our products. Micro-ISVs cannot afford to be acceptable, because what’s acceptable to IT departments and enterprises is conventional crap that no one ever got fired for signing off on.

Way back in the last century I was a “permanent” temp IT guy at American President Lines when it was still a proud American company headquartered in Oakland, CA. Over about two years I and a few other people brought about 200 Macs in through the corporate back door to replace aging Multimate Word Processors . Mac’s weren’t the safe, acceptable or popular corporate choice then, and neither is your micro-ISV app. Get over it.

Two last thoughts about design and micro-ISVs:

  • You don’t have to be a “graphic artist” to design an app that is true to itself. It doesn’t hurt to have some visual sensibility, but the biggest requirement is to stop trying to look like every other app out there. If you need graphic resources, you can find them.
  • Micro-ISV can build value on the shoulders of others. Whether it be third party commercial controls or Open Source stuff or adding value to the big software ecosystems out there like Microsoft Office, Mac OS, or Vista, or the Apple iPhone, micro-ISVs have the chance to dig deeper into all the problems smaller than the lowest common denominator stuff. If your micro-ISVs’ app goes in this direction, don’t try to look like Office or whatever: go further.

[tags]Apple iPhone, iPhone, micro-ISV[/tags]

read more
Bob WalshThe Apple iPhone & why design matters.

Localizing and Translating Software

By Ryan Smyth
(Winner 2006 Silver Faucet Award
Guitar and Drum Trainer – SIA Best Application Using .NET 2005 and 2006)

Everyone has their own take on who, what, when, where, why and how to localize and translate software. The marketing guys want everything and have no clue what it is beyond, “a new Japanese version”. The programmers will sometimes ask for an Excel file with all the strings in Japanese. The translator that got hired by the intern is about to finish high-school and will do whatever he’s told. The translation company that got hired after the kid got fired would prefer things done their way, but since you’re paying they’ll do whatever you ask. It can be a real mess trying to get things done.Since I’ve pretty much done everything from end to end at least a few times or more, I think I’ve got a fairly well balanced opinion on how to get things done right. I’ve worked on pretty much everything from professional journal articles and ad copy to small applications and documentation to large projects that incorporate client applications and server daemons with integrated websites. In each area different approaches and processes can work better and while there’s no “one right way” to get things done, there are some general principles and things that can help to keep the flow tight and produce good results. If you’re considering having your software translated, then hopefully this article will serve as a decent basic primer on software localization and translation issues for you, and point out some trouble spots and things that you will need to consider.

This time around I’m working on another few relatively small end-user applications, and sitting on the opposite side of the fence for one of them. For the sake of ease I’ll call them “App A” and “App B”. I’ll refer to them as examples from time-to-time.

Interpretation – Not Translation

I’ve already ‘translated’ App A before, end-to-end from the GUI and documentation to web content. I say ‘translated’ because while people understand that, that’s not really what I do. I don’t believe in ‘translation’ per se for software and web content (or much of anything else for that matter). It’s just a bad idea. You invariably end up with weirdness. Instead, some kind of ‘interpretation’ works better to get things right in the target language. Sometimes that means cutting things out and re-writing large sections. This is more important the further away you get from the original language group. e.g. While it’s pretty straight-forward to go from English to Spanish and vice-versa, you’ll have a tougher time going from English to Japanese and vice-versa. At all times you’ve got to keep your eye on the most important aspect of the ‘translation’ – your users.

Doing Things Right the First Time Around

Back to App A… While it’s already been translated, the original translation was pretty much unusable beyond itself. It was done directly in the EXE file and since then has undergone some serious upgrades with new resources and deleted resources, which I was expecting. So a good amount of work is getting redone and the work that has already been done is relegated to wasting time with copy & paste.

However, this time around it’s getting done right. The translations are now being pulled out into resource DLLs (the software is done in C++) that can be easily translated later on. That doesn’t help at the moment, but it’s certainly a step in the right direction.

If you’ve never pulled resources out into resource files, it’s a very good idea to start programming like that now. If you ever do localize and translate your software, you’ll be ready to do it very quickly, and it will make the actual programming more manageable for you.

The Right Tools

I’ve seen software translations done in Word, PowerPoint, and Excel. They’re almost always the wrong tools to use. PowerPoint and Excel have no place at all in any software translation. Word on the other hand does have some good uses, and they’re always called “Track Changes”.

Tracking changes in Word is most useful for larger projects where you need to keep track of the quality of a translation. Once the original translation is done, you’ll need to have it copy edited and then proof-read if the copy editing shows that the original translation had too many errors. Judging what constitutes “too many errors” is shouldn’t necessarily be numerical though; the type of error is more important, e.g. style considerations are often more important than simple tense, particle or article errors.

That isn’t the ideal way to get a translation done as you introduce extra steps where human error can occur, but it does give you some more control over the quality of the translation if you can’t do it yourself. For a typical small mISV I wouldn’t recommend going that route as the number of steps becomes much larger and the costs of doing it that way increase greatly.

Regarding human error, one problem that I’ve seen far too often is ‘copy and paste’ not being done right. The low-paid person handling the final document invariably ends up missing some characters when copying. Then again, I’ve seen people start re-typing things, which is an even worse idea.

While Word and tracking changes is good for quality control, it’s almost always better for the translator and editor/proof-reader to make changes directly in the resource that will be used. This eliminates any possibility of human error being introduced through copy and paste or retyping. If you’re using the ‘copy and paste’ method, you should probably get your proof-reader to go over things once more, which is an unnecessary step.

There are some very good translation tools available for a variety of uses. I use appTranslator (http://www.apptranslator.com/) and am very happy with it. It’s easy to use for translators and keeps things simple. While it may be missing some features that some more expensive solutions offer, it more than makes up for this in usability. i.e. You can either pay your translator to learn some new complex translation software, that you’ll have to pay for, or you can give them a free appTranslator Translator Edition that is highly-intuitive and simple to use. I’ve never missed anything or needed anything that I don’t already have in appTranslator.

If you want to keep costs low, then appTranslator is ideal. The professional version is reasonably priced and you can distribute a free ‘translator edition’ to your translators. Many other solutions require you to pay for the software licenses for each translator. This can really bring your costs up very rapidly, especially if you’re planning more than one translation. Also, with the easy to use interface in appTranslator, your translators won’t be fussing around with low-level or difficult interfaces that increase the risk of them making errors, either technical or grammatical. Those costs are invisible, but can end up costing much more when you end up redoing work that should have been ok in the first place.

There are several key benefits to working with resource files and a tool like appTranslator:

  1. Translation is done at a low-level which eliminates intermediary steps where human-error can be introduced.
  2. The work process is simplified greatly, which allows your translator/copy-editor/proof-reader to focus on their tasks, and not technical issues.
  3. You protect yourself against future upgrade issues with the ability to import translations from previous versions of your software.

On a side-note, I don’t believe that the cost of software should always be determined by a feature set; service and support takes time from real people and quite often that quick response to a support email can save your bacon. I’ve found that Serge, the appTranslator developer, is quick with support emails and very responsive. For me this adds significant value to the application as I’ve got someone to get answers from if I need. For many mISVs this probably strikes home as a real advantage that we as small developers have over larger companies with complex, slow, and often frustrating support procedures.

The Right Process with the Right People

Using the right tools is often enough to basically force you into a process that will produce a high-quality translation for you. However, even the best of tools will give you enough rope to hang yourself. These dangers are often avoided by using the right people to get the job done.

App B has already had its interface translated into Japanese, so only the documentation and web pages remain. The application will still need to be proof-read though. Since it’s a utility with some technical language in it, using an excellent translator that does fashion and tourism translations probably isn’t a good idea, so we’ve enlisted a Japanese proof-reader that works in IT.

While this should be a no-brainer, I’ve seen more than one translation done by someone who didn’t understand the subject matter, and the results were very poor. Don’t think that you can get just any-old “native speaker” to work on the project. It won’t work. Just for example, take something like the short paragraph below and ask your grandmother to explain it to you:

“Editing compressed audio will degrade the quality of the final product unless the compression is lossless such as with FLAC. Another consideration for achieving better quality results is to use a higher bit-depth and sample rate. However, if you’re recording at something like 48,000Hz, then you’ll want to make sure that you have a high-quality sample rate converter if you’re publishing at 44,100Hz.”

Nothing too difficult there, but if your translator doesn’t understand what FLAC, bit-depth and sample rate are, you’re bound to end up with some pretty bizarre stuff at the end of the day.

For another perhaps more poignant example:

“Instead of using where, try using an inner join.”

In that example your translator doesn’t have any choice but to leave “where” as “where” and “inner join” as “inner join”. The terms are opaque and not subject to translation as they are a part of a computer language and not a human language. For cases such as those, it’s important not only that your translator understand what a “where” clause and an “inner join” are, but also that you properly format them with italics, bold, a different color, or some other way to denote that they are opaque. Special formatting may not be possible in some dialogs or message boxes, which only goes to reinforce that your translator should be competent in your subject matter.

Consistency in the Original

If you start with dog-poo, the best translation you can expect is shiny dog-poo. And they both stink. Make sure that your original application and documentation are good quality.

A large part of that quality is being correct and consistent in your writing style and choice of words. E.g. “click”, “press” and “select” all have different meanings and should be used consistently in the correct places. You click a button with your mouse. You press a key with your finger. You select an item from a list with your mouse by clicking on it. E.g. “Press F4 to display the Preferences then click the ‘Advanced’ button to display the ‘Advanced Preferences’. Under the ‘Languages’ heading select your language from the drop down menu.” You wouldn’t click the F4 key and you wouldn’t press the ‘Advanced’ button.

Also make sure to be specific in what you mean and avoid ambiguous terms. “Upload”, “download” and “transfer” all have different meaning. “Transfer” includes both “upload” and “download”, and shouldn’t be used unless you want to include both cases.

When you have an item or function that has several synonyms, choose one and stick with it. While in general prose it’s nice to mix up the language for style, for software it will only create confusion, and for your translator, this can be disastrous. Are you talking about two different things or the same thing?

For some things synonyms should be divided to mean different things. E.g. “Options” and “Preferences”. “Options” is typically better for a main menu item while “Preferences” is typically better for sub-menu item. This is moot if you only use one of those words, but there are other situations where the general principle will hold, e.g. “folder” and “directory”.

If you need to, create a glossary of terms while you’re writing your interface and documentation. This will help you keep things consistent for you, your users, and your translator. Remember that things can take on radically different meanings in another language, and clarity in your original not only produces a better product in the original language, but also in any translations that you create.

A Small Technical Note

Formatted strings are wonderful and beautiful and make life grand, but don’t put more than one variable in them if you can avoid it. It’s better to break them into smaller manageable chunks with one variable per formatted string. For example:

("%d results returned for %s", count, term)Could also be written as:

("Search for %s returned %d results", term, count)What happens when your translator creates a wonderful, elegant translation for the second of those two and it reads something like:

("%d results returned for %s", term, count)Ooops. Your program just threw an error because you ended up with mismatched types.

Instead, try something like this:

("Search Term: %s", term) ("Total Results: %d", count)The problem becomes worse when the types are the same because you won’t even catch an error and the output, while technically correct, turns out to be gobbledy-gook when someone reads it.

Another Technical Note

App A and App B are done in different languages, C++ and Delphi respectively, and have different translation methods. While the resources are all neatly contained in language resource DLLs for App A, App B is using INI files instead. Both have certain advantages and disadvantages.

INI files are most certainly much easier to translate with a simple text editor like Notepad or EditPlus, while DLLs require special software that can cost you a few dollars. If forced to choose between them, I’d side with DLLs in a heartbeat. The pain of having to use/buy a special tool is small compared to the advantages of being able to easily manage those language resources and update them.

While examining the INI resources for the Japanese translation of App B, each and every variable in the INI file needs to be manually checked between versions. This is time consuming and costly. For App A, it’s just a matter of importing an existing translation into appTranslator, which takes all of 5 seconds.

The point here isn’t so much that it’s faster, but rather that maintaining the application is both more accurate and easier.

For my flagship product (Guitar & Drum Trainer, or simply GDT), I program in C#, and while I never did release the previous translations of the previous version (due to lack of time), I will be localizing and translating the current version again into Korean since it’s a complete rewrite. For me those maintenance issues are less important as I speak English and Korean and can very easily fire-up Visual Studio and make any changes to the program that I need. If you don’t speak the language that you’re translating into, then you don’t have that luxury and maintenance becomes a greater worry.

If you’re programming in .NET, then there are some convenient tools available to you and your translator. For Visual Studio 2005, look for “WinRes.exe” in “C:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\Bin”. You can find more information about it at http://msdn2.microsoft.com/en-us/library/8bxdx003(vs.80).aspx.

The Help File from 3 Perspectives

I write the documentation in English for GDT and for App B. I’ve already mentioned some of the important considerations for writing above, and they all basically boil down to clarity and consistency. From this perspective, things are fairly easy to deal with.

However, App B has Japanese documentation. Yikes. I don’t speak Japanese and won’t be able to personally ensure the quality. For a case like this, the process needs to be more robust to take care of quality issues.

GDT will have Korean documentation, but since Korean isn’t my native language, I know that there’s no way I’m going to touch that. I’m fine with translating the actual application into Korean as I’ve translated a few audio and multimedia applications from Korean into English and have an excellent grasp on the language in that area, so I have a proof-reader for that. Prose is a different story entirely and recognizing my limitations there is important. For that I’ve got a translator working on it.

The help file for App B is quite long and maintaining it could be problematic. The documentation for GDT is fairly short and is unlikely to expand to a level where maintenance becomes a real issue. For this my translator simply opens up the HTML and starts typing. Nothing difficult or complicated there.

Back to App B… As maintenance plays a very real part in the product life-cycle, it’s important to manage those help file resources as easily as possible while still maintaining a high level of quality. As the Japanese are well-known for perfectionism, quality is especially important.

The process I’ve chosen for this project is slower and more complicated, but is designed to keep quality high and keep the help project maintainable. I’ve chosen two tools for that:

  1. Help and Manual XML Edition
  2. Microsoft Word

The approach here is more like the old-fashioned edit-on-paper method. The basic translation is done in Help and Manual, exported to a Microsoft Word format for editing with the Track Changes option in Word. If the original translation turns out to have met its quality standards, then the changes are entered into the Help and Manual project. If not, the Word file is sent to another proof-reader for a basic “cleaning” from a fresh pair of eyes, then those changes are entered into the Help and Manual project where they can be exported to a CHM help file, a PDF, and set of files for online help.

This process introduces the possibility of human-error with copy & paste mistakes, but given the scale of the project, a more robust solution isn’t really justified.

Later on updates are more manageable with a single help source file and the process can continue with little redundant effort.

The process is basically dictated by the scale of the project. In other words, of all the resources allocated to the project, how much needs to be allocated to managing it versus doing it.

For the original English translations, I can quite easily create and maintain the help files. There’s nothing difficult about this. Here I’m the author. (As I mentioned above, instead of just ‘translation’, I ‘interpret’ parts, rewrite parts, and add new content where I find portions to be thin.)

For the GDT help translation, it’s quite small and easily manageable. An HTML editor or text editor is sufficient for the translation, and things are very straight-forward. If your application is small and the help is simple, you may find that this approach works for you.

App B has a large help file and there are quality issues to deal with. A simple process like for GDT won’t be sufficient. In this case, my role is managerial and my task is to ensure that the end product meets quality standards. If you have a larger application with more complex documentation, then a more robust process like this may work well for you.

Some Process Mistakes to Avoid

No matter how you decide to go about your translation project, there are some pitfalls to avoid. While these may seem trivial to some, I lost track long ago on how many times I’ve seen things like these happen.

Don’t try to translate an application and help before it’s done. If you make any changes to the application or the help, you’ll end up having to have things translated again. While you don’t necessarily need to have a final release ready, your interface should at least be finished with no additional controls or strings to be added. However, if the translation is being done in-house, then this approach can work, but will still involve some redundant work.

Don’t try to do it “one piece at a time”. If you try to get small parts of the application or help translated in small pieces, you may end up needing to use different translators. This can result in inconsistencies in style and word use, which reduces quality. Even if you use the same translator, if you spread out the translation over a long time, your translator may not have the previous translations anymore and if you haven’t made sure to keep your original consistent, it’s unlikely that your translator will be able to keep the new work consistent with the previous work.

Prepare the software before translating it. This includes taking care of any code page issues, extracting resources into DLLs, and making sure that formatting issues for dates, times, currencies, numbers and the like are taken care of. If you start with a mess, you’ll end up with a mess.

In Closing

There are many things that I haven’t covered above, such as support issues, or that I’ve glossed over very quickly, such as choosing a translator. However this article is by no means meant to be exhaustive or complete, and there are plenty more resources on software localization and translation available on the Internet to help fill in the gaps.

Hopefully this will help out a few people that have been thinking about providing their software to a broader market or highlighted some things to think about for those that are struggling with some common problems.

About the Author

As the “Renegade” behind Renegade Minds, Ryan writes and markets Guitar & Drum Trainer, a specialized audio player for musicians to more easily transcribe, practice and learn new songs by ear. He also offers several other programs and utilities at Renegade Minds. During the day, he’s the ALTools Evangelist for ESTsoft. Originally from Ontario, Canada, Ryan has called South Korea “home” since 1996. In addition to his many interests in software and software marketing, Ryan also enjoys playing various sports, studying to improve his Korean language skills and plotting world domination… errr… ‘liberation’ that is. :)

[tags]software localization, software internationalization, micro-ISV, micro-ISV best practices[/tags]

read more
Bob WalshLocalizing and Translating Software

Vendor Profile: Avangate

[Ed. Note: while at ESWC’06 in Cambridge, U.K. in November, I got to know several people from Avangate, a ecommerce/electronic distribution company based in Europe. I asked them to put together their pitch to micro-ISVs, and here it is. Any other vendors interested in selling to micro-ISVs and willing to put the time in to tell us what exactly they have are welcome to contact me at bobw@safarisoftware.com]

Selling your software online with Avangate
By Delia Ene
Marketing Communications Manager / Avangate BV

OK, there are several eCommerce platforms specifically designed for software sales and software registration services out there. As usual, when there is a choice, you need to know how to choose between them.
This presentation is not a comparison between providers, but a brief presentation of Avangate, eCommerce platform & software registration provider. Avangate is headquartered in The Netherlands, and part of the GECAD Group of companies (the creator of RAV, Reliable Anti-Virus Technology).

Below you’ll find the main points of the Avangate eCommerce solution. There is also a special offer for microISVs.

Whos’ who – Avangate

eCommerce platform for electronic software distribution providing all the tools and expertise you need to:

  • Accept payments online
  • Optimize the online software sales and logistical process
  • Increase your website visibility on the Internet

Why choose Avangate?

eCommerce offer includes:

  • an easy to use and secure online payment system
  • additional marketing and sales tools, such as an affiliate management system, automated cross selling options


  • software marketing services plus consultancy on how to increase software sales via the internet.

Avangate’s eCommerce platform allows you to:

  • Start selling in 24 hours
  • Accept multiple payment methods
  • Customize your Ordering Interface
  • Multilanguage, multicurrency
  • Real time Order Delivery – Key/ Code and Software Delivery
  • Cross Selling & Promotions Management Tools
  • Affiliates Program
  • Merchant & Shopper Support
  • 3-D Secure Merchant & Shopper Protection
  • Sales Reports & Statistics

We won’t go here into the nitty-gritty. Detailed information on platform features can be found on the Avangate website. Essentially, all Avangate options are easy to integrate and deploy. Software vendors are able to just click and implement a new sales mix; add straightforward licensing management system, special promotions and online sales reports.

A point worth insisting on are the software marketing services. We support you with expert advice on how to sell software online by:

  • Increasing your site’s visibility in all major search engines.
  • Distributing your product among the top ranked download sites and software directories on the Internet.
  • Better structuring your website and content, making sure you clearly present the power and benefits of your products, convincing your visitors to download and try them.

Whether you require our usability audit or software submission service, our expertise will ultimately help increase your website exposure and your software sales. Ask for our free personalized web analysis and we’ll take an expert look at your site suggesting appropriate web marketing solutions to help improve your online business.

Detailed information on Avangate software marketing services: http://www.avangate.com/ecommerce-services/

As a plus, there is also myAvangate, a web-based reseller management system specifically designed for software sales. myAvangate is still a Release Candidate – your chance to test it for free. More info on http://www.avangate.com/reseller-management-software/

Avangate’s special offer for microISVs:

-> attractive commission (two schemes you can choose from: 4.9% +1.95 EUR/2.5 USD or 8% minimum charge 1.95 EUR/2.5 USD). Fees are clearly explained on the Avangate website (go to http://www.avangate.com/start-selling).

-> three months web marketing services worth 1000 USD (SEO audit, software submission, PPC management, according to your needs)*.

*)Special conditions apply: minimum one year contract with Avangate and online sales of minimum 1000 USD per month.

Interested? Contact us. We are here to help developers sell software better and safer online. Email info@avangate.com and mention ref no: MicroISV offer BW.

[tags]Avangate, micro-ISV vendors[/tags]

read more
Bob WalshVendor Profile: Avangate

Making Plans for 2007 and mymicroisv.com

Having finally finished Clear Blogging (plug: available Feb. 7, recommended reading for micro-isv’s), I can start working on several stalled projects, including MyMicroISV.com. A year ago when Micro-ISV: From Vision to Reality came out, I conceived of this site as a blog+resources site. The blog has worked out – mostly because of the many guest posters who’ve shared their knowledge and perspective here – but the plus part has not.

So my plan for making over MyMicroISV.com is to make it a blog + wiki, and have that wiki become the single best place new and experienced micro-isv’s can go for how to succeed information. Think of it as the FAQ of the micro-isv world. I’ve talked to 8 other micro-isv’s who’ve agreed to contribute “starter pages” on numerous subjects, but there’s two big questions in my mind still unanswered: what wiki platform to use and how to structure it so it grows as good wiki should?

As much as I enjoy MyMicroISV.com, I have other projects too, and that means I’ve got to have a wiki that needs the least amount of administering to and yet provides the best results. That makes me think a hosted solution would work best. Also, while I use Wikipedia every day, I think it’s ugly beyond words and wiki markup is geeky lame, especially as of 2007.

That said, the main contenders are MediaWiki and Wet Paint, with two other possibilities: Google Jotspot and Drupal. Wet Paint would be perfect if they simply let me pay for it instead of it being “free” with Google ads built in. Google Jotspot might be great – but Jotspot is in lock down since Oct. 31 when it was acquired by Google. Who knows when it will next see the light of day? Drupal I’ve heard from others can do just about anything – if you’re prepared to invest mega-hours.
So, what wiki platform would you suggest for MyMicroISV.com?

[tags]Wikis, wiki, mymicroisv.com[/tags]

read more
Bob WalshMaking Plans for 2007 and mymicroisv.com

Know your rules of engagement

by Bob Walsh

One of my favorite sites, thinkvitamin.com, just put up a post I’d recommend every micro-ISV read: Tara Hunt on The Rules of Engagement. Tara sets out to answer:

What is that magic ingredient that turns people from ‘consumers’ of your software into active and enthusiastic evangelists? The truth is that there is no single magic ingredient, but there are some underlying principles to delighting your current customers that may just lay the groundwork to creating an evangelist or two.

And does a fantastic job. If you’re wondering why and how micro-ISVs are now in the community-building business, read this post and Tara’s previous post, Why 50% isn’t Good Enough.

[tags]community-building, micro-ISV[/tags]

read more
Bob WalshKnow your rules of engagement

Use STRING to get programming accomplished

By Bob Walsh

My friend Matt Cornell posted a great trick that should be in every micro-ISVs bag of tricks. This technique is ideal for those lingering small code projects we all have, but just have not found the motivation to code.

Matt’s technique? Think STING:

  • S – Select one task.
  • T – Time yourself.
  • I – Ignore everything else.
  • N – No breaks.
  • G – Give yourself a reward.

Now I have to add an “R” item to make this technique a little more valuable:

  • S – Select one task.
  • T – Time yourself.
  • R – Review the Desired Outcome.
  • I – Ignore everything else.
  • N – No breaks.
  • G – Give yourself a reward.

Reviewing the desired outcome puts first and foremost what you are aiming for, but I’m quibbling here. Definitely read his post about applying STING in full.

[tags]Matt Cornell, Productivity[/tags]

read more
Bob WalshUse STRING to get programming accomplished