Coffeehouse Thread

15 posts

Forum Read Only

This forum has been made read only by the site admins. No new threads or comments can be added.

Transition to WPF/E

Back to Forum: Coffeehouse
  • User profile image
    Larsenal

    I'll admit it.  I'm terribly excited about WPF/E.

    However, although the cross-platform plug-ins will be available, it would be naive to think Flash-level adoption will come overnight.

    With that in mind, is there any way to serialize WPF/E to PNG?  I'd love to be able to build out my data visualization with XAML, and then display PNGs for those not savy enough to install the plug-in.

    This capability would make it much easier to justify adopting WPF/E.

    (I realize that WPF/E goes beyond data visualization, but I imagine that will be a fairly common scenario.)

  • User profile image
    littleguru

    That's exactly what i discussed with a friend yesterday. He is going to design a new website, and he is going to use Flash.

    Why?

    It's going to take some time until everybody has the WPF/E plugin installed. He said also that average peoplethink that installing a plugin to view a website is weird. Most might also think that it's no good to install a plugin, because it could harm the PC - or some might even don't know how to do it.

    He wants to reach everybody and flash is available everywhere. That's why he goes with that.

  • User profile image
    kettch

    littleguru wrote:
    ...average people think that installing a plugin to view a website is weird. Most might also think that it's no good to install a plugin, because it could harm the PC - or some might even don't know how to do it.


    As annoying as it can be in this case, that preconception is actually a good thing over all.

    Hopefully WPF/E will go out as an update to IE.

  • User profile image
    littleguru

    kettch wrote:
    
    littleguru wrote: ...average people think that installing a plugin to view a website is weird. Most might also think that it's no good to install a plugin, because it could harm the PC - or some might even don't know how to do it.


    As annoying as it can be in this case, that preconception is actually a good thing over all.

    Hopefully WPF/E will go out as an update to IE.


    Yes. That's true. It's a good thing, generally.

    If going out as IE update you don't reach the FF users. And there are quite a few out there. And try to convince an FF user (my buddy uses FF) to develop a page that uses WPF/E... Wink hard job.

  • User profile image
    BryanF

    I understand what you're saying, but isn't there a chicken and egg problem here? I mean, why a non-geek go out of their way to install a plugin they don't need to view their websites? While I would probably agree that WPF/E might not be appropriate for big, public-facing projects until adoption picks up, for smaller projects, you may be better off going for it. While the majority of WPF/E client will be running Windows, the fact that WPF/E is cross-platform mean that they wouldn't be able to push it to everyone even if they wanted to. My understanding is that the plugin should only be a few megabytes, and Microsoft will almost certainly sign the control. You yourself good help matters by providing a link to Microsoft's download page (rather than a link directly to executable itself) to further assure visitors that they aren't about to download spyware.

    I agree that most users--including myself, to be honest--may be hesitant to install a plugin from some random website. But once WPF/E is installed the first time, the experience should be automatic for all other sites, just as it is with Flash. Aside from the development stuff, one of the nice features of WPF/E is that it doesn't have that "Click to activate this control" experience that has made flash sites cumbersome and sometimes confusing to navigate in IE. I wouldn't use it for corporate homepages at this point, but otherwise it might not hurt to give it a shot.

  • User profile image
    kettch

    littleguru wrote:
    
    kettch wrote: 
    littleguru wrote: ...average people think that installing a plugin to view a website is weird. Most might also think that it's no good to install a plugin, because it could harm the PC - or some might even don't know how to do it.


    As annoying as it can be in this case, that preconception is actually a good thing over all.

    Hopefully WPF/E will go out as an update to IE.


    Yes. That's true. It's a good thing, generally.

    If going out as IE update you don't reach the FF users. And there are quite a few out there. And try to convince an FF user (my buddy uses FF) to develop a page that uses WPF/E... hard job.


    But Firefox users loooove to brag about their extensions, how many there are, and how easy it is to install them. Tongue Out

    As far as convincing a developer, it's all a matter of what is familiar. I wouldn't try to convince a flash developer to jump on WPF/E unless there was a good reason for the switch. Even then, it all depends on the tools and languages that the developer is familiar with, and how much effort they are willing to go to.

  • User profile image
    Larsenal

    BryanF wrote:
    .... I wouldn't use it for corporate homepages at this point, but otherwise it might not hurt to give it a shot.


    Well... it might actually hurt a lot in some cases.

    When you invest time (and therefore money) into developing with a tool or platform, you have a lot to lose if that tool or platform turns out to be a dud.  Even if the adoption occurs but occurs slowly, it can be a big problem for your business.

    If you're developing an application critical to business success, the "try it and see what happens" approach will not go over well--especially if "trying" involves significant cost.

    Offering some way to serialize WPF/E graphics to JPEG or PNG would greatly reduce the risk of development on this relatively young platform in certain scenarios.

  • User profile image
    BryanF

    Larsenal wrote:
    
    BryanF wrote: .... I wouldn't use it for corporate homepages at this point, but otherwise it might not hurt to give it a shot.
    Well... it might actually hurt a lot in some cases.

    When you invest time (and therefore money) into developing with a tool or platform, you have a lot to lose if that tool or platform turns out to be a dud.  Even if the adoption occurs but occurs slowly, it can be a big problem for your business.

    If you're developing an application critical to business success, the "try it and see what happens" approach will not go over well--especially if "trying" involves significant cost.

    Offering some way to serialize WPF/E graphics to JPEG or PNG would greatly reduce the risk of development on this relatively young platform in certain scenarios.
    I think I understand what you're saying, but I'm not quite sure I agree with your reasoning.

    While you're certainly right that using an unproven tool or platform can be risky, it would seem to me that the greatest potential for disaster would be on the development side of things. For example, you make a large investment in the technology only to discover that the platform cannot do what you need it to, or that the tools are still too immature to give you the productivity you need. In the case of WPF/E, these issue are likely to come up regardless of whether the end result is pushed to the user as XAML or PNG. In fact serializing to PNG might actually increase this type of risk in that it adds another step that needs to be accounted for and tested. If I gave the impression that I was advocating a "code first and hope it all works out" approach to new technologies, I apologize; I certainly appreciate the necessity of ensure a technology is up to task before commiting it to an important project.

    By comparison, getting the control onto the clients should be less risky. WPF/E's 3D capabilities are far more constrained than the full framework's, so performance requirements should be relatively modest; and the size of the download should be roughly an order of magnitude less, so that should be relatively painless. In corporate environments, you should check if the IT staff is willing and able to install the control on the managed PCs. In the wild Internet, you need to consider whether the percent of people who would refuse to install the control is small enough to justify the risk. Given that WPF/E is from a trustworthy and well-known vender, the chances are more in your favor than they would be for other controls. The only case were I would really say it is too risky to use WPF/E until adoption is substantial would be an application that is exposed to a third party's network, where users' PCs are managed by an IT staff you have no influence over.

    Also, I'm assuming what you're asking for is a server-side component, since another client side control would be missing the point. But WPF/E is completely client-side, so getting the effect you want could mean getting it to run on the server and pass output along to a serializer, and getting all that to work via AJAX or something to communicate with the client. It could be done, but I suspect it would be easier to use an existing server control that is capable of generating PNGs.

    Please tell me if there's something I'm not getting, because this is really an interesting idea. I'm just inclined to think most of the serious problems around risk are more likely to emerge during development.

  • User profile image
    Larsenal

    Yes, I agree that you must--inasmuch as you are able to--access the capability of a tool before using it.  However, my point about rasterized serialization was more aimed toward the risk of using a dependancy (in this case the plug-in) that isn't adopted quickly.

    There are many situations, especially in a corporate environment, where a user may not have the ability to arbitrarity install browser plug-ins.  If your app targets these users, you may need to offer an alternative even if it is not as "rich" an experience.  However, my thought was that if you build up some pretty visualization in WPF/E it might be nice to be able to display something other than "Oops!  Install the plug-in" without having to develop a GDI+ or 3rd party alternative

    I realize that WPF/E is client-focused.  However, in a data visualization situation somewhere you're likely binding your visualization control to the underlying data.  Let's say in most cases where the plug-in is installed binding occurs over AJAX to a client-side WPF/E object.  Only when the plug-in is not installed would the server do the binding and emit a PNG.  The assumption of this scenario is that the secret-sauce is contained within the code that takes a dataset and converts it to valid XAML for display.

    I don't entirely disagree with your logic for the situation you described.  However, I think the scenarios we have in mind are fundamentally different.

  • User profile image
    Xaero_​Vincent

    <rant>
    Why is it so important that WPF/E become a Flash killer?

    So that all Linux, *BSD, Solaris users are shunned on the web because there does not happen to be a fully functional plugin for those platforms?

    Dont talk to me about a reverse engineered FOSS alternative. Just look at the FOSS alternative to Flashplayer... its pure trash.

    I much rather see Flash improve and rival all of WPF/Es features, instead. That way everyone can have an equal online experience.

    Either that, or open source WPF/E so that the decent plugins can be made.
    </rant>

    Thanks

  • User profile image
    Larsenal

    Xaero_Vincent wrote:
    <rant>
    Why is it so important that WPF/E become a Flash killer?
    ....
    </rant>


    Did someone say that it should be?

    I agree that competition among big players in this space is good.  As Adobe and Microsoft battle it out to maintain (or earn) the best "rich" plug-in position, hopefully the developers and consumers end up winning.

  • User profile image
    dotnetjunkie

    This is why Microsoft should have bought Macromedia.

    I still can't understand why they gave away such an ubiquitous technology (Flash) to Adobe!

  • User profile image
    Rob Relyea

    Nobody really answered the original question [which I'll stick to Smiley]

    Most of the vector graphics in a Xaml file from WPF/E can be natively loaded into WPF. (they share a common <Rectangle /> tag, for example).  If you want to build WPF/E content that works in WPF, use the WPF xmlns (http://schemas.microsoft.com/winfx/2006/xaml/presentation) and stick to the common subset.

    WPF has a fantastic Imaging platform built into it, including the ability to create bitmaps (png, jpeg, etc..)  See:

    *) System.Windows.Media.Imaging - in the .Net 3.0 API.
    *) Channel 9 coverage of WIC/S.W.M.I: WPF Imaging
    *) WIC - the Native Windows Imaging Components.

    So, yes, it should be pretty easy to build a Xaml vector graphic converter to bitmap conversion tool.

    If you build this, places to get help include the WPF Forum and Robert's blog.

    Thanks, Rob Relyea
    Program Manager, WPF Team
    http://rrelyea.spaces.live.com/">http://rrelyea.spaces.live.com

  • User profile image
    Larsenal

    Thanks for answering the original question.  This is exactly what I was looking for.

  • User profile image
    ScanIAm

    littleguru wrote:
    
    kettch wrote: 
    littleguru wrote: ...average people think that installing a plugin to view a website is weird. Most might also think that it's no good to install a plugin, because it could harm the PC - or some might even don't know how to do it.


    As annoying as it can be in this case, that preconception is actually a good thing over all.

    Hopefully WPF/E will go out as an update to IE.


    Yes. That's true. It's a good thing, generally.

    If going out as IE update you don't reach the FF users. And there are quite a few out there. And try to convince an FF user (my buddy uses FF) to develop a page that uses WPF/E... hard job.


    Another problem is that there are some installations that simply don't update as fast as we do.  In my previous job (and current) most people still use IE6 because many of the web based enterprise applications simply won't work in IE7. 

    Sure, the latest versions of those apps will work, but it's naive to think that the process of updating that application won't cause other issues.  My favorite issue:  Web Applications that look, in advance, to make sure that the browser is compatible.  Some of them refuse to run if they believe that the browser isn't compatible even when this compatibility is broken by going from IE6 to IE7 (looking at you, Mercury TestDirector).

    My point?  Not everyone can actually update their web-browser even if it did come as an update. 

Conversation locked

This conversation has been locked by the site admins. No new comments can be made.