SmoothSpan Blog

For Executives, Entrepreneurs, and other Digerati who need to know about SaaS and Web 2.0.

Archive for the ‘ria’ Category

« Previous Entries

Nokia-Microsoft Deal Completes the Three Winning Strategies a Market Can Have

Posted by Bob Warfield on February 11, 2011

According to Michael Porter, markets have three winning strategies:

–  Best:  Build the best product in the market.

–  Low Cost Provider:  Compete on Price.

–  Niche:  Service a niche that is under-served by the other two strategies.  All markets have niches of one kind or another.

Can you guess which of the three smartphone players goes in which slot?  It’s easy:

–  Best:  Apple’s iOS products.

–  Low Cost Provider:  Google’s Android

–  Niche:  Nokia-Microsoft had better be targeting this spot, at least for now!

It’s not an unreasonable play for the two companies, although most commentators see it as a marriage of desperation.  Still, we shouldn’t let that reality steal too much away.

How can Nokia-Microsoft serve niches that are underserved by iOS or Android and go on to prosper?

In many ways, the Microsoft .NET world has grown up to be just such a world.  It isn’t really the best, despite what Microsoft or some fans might argue.  The ecosystem that places Oracle instead of SQL Server at its center has that base covered.  It isn’t the cheapest either, since Open Source of various kinds has handily taken that spot.  Instead it has grown up to fit into all the gaps these others leave under-served, and it’s worked out reasonably well for them.  Take a look at the XBox business for example.  It’s been reborn with a vengeance by the Kinect, which is a niche gizmo.  A very cool one to be sure, but it isn’t as if every single game you’ll ever want to play is a Kinect game.

Now in the phone world, Scoble has two pretty good examples of the kinds of niches Nokia-Microsoft can go after:

1. Nokia has dealers and stores in the weirdest places on earth. Places Apple won’t have stores in for decades, if ever.

2. Microsoft has great developer tools.  I will add to that they have the .NET community and ecosystem, which is under-served by iOS and Android.

Ideally, Nokia-Microsoft should look for more of these niches.  For example, Nextel created an awesome cell phone niche play by rolling up the features needed by services that dispatched their trucks, taxis, and other vehicles by 2-way radio.  Perfect example of a niche play.  Nokia-Microsoft will have a great niche if they can better serve Windows users than iOS or Android, since that’s already Microsoft’s niche and a huge one at that. 

Speaking of serving Windows users, HP is showing some fascinating new developments.  For example, the ability to see your phone’s instant messages on your PC without having to go get the phone in the next room.  That’s the kind of stuff Nokia-Microsoft should be doing for Windows.  The question in my mind is where does this leave HP?  They’ve decided to go it alone, even talking about Notebooks without Windows.  The demonstrations they’re showing are spot-on the kinds of things that under-served markets love to get their hands on, so I would say that what we are going to see is a real dogfight between HP and Nokia-Microsoft because neither has much chance of usurping Apple or Google from their Best and Low-Cost plays.

What’s also interesting is we will see the play between Vertical and Horizontal Integration and Partnerships.  Andy Kessler wrote a great article at GigaOm on Ken Olsen, who recently passed away, that talks about how DEC lost the war by trying to be too vertically integrated like IBM.  They wanted to do everything soup to nuts.  I don’t agree that this was DEC’s only problem–they also faced the horror of rebuilding their whole channel to work the way the emerging retail world operated instead of via Direct Sales.  Faced with that, most companies give up.  It means taking a real dip before you get back to ascendency and throwing away many core competencies while you learn something new.  Nevertheless, it was a factor, and one to consider for HP, who are assuming they can go it completely alone.  Yes, there is an installed base, but that’s about it.  Nokia-Microsoft can at least hope to rally a broader ecosystem around their axis which is crucial when dealing with a platform like a mobile phone.

As I was reading fellow EI Vinnie Mirchandani’s take on the whole thing, I was reminded that this is a wonderful study in when to be a polymath (vertical, doing it all) and when not.

The Polymath, who is expert at all the key areas needed for a project, has the advantage in producing the Best because they avoid all of the cruft and friction of fitting together two areas of expertise when the experts don’t speak each other’s language.  Apple may be the world’s foremost example of this, at least in terms of visible consumer products.  In terms of being the Low Cost Provider, there will certainly be opportunities for the Polymath because there are savings to be had in avoiding the friction of fitting together.  However, the advantage is not so great.  The reason is that Best has to start out Best and stay that way.  There is therefore very little time to learn and evolve your way to Best.  Low Cost is always looking for incremental savings.  They can learn their way past their lack-of-Polymath.  For many years, I think Dell would’ve made a fabulous example here.  They outsourced so much that they were basically marketers and component specifiers.  They did not have the Polymath knowledge of a great many things and didn’t want it.  I don’t know if they are still the masters.  Because one can learn to be lower cost, it is a less defensible barrier.  As for the niche, this too seems like an excellent Polymath domain.  Niches often come about because the Best and Cheapest players just don’t know enough about the niche.  The Polymath has to span that gulf in domain knowledge.

It’s going to be interesting to watch the Nokia-Microsoft and HP gambits unfold.  Probably the biggest obstacle against them is time.  Nokia-Microsoft are talking 2 year time scales at a very pivotal point in the Smartphone era.  That’s a long time to wait!

Posted in business, mobile, ria, strategy | 7 Comments »

Android is so Open, it got Flash Back on the iPhone

Posted by Bob Warfield on September 9, 2010

How ironic.  On the same day that MG Seigler was penning one of his characteristically snarky posts (snark is one of the ways Techcrunch pursues its Follower Economy) about how Android isn’t really open, Apple announces the return of Flash to the iWorld.

Adobe’s stock price is cooking this morning as a result (I wonder if 10% of Adobe’s revenue is even traceable to Mobile Flash? Maybe), and I have to admit, being the Adobe Flex fanboy that I am, I’m chortling over my morning cafe mocha too!

A couple of things to talk about on this news.

First, why do I award credit for this to Android?  Peeps, come on–Steve Jobs didn’t just wake up from his hissy fit about Flash (thanks for that link, Larry!) and decide, “Oh darn, I was wrong.”  No, no, no, not happening.  Something grabbed Steve Jobs by the throat and shook him right out of his reality distortion field.  That something was competition.  Not only has Android been selling extremely well, but the Bastiches have even been using Apple’s, “Hey, we’re not the Man, we’re Cool“, marketing tactics.  Dude, what’s next, Android thinking differently (I can’t see Google having the populist moxie to get that grammar wrong the way Apple did, all those PhD nerds just couldn’t handle it).

Competition is what forced this change, MG Seigler.  Android’s “We’re more open than open can be” pitch was working.  In fact, this Apple announcement sweeps away most of what one would’ve argued were barriers to openness.  It isn’t just Flash that benefits.  Besides which, a heck of a lot of people love their iDevices (3 out of 4 of our whole family have iPhones and we share an iPad) but want Flash access.  Forget movies, they can change.  I can’t even see the stock graphs on Yahoo because they’re Flash.

Gordon Gecko was wrong when he said, “Greed is good.”  It pains me as a person often described as being slightly to the right of Attila the Hun to reach that realization.  What Gordon should have said was this:

Competition, for lack of a better word, is good. Competition is right, Competition works. Competition clarifies, cuts through, and captures the essence of the evolutionary spirit. Competition, in all of its forms; Competition for life, for money, for love, knowledge has marked the upward surge of mankind.

And here, it has let Flash back into the iWorld.  Good job, Android!

Second, I want to take a few lines to talk about why I think Flash is so important.  Much has been made of how the LAMP stack has transformed web development.  Companies can now create products without requiring millions of dollars in R&D expense.  But the LAMP stack primarily benefit the back-end, in other words the server-side.  What about the client?  What is the equivalent of a LAMP stack for client development?  Unless you’re a tremendous fan of 3270 green screen UI, and I know some are even in this day and age, you need the equivalent of the LAMP stack to efficiently product great clients.  Here is the secret:  Flash is the LAMP stack of UI development!  Yes, there are some Flash wannabes out there, specifically Silverlight.  So what?  Microsoft would love for .NET to be the LAMP alternative too.  Flash is it for these simple reasons:

–  It is ubiquitious.  Aside from the iWorld, and that changes today, the vast majority of the world has already installed Flash and it runs in their browsers.  That’s 99.3% penetration in mature markets.  Essentially, everyone has it.

–  It is a write once run anywhere tool that really works.  You write your Flash code and all 99.3% of users can run it without you needing to give it another thought. 

–  AJAX and Javascript, the alternative, is riddled with browser dependencies.  Any dev team that has tried to get even simple rich UI like a Wiki-style rich text editor to work understands this.  It’s a huge overhead to keep up with all of these browser dependencies, and a constantly moving target.  With Flash, Adobe does that work for you so you can get on with building your app.

–  Flash has amazing graphical power and Job’s protestations to the contrary is actually quite fast.  People are writing 3D games in it, for example.

–  Flash can transcend the browser to create apps via AIR, and as we’ve discovered in the mobile world, apps are where it’s at.  Google used to offer Gears for this purpose, but pulled the plug on it.  Silverlight?  Hey, competition is good, bring it.  But they aren’t really there yet.

This all adds up to something that’s very important to the ongoing evolution of User Experience across all devices.  Simply put, Flash deserves to keep going and to be available on all those devices.  Thank you, Steve Jobs, for relenting, even if it took a gun to your head.  Adobe: now is not the time to rest on your Laurels.  There are some issues here and there in the House of Flash that you still need to attend to.

Posted in apple, platforms, ria, software development, strategy, user interface | 6 Comments »

Adobe: 7 Things You Should Do With Flash/Flex

Posted by Bob Warfield on June 21, 2010

Dear Adobe:

Apple has started the anti-Flash/Flex snowball rolling, and it is getting steadily bigger.  It’s a perfect storm, because they’ve got the platforms that are perfectly suited to Flash, their platforms are wildly popular, and your faithful audience desperately wants to be there.  But that’s not all.  They didn’t just prohibit Flash, they have called a lot of attention to a credible competitor: HTML5.  I know, I know.  It will be a long time before HTML5 is everything Flash is today.  It’s not even close right now, and a lot of people have conflated media delivery with Rich User Experience in ways that unfairly diminish your platform.  Get over it.  Economic pressures (aka naked greed and envy to be on these precious Apple platforms) have created a hill of growing height, and the water that is developer mindshare is rapidly flowing down that hill and away from Flash.

What can you do?

Lame ads won’t help.  Complaining about it won’t help.  Technology and innovation can help.  If you move quickly, and you have some things in your camp that buy you time (Android), you can still salvage the situation.

Here is what it takes:

1.  Absolute Single Minded Focus on Performance and Stability

People have concluded your platform is buggy and slow.  It doesn’t matter if you agree or not, the customer is always right.  When you hear McAskill at Smugmug and Adler at Scribd railing about your stuff, it’s time to move from denial to acceptance.  Their voices and those of many others are too loud and being spread too efficiently to pretend it isn’t so.  It’s past time to deal with it, in fact.  You need to embrace this problem, own it, and deliver the solution as quickly as possible.  The solutions can take many forms.  My recommendations are part of this post, and this point is more about declaring a focus both publicly and internally and owning the problem.  You don’t have to say, “We agree, our platform is slow and buggy.”  You do have to say:

“We have a great platform and our customers have told us to make it dramatically faster and more stable.  That’s our #1 priority, and here’s how we plan to do it…”

2.  Stability:  Quality + Security.  Get a Czar.

I’ll define Stability as consisting of equal parts Quality and Security.  Your customers are finding too many bugs.  There are too many public security issues.  This is happening at a time when you can ill afford it.  Get a Czar nominated and equipped to deal with this area.  Apportion your development cycles between performance and stability, give the stability cycles to the Czar and just do it.  The Czar needs to rapidly do the following:

– Identify the most egregious problems you have missed that are troubling your customers.  Look outwardly not inwardly to find them.  Fix that first tranche rapidly.

– Upgrade your automated testing so regressions are under control.

– Put in place a culture of quality that ensures that every single release is better than the last one.

– Investigate whether some of the quality issues don’t stem from education issues.  If customers are approaching it wrong, or don’t know how things work, they may be seeing behavior that is exactly what’s expected, but that looks to them like a bug.  Do not let this be an excuse for thinking you don’t have real bugs too.

– Be transparent about the plans and the results.

Get this stuff fixed and make sure it stays fixed.  This is not a, “Let’s fix the top 100/1000/or whatever bugs,” thing.  It’s a cultural change accompanied by results.

3.  Build a High Performance Native Compiler

Yes, I know, it is wonderful that Flash programs work everywhere.  But you are dealing with Performance perception and a company that says they will only let Native tools in the tent.  Figure out how to kill both birds with one stone.  Every platform does not need a native compiler.  But, if Facebook can afford to build a PHP compiler for performance sake, you definitely can afford to do this.  If you don’t have any serious compiler gurus, get some on board.  While you’re at it, build an optimizer for your interpreted stuff too.  You need a two-pronged attack:

–  Better bytecodes with the usual optimizations that matter closer to the language–operator strength reduction and all that.

–  Killer native compiler that will run circles around your bytecode stuff when it needs to.

If you do it right, it should be possible to pick and choose which classes are native and which are bytecode within the same Flash app.  You will also need to provide infrastructure that makes it easy to serve up the right native version to whatever platform is being used by the consumer.  Don’t make your developers figure that out.  BTW, you need to get this into Beta in less than 12 months.  You don’t have much time.

There is an old saying, “If you want people to make a new decision, you must give them new information.”  This pair of developments is the new information for performance haters.

4.  Revisit the Asynchrony of Flash and Embrace Multicore

This may just be baked too deeply into the programming model, but it sucks.  Sometimes programs want to be able to block until something happens, and when they can’t they wind up wasting their time and you mobile device’s battery life to no good end.  This asynchronous stuff is a throwback to not having a real multi-thread model for Flash, and in the Multicore Era, that’s a liability.  Sure, current mobile platforms don’t have many cores.  It doesn’t matter.  #3 is really only a stopgap.  In the Multicore Era, if you want to completely crush the competition on performance, do it with more cores.  When I was at Oracle, it was all about building benchmarks that could use more cores than SQL Server.  Once you use more cores than the other guys, you become almost exponentially faster.

And while you’re at it, you will deliver a model that is much friendlier to developers.  Being able to deal with multiple threads and blocking should be the basis for Flex 5.

5.  Embrace the GPU and Knock ‘Em Dead With 3D

Last point.  For most machines, the graphics processor is the most powerful CPU in the machine.  That’s a big surprise to many, but hey, it’s true.  That sucker has got vector processing going on just like the old Cray supercomputers.  There are companies building supercomputers out of them, for Heaven’s Sake.  Our freakin’ Air Force uses the GPU’s in Sony Playstations to build supercomputers fer cryin’ out loud.  I know it is a pain to go native on the GPU.  Sometimes the OS doesn’t help you very much.  But you have to find a way to get your developer’s hands on those beautiful MIPS.  This is especially true since Flash is all about the visuals.  While you’re at it, build a killer 3D subsystem for Flash so peeps can create virtual reality, 3D modelers, CAD/CAM, killer FPS games, and a whole of others things you haven’t even thought of.  With #’s 3, 4, and 5, nobody will be able to touch you on the performance front.

6.  Bring Back the Flock with a Cross Compiler

In many ways, Apple’s insistance on anything but Flash is like an old-fashioned shelf space war straight out of the pages of Ye Olde Shrink Wrapped Software.  If I build my app in not-Flash, it is a pain for me to go back to Flash no matter how much I like it.  It is worse if my not-Flash is on a super hot platform, because I kind of want to just keep writing not-Flash on that platform once I get hooked. 

Here is the thing: if HTML5 is really as limiting as Flash devotees claim, it should be trivial to translate the limited functionality of HTML5 to Flash.  While you are at it, please undertake the slightly less trivial task of moving Objective-C to Flash.  Sound hard?  It is a little, but not any harder than all the other stuff you need to do.  Besides, I’ll bet you can do this one as a joint project with Google.  Why?  Easy:

Take any award-winning iPlatform app.  Feed source into your new cross compiler.  Push a button.  Get back an award-winning Android app written in Flash.  BTW, you can have it on your desktop or anywhere else too. 

Now what iPlatform developer could resist that if it all works great?  Don’t think of it as aiding the enemy by giving developers an opportunity to start from HTML5 with less downside.  The developers that will use this are already lost to you, and you need to bring back your flock.

7.  Keep Your HTML5 Powder Dry

By now Adobe, I expect you’re really feeling pretty unhappy with this post.  The stuff I am telling you needs to be done is not easy, and it won’t be cheap.  At the same time, you know in your heart that this is what it really takes to win this war.  It’s about to get worse.  HTML5 is coming.  All of those other steps will only allow you to maintain your lead for longer. 

You need to recreate everything that is great for your platform on HTML5.  But, you need to keep it in the backroom until the timing is right.  Don’t dribble it out.  Do big quantum leap releases.  Your first one should not be an also-ran.  It should establish Adobe as the premiere resource for HTML5 developers.

It’s just that simple

As I’ve said, this is a hard road.  But, if you don’t follow it, if you don’t dig down deep and go to war now in a meaningful way, you won’t catch up later.  You’ve got a great platform.  If you want to keep it, you know what to do.

Posted in apple, flex, Marketing, Open Source, platforms, ria, strategy, user interface | 6 Comments »

Tim Bray’s Schtick: He Likes 3270 Green Screens as UI

Posted by Bob Warfield on May 6, 2010

So I’m reading Bray’s blog as usual, and I come across his argument against Flash that I see occasionally–namely, that all Flash UI sucks.

Why?  Here are his words:

What’s not to like, then? Well, the user experience, which in my experience is fourth-rate for anything but games; No “Back” button, feaugh. And of the course the fact that it remains essentially proprietary.

So, I use a Flash-blocker every day, and I am not a friend of Flash inside Google, but none of my arguments have anything to do with being part of the Web, or not.

The closest thing to an explanation is that there is no “back” button.  Hmmm, is that really the issue?  Needing to understand more, I did a search for “Tim Bray RIA”.   Sure enough, I find this article which says:

One of his points is that Rich Internet Applications aren’t worth the hype. He says that web applications are generally better than desktop applications, because they enforce simplicity and support a back button, and that users prefer them.

WTF?  Really?  All this for a frickin’ back button?

When you get down to it, Web UI sans AJAX, Flash, or some other RIA (Rich Internet Application) engine is just like the 3270 green screens of old.  It’s fill in the form and press the “Enter” button (BTW, that’s why it’s called the “Enter” button).  Yeah sure its simple.  Darned right, it doesn’t get much simpler.  And for many things, it’s just exactly the right thing.  But heck, if its the only way to do everything we’re really selling the web short.  It’s the old when you have a hammer everything is a nail.  I just can’t get my head around the idea that “web applications are generally better than desktop applications” if for no other reason than there’s so many types of user interaction that just don’t make sense for a 3270 Green Screen.

Maybe its a Learning Style thing, I dunno, but it’s not for me.  Give me a simple UI where simple makes sense and a Rich UI where that makes sense, which is a lot more places than just games.

Posted in ria, software development, user interface | 7 Comments »

SmoothSpan Nails Thermo!

Posted by Bob Warfield on October 2, 2007

The news is out on what Adobe’s Thermo is, and it’s basically what I had predicted and hoped for.  In essence, it is a graphical non-programming tool that let’s designers bring images to life as interactive elements for web apps.  As Adobe puts it, you can:

Turn artwork from Adobe Photoshop, Illustrator, or Fireworks directly into functional components that use the original artwork as a “skin”.

That’s really cool stuff!  Too bad we have to wait until summer, but it is one more obstacle removed from taking visual design to reality on a web application’s user interface.  I don’t think it will be quite the whole Magic Ink vision, but it looks very close and very useful already.  They’ll build on it more from there.

Interestingly, Magic Ink’s creator, Bret Victor sent me a note saying he’d been interviewed for the post at Adobe that started the speculation, but had taken an even more exciting job at Google Apple.  Geez, now we have to guess what that might be!  And BTW, Bret was a gentleman and wouldn’t confirm or deny what Thermo might be.

I love it when a plan comes together!

Related Articles

My original prediction…

The original “leak”…

Mark Anders response to the leak (the cat’s out of the bag)…

Posted in ria, user interface, Web 2.0 | 2 Comments »

Flex/Flash Solve A Lot of Problems: They May Be Disintermediating the Browser

Posted by Bob Warfield on September 20, 2007

Joel Spolsky gave out a big yada yada post over at his blog that wound up saying the browser incompatibility has got to stop.  He draws parallels with how portability won the day in programming languages.  A lot of what he says is right, some of it is just plain wrong:

The winners are going to do what worked at Bell Labs in 1978: build a programming language, like C, that’s portable and efficient. It should compile down to “native” code (native code being JavaScript and DOMs) with different backends for different target platforms, where the compiler writers obsess about performance so you don’t have to.

It’s a fond rememberance, but C definitely made the programmer, not the compiler writer obsess on performance.  C was and is a portable assembly language.  So many of its features include pre- and post- operators, wild pointer arithmetic, and macros are drawn straight from the instruction set of the PDP-11 it was created for.  Writing a C compiler is pretty darned easy, and the list of optimizations you can do on C is relatively short because the language is already basically an assembly language.  But we digress.

Spolsky wants to rely on some sort of compiler to generate Javascript/DOM “native code” that every browser will get right. 

My response, posted to somewhat the wrong place in Sam Ruby’s blog, was to suggest that things like Flex are solving this problem for those that want to build RIA’s.  Imagine my surprise when I went on down the blog reader and found Ryan Stewart saying essentially the same thing!  And there were others, such as Tim Anderson.

There is that old saying: once is bad luck, twice is coincidence, and three times is enemy activity.  Woot!

This made me think back to my 7 Tactics for Building a Guerrilla Platform and see that Adobe (and Microsoft with Silverlight wants a piece too) has used a few of those tactics.  Heck, they’ve used every single tactic:

Tactic #1:  Launch a great application that contains a thinly concealed platform.  Flash was the great application for animation.  Flex is a platform built around Flash.

Tactic #2:  Give away a distributed open protocol.  Flash qualifies here again.

Tactic #3:  Be the middleman and establish a bridge protocol that resolves the differences in other platforms.  Hey, that’s what we’re talking about here, resolving browser incompatibilities!

Tactic #4:  Talk down your platform:  “Don’t mind us, we just want to help web designers make cool stuff on the web.  We like all the other web stuff too.  Tra-la-la-la-la.”

Tactic #5:  Minimize the friction to get in a little bit at a time and maximize lock-in.  Check!  The more content you produce, the more inertia you have to keep you with the platform.  Meanwhile, Adobe tells us they have 99.99999% or whatever it is penetration and nothing else comes close.

Tactic #6:  Quid pro quo.  Give away something valuable to make platform participants unwitting participators in your plans for platform domination.  The Flash player is free.  You do want to see all that cool Flash content, right?

Tactic #7:  Give away a Widget on another platform to subconsciously convert people to supporting your platform.  That Flash in my browser is an awful lot like a Widget, isn’t it?Isn’t it cool to see all 7 tactics at work simultaneously?  Those Adobe guys sure are smart, huh? 

I love it when a plan for world domination comes together…

Posted in platforms, ria, Web 2.0 | Leave a Comment »

And Now For Something Completely Different: Visual Programming Cracks the Multicore Barrier

Posted by Bob Warfield on September 19, 2007

I’ve been admiring LabView, a visual programming language created by a company called National Instruments.  To be precise, the language is actually called “G”.  These guys didn’t set out to solve the multicore problem, in fact LabView was introduced way back in 1986 before anyone was worried about multicore.  It’s used in data acquisition, instrument control, and industrial automation tasks. 

Jim Kring called my attention to LabView in a couple of different ways.  First, I came across his great book, LabView for Everyone, in a Borders Books.  It’s a wonderful introduction to the potential for this language, but you won’t find the book in the programming section–it’s over by the Engineering books.  Second, Jim and I have corresponded about the Multicore Crisis for a little while and he recently posted on his great blog about how LabView is one potential answer to the problem.

Why is LabView able to scale more easily than conventional curly braced languages?  The answer is simple, and perhaps surprising: because the language says very little about the sequence of execution.  It is what’s called a Dataflow Language.  You’re almost certainly familiar with the world’s most common dataflow language already: spreadsheets.  Like spreadsheets, LabView has a very simple way of specifying sequence of execution.  An object in LabView executes whenever all of its inputs are ready.  This corresponds to a spreadsheet where a formula may be recalculated as soon as any other cells it depends on have been recalculated.  So, in theory, every single cell in the spreadsheet that creates an input for a certain cell may be computed in parallel.  Likewise with the objects in LabView.  Conventional languages, by contrast, consist of lists of steps that must be evaluated strictly in order.

Here is the other amazing thing about these two.  People may complain about how hard it is to learn parallel languages like Erlang, but who complains about learning spreadsheets?  They’re easy.  LabView is so easy that National Instruments has managed to build an almost $700M a year business around it.  Their EBITDA income was a little over $100M on that, and they are growing at about 20% a year.  Now Sun won’t break out Java’s revenues, but this company is nearly 10% of Sun’s size.  I have to figure that if Java were close to $700M they’d want to talk about it.  How’s that for the biggest language company you’ve never heard of?

When we compare LabView to something like Erlang, it shows up pretty well.  Recursion is a fundamental construct in many parallel languages like Erlang, but it isn’t necessarily a fundamental construct for many human minds.  Yet the idea of delegation, which is one form of parallelism, and of an assembly line, another form of parallelism often called pipelining, is very natural for people, and is inherent in dataflow languages such as spreadsheets and LabView.

There are other languages like this floating around too.  Yahoo’s Pipes is one designed for doing mashups that’s very cool.  The ease of use seems to carry over into this domain too as I read various examples:

The list goes on, but there seems to be a lot of potential unleashed when you quit thinking about things as a linear list to be solved strictly in order and break loose a bit more parallelism.  Like I said, it’s something completely different to think about.

Posted in multicore, platforms, ria, software development, Web 2.0 | Leave a Comment »

Psst! Have you heard of Adobe Thermo?

Posted by Bob Warfield on September 18, 2007

Okay, I’ll come clean, I have no idea what Thermo is, but I did read a blog post that sounded intriguing:

“You will lead a highly motivated team developing an innovative new tool, codenamed Thermo, that will enable designers and creatively inclined developers to easily build rich internet applications and interactive content. “Thermo” will streamline the process of adding interactivity, behavior and motion to creative assets and will work seamlessly with both Adobe’s Creative Suite tools, such as Photoshop, Illustrator, Fireworks and Flash, and with developer oriented tools such as Flex Builder.”

Clearly part of a job posting.  Now for the fun part: let’s guess what Thermo is.  In the spirit of being frequently wrong but never in doubt, I do hereby suggest that Thermo as described above, falls into the category of Magic Ink.  What’s that, you haven’t heard of Magic Ink?  It’s a way cool idea by Bret Victor for enabling visual designers to have a language of their own that adds interactivity to their designs.  The Usability Institute has a somewhat less scholarly post on Magic Ink that will hopefully show just how cool this would be.

Today designers are limited to getting programmers to help them add these kinds of features.  A tool that works by example to them them create fully interactive user interface would be awesome.  It’s not so hard to imagine either.  Anyone who has played with a really slick CAD program such as Rhino3D or Ashlar’s Vellum has seen drawing with constraints.  These constraints work to make it easier for you to create great drawings faster and more easily.  There’s also a whole world of Parametric CAD that does similar things. 

Now let’s reverse the process.  Imagine that we’re taking the drawing and defining constraints to control its dynamic behaviour.  A slider consists of 2 images.  One is the background and the other is the movable part.  Constraints would tell us to keep the movable part inside the slider’s track, and would also tell us how the slider can be grabbed and manipulated.  Further declarative code would tell us how to interpret the slider’s position to update a variable.  The whole thing could be completely interactive.

Work like this has been going on for a long time.  The first one I remember seeing was a Smalltalk program called “Thinglab” which was all about constraint oriented simulation.  I remember thinking at the time, “What a cool UI design tool that would make!”

If I’m wrong on what Thermo is, don’t be surprised, but the vision I describe is something someone ought to build.  If I’m right, be very very excited.  It will unlock a lot of cool new territory to the non-programmer world and put it in the hands of talented designers.  Thanks to Ted Patrick for starting this line of random speculation in my head!

Related Articles:  I was right!

Posted in ria, user interface, Web 2.0 | 5 Comments »

What’s the Killer App for Multicore?

Posted by Bob Warfield on September 11, 2007

I saw this question posed on MulticoreEra, so I thought I’d take a crack at it.

Let me start out with a contrarian view of the whole Multicore Thing.  Many have called it the Multicore Crisis, and I am definitely part of the “Crisis” crowd because I think software is not keeping up with hardware.  It’s too hard to write software that takes advantage of a lot of cores.  So here is my contrarian proposition: if it’s too hard, maybe the first killer app won’t be parallel at all.  Maybe it takes a lot of serial killer apps and just a few parallel killers to get us started.

Your desktop suddenly sprouts 4 cores.  Windows uses 1, your current app uses another, maybe something in the background uses a third, but what do you do with the 4th core?  And next year, what to do with cores 5, 6, 7, and 8?  I suggest we look for the Killer App to be something that runs in the background all the time, has an insatiable appetite for cpu cycles, and is completely indispensible: once we get it, we can’t live without it.  That app may or may not be parallel itself.  If its not, we’ll just run a bunch of differnet ones on the different cores to take advantage.

One last disclaimer:  lots of Multicore Killer App possibilities for the server end, this post is focused on the desktop.

Without further ado, here is my list of possibilities:

Be Speculative

What if your computer was always one step ahead?  Speculative execution has been a mainstay of cpu design for a long time, but this would be speculative execution of software on your PC.  What the system needs is some idea of what you might want to do next.  This could be as simple as knowing which files you’ve accessed recently.  Based on that, the system would know which apps you’re most likely to run.  Imagine if on startup, each core took one of the most popular apps you like to run and started to bring it up behind the scenes.  If you actually ask for the app, it pops up immediately because it was already there. 

The same trick can be employed with data.  Let’s get the data I’m likely to want into RAM and off the disk (or off the Net).  It will be much faster to access it there if it’s called for.

Programmers Need Compiler Farms/Testers Need Test Farms

This is one of those insatiable desire problems if ever there was one.  Make the compile of a single file parallel or running a single test script in parallel might be hard.  However, most programs have many files and many test scripts.  With a little creative scheduling, we can do a lot of that work in parallel even though most of the software uses only one core at a time.

Indexing

If you’re like me, anything that makes it easier to find what you’re looking for on your computer would be indispensible.  But since we’re talking about exotic multicore stuff, how about getting a little more exotic and creative?  I’m thinking of a background task that trolls through your digital photos and uses face recognition to provide an index of who is in the picture.  How cool would that be?  You’d start this program out with a nucleus of starter definitions.  Perhaps your family members and closest friends would be identified manually in a few pictures.  The program would then go off looking at pictures and looking to do a couple of things:

1)  Identify the face regions.  It creates a list of cropped rectangles for each picture, one rectangle per face.

2)  Identify faces.  It matches the regions to known faces.  There’d be a relevancy ranking:  72% chance this one Aunt Jane and only 17% chance its really Uncle Joe.

3)  It asks the user to confirm any faces where the relevancy is too low.  In so doing, it would learn how to identify a particular face better.  Likewise, you’d be able to easily correct its mistakes and it would learn there too.

4)  It builds a list of unidentified faces and ranks them by frequency.  Periodically, it would ask you to identify those that are the most common unknown persons.

Now, any time you want to look at your photos, you’d get captions to go with the photos telling who the people are.  The technology to do this exists today, and it seems to me would make for a killer app.

Tend the Garden

While we’re indexing, there’s a lot of other tasks one could undertake tending the garden of local data.  Clearly I can be on the lookout for malicious offenders: viruses, spyware, and all that sort of thing.  I can rearrange the data on the disk to defrag it and optimize it for better performance.  I can back it up over the web to keep it safe.  I can prune by looking for candidates for deletion.  I can encrypt to keep prying eyes from accessing the data too easily.

Hang Out a Shingle

Even if you don’t have software to take advantage of extra cores, maybe someone else does.  You can hang out a shingle (digitally, of course) whenever you have idle cores for rent.  Anyone whom you allow to share your cores gets to use some of them.  Perhaps it works along the lines of a Hadoop.  Heck, you could envision a search firm letting it’s users do both the web crawling and the search indexing during the normal course of their web browsing.  What a good opportunity to periodically ask them a question to help make results better.

Endless Possibilities, OS Help Wanted

There are endless possibilities here.  Right away it seems that we’ll want some sort of OS help to enable proper sharing of system resources among all these different apps that have suddenly sprouted.  The thing I’d worry most about is disk access.  When my antivirus program fires up it ruins performance of most other apps by hogging the disk.  The OS knows which app has focus and needs to be smart about parceling out that scarce disk resource.  Greater sophistication will be needed there to fully maximize the Multicore Experience.

Posted in grid, multicore, ria, user interface | Leave a Comment »

Using Mindmaps to Explore User Interaction and Create QA Test Plans

Posted by Bob Warfield on September 9, 2007

Using Mindmaps to Explore User Interaction is a cool idea.  Basically, you depict the flow through the UI as a visual map:

WordPress UI Mindmap

Doing so can give you an instant idea of how hard or easy it is to navigate the UI to key functionality.  I would venture to add that studying the “traffic patterns” along the mindmap’s highways and optimizing them the way you would a web site is probably a good way to tune up a UI.

Now here is a newsflash:  you can buy a piece of software that will automatically generate these mindmaps.  It’s called Rational Test Factory.  Here is a UI Map from Test Factory:

Test Factory UI Map

Same principle, with each UI object called out inside its container (window) and links showing how you navigate.  Test Factor is a product I built once upon a time at a startup I founded that was called Integrity QA Software.  There were a number of unique aspects to the product.  First was its ability to “spider” or crawl a user interface and produce these maps.  Second, it had the ability to automatically create test suites by using the map as a template to generate tests. 

QA people take note, because these maps are good for a lot besides UI design and optimization.  A mind map like this of a UI is exactly the map you need to plan your testing campaign!  I could see putting a big map up on a wall and using it to cross reference your test plans and see that you were getting proper coverage across the whole UI.

A third thing we did that was very powerful was we defined behaviours at each node.  A button is obvious, but menus and type-ins are more interesting.  For example, we made it easy to cycle through a bunch of test files.  The type-in for the file name would be given a property that was a list of test files.  Push a button, and a script got generated to crank through all those files.  Being able to define allowable inputs (for example, what is the range of valid numbers) is hugely powerful for testers.  But it would also be hugely powerful for UI and even program design.  This tool was aimed at testing, but at some point we planned to use it as a UI design tool and do code generation to create a UI from one of these maps.  Never got to it.

The fourth really cool thing this product did was to use Genetic Algorithms to generate optimal test scripts.  This was some seriously cutting edge stuff.  The UI maps gave us templates and made it easy to generate test scripts.  The role of the Genetic Algorithm was to evolve better and better scripts.  “Better” was defined by a fitness function.  We used code coverage and script length.  The shortest script that tested the most code was deemed the best script.  QA people loved this thing.  If the developer’s changed the UI, they could just remap and regenerate new scripts.  Add new code?  Regenerate scripts to test the new code.

The last way cool thing was that this was the first product I build with a grid architecture.  We had a demo room with a rack of 4 by 4 (16) PC’s and two really comfortable chairs set in front of the rack.  On a table between the chairs was the 17th PC that served as a control console.  We’d sit a customer down in one chair and the demoer in the other.  The customer’s software would be loaded.  Hit a button and all 16 machines started mapping the UI in parallel.  The customer’s eyes would literally bug out watching all that activity on their familiar product.  Then testing would begin.  Bugs would start being reported on the console.

I haven’t kept up with Rational’s doing with the product, but at the time it wasn’t suited to testing web applications because it was built before there were many.

It certainly is a fabulous example of how to use multicore to solve a hard problem.  The graphical programming aspect is also intriguing.  It begs for that UI design and code generation tool we never built.

Submit to Digg | Submit to Del.icio.us | Submit to StumbleUpon

Posted in grid, multicore, ria, software development, user interface | 2 Comments »

« Previous Entries