Developer/Designer Workflow According To Me - Take 1

A question I keep running into when I speak about XAML-based application developer is how the developer/designer workflow should work. I don’t know if the question is common in general, or if it is because people feel that I’m not only passionate about coding, but also about design.

I have spent quite a lot of time thinking about how this workflow should work when working with XAML. In other technologies, I believe that the flow is much harder to get going, and I believe it requires more steps. In the “XAML world”, it should be a lot easier. The separation between functionality and design is pretty clear. And this separation should enable quite a well working flow.

Before I get into how I see it, I want to add a disclaimer… I have not been able to try this out in the real world as much as I would have liked. Mainly because I, in most cases, play all the roles. Or at least manage everything from XAML to code, with visuals coming from a designer.

Now, with that out of the way, I can get down to business. To be able to show how I see it working, I have decided to write this post based on the idea of building a Twitter client. As I don’t have time to sit and design a new client, that will never even be built, I have decided to use an existing client for the example in this post. It happens to bet the Twitter client I personally use, TweetDeck. I hope they don’t mind me using them as an example…

If you happen to be involved in developing TweetDeck and find that this blog post is out of line, just drop me a line and I will rewrite using another Twitter client…

The first step in building a new application is generally to sit down and talk to the client about what he or she wants. I suggest having several people involved in this.

There should be a person responsible for communicating with the client regarding project progress, as well as day to day management. Basically a project manager. The project manager will not necessarily be adding input to the discussion, but as the PM will handle communication with the client throughout the project, being there and hearing the talk might prove valuable later on.

I obviously want a senior designer there. He/she is responsible for talking about the user experience and finding out what the client wants out of the application. What functionality is needed, what feelings should it invoke, what does the client want to convey and so on. Possibly pulling out some personas and so on.

And finally I want the lead developer there as well. Yes…I want the lead developer to be there during that initial workshop as well. Preferably I want the lead dev at as many workshops and meetings as possible. He/she might have valuable feedback about feature that are easy to add, or that will cause issues or add extra development time.

After this meeting, or possible several meetings, the designer should be able to draw up wireframes. I personally love the tool Balsamiq for wireframes. But obviously, if you know how to use Sketchflow that would work just as well. It all depends on how much the client needs to decide. Balsamiq is static pictures, but conveys the basic layout and functionality. Sketchflow can do the same, but is aimed at an interactive experience that conveys more of the user experience with transitions etc.

For the Twitter client, the wireframes would probably turn out something like this

TweetDeck Mockup

And with some tweaks back and forth, the client signs off on the wireframes and gives the go ahead with building the application.

Ok…so it might no be that easy in the real world, but hey, this is a simple blog post about it. Use your imagination!

From this wireframe, the developer and designer, or possibly developer and “devigner”, can sit down and decide what functionality and data that needs to be used to build the application. This obviously turns into contracts for our viewmodels.

I use the word contract instead of interface as a lot of developers start seeing actual code interfaces… I am just saying that we can define what properties the VM needs to have.

Looking at the above wireframe, this is what I see

TweetDeck Main VM

Some form of “main” view model that has 5 ICommands for the buttons at the top, and 2 “column” view models that will hold the information for the Friends and Mentions columns.

However, I will not go for 2 column properties. This UI will need to add and remove columns, so it needs to be a collection.

So the finished VM might look something like this (pseudo code)

public class MainViewModel
public ObservableCollection<ColumnViewModel> Columns { get; }

public ICommand NewMessage { get; }
public ICommand AddColumn { get; }
public ICommand Refresh { get; }
public ICommand ViewSettings { get; }
public ICommand LogOut { get; }


Next I would have a look at the removed parts from the previous picture

TweetDeck Column VM

Which once again turns into to a new VM, called ColumnViewModel in the previous pseudo code. It needs a name, 3 ICommands for the 3 buttons, and a list of tweets. I also know that the list of tweets will change as new tweets come in, so it also needs to be an ObservableCollection<T>, turning the VM into something like this

public class ColumnViewModel
public string Name { get; }
public ObservableCollection<TweetViewModel> Tweets { get; }

public ICommand Filter { get; }
public ICommand ClearSeen { get; }
public ICommand ClearAll { get; }

Keep in mind that this code is written in Live Writer so there might be spelling mistakes and stuff… But you should get the general gist…

Finally, the last part of the puzzle is this

TweetDeck Tweet VM

Which gives me the last VM

public class TweetViewModel
public ImageViewModel Image { get; }
public string Username { get; }
public string Content { get; }
public DateTime TweetDate { get; }
public string Client { get; }

public ICommand AddToGroupOrList { get; }

The ImageViewModel is a “standard” viewmodel I use all the time. I have blogged about it several times previously. It basically encapsulates the download of the image, and exposes a progress property that enables the designer to build a progressbar and so on…

Now that this has been set, work can begin on building the application, and this is where it gets funky. As the designer goes of to do his visual design, which can take a while, the developer goes of and creates the application development solution. All in parallel…

The developer starts out by building quick and dirty design-time viewmodels. They are almost done with the pseudo code above. All we need are simple classes with hardcoded data. Just set up the classes in the constructor and you are fine. Nothing fancy…

Yes, you could also create this data in Blend using Blend’s design-time data support, but I actually prefer the quick and dirty custom VM way. That’s just the way I am…

The developer might also have to build some “behaviors” that the designer/devigner needs to use when doing the UI in Blend. In this case there are no fancy functionality that needs to be custom built.

He or she will then create the views that are needed, but just throwing them into the solution and adding the basic controls that are needed, which is simple Buttons and ListBoxes in this case. That way, the dev can hook up his VMs and make sure the work with an ugly looking UI. He or she will also make sure to hook up the design-time VMs using d:DataContext. This is not something that the designer might feel to confident doing…

Once this is done, and the solution is in source control, the dev can do on and start building services, dependency injection and real viewmodels. Basically geek-out doing things that we devs find interesting.

While the dev is doing his thing, the designer finishes off the design. In this case it turned into this


The cool thing now is that the designer, or his friend the devigner, can open up Blend and start working. Blend even has support for TFs integration, which is actually a great reason to use TFS.

I am not going to start a source control war, but what I want to say is that most designer find using Blend a stretch. Try getting them to use a source control system like GIT or SVN. You might as well forget it. TFS on the other hand is built into the tool, and pretty much hides the fact that it is there…

Anyhow…after the source is out of the source control, he/she can go on and change the control templates to look like they should according to the visual. And even do databinding to the design-time VMs, making sure that text flows properly and so on.

Unfortunately, the databinding dialog in Blend is crap compared to the one in VS2010, so I prefer the databinding in there instead.

This can, as mentioned before, go on in parallel to the developer coding up the functionality.

There will obviously be changes along the way that will cause the VMs to have to change and so on, but that is often easy to fix. This mostly happens when the designer starts doing the visuals and realize that it would be nice to have other data on the screen, or other functionality available. At that point, he/she can talk to the dev and explain the changes, and together they can either implement the changes, or decide that it is too hard/complicated/timeconsuming/expensive and skip it.

Once the designer is happy with a view, he/she checks it into source control. And once the dev is happy with his work, he checks it in. And in most cases, there won’t even be conflicts in source control as they are working on separate files. One is building UI, and one is building functionality. Just like it should be!

And at the end of the day/week/month/year you can check out the the whole solution and build it. And at run-time, the design-time VMs are ignored and the real VMs with the real functionality comes through and takes over and provides the UI with the correct data and functionality.

Yes, at the end of the day, this is a little utopian, but I still find it doable. it does demand some training and might be time-consuming at the start, but as soon as you get used to it, it should work. The tools are there, as well as the pattern and technology. You just need to invest the time to get it going and get some plumbing built. But the most important thing is to make sure that the designer/devigner/developer communicates throughout the process.

That is the way I see it… I would be happy to hear any thoughts!

PS: If you wonder what a “devigner” is, it is a person that is part designer and part developer. He/she sits “between” the developer and the designer and works mostly in Blend. Some people call it a interaction designer, but I find that being a different person with different abilities. I don’t really like the word “devigner” as it sounds a lot like divine, which has nothing to do with it…the person might be great at his/her job, but absolutely not divine.

Comments (2) -

Hi Chris,
nice to see your workflow matching in big parts our current workflow. We are doing WPF/Blend/TFS (& Scrum) as well and besides some annoying "XAML/Codebehind merge bugs" it feels very fluent.
I think your workflow is sort of ideal as there are always changes during development: Having all sorts of thoughts and requirements already done before development starts, even if its a must, is possible at small scale projects only. This forced us for a recode and extra devtime of three weeks this summer.
For me as a Sen. Designer, it worked best to start with paper sketches first. If needed I scan it for clickable paper prototypes, giving me a sort of timeline.
Now there is a break, because transfering SketchFlow-Prototype into our current App doesnt work. SketchFlow works fine as long as you aren't fiddle with frames, navigation and components, because this needs some coding effort and is has some buggy implementations. But our applications has frames, components and so on, so Im doing a rough protoype in XAML and gradually add styles until final GUI.
I dont think, that pure Grafic-Designer will ever be able to work in this enviroment, even if its intended by Microsoft, because GUI-Design is still so interweaved with programming, that you need coding skill to fully complete a GUI.
Or you have Devigner in between as you suggest.

Hi Frank!

It is great to hear some feedback. I know that it is far from painless to get this workflow going, but I think it should still be able to work. But as you say, it does often need some code-behind hacks or some scaffolding. but after a couple of projects, most of that should be ready and be possible to pull off the shelf...

As for SketchFlow, I love the idea, even if I haven't worked with it that much. I do however believe that it is a bit limited as you say, and I don't think you will use the XAML coming out of SketchFlow in you actual application. I think it probably needs to be thrown away and replaced by the real stuff, but it still has a place in the design cycle. At least depending on the client...

// Chris

Comments are closed