The Recursive ISV

A while back I blogged here about good user interface design in If You Don’t Love It Don’t Release It, and I’ve mentioned a few times about releasing early and that I believe you should.  I’m writing this post to expand on these two things a little.

Releasing early is something that was intrinsically avoided by most and indeed frowned upon by many, yet it has become the battle cry of the mISV (and ISV’s!).  It’s based on the premise that if you keep coding to perfection with a complete feature set you will never, or at least take a long time, to release *anything*.

Steve Jobs (Apple) famously is supposed to have said: “Artists ship”.  I think it applies to all of us. 

What’s the point if nobody sees it and it’s not out there performing its function?  Until a product is released it’s a theory, no more and vapourware at best.  Trust me - I have a Bachelor in Vapourware and doing my best to avoid a Doctorate! 

Another big no no trumpeted at us for decades, it seems, is that you shouldn’t write a product that has established competitors.  This is bunk.  It’s a generalization.  Copying what someone else has done is clearly lame, but competing with a new product is completely logical and unavoidable in almost every instance.  As always there are exceptions.

Recently I had the pleasure to try out a brand spanking new product by a new mISV.  While the developer and owner of IceTips Software is no newcomer to writing code or even being independent he’s certainly new to embracing the more recent and modern drive behind what has been called “Web 2.0” (which tends to be applied to anything and everything these days) or what I prefer to call “Bootstrapping Common Sense.” 

It would seem he’s taken on what he’s learned and applied it well.  It’s to soon for him to be a roaring success, or even a little bit successful (product is that new), but it’s a nice product and it’s very clear from the user interface and his dedication to get it right (he is lightening fast on replying to user issues, that’s experience first hand BTW) is crystal clear.

His product is a Build tool for developers.  Now – yes there are lots of established build tools out there.  I use one (so should you) already and I’ve been a happy and loyal user of it.  But Build Automator (that’s the name of the product) is actually very fresh and clean. 

It’s not jam packed with every bell and whistle that so many build tools overwhelm us with, though he has said he has some additional, and very useful, things to add in the near future, the point is he’s released! 

This artist has *shipped*! 

In an online forum I am a member of he was asked (when he announced Beta) whether or not he’d be giving away free copies to Beta testers.  He replied beautifully by stating that the product was release ready *now* and neatly side-stepped this inevitable and annoying line of questioning.  I too grow weary of folks looking for a freebie.  He’s built this to feed his family and for the pleasure of running a business (I assume).  He has the domain knowledge, code skills and design skills so why the heck not be paid for it?!!

Now – about loving it.  I said he loves it – right?  Well it’s very clear he does, beyond his fast replies to what were a few minor issues (related to my hardware).  He’s gone with the, what I feel is, smooth Office 2003 look featuring the blue gradient toolbars and menus.  I’m not saying this is the *only* way of producing a pleasing interface, it isn’t the only way.  But it’s one way and it works well with this application.

His primary application icon is professionally designed and *unique* to his program.  First impressions count and this impression was flawless. 

The installer was smooth.  The installer didn’t change associations to various files on my system without my permission or any shenanigans like that, it didn’t place an icon on my task tray, it installed the program cleanly.

The icons in the toolbar are *clean*.  They blend well, they are not the same colour of course which would not be right, and they work well together.  They are chosen with care and consideration.  They are logical for the task at hand and I’m told he’s actually replacing some of those in the next build or so – so here’s a mISV who really does take pride!

Build Automator features nice clean dialogs, with careful and considered use of white space where needed, while not totally abandoning the standard Windows grey theming on XP (runs perfectly and properly on Vista too of course).   

Program functionality is neat and tidy and seems to be well thought out and coded.  The program does what it’s supposed to do – build projects for developers.  While IceTips is yet to add all the build options for the different compilers it currently supports most common ones including Delphi, Clarion 7, Clarion#, Visual C++, Visual C#, Visual Basic.  It supports a growing number of installers (more being added soon I’m told) and other tools one would expect.  The ability to FTP a build up to your server (coming soon I’m assured) isn’t there yet, something I personally need but it’s a flying start for a very usable product.

I’m not in the habit of recommending products, but if you’re not using a build tool now, or are looking for a new one I think Build Automator is worth some time checking out.  The price is right and IceTips seem keen to be of help if you have any questions.  In the sense of checking out a nice fresh, *clean* user interface it’s essential viewing by all ISV’s as I firmly believe it’s an indication of where and what we should be trying to achieve, especially if you are in the pre-release stage or just starting your project.

IceTips and Build Automator can be found at:

http://www.buildautomator.com

He has a blog, too.  I’ve added that link to my Blog Roll but you can access it direct here:

www.buildautomator.com/blog

The Splash Screen, so long beloved of dev’s on Windows, looks to be on its last legs.    The passing of an era, the mark of a vintage app, the deaths knell for artistic flair or good riddance?

Some folks would definitely go with the latter.  Some state that they can tell the quality of an application by virtue of the fact it has a splash screen at all.  They claim the splash screen is there to mask incompetent and ugly coding practices and to fool the user into thinking something important is actually happening. 

Yep, we’ve read those comments, perhaps pondered them, or ignored them or thought about our own applications – and shut our mouths. 

Personally I say bunk!

Yep.  It’s total absolute bunk.  It’s a maledicted generalization that may have some basis in some instances, but like all such generalizations fails with numerous exceptions.  Clearly dev’s who spout this nonsense have never had to work with loading heavy dll’s, database libraries and files or had to struggle with users who have sub standard or even over loaded CPU’s and RAM.  Even systems with modern CPU’s can (and do) fail to deliver when something like Symantec’s Internet Suite is busy guzzling CPU cycles like some kind of  neurotic, byte consuming camel – which is most of the time for that and similar “suites”.  Got two cores?  Hold the fort and baton down the mobo, your anti-virus/firewall buddy is going to splice itself into one of each thanks!

The purpose of the splash screen was originally to provide clear visual feedback to the user that something was actually happening.  The program (or the operating system) hadn’t gone to the land of Nod, the keyboard hadn’t locked up or the graphics card hadn’t frozen and normal services would be restored in…  sometime under 30 seconds.

Or was it?  Certainly we’ve used that excuse for almost two decades now.  But the splash screen became much more – quickly.  It became branding.  It branded the product right into your brain.  Who could forget the green splash screen with the sailing ship’s wheel of Netscape Navigator?  Or the jigsaw puzzles of MS Office?  Or the super arty screens of high end graphics programs.  Nor can we forget Borland’s Athena.

Microsoft has now joined Apple in stating the splash screen is a no-no in most situations for most applications. 

Though there are exceptions of course, programs that take a long time to load, for starters, oh – and of course Vista itself, which makes no bones about a startup splash when the OS is loading up into RAM – using every micro-second purely for the purpose of loading essential stuff like device drivers, utilities, services, license checks – and brand awareness.  Oops – I mean user awareness that something is happening. 

So should we splash in our own applications?  Should we follow the advice of the OS vendors (MS and Apple) and just load, fast as we can, with no indication?

Splashing on the Mac has been pretty much out since OS X was released and not always that common on OS 9 and 8 (compared to Windows where dev’s were and are clearly addicted).  However, the Mac has those cute little bouncing icons on the taskbar, a visual clue to the user that all is well in program loading land and in just a moment, all things being equal, bouncing icon will stop and program will appear.  But not on Windows, no bouncing icons there, just some cursors that many users fail to intuit. 

I’ll never forget the reaction of a supposed power user (IT trainer) when I showed him the Beta for Windows 95 (his first look, I was testing).  Some software was loading, little arrow with the hourglass combination cursor appears and he says: “Yeah – I’ll bet!”   He really couldn’t really explain what he meant to me.  From what I could tell from his babbling he thought it represented speed, not the process of multi-tasking or more specifically multi-threading.  It’s worse now too as the majority of users have never worked in a process swapping environment like Windows 16 bit let alone the single instance environment of DOS.

So edicts are fine from Microsoft, but how are they addressing intuition by the user? 

Given MS borrowed liberally (sorry for using the ”l” word to any Republican readers here <g>) from OS X for many of Vista’s graphical elements why not bouncing icons? 

It’s not that I’ve got this thing for bouncing or anything, but an indication surely isn’t to much to ask for if you’re asking dev’s to abandon their beloved branding – er – splash screens?  Particularly now that Windows supports transparent regions on forms and users can see their favorite applications splash screen, like their pirating software, I mean file sharing software, like LemonWire in the shape of a freshly cut lemon?  It’s just not fair!

So back to the question at hand, should we splash our programs on startup?

I’d love to hear what folks reading think.  Personally I think it’s horses for courses.  I don’t mind splash screens, I’ve included them in the past and probably will where I think they are needed in the future, and of course being able to turn them off for the cranky bums who don’t like them, well that’s only fair – I guess!  ?

Recently on the BOS forum there was a discussion about some of the weird things people do in relation to various software packages and specifically using spreadsheets like Excel ™ as databases.  I’ve had my own experiences with users in office environments using Excel ™ for this purpose and them getting into a real pickle.  I’ve even had to correct some IT trainers for *teaching* that Excel makes a great database and is “no different, but easier to use than Access ™” and other database systems (where do these guys and gals get accredited?!!). 

But the post that took the cake, in terms of things people do, was submitted by Patrick McKenzie.  Patrick had met people embedding OLE documents into OLE documents into OLE documents into…   You get the picture.  The classic mirror facing a mirror paradox. 

If Alfred Hitchcock had been a computer programmer he would have taken glee in implementing this *everywhere*.   Thankfully he stuck to making movies about mirrors facing mirrors. 

So would Microsoft’s dev’s have ever considered that users would do this OLE inside OLE ad infinitum routine?  I can’t answer that.  I do know it gave me a long chuckle when I read it.  But it made me think, just because we *can* allow a user to do such a thing, and given how messy it can get (and dangerous to data) and of course the average computer users’ proclivity in doing something the developer never dreamed of, should we allow such things to happen? 

If indeed we can justify it happening in certain instances, should we not at least warn them of the potential of such techniques when they start to do it in such a manner?

IMHO. Yes!  

I believe this relates to ISV”s and mISV’s as well.  A lot of programmers (I think most of us have been guilty of this at one time or another) introduce features because “we can” rather than because “we should”. 

Having done it we don’t safe guard the user from (with the benefit of hindsight aside) obvious abuse of the feature.  We are then left with a conundrum when the feature is abused as the user blames the programmer for allowing whatever went wrong to go wrong – even if it’s due to abuse in a manner never envisioned by the designer of the feature (or coder of the feature if they are distinct persons).

We are left with two choices in this instance.  Pull the feature and cop the wrath of those who love it and *need it* or try and bug fix it so that it handles the whole problem gracefully. 

But there is, to my mind, a third option.  It’s done before the user ever becomes aware of the feature, before they even see or hear of it.  It’s incredibly easy to implement and is 100% guaranteed to be bug free and user error free.  It’s simply this:  Do you really need that darn feature in the first place or are you adding it because “you can” rather than because “you should”?  

If the answer to this is “because you can” then the feature is going to bite you, potentially later, in many instances.

I use a lot of pro audio software.  One of the big “features” these packages have is the ability to use plug-ins based on Steinberg’s VST ™ API.  This API is pretty cool, it’s got a massive market acceptance and third party support and is *the standard*.  But…  It’s a right royal pain to work with when you need more than one audio effect open at once, even if you have multiple monitors. 

But that’s not the worst part (and it’s true one can live with this).  The worst part is the attempt to model the UI of these plug-ins on real world user interfaces.  In this instance knobs.  Round knobs are cludgy and hard to use via a mouse (or even fingers on a touch screen).  Yet they are thrown in by the developers of these plug-ins time and time again, just because *they can*.  Practically a slider control – not dissimilar to the linear fader style control in the “real world” - is far easier to manipulate with a mouse.  In fact in the real world they are used on pro audio devices for *exactly that reason* - they are easier to use and more accurate even with fingers.  In a domain where minute changes to a signal can create the next “Itchycoo Park” this is simply to vital to mess up with a cludgy knob.

OK.  We could use the keyboard to do it – right?  Sure, but now we’re into the fix a feature to force it to fit territory or the “mirror within mirror” syndrome of OLE embedding discussed above.  I’m a great believer in cool interfaces and firmly believe cool sells.  But there is cool and useless and round knobs on a computer interface are not cool – they are a bloody nuisance!

For the sanity of your users and your own sanity when it comes to fixing it – ask yourself more than once if a feature is *really needed* before you throw it in because “you can”. 

Consider it from all angles and consider the potential for misuse.  It might just save you and your customers some heartache later on.

You’ve passed your apprenticeship, you can code confidently and at the very least competently and now you’re striking out on your own because you have that creative spur to *do something*.

So why on Earth, or Mars or Venus would you rip the code from a component vendor’s demo, make a few cosmetic changes and expect to sell it? 

Yet that’s exactly what I saw suggested today on the BOS forum.  It’s the kind of disinformation newcomers do not need.  I blogged here recently about “If You Don’t Love It Don’t Release It”.  How the heck can you love something you have zero creative investment in and zero intellectual investment in?  You can’t.  You’re literally embracing Amateur-Ville.   The realm of the clueless and bereft of talent.  There are so many things that need writing/designing and being made available to so many markets. 

How did Andy Bryce come up with Perfect Table Plan?  Was it because a component vendor made something similar available as a demo?  Nope.  He identified a market that he could bring his talents to and developed something people wanted.  He sells software he clearly loves and from what I can see his customers love it too. 

Andy is not the only one.  There are so many great applications and some of them don’t take a lot of brain and teeth gnashing to come up with.  Patrick McKenzie and his Bingo Card Creator.  Hardly a new idea, yet Patrick’s approach is very fresh, compared to his competition, especially his marketing and after sales.   His customers seem to love it and it sells.  What more could one ask?

A very good friend of mine writes beautiful components for Delphi.  Some years back I wrote some of the demos for his ESBPCS VCL library.  They are designed purely to demonstrate using the components with, in the case of the demos I did for him, a database via the VCL.   They are rudimentary - but they belong to the developer who created them - or the developer they were assigned to (I assigned the code to ESB).   I, nor I doubt ESB, would bother chasing a looser trying to sell the simplistic demo as a product, but honestly, how could one feel anything but utter contempt for such a lame brain?

If you have to rip a demo program, mod the interface a tad and release it as a “ISV” product then I’d suggest you do not love your product (how could you with zero intellectual or creative effort invested?) or your ISV company and have complete contempt for your customers, current or potential. 

As I’ve said here before, an unloved product ultimately expires via a death of asphyxiation caused by lack of interest and lack of sales.  It even harms the efforts of other ISV’s by jading consumer’s perceptions of small software companies.

This is not to say a product must be complex or even totally original or unique.  In fact simplicity can have elegance and simple, competent and elegant sells – ask any Mac user.  But ripping a demo, modding a few UI elements and expecting to earn a dollar is in my mind immoral at worst and clueless and lame at best.

Over the years as a moderator of software forums I’ve seen a lot of lame stuff submitted for announcement.  Over and over again I’ve seen the example program from a certain Delphi how-to book consisting of a rudimentary calculator being sold for $29.95 down to $9.95.  They were kidding right?  They didn’t even have divide by zero protection coded in, had no keyboard support, just mouse, and looked like crap.  At least one of these “developers” went on to moan publicly that nobody was buying his software and he assumed piracy must be the reason.  Windows comes with a calculator 10,000 times more powerful than these ones and they reckon it was pirated?  Abject losers!

Please.  If you think you can do something worthwhile by making interface changes to a demo program offered by a component vendor – do the world a favor and get a job more suited to your talents.  Like becoming a dole bludging surfie.*

(*Dole bludging Surfie – Australian slang for an unemployed, lazy beach bum).

In my last entry I bemoaned the look of most mISV software (and some bigger ISV’s too) and how amatuer it looked in general.  I thought it’d be nice if I showed an example of a product (that I have no relationship with at all) that simply looks well done and balanced.  See this link at Evolved Software.   As you can see it’s icons are nicely chosen and fit well with each other.  It doesn’t bend or break design rules and pretty much adheres to standards.  The result is a nice professional and easy to intuit interface.  Well done to the developers!

..Or Getting Rid Of That Infernal Noise

A lot of folks are going to get incredibly annoyed at this entry (you know who you are). 

OK.  I’m a moderator of three Usenet big 8 newsgroups (comp hierarchy) and they relate specifically to so called “shareware”.  I’ve been the moderator there since there inception a decade ago when Usenet was still a big communications channel and nobody had really thought much about online forums.  Blogs was a noun used when referring to an unknown person (Joe Blogs) and of course it was before the so called .com bust.  Pretty much everything that happened in the arena of small companies selling software that you could download and try was defined as “shareware” back then.  ISV and mISV etc had not been defined. There were a few lame attempts at terms like “Trialware” here and there that never had a hope of going anywhere as a term.   Consumers defined a company, as did magazine reviewers and pundits, as a “shareware company” and around about this time the folks running these companies tried, in vain, to get people to understand that “shareware” was a marketing method and not a type of software – or company.  I say in vain because the majority, including the IT industry by and large don’t get it and in cases I’ve met personally refuse to get it.

So what’s the big deal anyway?  Does it actually matter what you call yourself?  Is “shareware” a negative connotation?   To this I really have to say, yes and yes.  But not for the reasons quoted by most folks.

To the first the obvious answer is you are a software company.  Simple.   Your customers won’t know what an ISV or mISV is – maybe this will change in time, but it’s not important.  They will know what a “shareware” company is (even though their definition is in error) however and I really do believe you *must* avoid this for 97% of people.

The second is about application look and feel. 

Go to any download site and most software sites run by people selling downloadable trials of their software and it pretty much *looks like so called shareware*.  Seriously.  That’s the first impression of the screenshots.  That’s the first impression after downloading the program. You can justify the validity of definitions till the cows come home, but this is what people think after downloading. 

First impressions count and so do ongoing impressions. Is this bad?  I argue yes.  Look and feel is more important than us geeks often realize.  Products like Visual Studio from Microsoft and Borland’s Delphi and so on allow us to create a look and feel for our applications that fits with the Windows paradigm for user interfaces.  On the Mac tools like Interface Builder from Apple perform the same function. 

On the Mac people using this tool seem to get what they are supposed to do with it.  But too many, way too many, Windows software developers (small and large) totally and completely and utterly stuff it up!  

The Office 2003 look, for example, is not hard to achieve.  It’s a consistent UI and lots of people use it in their app’s for Windows.  But they still make the blasted things look like a drunken wombat careened through the interface with roller-skates wielding a machete!

No balance, no thought, no idea!

I’ve blogged about the importance of good icons and so on in another post here recently.  But I’ve actually seen examples of folks who bought stock icons that matched and were perfectly useable and still managed to screw them up!   Mixing sets can work – but it takes care and it takes trial and error. 

I’ve also seen them somehow manage to shift the colors of the icons into ghastly 16 bit aka Windows 16 bit/Windows 95 style.  Get a grip!  If you can’t stand the heat hire a designer!

I have a new image format mantra for icons and glyphs.  If it’s not PNG with alpha channels it’s out!

How many people spend even 25% of their time developing a slick UI for the software compared to the time spent writing code?  It should probably take most weeks of tweaking judging by the array of ghastly interfaces available to terrify the unwary downloader. 

In a reasonably sized application if it took you a day (or worse you did it on the fly and rushed off to get to the code) you probably haven’t got it right – nowhere near right.  Henry Ford famously offered his Model T in black and black only.  But he *did* paint it at least.  The Model T looked finished, quirky or obsolete by today’s standards sure, but it looked balanced and finished.  Most software companies don’t do this.  The UI is totally overlooked.  In a couple of words “they suck.”

Is your application a Porsche or an old rusty bicycle?

Study interface design. This should be an ongoing study that never ends.  Look at the top end of town.  See what they are doing in the big app’s or the high volume sales app’s.  See what works (some of it does not). 

Only use skins if skins add value to the program (just skinning for the hell of it often looks exactly like that).  Remember if you choose to skin allow folks to disable skins because not everybody likes your color preferences.  By their standards you might qualify as color blind! 

Note that some users hate skins period.

Don’t ignore looking at interfaces on other platforms like the Mac.  The Mac really has it together in this regard and those of us who generally code for Windows can pick up some subtle lessons.

One important lesson from the Mac is task related design.  What are your users tasks and how does your program fulfill them.  Crowding up your interface in every screen with every task is not a solution it’s a disaster and it’s more often than not butt ugly.  Consider breaking tasks into multiple windows or hidden panes.

Great thing about this is that it can reduce new user support issues as well while not impeding advanced users.

People do like “cool”.  The wow factor in this industry can not be overlooked.  Ignore it at the cost of sales.  How your product looks may well be the deciding factor between your product and somebody else’s. 

Cheap knock-off programs (like those you compete against) won’t stack up to a quality professional interface.  

Most people like to own things that look the best and make them feel happy.  Crush the losers who copy you with a class act interface.

Make a statement with your interface about who you and your company really are!

One of the things that really bugs me is seeing software that not even its mother, the software designer, loves. 

We see it all the time with ugly screens, broken functionality, sixteen bit icons, stolen icons, icons that come with the IDE etc ad nauseam.  Why?  Because the developer gets a “hot idea”, plugs away and then releases to the world, throws it onto download sites, maybe does some SEO with Google et al. 

Said software rarely gets updated, rarely gets bug fixed, rarely gets bought and is frequently dismissed if not despised.  Heck, it even gets small software companies a bad rep amongst B2B and even consumers.

Who ever thought up the idea of selling programming languages to Joe and Jill Sixpack?  Websites or shrink wrapped products with “Even you can program” ought to be taken out back and shot, or at least hauled up under local laws for false advertising.  We see this all the time on the software forums.  Folks wanting an “idea” to write the “next killer” program, or how to find an idea for the “next killer” program, oh – and they want to be able to do it all in two weeks!! 

This is how some unloved software is released.  Money is the only motivator, no interest in the product, customer or future.  Product is abandoned.

Another instance is where a hobbyist with domain knowledge writes a product and releases, initially loving the *idea* of such a program (and the kudos that come with it) but are technically inept and lack design skills.  The idea is loved here but not the program.  Product is abandoned.

In other instances the programmer is technically competent, loves programming, has domain knowledge and loves the idea.  However the actual program is not loved, as evidenced by look and feel.  Products frequently abandoned.

It’s interesting to see that the products that are clearly loved by their “mothers” survive and prosper.  Some of them are pretty basic as far as depth of functionality goes, yet have loyal customers and benefit from frequent updates.

It’s not enough to be technically competent to love a product *we’re talking products for resale here – not tools or basic utilities).   A car does not need paint to run, it can be rusty and look awful but run just fine and do what it is supposed to do, get you from a to b.  But would you love such a car?  Nope.  You’d hate a car to look like this, no matter how functional.  A nice shiny, nicely painted car, for most people, is something to love.

Software is no different.

Build your product so that it is technically competent.  That’s essential and bears no dissention.  Certainly release early, I believe in that fully.  But love the product.  Be meticulous with the graphics and layout.  Icons should be modern, there is no excuse for this.  They can be bought pretty cheaply too.  See http://www.icons-icons.com/  for some great designs, there are others. 

Take some time out, if you are a Windows or *nix developer, to look at some Mac products.  Mac developers get this idea.  In the best products the icons on toolbars are color coordinated.  They take the time to do it right, showing they love the program and their customers, Mac users, demand nothing less.  When delivered they have some of the most loyal customers you could find.  

Keep in mind at all times that if you love your products and it shows you love them through attention to detail, not just code but look and feel, it’s more likely your customers will love them too.

So do you *really* love your product?