I’ve been testing a few of the new features in Workflow Foundation 4.0 and getting to know the completely revamped Workflow Designer in Visual Studio 2010 beta 1. In a broad sense, I think it’s an improvement over the old designer in VS2005/8, but in the end I’m still far from happy with it. Here are some comments on what I like and don’t like:
What I like
- It’s hard to argue that the new designer isn’t a big improvement in the looks category. It sports a somewhat minimalistic view, making much less use of gradients and other bling that was common in its previous incarnation.
- The option to zoom in/out of the current workflow view is great. Not only is it useful, it’s very smooth as well.
- The mini-map rocks when navigating a large map, and I find it particularly useful when I’m working on a zoomed designer window:
- I like the breadcrumbs navigation list at the top-left of the designer as you dive deeper into nested activities. It could be a bit more visible, though.
- The variables and arguments windows are useful, and certainly the underlying concept is, in general, far more solid than the activity binding model supported in previous versions of the runtime.
- The new Flowchart workflows types, and it’s associated designer is, in my humble opinion, a massive improvement over the previous models. It feels a lot more natural to write flows like this and it’s a lot easier to organize the workflow visually into something that makes sense.
- There’s a Save As Image option in the designer popup menu that can be used to save a JPG file with an image of the workflow as it’s currently shown in the designer. It’s useful, though not thrilled that warnings/errors are rendered into the saved image.
What I don’t like
Unfortunately, this might very well be a far longer list:
The overall way of writing workflows through the designer remains extremely clunky, and it’s a pretty slow and awkward process. Maybe it’s just me, but I don’t find the overall experience very pleasant.
To start with, doing almost anything requires way too many clicks here and there. You find yourself constantly jumping between the workflow window, the variables window, the properties window and one or more popup tool windows to enter data and edit data.
To make things a bit worse, I find the lack of connections between all these to be somewhat unsettling, because no part of the process is oriented towards doing tasks but just small parts of tasks at a time. Because they are not connected across the entire process, I would find myself jumping back and forth between windows.
For example, let’s say I add a new activity and want to bind some data to one of it’s properties. When I go to the properties window and fire up the expression window, I realize I needed to move data from somewhere else and would like a workflow variable for that. So now I have to back out of the current spot, go back to the Variables window, add the variable, back to the properties window and into the expression window. Too many steps!
Another thing I’m not a big fan of is having activities provide lots of built-in editing windows right on the designer surface. For example, the InvokeMethod activity allows you to enter the expressions for Target Type, Target Object and Method Name right into the designer.
At first glance, this would seem like a good thing; after all, it saves you from a few trips to the properties window. But later, it becomes a bit more cumbersome, as it is data that you’re simply not interested in looking at the whole time. Also, most of the time the activity’s display surface will be too small to display entire values, so it’s not even that useful then.
Tool Windows
Tool Windows in the current beta are horrible to work with; they have very poor usability. I’m referring to windows such as the expression editor, the type selection window and so forth.
The first problem I ran into is that almost none of the popup windows are resizable. For most windows, this is really annoying, and what’s worse is that this includes the all around common Expression Editor window. Seriously, have we learned nothing from all the complaints around this from the BizTalk Orchestration designer?
For some windows, though, it gets even worse. Some windows, such as those that have grids, are not only not resizable by the user, but they also change size on their own. Drives me nuts!
A good example of this is the window that comes up when you try to edit the Parameters property of the InvokePowerShell activity: Initially, it contains just enough space to display a single row. After adding one row, the window resizes to show the original row and a blank new row, and keeps doing that as you add data to it. If you delete a row, the window becomes smaller again. There’s also no built-in scrolling at all, so if you need to add more rows than fit vertically on your screen, well, you’re hosed.
Another thing that gives a bad initial impression is that some windows react strangely to input from the user. For example, consider the Expression Editor Window. When it comes up, it has one size. Click on the actual text box to change the expression, and the window jumps around resizing itself twice (to end up with the initial size). Annoying.
To be fair to the Expression Editor window, user input isn’t always handled correctly in other places. For example, try to enter an expression for the default value of a new variable in the Variables window and try selecting the “All” button under the IntelliSense window when it pops up. Yep, it all goes away.
Here’s another that doesn’t make much sense to me: The Browse for Types window that comes up when selecting the type for a variable lists types by assembly, and inside each one ordered by type name, without consideration for namespaces. Yes, types are not grouped around namespaces at all.
Oh, and while we’re at it: All those new tool windows have nice and shiny white backgrounds all over the place. Considering plucking my eyes out as a workaround.
The Flowchart Designer
Flowcharts are (to me) the single most important feature in WF 4. They are a much nicer model to work with, I think. That said, the designer is not without faults:
- Connection points are too sensitive, making them hard to target and pinpoint accurately. Sometimes links just end up going where you don’t want them to.
- Arrows are too small, making it hard to grasp the flow at a glance (particularly when the view is zoomed out).
- The automatic routing of arrows is sometimes quirky (though I guess it’s OK).
- Sometimes selection isn’t handled correctly. Many times I’ve selected an arrow, seen it clearly rendered as selected, hit the Delete key only to find the entire workflow is deleted. At least Undo seems to work.
- I love that you can resize the flowchart designer area. I hate that you have to scroll all the way to the bottom right to do it.
Variable Scope
In WF 4.0, Variables are scoped to composite activities. That is, you can define a variable either on the top level workflow, or on a specific activity, like a Sequence or a CancellationScope already in the workflow.
Unfortunately, the way this is exposed at the designer level is incredibly clunky:
- The scope is not represented visually in the Variables window. Instead all you get is the Scope column in the variables list:
Even BizTalk 2004 got it right: It needs to be shown visually. Nested scopes are a tree, don’t try to represent it with a list; it doesn’t work. - The variable window will show / hide variables based on the scope. If you select a composite activity, it will only show variables declared at its scope and that of its ancestors. Variables defined in children of the activity are not included.
I understand it’s trying to be useful, but this just gets in the way. If you want to define or look at a variable defined 3 levels deep, then you get to first navigate all the workflow to get there just to be able to get the Variables window to show you the definition. Gah! - When adding a new variable, scope defaults to the activity currently selected in the designer. This almost makes sense, but if you decide that’s not right, well, surprise! Scopes shown in the drop down list for the Scope column follow the same rules as above. That means you can’t add a new variable in a scope without being physically nested within it (i.e. can’t add to a sibling activity). Annoying.
Conclusion
Many of the issues I’ve brought up here are basic usability problems, but many correctable. One can hope there’s still time in the Visual Studio 2010 timeframe to see some of those UX issues addressed.
I’m not very hopeful, though, about having a designer that’s really more pleasurable to use and that addresses the bigger issues related to the experience of creating and editing a workflow more conveniently and with less clicking, as those might very well require rethinking the entire process over. It’s really more of a conceptual issue than a technical issue, in a way.
Don’t get me wrong, the new designer is an improvement over the old one. Unfortunately, that’s all it is: An improvement. It provides an interesting foundation to address some of the technical shortcomings that the original Workflow Designer has, but it doesn’t really provide a more meaningful/powerfull way of designing workflows. In that sense, I do think it’s a bit of a missed opportunity.
