March 29th, 2010
Restarting with Silverlight 4.
Sometimes, you just have to throw it all away.
After we launched [rssTunes], we went right back into the labs and started working on something new. We don’t want to give too much away – because, hey, secrecy works for Apple, right? – but needless to say, our next big Silverlight project was a monster. Multiple external APIs, over 50 screens, lots of classes, calls, etc.
We designed the application in our heads before we’d really gotten to know Silverlight, what it could do, and how easy it was to get it to do things it didn’t know it could do. We had an expectation of functionality, and though we did the actual design after three separate Silverlight projects, we were working backwards.
Our biggest mistake, and a source of constant frustration for me as a developer whose job it is to work around dumb design mistakes, was assuming Silverlight 3 would “just work” with external APIs. Turns out, it’s really hard.
Security sandboxes exist for a reason, but they’re a nuisance. Personally, I’d prefer if Silverlight/Flash etc. just used their own internal connection to web servers, instead of sharing the browsers. Without sharing the browser’s cookies, cross domain security issues would be removed, and, as a developer, I could do a good deal more inside of Silverlight.
As it was, we had to engineer this massive infrastructure to handle the proxy of possibly millions of requests to other servers we didn’t control, which caused a few hiccups a few of you might have noticed, and had to design parts of the UI to deal with possible errors from delays, encoding, API passthrough issues, etc. We’d made our lives hard.
Then at MIX 2010, Microsoft announced Silverlight 4 (officially), and I began really reading the release notes.
An inline WebBrowser control that would remove our need for at least eight whole sections of overly complicated, didn’t work yet, XAML.
The removal of the security sandbox for desktop only applications, removing whole swathes of caching infrastructure, and entire bits of code dedicated to error handling, plus the related screens.
Improved list boxes, which removed UI workarounds we’d designed to make the UI “feel” more desktop like.
The list kept piling up in my head.
Finally, last week, we made the call. We were going to abandon two months worth of development, and just start fresh. Redesign what we had to utilize the new features of Silverlight 4, destroy our infrastructure worries and just get it right.
New deadlines, new designs, new code.
This is gonna be fun.