I’m a career long Flash designer and developer. I have used Flash Professional and Flash Builder (a.k.a. Flex Builder) just about equally now, over this time, which means I’ve spent about the same amount dragging/dropping/drawing symbols in Flash Pro as I have writing AS/MXML in an Eclipse environment. I’ve approached projects starting on both ends of the workflow, as a designer building a prototype, and as a developer applying code and framework to existing or non-existing designer assets.
A recent new project at my job prompted me to learn and begin working with your Silverlight products and platform. Here are my notes, some suffering points, some compliments, and overall suggestions for how to improve your relatively new process for building RIAs.
1. What’s with the extremely long install process? Why is it that in order to install Visual Studio, I had to download an .iso (not an .exe like most installable software), then burn it on to a write-able DVD, then install it? Is this a process that your existing customers have told you they enjoy? Even after the download and burn, which took several hours at Fios speed, the install process took nearly 3 hours by itself. That’s right. To install Visual Studio 2008 SP1 on Vista, it took way too long. [Visual Studio 2010 beta took even longer.]
2. After figuring out what Silverlight SDKs and toolkits I needed, and where to find them, I downloaded and installed each of them — another very long process. Upon launching VS 2008 and going to start a new Silverlight project, I was hit with a deadly show stopper. VS 2008 would prompt an error “Object reference not set to an instance of an object” and then crash.. each and every time. Now, I posed this issue to several of my “.Net expert” colleagues, and each assumed I was missing some aspect of the Silverlight SDK/Toolkit install process. Turns out I was not. After searching (via Google) for the error, I found a helpful hint on a random blog (GeekswithBlogs.net) which gave me instructions to run something from the command prompt (devenv /resetskippkgs). After restarting Visual Studio 2008, this did the trick. Thankfully, and unfortunately, the issue covers Siverlight 2, although I experienced it working with Silverlight 3 as well. Now, this seemingly undocumented/unofficial ‘fix’ was very hard to find, so I was left wondering if these are things the experienced C#, VS or Silverlight developer just knows…
3. This next one I can’t fault you on, but it was confusing to me nonetheless. Working with Dlls was very awkward to me. The concept that I need to not just import (using…) a namespace/class library, but literally install an ‘assembly’ into my project seemed a bit strange to me. This process seems somewhat close to working with SWCs, but just a little beyond the bubble of what made sense to me. As a lifelong PC user, Dlls were always those library files that accompanied .exe’s when installing software on the PC. Now using them to add features, framework and tools to my project just seemed rather extensive. I realize this is a longtime standard practice, but for the newbie, was hard to wrap my head around initially. Perhaps some more documentation and examples on the what and why of this process would have helped.
4. I found out the hard way that the ‘Toolbox’ in Visual Studio 2008 (and 2010) is useless. It just doesn’t do anything for me. Sure, I like all my available tools and Controls listed, but what good is dragging and dropping tools into my code if they don’t come with some initial properties for display, event handlers or other functionality? VS assumes I know how to work with the Control, which is far from the case. Furthermore, there seems to be no publicized Control browser/view, which helps me explore properties of the Control/tool, how to customize it, etc.
5. Along the same lines, I found out the hard way that the Silverlight authoring flow changed in the middle of my projects. When I first installed VS 2008 (and 2010), inline Design view was part of the workflow. Just like FlashBuilder (in Eclipse), I could toggle between code/source view and Design view, if only to validate that my app’s layout was right on. Aside from never really understanding nor getting the Design view in VS to work, it seems that option is now all together eliminated. Now, I must simultaneously run Expression Blend to work on my layout and validate in Design view. Why can’t I do this in the same IDE? Were folks complaining about performance or having too capable a single authoring environment?
5. Again, along these lines, the whole code behind thing was not new to me, but took a while to get used to in your environment. It just seems that having two classes, one for layout and one for code is a bit arbitrary, especially for simple applications and examples. This necessity, which I’m assuming goes back in time way before Silverlight, seems to add further dependency on the need to work with both Expression Blend and Visual Studio to get things done right. Now I realize that in the big firm, you may see it as design being done with one tool and code being done/added with another tool. But, for the one man band that is me, in this case, having two apps open, worse yet, THE SAME PROJECT open in two apps, is a very weird workflow. I had to get used to seeing “this file has changed in another application” way too much.
6. I got caught in the void between Silverlight 2 and 3. Looking for books and references online, it seems there is way more written and blogged about SL2. Yet, your site and everyone in your community tells me SL3 is now the defacto way to build SL applications. Why is there such a lag with getting new examples for SL3? I’m surprised that all those early adopters who put out SL2 examples are so behind in updating those to SL3. It’s hard for me to tell which SL2 examples to ‘trust’, not knowing really what does/doesn’t translate from SL2 to SL3.
7. One thing I like about working with Visual Studio is the ability to launch multiple instances of the app. With two screens, which I truly hope the average MSFT developer has, it makes it easy to compare code from multiple projects by viewing both at the same time.
8. Another thing I like is the debug environment inherent in Visual Studio. Breakpoints are easy to work with and the stack dump is very easy to navigate when trying to figure out how to parse XML/JSON for the first time. It’s too bad that the IDE locks up (for me, anyway) when I’m in debug mode and that, upon stopping the debug process, I lose this stack as a reference when I’m further coding my app. Something tells me that there’s a way to sustain this view after debugging, but I haven’t figured it out yet.
10. While I have issues with the separation of Expression Blend functionality from Visual Studio, I do think it’s a very tightly designed product. The interface to toggle control layout, size, color, etc, is very clean and intuitive. It responds well, and generally, what I see in the IDE is what I get in the browser.
In closing, I realize that much of my issues may be a result of my not being a seasoned Microsoft and/or C# developer. Perhaps those familiar with your workflow and tools can find their way in and out of these shotgun issues much easier. I consider this, but then realize, aren’t you going after developers just like me? Aren’t you looking to give me a broader choice of tools and platform when I need to deploy a rich application?
Perhaps my situation is a bit different. As a platform evangelist, I’m not really evaluating your product, nor am I choosing what’s best, for my customers. Thankfully, for your case and mine, my customer , in this instance, is already your customer. In other words, we’re deploying a new SDK for your existing developers, so I’ve got to figure out not only how to develop in the Silverlight environment, but figure out best how our service fits in from both a practical and instructional perspective.
In closing, I hope what I wrote here helps you make your product better for your existing and future users. Don’t dumb things down on my account, but understand that not everyone installing (rather, waiting for the install process to complete so they can use) your tools knows them well enough to get themselves in and out of your workflow with ease. Lower the barrier of entry and you may appeal to, and more importantly, enable, a lot more folks. This may be hard for you, seeing as your existing and historic developer contingent has already adapted to what I think is a very hardcore centered developer process. Creative people need free flowing tools to put their ideas in motion. They need to express themselves in their own why, so you may not be able to ‘blend’ it easily with what you already have.