WPF leave to the developers the freedom to realize appealing user interfaces that support an alternative interaction model not tied to the old windows controls. The benefits for the end user are countless, more productivity, easier interaction, information “find-ability”, and so on…

But what happens most of the times?

As soon as a new developer opens Visual Studio he asks: “Where’s the DataGrid?”

Why?? Is it possible that the only way that a developer knows to show some data on the screen is to put it in a grid?

I developed a bunch of WPF applications and only in one case I used the DataGrid, I always used ListBoxes, ItemControls, StackPanles….using a template to customize their appearance to show the most important information and to give the user the ability to drill down into the details when needed.

So, please, please, with WPF we have the power in our keyboard don’t use datagrids to show your data, think about your user!

The web is full of examples that don’t use the DataGrid (Google and Amazon for example) so don’t be lazy, take time to design a better user interface!

* No datagrid was used to write this post

Years ago, for me, was a must that the develop of new application begin from the database and over there I design the DAL and up till the user interface. For this reason the firsts days was dedicated to the design of the database. What I got was an application based on “Transaction Script” or “Table Data Gateway” with their pros and cons.
At that time the database was the most important thing in my applications.

The problem with bottom-up approach is that it takes you to create a myriad of “micro-methods” that makes very tedious developing other layers above DAL. The classic “error” is to create all the CRUD operation for every tables in database, discovering later that a lot of them are useless or that they force the other layers to know the database structure (for example they need to know the right insert order to not break the foreign constraints).
The other smell was that the design of my application was not very Object Oriented, the only thing that I used was a little bit of inheritance in the DAL to reuse some code dedicated to manage the database connection.

In 2003 i read a book that change the life to a lot of developer “patterns of enterprise architecture”.

After having read it I understand that something in my approach to  design application should be improved: I discovered the Domain Model.
Then I begin to think at my applications starting from Domain Model and once the DM was ready I start with Database and User Interface at the same time.

Now I’m in a transition period and I feel to start my applications from User Interface. I know that the UI is for the final user the most important thing of the application (stated that it works), not from a aesthetics point of view rather from an interaction and usability point of view and the way the data is displayed on the forms.
The first thing I do is to design (on paper) the mockup of the UI thinking about the interaction work-flow and the data that should be displayed. From the interface I go down to the Domain Model and then the Database.

The problem with starting from Domain Model is that your User Interface design is often binded to it and is not free to achieve the user’s needs. So starting from UI is a natural way to obtain what the customer really want, maximizing the usability and the fruibility of information.

This is not a proofed methodology for me, I’m trying this way in these months. For now I can certainly say that the mockup on paper likes a lot because the user can easily try to imaging how the interaction with the software will be and he can modify the stories of writes a new one. The Domain model grow in a more natural way guided from the functionality to implement.

Does this state that the DM and DM are less important? Absolutely not, but the user don’t bother them.