When it comes to designing applications it’s definitely a lot easier when you can visualize what you’re creating without actually running the solution.
So why should it be any different for Silverlight and WPF?
If you just want to know how you can populate controls during design time the links below show three (of the many) ways you can populate your pages, windows, user controls, grids etc with sample data in Expression Blend or Visual Studio.
One of the problems with prototyping tools like SketchFlow is they can sometimes leave your client with the impression that all the work is done the and product is in some way releasable or production ready.
Now I’m not saying nothing can be shared between the two solutions (e.g. resources) because that depends on the design and project you are working on.
What is clear however are the aims and mindsets used to create a SketchFlow prototype are different from how you would go about creating a real world production solution.
From a design perspective the layout of controls in SketchFlow are done using a single grid and their margin property. In a real world application you would pay more consideration into the layout of the design and think about things like how the page would scale.
From a developer perspective a SketchFlow prototype doesn’t easily lend itself to good development practices such as SOLID design principles, code reusability and testing.
And in any case would you really deploy files called something like Screen_1.xaml to a production server?
Even if these things don’t matter to you, I still don’t recommend using Microsoft’s solution because
there are still references to the Microsoft.Expression.Protyping libraries in a supposedly production ready solution. Having libraries in your application that you not sure are being used before you launch will only get worse as time goes on.
Microsoft’s solution is not 100% successful, lots of people are having problems with navigation not working properly.
So what should I do?
Focus on creating designs that satisfy the customers’ requirements and not about the final design. You can think what resources could be reused later in the prototyping cycle.
Deliver prototypes to your customers early and often. This will allow your customer to give feedback early so you can inspect and adapt.
Keep your screen designs simple and lightweight so changes can be done quickly and with the knowledge that you won’t be breaking anything.
Keep an eye on how many events and behaviors are used on a control or screen. It’s too easy to get carried away remember it’s only supposed to be a prototype.
Take advantage of the sample data resources available and not bind to databases or web services.
Keep code behind to a minimum, ideally having none at all.
Jag Reehal’s Final Thought on ‘Converting a SketchFlow Prototype into a Production Application’
I can understand why people are looking for a solution where they can use a prototype and a production application interchangeably because like documentation prototypes can easily get out of date and no longer reflect the design used in the production version. Unfortunately the only answer is to adhere to good practices and always start by prototyping and not by retrospectively making your prototype match your production design.
Prototypes are extremely useful… as prototypes and nothing more!
Have fun using SketchFlow I love it, and it’s definitely my prototyping tool of choice.
This weekend I attended barcamb3 in Cambridge, UK.
I really liked the event.
Around eighty people with different interests and backgrounds attended the event and this is what made it work so well.
The .Net events I attend and enjoy in Cambridge are good but you don’t get start ups that are passionate about what they are doing, or hearing about the problems they have had to overcome and what they hope to achieve.
The mix of attendees also meant that the talks on the day covered a variety of topics from abusing social media sites like Facebook/Twitter to get more traffic to talks about geo location. Not everyone was a developer so there were good discussions which weren’t about programming such as how paperless could we become.
There was also a talk on TDD. I learned that developers going for a job at the Guardian newspaper have to take part in a TDD exercise as part of their interview process! As soon as the presenters mentioned pair programming, it became the main topic. Having written a blog post called ‘Pair Programming Is Not a Silver Bullet’ it was reassuring to hear other developers experiences were the same as mine… both good and bad!
My talk about developing prototypes with SketchFlow
I did a talk about using Expression Blend and SketchFlow for developing prototypes covering topics such as
Lo-fidelity vs high-fidelity prototypes
Advantages over other prototyping tools such as Visio and Balsamiq
The Visual State Manager
Converting a SketchFlow prototype into a real world app
Alfred – Mac App of the year 2010?
One of reasons I make an effort to attend events such as these is to get inspiration from other developers.
I talked to so many people over the weekend and found out some interesting information about developing sites that streamed music, search applications and content management solutions.
But without a doubt the most innovative and interesting was Alfred, an application for the Mac.
How did I find out about it? By just saying hi to Andrew Pepperrell. We got talking about each other do, then he grabbed a Mac and showed the application to me.
If you have a Mac get this application now! Calling it a quick launch application doesn’t do it any justice. If I knew how I would develop a Windows version because it’s so good.
I’m really happy for Andrew because he has dedicated so much of his own time developing an application which is getting positive feedback from the IT community around the world.
I would like to thank all them who organised this fantastic event and am really looking forward to barcamb4!