Share via

Wireframing in Silverlight 1.0

  • Article

firestarter_300 (2) If you are a designer working on a Silverlight 1.0 project, or if you are working with designers, check out the video by Arturo Toledo entitled "Workflow of Silverlight with Expression and Visual Studio from the recent "Silverlight 1.0 Fire Starter" event in the US.

Arturo talks about wireframing in Expression Blend and emphasises the importance of establishing a naming convention as early as possible.

Wireframes

Interaction designers typically create wireframes for user interfaces to represent the high-level interaction design - before visual design is applied. Typically, these wireframes are static, and created with drawing tools like Illustrator, Visio, OmniGraffle or even PowerPoint. Sometimes the wireframes are turned into click-through protoypes using tools like Axure, Intuitect or iRise.

One of the advantages of wireframing is that it allows interaction designers to test the usability of the user interface with real users before time is invested in coding, or visual design. Wireframes are also a great way to communicate the vision for a system to the wider project team.

Arturo talks about how to wireframe in Expression Blend. While Blend is not a prototyping tool per se, there are some advantages of wireframing in Blend, including:

  • You can wireframe dynamic elements, like transitions and animations
  • The wireframe can be handed off to visual designers and developers to start working on the visual treatment, and on hooking the user interface up to business logic and data.

Designer-Developer Workflow - the Reality

At Microsoft we talk a lot about the workflow advantages for developers and designers working together with Expression Studio and Visual Studio. At the end of the day, though, there has to be some glue that binds the designers work and the developers work together. That glue is the names that are given to the elements that make up the user interface, and to the event handlers that process user actions in code. For example, designers can change the way a login function is called, from a button to a menu item for example, and as long as the right event handler is called by the right name, the developer doesn't need to know there has been a change.

Naming Conventions

In Arturo's video, he emphasise the advantages of establish naming conventions for the elements and storyboards in the user interface as early as possible. That allows developers (and visual designers) to work independently as the interaction design, the visual design and the actual application logic evolve.

So in the video, Arturo locks down the names for all the elements early, even though he doesn't know yet how they are going to look or behave on-screen.

Now, in a perfect world those names will never change, and developers and designers will live happily ever after. Realistically though, some things will change. For example, usability testing inevitably reveals problems with the user interface, which may require functionality to change, or to distributed across pages in a different way. This is gonna annoy developers. It just is - just as it always has. The best you can hope for is to minimise this disruption (with up-front, broad wireframing and testing), and to manage any changes as smoothly as possible.

clip_image001A contract

In the video, Arturo shows a document which lists all the UI elements which the coder will need to interact with and their name and function. This is a good start, as it forms a kind of 'contract' between designers and developers, which will help manage changes over time.

This is good advice from Arturo.

If I had my way...

If I had my way, there would be a way to encapsulate this kind of design documentation inside the design file in Blend itself, to make it easier to work with, and to reduce the chances of it getting out of sync. (Let's face it, designers are lazy when it comes to this kind of detail.)

Even better, Blend would use that information to produce a specification document, like Axure, iRise and Intuitect do. Or, best of all, Blend would talk to Visual Studio Team Foundation thingy and try and keep track of how changes in the code or the UI might affect each other and help manage that process.

Silverlight 1.0 Firestarter

In the meantime, check out this and the other videos from the Fire Starter event.

Comments