Visual Designers Don’t Scale

Tuesday, May 20, 2008

Microsoft has a long history of being visual. They've made quite a bit of money implementing graphical user interfaces everywhere – from operating system products to database servers, and of course, developer products. What would Visual Studio be if it wasn't visual?

And oh how visual it is! Visual Studio includes a potpourri of visualization tools. There are class diagrams, form designers, data designers, server explorers, schema designers, and more. I want to classify all these visual tools into one of two categories. The first category includes all the visual tools that build user interfaces – the WinForms and WebForms designers, for instance. The second category includes everything else.

Visual tools that fall into the first category, the UI builders, are special because they never need to scale. Nobody is building a Windows app for 5,000 x 5,000 pixel screens. Nobody is building web forms with 5,000 textbox controls. At least I hope not. You can get a pretty good sense of when you are going to overwhelm a user just by looking at the designer screen.

Visual tools that fall into the second category have to cover a wide range of scenarios, and they need to scale. I stumbled across an 8-year-old technical report today entitled "Visual Scalability". The report defines visual scalability as the "capability of visualization tools to display large data sets". Although this report has demographics data in mind, you can also think of large data sets as databases with a large number of tables, or libraries with a large number of classes - these are the datasets that Visual Studio works with, and as the datasets grow, the tools fall down.

Here is an excerpt of a screenshot for an Analysis Services project I had to work with recently:

Here is an excerpt of an Entity Data model screenshot I fiddled with for a medical database:

These are just two samples where the visual tools don't scale and inflict pain. They are difficult to navigate, and impossible to search. The layout algorithms don't function well on these large datasets, and number of mouse clicks required to make simple changes is astronomical. The best you can do is jump into the gnarly XML that hides behind the visual representation.

I'm wondering if the future will see a reversal in the number of visual tools trying to enter our development workflow. Perhaps textual representations, like DSLs in IronRuby, will be the trick.


Comments
Brett Morgan Tuesday, May 20, 2008
You've hit the reason why graphical programming languages never work out. It's a question of informational density. And above a certain level of density, diagrams turn into soup.

The important thing that is missing is abstraction. The biggest advances in mathematics were always predicated on an abstraction of the underlying information.
Frans Bouma Tuesday, May 20, 2008
Indeed!

It's already a pain with AdventureWorks in the entity framework designer... and that only contains 90 or so entities.

There's a way to do it though, (graphically, or combined with text if preferred), I'll show you in a couple of months :)
Mike Tuesday, May 20, 2008
+ 2^18

I've recently being trying to visualize an extremely large database schema and some meta information as o queries executed against it.

If I try to include the entire database in the output image it results in a 140000 x 10000 pixel image. Its spit out in SVG though so its not much an issue except for the fact that the diagram is utterly useless.

I've found that you can increase the visual density by making some aspects multi-dimensional by using colour, line widths and different shapes to represent certain attributes but it'll only take you so far.

I've resorted to a piecemeal interactive approach which is basically a flash based explorer for the data as the only way I found to scale it was to break it in to smaller chunks.
scott Tuesday, May 20, 2008
Frans:

Looking forward to what you to show in a couple months.

Jon Tuesday, May 20, 2008
Visual designers are still helpful, if it uses a layer of abstraction that is appropriate for the amount of information it is trying to display. I think the ultimate would be some kind of "deep zoom" capability for a visual designer that traverses the different layers of abstraction. The farther out you are, the more abstract (assuming there is an abstraction that makes sense). As you zoom out, for a database, it might do something like group like database tables (e.g. customer information, purchasing details, products, etc.) in a more logical organization of the database. When you drill in, it will get more granular and show more information (e.g. showing table relationships and then the fields).

Then again...this may just be another one of those really cool demos that doesn't have much practicle value. ;-)
scott Tuesday, May 20, 2008
@Jon - I think there is some value there. The current method of scrolling and zooming is very cumbersome. If you could combine some sort of layering with an intuitive zoom and scroll, we might be in better shape. A search or find option would also be helpful.
yipyip Tuesday, May 20, 2008
Search is key. There's a reason why Google won out over everyone else back in the day.

No amount of zoomable UI goodness will make up for a lack of search.

I think the the techniques are highly complementary, though.
Steve F Tuesday, May 20, 2008
There are scalable visual designers out there, look at the popular DB modeling tools like ERWin or ERStudio which allow you to break things down into submodels very easily.

I use ERStudio personally and I have used it on very large models (>300 conceptual entities), as long as you segment things into submodels it is very usable. I would argue much more usable than a text based model in this kind of scenario.

That said, a poorly thought out visual designer (ie all of the microsoft ones I have ever seen) does not scale very far at all.
Clinton Gallagher Tuesday, May 20, 2008
Actually, as an architect I have to chuckle a bit because it is in fact when developers start using the right tool for the job 5,000 x 5,000 pixel displays will become common (as they already are when used by architects). Productivity will soar when you adopt the use of multiple monitors and ultra high resolution as it has for architects who have the background in CAD with years of experience working with dozens and dozens of detailed diagrams as KSA depicted using the medical database as the example.

Granted, the Visual Designers must continue to be improved. I can't help but think this will occur when WPF is integrated into Visual Studio but when is the real question ainna?

Then you guys who started with line by line programming and are now moving to the other end of the visual spectrum can meet up with us who started on the visual end of the spectrum and are now writing code.

Its somewhere in that middle --common-- ground we'll meet up but that's where we are headed. So again, who knows how long it will take Microsoft to build modern tooling to support what we architects are already capable of? Visual Designers will be developed using WPF of this I am quite confident as its 3D that will bring you flatworld programmers into the real world of objects and their logical representations.
Bunter Wednesday, May 21, 2008
As you don't need to see 100 code files at the same time, you rarely need to see 100 classes/tables/whatever at the same time. It is just the question of additional layer above diagrams to keep things organized. Lot of tools seem to have developers who ran out of steam while it came to "organizational visualizing".
Federico Friday, May 23, 2008
Interaction is the key: Google maps scales pretty good. Although 3D is the perfect solution, interactive 2D has already proven to be a huge success. They basically designed a map of the world. You can't scale more than that :)
Casper Bang Friday, May 23, 2008
Ehh, I get your message but I don't agree.
First of all, your data model example proves nothing. I see few interrelations, you should decompose it into smaller contextual chunks.

Just because our tools (hardware and software) displays trouble scaling, that's not necessarily an indication of doing something wrong.

The fact of the matter is that a picture paints a thousands words and convey an awful lot of information we humans are quite capable of recognizing and processing rapidly.

Problem domains have increased in complexity, I am sure we will find ways to work with them visually. Have a look at the MyLyn plugin for Eclipse (http://www.eclipse.org/mylyn/) or the amazing PhotoSynth work (http://youtube.com/watch?v=lkuGrCB85H8) if you feel like you need to get visually inspired - which it sounds like you do. ;)
Scott Allen Friday, May 23, 2008
Perhaps I should say that the way the designer tools in Visual Studio are implemented inflicts pain. There are visual UIs that can scale well, and perhaps some software designers, but I think we always go back to a textual format for software of any complexity.
Liviu Uba Saturday, May 24, 2008
I think Microsoft went on a shiny but wrong way with this designers. Even the LINQ designer suffer conceptually the same problem.

What is so hard to have an addin that shows you all the relations visually, but you specify the relations using attributes directly in code?

I wrote myself a tiny orm that is based solely on attributes, and i use an addin to visualize and manage relations. I use a searchable treeview for showing that information, no big graphs that layout silly automatically.
I do not have any problems with Source Control.

Why cannot Microsoft think simple?
Thanks for your comment!
tc Saturday, May 24, 2008
So you've got a tool that's difficult to use, has poor search features (no isearch?), has poor algorithms, and poor/no keyboard support. But instead of blaming the tool for these lacking features, you're blaming the entire *style* of program?

Perhaps it's just that Microsoft's Visual-* tools don't scale. Wouldn't that be the logical conclusion here? I'm trying to think of another case where a Microsoft tool did poorly, and from that one could safely generalize to the entire rest of the industry, and I can't think of one.
scott Saturday, May 24, 2008
@tc: I primarily work with Visual Studio so its the only tool I feel comfortable commenting on.

I can think of a few area where Microsoft did poorly as well as the rest of the industry: artificial intelligence, voice recognition, and elimnating junk email.
Liviu Uba Sunday, May 25, 2008
I can think more areas where Microsoft did wrong in all its IDE Tools: Property Window. The Property Window is a monstrosity, it is not searchable, it lists tens till hundreds of properties but has no concept of what is important and what is not, what is more used and what is rare used. There is no link between appearance and property. I would like to be able to click on the grid line and set grid line width and not to search for this property in hundreds of items. Microsoft is not promoting usability even with its own visual controls.
aRBee Tuesday, May 27, 2008
Hmmm... I don't see a table for the gross yearly production of tea in China in the diagram. Maybe I should read a bit more before commenting, but it seems like if you have that many tables in your problem domain, then you may need to re-architect a bit.
scott Tuesday, May 27, 2008
@aRBee: Healthcare information systems aren't exactly simple. If I could layer the view into sub-domains I would, but the tools won't let me.
smortensen Tuesday, May 27, 2008
I'd very much like to see support for different levels of detail in database diagrams. Aspects, themes, views or groups, call them what you like. Select some tables and specify what group/s (or attribute the classes, etc) the belong to and only show me the high level overview with the groups. eg VwUserManagement or VwNetworkProvisioning.
A simple double click to then drill down into that aspect so whilst i'm working on that aspect, that's all i have to see...
Comments are now closed.
by K. Scott Allen K.Scott Allen
My Pluralsight Courses
The Podcast!