it:ad:patterns:views_are_not_screens_strategy

IT:AD:Patterns:Views are not Screens Strategy

ASP.NET WebForms development, which has dominated the .NET web development landscape for over 10 years, has left it's mark – and vocabulary – on both developers and BA's.

This vocabulary is not consistent with performant UX/ design.

A Bit of History First

To understand why it has a cost, let's go back a bit.

Microsoft IT:AD:Patterns:MS Sells VS (not Good Practices) Strategy. Actually they are first and foremost, a vendor (IT:AD:Patterns:Vendors Suck Strategy).

At the turn of the century they dominated the developer landscape, with more developers knowing VB and WinForms than all other forms of development combined.

Then came the web. And people were moving off of COM+ to Perl, PHP, off of VBA to Javascript, and off of VB6 to Java for web development. For the first time in time immemorial, Microsoft was losing market share among developers.

The trouble was that the web was so different from winforms that for a long while, Microsoft/ didn't have a clue of how to reeducate their developers, without losing them.

And then Scott Guthrie came up with a framework that could save them the pain of doing so. By this, I mean save developers some pain, but most of all save Microsoft/ the pain of losing customers in the process: they came up with a framework that could emulate winforms as closely as possible using HTML/ and HTTP/.

Think of this for a second. One one hand, Microsoft/ stood to lose billions in terms of visual studio sales, market share, developer mindshare, etc….or … or force an emerging (1996) brand new continuous flow stateless server/client-side rendering –disruptive – technology, to emulate a WIMP/ windows framework from the 1970's.
It wasn't even a close call in terms of a business strategy, and the rest is history.

As the rest of the world – the non-MS developer crowd – moved forward with web development, AJAX/, SPA/, etc….the large enterprises that are Microsoft/'s bread and butter, stayed in this time warp.

By time warp, I mean that it was a genius duct-tape solution…except for one niggling (huge!) part…they couldn't easily modify their first version. So while the HTML protocol evolved, Microsoft/ had to fight hard to keep it from changing, so that it woudn't break their investment.

They were able to do so for about 12 years – until finally Google/ got big enough, broke ranks, made their own browser, and basically forced them to give up on offering only ASP.NET/…hence ASP.MVC/ which gives html control back to the developers (and more work unfortunately).

I'm not saying that WebForms didn't progress at all during the last 10 years – just that it progressed at a glacial pace compared to what other's could do with the web without ASP.NET in its way (nobody used the CSS rewriters, etc.).

MVC

Finally, an internal team at Microsoft broke rank, and developed MVC, and that's a different story.

Views and Screens

I've gotten a bit offtrack on that one…but the point is that ASP.NET was designed to post back to the server on every form submission. That meant that both developers and their BA's – by force of working so long in this way – developed a vocabulary of breaking down use cases into Screen Steps. Each little step of the workflow postbacks for a new page, that is rendered with a Header/Footer/etc.

And the delay between steps is considerable when working with ASP.NET due to browser has parse the header for determine what view engine to use, fire up an Html engine, go through all the css and js files, send off for them, render out the whole page, etc. It's slow.

It shouldn't be the case.

If you think of the steps as just View Fragments within a Screen – a sort of mosaic of elements that you can make appear, hide, slide left or right, you have a lot more flexibility in addressing where you are in the flow. User awareness means less error input, etc.

Also…it's no longer slow.

  • Most actions can be handled on the Client, without a server postback. Makes things much more zippy for the interim actions right up to the final submit.
    • ASP.NET/ WebForms sometimes can do some client side validation, but client side work is really not ASP.NET/'s forte, and always looks rather lame.
  • Information that needs to be posted back to the server almost never need a full page refresh. They just need to wipe out the square of the UI,and replace it with new text. Without the server having to recalculate the header/footer – just the pertinent “Thank you for your submission!” text, the response time becomes zippy, to the point that it almost feels like a client event.

New Vocabulary

It's for this reason that Screen is no longer sufficient to describe well the functionality desired by clients. Expand the vocabulary to talk about Screens that contains multiple Views, that may or may not contain Forms that contain Controls.

And btw – controls should not be “TextControl” to talk about numbers. A TextControl is also an abberation of ASP.NET/ … What we're talking about is an Integer input, a Currency input, (the business function) etc….and let the devs figure out how they will be forced to use an html text input to pull that off (a technical solution). In future versions of HTML/ there will be other inputs, at which point text inputs will be an incorrect term.

Conclusion

As Gareth said:

  • /home/skysigal/public_html/data/pages/it/ad/patterns/views_are_not_screens_strategy.txt
  • Last modified: 2023/11/04 03:29
  • by 127.0.0.1