Beta 2 Sneak Preview of the New Visuals for the Distributed System Designers
Okay, I think it’s time we show you guys a preview what our designers will look like in Beta 2. We’ve had Jesse, our User Experience guru, revamp them completely and he’s done a great job prettying them up considerably from Beta 1. Jesse and Bill Gibson, my feature team lead, have given almost all the colors, shapes, and drop shadows some sort of semantic significance.
As for the colors, I have to honestly say that I would have picked them differently. Being color blind, all I know is that WindowsApplication and the GenericApplication applications appear to have the same color, even though everyone’s told me otherwise. Let me know if they look the same to you too! J
In the following images I’ve zoomed into the designers so that the visuals show up clearly. Therefore, they will in appear slightly smaller in the product itself.
Furthermore, the application that I have used to display the new visuals are in no way indicative of how an applications and datacenters should be built/structured using our designers. I’ve just dragged and dropped several applications, application hosts, etc so that you guys have an idea of how they will look in Beta 2 and most probably going forward in V1. I am not trying to give any guidance on how these applications/datacenters should be created in this post.
I’m also not going into detail about the functionality of these designers. That information can be found in the following article: https://msdn.microsoft.com/msdnmag/issues/04/07/whitehorse/default.aspx.
Warning: I wanted you to see the details of diagram so the images are quite big.
Application Designer (AD)
This is the puppy that I spend the most time working on. The first change you’ll notice is that we have changed the name of the designer, from Application Connection Designer (Beta 1) to Application Designer. This is because we received comments from customers along the lines: “In addition, since you can do [or rather "will be able to do"] many more things than configure connections I suggest the term connection be removed entirely”. The reason that we had originally decided to go with the Application Connection Designer was because we thought that the name Application Designer was more adequate for the designer of a single application. Therefore, going with Application Connection Designer gave us the room to later create an Application Designer which was the drill down view of an application. We later rethought the issue and decided that it was okay to have different scopes for the Application Designer if we ever decided to do the drill down version of the Application Designer.
Note:
- The toolbar can be used as an index to identify the new shapes
- The provider endpoints on the Application Designer are filled. Unfilled endpoints are consumer endpoints.
- The exclamation mark in the Storefront’s Web service consumer endpoints is there to indicate that the consumer endpoint is not implemented even though the Storefont application is. This is because the provider endpoints the consumer endpoints are connected to (OrderService and CatalogService) are not implemented yet.
- There is a new type of endpoint called the Web Content Endpoint. A web content endpoint tells us that this *webapplication* exposes content that is addressable through an http endpoint. (I’ll cover this in more detail in another blog)
- The generic application on the diagram represents a way of documenting a legacy system directly on the Application Designer.
- Also, please notice that we’ve changed the name of the EDW to the Web Service Details Window. This was done because the Web Service Detail window will be used exclusively in V1 to define the operations for the Web Service provider endpoints.
- In the Web Service Details Window we’ve also changed the icons of the operations. This is because the earlier icons were similar to those used by the class designer’s details window to indicate methods. This was causing users to believe that the Web Service Details window is where they would enter methods as opposed to operations. (I’ll cover this in detail in another blog
System Designer (SD)
The System Designer is where the user can created application systems that he wants to deploy onto his logical datacenter. You do *not* need to go through this designer to create a deployment and you can directly ‘Define Deployment’ from the Application Designer. Doing so will result in a default system being created with all the application definitions in the Application Designer so that you can define a deployment definition in the Deployment Designer without having to go through the process of creating a system first.
I’ve created a AdventureWorksSystem that contains several application definition uses and nested systems (CatalogSystem, OrderSystem, InventorySystem). The user can drag and drop uses of the application definitions (defined in the Application Designer) and systems created earlier (in the solution) onto the System designer to place them into the current system.
Logical Datacenter Designer (LDD)
The coolest thing about the visual changes in the LDD is that I can now tell you immediately what direction the Zone endpoints flow is (Inbound, Outbound, and Bi-directional).The color of the datacenter’s logical hosts also match those of application definitions that can be deployed on them .
Deployment Designer (DD)
We’ve given better guidance to the user about how to bind application definition uses by dragging and dropping them from the System view onto the Deployment Designer.
There’s a lot that I haven’t covered in this post because I wanted to avoid writing an overwhelming blog. Let me know if there are any areas that you would like me to discuss in more detail…
Cheers
Comments
- Anonymous
January 11, 2005
The window tabs are very OneNote-ish... coincidence? - Anonymous
January 11, 2005
The comment has been removed - Anonymous
January 11, 2005
Hmmm... interesting ... I didn't know this but evidently they are based on OneNote.
I pinged one of our lead product designers (Janet)who said:
"Yes, it was . . . we looked at several styles for the document well (different from tool windows) and felt this was the most economical in the space and showed clear selection (overlap)." - Anonymous
January 11, 2005
DotNetJunkie:
Whoops... I removed my previous comment as I was mistaken.
AD: There is no reason for why the icons/text are not vertically aligned. There was additional work required to vertically align them and we decided that we'd spend the resources on other more pressing issues.
SD:
In the System Diagram you can create multiple uses of an Application Definition created in the AD. A user might want to do this if he wants to reuse the application multiple times with different configuration settings (set in the Setting and Constraint Editor).
Each use of the Application Definition has to have a unique name. By default, the first Application Definition's use name is the Application Definition name.
When the Application Definition's use name is different from the Application Definition name, the Application Definition's use name appears on the top and the Applications Definition's name appears in that space you have an objection with.
Have I lost you yet?
See: http://a_pasha.members.winisp.net/images/MultipleUses.jpg - Anonymous
January 12, 2005
If I remember correctly, earlier in our product cycle the space was intended to be used as an icon "channel" to display the attributes of the app/system that has since been descoped for v1. However, work was not done at least for Beta 2 to fix general alignment issues as the team needed to focus on issues of higher priority/severity.
I do agree w dotnetjunkie that the alignments do look a little off in the screenshots so Ali look for some fit & finish bugs to come your way the next few days ;)
Quick comment on the new visuals: The key areas that we wanted to address with the redesign, apart from prettification, is to help convey or reinforce the abstract concepts behind the diagrams, as well as to ensure a sense of visual cohesion between the elements within each diagram, between the 4 diagrams as well within their IDE shell. Lastly, we also put a bit of thought into how these visuals may scale out in v2 as we support more abstract types as well as functionality such as user color-customization. The Beta 1 visuals I thought, suffered from over-stylization & almost arbitrary color choices, resulting in screen clutter & thereby impaired the function of the tool. To that end we eliminated the visual elements that had no semantic significance, simplified our color pallette but also made the shape-to-shape distiction color-agnostic, so that users wouldn't have to rely on color alone to distinguish between types. In terms of personal aesthetics, I'm in the "less is more" camp, so I was very selective (perhaps to a fault) in terms of what elements we chose to emphasize visually.
I'm no "guru" by any means so any feedback on the new visuals would be much appreciated!
And thanks Ali for fowarding me your blog :) - Anonymous
January 13, 2005
As Ali says, there was a lot of careful consideration given to just about every aspect of all the diagrams' look and feel. (Not to say we've necessarily got it right!) Ali's response and linked diagram explain why the space was reserved on application shapes. We determined that a common layout on all the diagrams was more effective than changing the application shape structure between the AD and SD. We considered a few issues:
We didn't want the vertical position of text and icons moving when you add a usage name on the SD. We wanted horizontally aligned application shapes to continue to have aligned content regardless of the presence/absence of the use name.
We wanted to preserve the layout between the AD and the SD so that when you select a group of shapes on the AD and use these to create a system, the usage shapes created on the SD would have the exact same sizes and layout.
We were also considering supporting systems expanded in-situ on both the AD and the SD. This would further stress the need for common geometry between both diagrams.
We were developing common implementation classes that would let us build all the diagrams in the most cost effective and robust way. The same base classes underlie all the SDM-based designers in VS2005.
And having said all this, we're certainly open to reviewing this kind of detail although we have our hands full with more substantive issues right now!
And to Jesse's comments regarding the glyph channel, that lies below the type name and you will see it in action in beta 2 builds when a validation error occurs or if the application diagram and objects on it become locked after a parse error occurs. I'd like to see us use the glyph channel to give additional implementation feedback to users, for example to provide a language cue.
