The "Fix WPF" slogan and movement seems to not actually call out
anything significantly *wrong* with WPF. - just "Fix it, it's broken".
This is some pretty unusable feedback in my opinion - nobody needs a
.NET Developer Tea Party movement.
This site doesn't describe what "fixed" even means - it makes some
fair criticisms about better messaging, but that's about it. What does
an ideal UX platform even look like? After the WPF team reads this
page, what do you expect them to do?
--
Paul Betts <pa...@paulbetts.org>
On Tue, Feb 22, 2011 at 4:53 PM, MossyBlog <scott....@gmail.com> wrote:
> We used to pitch the following when asked this question -
>
> "If you want good experiences, HTML/JS is for you. If you want great
> experiences than Silverlight is for you and if you want ultimate
> experiences, WPF is for you" or something around that remark. To this
> day I can't believe I said it and i honestly can't believe it squashed
> questions like this as in reality, the answer is "I have no clue, what
> are you good at and what do you want to do - aka It Depends?"
>
> Personally, if you want tighter control over how a user interacts with
> your application and don't have the time to muck around with
> serializing and unsearilizing data at both ends, WPF can give you some
> bonus. Silverlight can give you more of a passive reach in terms of
> your deployment but in the end the split between WPF and Silverlight
> comes really down to whether or not you want to prompt the user to
> install a plug-in or try your luck and assume the person is on Windows
> Vista and above and no plug-in required other than a clickonce prompt.
>
> HTML5 is HTML with some extras that are ready for a new breed of
> browsers. You still have the awkward ubiquity problem, but in the end
> once you win that battle you're still mucking around with CSS/
> JavaScript trying to emulate some sense of order that you commonly
> would get in most languages like Java or .NET. If you make a mistake,
> the tooling in question may or may not tell you depending on how far
> down the JavaScript development learning curve you are. CSS is hacky
> at times if you haven't settled on a rhythm and know ahead of time the
> semantics of what works and what doesn't - not to mention browser
> compatibility issues can play a role at times.
>
> You can't predict data as cleanly as you can with WPF/Silveright as
> its really "after or before" the fact analysis. So preloaders or
> Modula loading can separate the boys from men fast, as understanding
> the mechanics of DOM is key in knowing how to pull together a large
> application in a way that seems seamless to the end user. That's the
> ultimate goal in the end right? make the user feel as if the
> application is snappy and has it's act together. No matter what tech
> you throw your lot under in terms of "which" in the end it
> realistically comes back to the maturity levels of the people beside
> you when you code this app you're about to write.
>
> If everyone in the room gives you a nervous look when you say HTML +
> JavaScript + CSS, probably not the smartest move to go full steam
> ahead on. Same goes for the other two as, in the end all three have
> their degrees of tax and its usually not so much what each of them can
> do technically it's more of a team environmental issues (tooling
> support, team skills, timelines and budget).
>
> Bottom line is..no matrix will give you a short quick answer that will
> relieve you of having to fight this out within...not right now anyway,
> years to come..maybe...but thats a big maybe..