The Recursive ISV

If you're new here, you may want to subscribe to my RSS feed. Thanks for visiting!

If you were following things back in June during the 30 Day mISV sprint you might remember I blogged about Treeviews and the problem with them in relation to what I’m doing in MixAction.

Suffice to say I was still not happy with what I finally implemented.  It was much to limiting for the user.  So I thought “bugger it” and ripped the tree out and started from scratch on it.

I admit I skipped the buttered scones, hanging out in bars and frilly, lacy clothes - but…

I’m very glad I did chop it out and fixed it.  It now does exactly what I wanted.  Drag and drop, auto incrementing  nodes, re-ordering and much more, despite the real location of a record in the “database” and so on.

In a very real sense I melded much of what I had setup prior to June 1st and added a bunch of stuff I wanted.  It was certainly not without some pain.

It using memory streaming rather than temporary files (as are the playlists now) again and has no direct relationship to the “database” in the sense it is only stored there as a blob.

This is the kind of thing one certainly can’t do when setting limits. There is no time to wrap oneself around a problem and fix it properly.

You can’t take shortcuts on integral functionality. 

In fact, I think that’s so important I’m going to repeat myself:

You can’t take shortcuts on integral functionality. 

Steph wrote on his blog (in a great article well worth reading):

“The morale of the story, be careful before you start trashing user interfaces, there might just be a reason for some odd solutions.”

Steph is entirely correct in this.  In fact some folks took umbrage at MixAction’s design because it was reminiscent of iTunes.  At no time did the reason for the similarity enter the topic - rather it was more “I hate iTunes” which is of course is utterly ridiculous as an argument in isolation. 

What is not ridiculous is that some people don’t understand the iTunes design. 

It’s a Mac design.  A very Mac design.  But the principle is the reason it gets criticized on Windows.  It’s the “to much empty space” issue which of course is exactly the point. 

Clarity and elegance is trademark of the Mac, not Windows.

Indeed, as I’ve written before, Windows dev’s have a habit of throwing one of everything onto a UI utterly confusing Joe and Jill Average completely.

BUT - when it comes to core functionality widgets should perform as expected and my humble project treeview in MixAction did not.

The usage may be odd, actually it is odd, not may treeviews in programs on any platform iterate automatically as the program goes through it’s paces, usually the nodes are just clicked on to select them. 

Yet in MixAction this is exactly what happens. The program selects nodes as it runs.  Has to happen - or the whole “easy to use and automated” paradigm does not exist.

It’s these little things that are holding up the release of the product.  They are fiddly. 

I refuse to write them every time I need them so that means being more abstract and building objects that give this functionality when dropped on a Window at design time.  As there are no existing controls doing what I need I have no choice other than to write them, so that the end user never has to think twice about it - and things behave pretty much as they’ve come to expect through using other programs that use widgets, such as the treeview.

Scott Kane

Quote of the day:
It takes hundreds of nuts to hold a car together, but it takes only one of them to scatter it all over the highway. - Evan Esar

Monty Python The Lumberjack Still Photo Is Copyright BBC London England.

Related posts brought to you by Yet Another Related Posts Plugin.