Sponsored By Aspose - File Format APIs for .NET

Aspose are the market leader of .NET APIs for file business formats โ€“ natively work with DOCX, XLSX, PPT, PDF, MSG, MPP, images formats and many more!

Design Conundrum for StoryTeller — Opinions Wanted

I made the preview release of StoryTeller a couple months ago as soon as I got some sort of “intelligent editor” functionality going in the WPF client so you very rarely ever had to expose your tender eyes to the horrors of the underlying Xml storage.  Fine, except for one little problem:  the UX and usability suck (and I know because my team uses it and I’m irritated with it when I use it.  Hooray for dogfooding).  It’s also butt ugly. 

Flash forward to the past couple months.  My team at Dovetail is putting the finishing touches on our online rules engine editor feature in our product (I’m blogging about it soon).  We basically use StoryTeller as our “DSL” engine, but we built a completely web based editor for the StoryTeller grammars and integrated that into our web application.  I had originally envisioned this module as being written in Silverlight because of the complexity of the dynamic layout and behavior.  Instead, we decided to build the UI out with client side JavaScript.  We do generate HTML templates on the server representing the DSL grammars that embed behavioral directives with class attributes and copious usage of the jQuery Metadata plugin, but all the behavior of the UI is accomplished through client side scripting.  My team might not completely agree, but frankly I’m thrilled with how it’s gone.  The UI looks pretty good and the screen behavior was relatively easy to create with the HTML/JavaScript/CSS/jQuery combination. We were even able to TDD quite a bit of the JavaScript development using QUnit.

So here’s my dilemma, I’m committed to making StoryTeller rock and I absolutely need to replace the existing test editor functionality.  At this point I have two options — either write a new version using WPF that closely mimics the improved usability that we built at Dovetail or stick with JavaScript/jQuery/HTML and embed a WebBrowser control into StoryTeller’s WPF client (which I already do).  Here are the facts as I see them and I’m obviously biased at the moment toward the HTML/JavaScript model — but I’m looking for other people’s opinions, especially about WPF:


  1. It’s an excuse/reason to learn a lot more about WPF for me.  I think I’d finally have to dig into data templates, styling, and attached behaviors to do this well.
  2. Embedding a WebBrowser control into a WPF app and letting more COM stuff in the door is kloogey and occasionally error prone.  The integration is odd
  3. Might run faster
  4. Richer editing controls



  1. The amazing jQuery ecosystem of plugins and support.  At a minimum, I’d be using the jQuery UI sortable/draggable stuff, jQuery Validation, and jQuery Metadata.  I went looking today and I just don’t see any substantial OSS community around WPF other than more copycat MVVM frameworks than you can shake a stick at.
  2. I’m much more familiar with the jQuery way of doing things and HTML
  3. I’ve got a successful working prototype to start from
  4. Many of the mechanics are much simpler with jQuery than with WPF.  For example, I want users to be able to reorder parts of the StoryTeller specification by dragging elements around.  This is just a matter of some declarative class names in HTML with jQuery, but the WPF equivalent looks exceptionally nasty.
  5. I actually like coding with JavaScript and the dynamic features make it relatively easy to extend the model with less ceremony than a static typed language
  6. The feedback cycle is faster with JavaScript than C#
  7. I’d really love to be able to allow users to embed the StoryTeller editor in their own applications, and the HTML/JavaScript model has much more reach than a WPF or even a Silverlight model would.
  8. I think this model is actually much easier to test than the WPF model.  It’s hard to write automated tests against WPF without something special like TypeMock that can get around how the WPF team sealed so many of the routed event classes or an expensive 3rd party tool that screen scrapes.
  9. Truth be told, I don’t really like WPF.  It’s weird and has more “oddball-ness” to it than any other technology I’ve ever used.  There are parts of it that I love (the layout system comes to mind), and others that drive me batty (XAML’s runaway verbosity, binding expressions, routed events).  I don’t hate it on first sight the way I did WebForms back in the day, but something about it just doesn’t agree with me.


Call it a Wash

  1. I’ve got JetBrains RubyMine for the JavaScript editing, so the tooling support is not really an advantage for the WPF/C# solution anymore
  2. qUnit isn’t that hard to use, so I’m not sure that the C# code is any easier to test and I have a recipe for integrating qUnit tests into an automated build anyway.


Anyway, it’s been interesting.  Now, what do you think?


About Jeremy Miller

Jeremy is the Chief Software Architect at Dovetail Software, the coolest ISV in Austin. Jeremy began his IT career writing "Shadow IT" applications to automate his engineering documentation, then wandered into software development because it looked like more fun. Jeremy is the author of the open source StructureMap tool for Dependency Injection with .Net, StoryTeller for supercharged acceptance testing in .Net, and one of the principal developers behind FubuMVC. Jeremy's thoughts on all things software can be found at The Shade Tree Developer at http://codebetter.com/jeremymiller.
This entry was posted in StoryTeller. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • http://www.jvsg.com CCTV software developer

    I would go for silverlight or Flash. Personally I used flash in my http://www.jvsg.com/online/ online lens calculator.

  • http://www.jvsg.com CCTV software developer

    I would also put a vote over Silverlite or Flash. I made a simple RIA app just in 2 days and it worked well for my CCTV lens calculator at http://www.jvsg.com/online/

  • Casey Manus

    I would put up a vote for Silverlight over WPF or any javascript / jquery based solution. Admittedly, I am very biased against anything javascript / html based. Silverlight gives you 99% of the advantages of both technologies with few of the disadvantages.

  • http://codebetter.com/members/jmiller/default.aspx Jeremy D. Miller


    I can’t even begin to tell you how little I care about swappable UI’s here. It’s a testing tool, not something for the general public that needs to be skinned or ever pretty. Just fast to author tests.

    It’s 100% plugged in through IoC though, so knock yourself out.

  • Brian Mavity

    One of the things I want to build into StoryTeller is the ability to plug different UIs in for different scenarios. The “generic” UI is fine in certain circumstances, but an easy way to swap in multiple UIs is so much more powerful and a better UX for less technical people.

    With that being said, why not have the html hosted window be just another one of the UI choices? That way you don’t have to commit one way or another and I can keep my dream of pluggable, rich UX. ๐Ÿ˜‰

  • Simon

    Vote 1 silverlight

  • Kevin Thex

    The ‘ol Web\Win. It’s interesting that 10 yars down the road, we still have to choose.

    An interesting question (to me anyway) is how can we structure our code to allow for both? Or more… if we include iPhone/Android/WMobile platforms.

    It’s seems that it’s no longer a fair question of whether to deliver an entire app via. one platform. Rather, which features lend themselves to which platform.

    Obviously not in the scope of your project :-), but I for one think it would be pretty cool to see an elegant solution to that problem.

  • http://codebetter.com/members/jmiller/default.aspx Jeremy D. Miller


    None, zero, zilch, nada. All you need is the .Net framework and IE — which you can’t remove completely anyway.

    One last time for effect, I’m just talking about embedding the WebBrowser control inside the existing WPF shell. Nothing more.

  • Shane Courtrille

    What requirements does going the web route place on users of the tool vs the WPF route? I liked how quick and easily it was to get the WPF version working. And deployment is super easy as well.

  • http://wizardsofsmart.net/ Ryan Riley

    Looks like your majority leans slightly with you, towards JS. jQuery in particular is fantastic and has a lot going for it, but I think you’ll later kick yourself for breaking your application into two paradigms. The biggest problem with WPF apps to date is that few fluid, dynamic WPF apps can be found, so you’ll be stuck making it up. I think you of all people would be capable of making that work, but it certainly won’t be the easy way out. I think your decision really hinges on the question of time: do you want a new release with the new piece now or (potentially much) later?

  • Eric Nicholson

    One more vote for HTML/JavaScript here. I’d add that with HTML/JavaScript there’s a high likelihood that StoryTeller could be ported to other platforms (via Mono). As I understand it, the WPF framework is so big that nobody is looking to port it currently.

  • http://dnperfors@blogspot.com David Perfors

    If I where you, I would see this as a great opportunity to learn more about WPF. But if you want this feature quickly in StorryTeller I would say go for the Javascript version for now and try use the WPF version later… (But I would choose for WPF anyway, since it would be great to learn and I am more a Desktop guy ;))

  • Tom

    WPF offers up new paradigms that are unique and innovative in the UX space. Whether it actually sticks or not is another story. And it may well be too much for the 9-5 corporate developer. But, as you are an authority you REALLY need to dig in and understand the shift in thinking. All in all its a powerful model that JavaScript thing just pales next to.

  • Lloyd

    To repeat your words a bit differently, basically you have to choose between something you know well and which does the work reasonably quickly and love (web), against something you don’t know despise a little and has a big learning curve (wpf).
    What would you choose?

    Now, I will concede that WPF has a big learning curve, heck many WinForm desktop developer are still not getting their head around it after 4 years!

    But take a book and 3 weeks to learn, and I can assure, you’ll never look back!
    And it will be all easier quicker and more potent!

  • http://blog.ploeh.dk/ Mark Seemann

    @Nigel Spencer: Thanks for putting in words all the things I was also thinking about, but couldn’t crystallize into words!

  • http://codebetter.com/members/jmiller/default.aspx Jeremy D. Miller


    I’m not talking about a 100% web based client, merely one part of the application. It’d be a web browser hosted in the WPF shell — which can be a problem of course.

    As far as usability though, I’m not convinced that SL/WPF is a slam dunk over HTML/JavaScript.

  • http://blog.spencen.com Nigel Spencer

    If StoryTeller is supposed to be a frequently used tool that people will spend a fair amount of time doing complex interaction with then I don’t think you have a choice – you’d have to pick WPF. There isn’t a single browser based application that I have used that doesn’t get frustrating very quickly when used heavily [think context menus, interaction with OS (print/drag’n’drop/taskbar), keyboard shortcuts, terrible state management, poor client side caching, exception management, SLOW]. That includes browser based mail clients and RSS readers – the UX is always greatly inferior to a well written dedicated desktop client. I’d argue even StackOverflow would be better if they had a downloadable client (in WPF!).

    Given that you’re even considering HTML/JS for this I’m guessing you have a differnt opinion on this – or maybe you’re just looking for the easy cop-out :-)

  • http://blog.ploeh.dk/ Mark Seemann

    As a user, I’m always put off by an application when I get something that’s supposed to run on my desktop, and it turns out to be a browser-based app. I am sure that you can create something that is far more robust than the majority of web developers out there, but still…

    In 2009 I would expect a locally executing application to be a WPF app.

    I never really understood why you dislike WPF so much, but now that you list all of the things you might consider digging into (data templating and styling) I can begin to understand why you have yet to find it attractive – the best is yet to come :)

    I don’t even find XAML to be particularly verbose – sure it has closing tags with redudant text in it because it’s XML, but apart from that you only need to specify what you care about.

    In case you are in doubt, I vote for WPF :)

  • http://codebetter.com/members/jmiller/default.aspx Jeremy D. Miller


    I’m not ditching the WPF shell itself, just the “Edit” part of the test view. *Nobody* is defending that code. I’m using the rest of StoryTeller for sample code for the book.

  • http://www.bjro.de Bjoern Rochel

    Hi Jeremy,

    I guess I would vote for the WPF way. I would love to see the StoryTeller WPF UI stay around and evolve into something more usable.

    Don’t get me wrong. I do understand your reasoning behind wanting to switch to a HTML /JS based UI . However I would like to add one more (maybe not directly related) point to the discussion.

    StoryTeller (in its current state) is imho already very beneficial for the .net community. Not as the acceptance-test-killer-app, but as the BEST RESOURCE I know that shows how a desktop app CAN look like when it’s build with topics like SOLID, IoC & testabililty in mind.

    There’re a lot of good resources out there for web-based architectures in .NET but only very few resources of comparable quality for dektop or smart client apps.

    That beeing said, I think it would be a pity to loose a WPF StoryTeller (Maybe I’m kind of egoistic here, I don’t now).

    Just my 2 Cent. cheers,

  • http://codebetter.com/members/jmiller/default.aspx Jeremy D. Miller

    @Michael C. Neel,

    It’s not an issue of me not understanding SoC or UI patterns (I better since I’m writing a book on the topic), it’s a matter of what’s the easiest way to create a *very* dynamic UI from the metadata of the DSL structure. This isn’t even remotely a common problem — or one I expect to ever face in a normal LOB app.

  • http://codebetter.com/members/jmiller/default.aspx Jeremy D. Miller


    I did say that in the Pro-WPF list. It’s something to be considered. Honestly though, I probably don’t have the time to commit to trying the WPF way.

  • http://codebetter.com/members/jmiller/default.aspx Jeremy D. Miller


    This really is more about getting done than experimenting at this point.

  • http://codebetter.com/members/jmiller/default.aspx Jeremy D. Miller


    That’s not a slam dunk for C#. C# requires much more code and more ceremony. There are a lot of language tricks I can exploit in JavaScript that aren’t possible in C#.

  • http://codebetter.com/members/jmiller/default.aspx Jeremy D. Miller

    @Rob G,

    I have a user for that turkey? And for the record, that’s just poor usability of an alpha. I think I have the vision for a better UX, just need to execute.

  • ais

    IronPython, IronRuby?

  • http://codebetter.com/members/Miksu/default.aspx Mikael

    I would recommend you to take the WPF-approach and use the project as a personal learning tool. Or you could skip the WPF and use Silverlight. It feels that you’ve somewhat mastered the jQuery so maybe this could be a way to get new challenges into your programmer-life? :)

  • Corey

    I would love to see your implementation of HTML / JavaScript in a desktop application.

  • http://blogger.forgottenskies.com Steve

    Have you considered Silverlight ?

  • http://blogger.forgottenskies.com Steve

    Jeremy, you might like Grails – combine that with jQuery and you have a great setup! :)

  • http://www.vinull.com Michael C. Neel

    From your post, it sounds like this was a first time WPF app attempt? It also sounds like the code is pretty tangled together – so separation of concerns, so it’s not just a matter of polishing the view and extending (if needed the model). However “to learn WPF” is not a valid pro for a product – users do not care about the framework in the apps.

    WPF itself is really great, but its botched with the default controls and stock implementations. jQuery has a much better set of controls though plugins, and the controls are easier to use. XAML doesn’t need to be bloated, however there isn’t great documentation on XAML that shows the “easy way” and too much out there showing the “hard way”. (I work in both WPF and jQuery often).

    Technology aside, it sounds like the real question is are your customers better served with a web based solution, or a desktop solution. That should be the deciding factor over frameworks.

  • http://michaelstechnical.blogspot.com Michael Hedgpeth

    Another pro of the WPF is it’s a good way to sell the patterns in your upcoming book.

    I personally would prefer the WPF way because I’m trying to figure that out myself and it would be a good benefit to the community for someone in the open source community to show good application design with WPF.

  • http://www.bluespire.com Rob Eisenberg

    I’m definitely not making any commitments. I have enough to do ๐Ÿ˜‰ I was just curious.

  • http://blog.cozwecan.com Rob G

    Hey Jeremy,

    As one of your users (of StoryTeller) I would strongly advocate for the HTML/jQuery route. I find the WPF runner very clunky, but I’ve always just put that down to the fact that it’s an “Alpha” which is fine, but then I agree with just how much work it’s going to take to get it to run as smoothly as the jQuery solution.

    The web has YEARS of blood, sweat and tears poured into it, and so is a perfect platform for the tool really, whereas WPF is like trying to drive a garbage truck around the F1 circuit and still hoping for poll position. The tooling is years behind…literally! And it means that I have to look forward to reading tons of frustrated tweets coming from you :-)

    Personally I hope you go the HTML route – and if you’re looking for some help on that front, I’d be keen to roll up the sleeves.

    Rob G

  • http://codebetter.com/members/jmiller/default.aspx Jeremy D. Miller


    Yes, but I would have to build the behaviors from scratch and I have neither time nor inclination to do that. In jQuery world someone else has already done that for me. Technical ability aside, I really do think the jQuery ecosystem is far more mature than WPF.


    Careful about the time commitment. I don’t see this particular feature being something typical that’s worth your time, and I don’t see how Caliburn addresses the issue. You’d have to build a parallel ViewModel hierarchy because the internal StoryTeller model isn’t appropriate for data binding — which isn’t the end of the world.

  • DaRage

    What?? you’re dumping C# for javascript?? that’s a no brainer of course C#?

    I no that javascript is being rediscovered and all that but it’s in no way close to C# and will never be. period.

  • http://realfiction.net Frank Quednau

    Well, if WPF leaves that after-taste in your mouth I suppose you already decided. I basically never touch routed events since I usually introduce a couple of classes that allow me to hook command-classes to the Command-Architecture and restrict myself to testing on a ViewModel level. Based on attached properties you would also be able to introduce behaviors like draggable and once having it in place apply it similarly to what should be possible with javascript. XAML and Binding Expressions require some getting used to but from my perspective are beyond anything that has been previously available. With things like Data Templates, and mechanisms to DRY away GUI look & feel mechanics, I think WPF allows for some pretty decent GUI setups.

  • http://www.bluespire.com Rob Eisenberg

    If you were to build it with Html/JS, would you be interested in someone else building the WPF version? No commitments here…but it might be interesting to use as a *serious* Caliburn sample…

  • KevDog

    It looks to me like you have talked yourself into the html/jquery model and are looking to overcome something else in order to convince yourself. If you look at the lists, there are many more knowns in the the jScript section.

    What else is going on that is leading you to doubt your decision?

  • http://webgambit.com Karthik Hariharan

    My preference is always to go Web. I just don’t find the UX story to be compelling enough to use WPF unless you’re doing something very graphically intensive.

    Based on your 4 pros for WPF versus 9 pro’s for HTML/JQuery, I think you don’t need convincing, but maybe your team does? Probably you have one or two “I hate Javascript” types on your team.